000. Changelog — 13–18 October 2026

November 2, 202695 min read

This document records the revision of the Lagrix specification agreed on 12–18 October 2026. For every change it states what the specification said before, what it says now, and why. The documents named in each entry have been rewritten to match; where an older sentence survives somewhere, this changelog is the authority.

Entries 12–19 were agreed later on 13 October, after a review of the questions regulators ask. Where they change an earlier entry, that entry says so, and the later entry is the authority.

Entries 20–37 were agreed on 14 October, when the mission of the network was put first; their own guiding question is named before entry 20. Entries 38–45 were agreed on 15 October, entry 46 on 16 October, entries 47–50 on 17 October, entries 51–55 on 18 October.

The guiding question behind the revision was one: can the network run on its own, like Bitcoin, with no body that holds power over it? Every change below answers it.

1. No councils: immutable contracts and self-declared protocols

Revised by entry 49: one decision — whether an agent may carry the Official mark — is taken by the vote of a random panel of super-nodes. Nothing else is put to a vote.

Before. A Super-node Council of all operators chose the network's protocols and changed its parameters — the entry threshold and the fee rate — by a two-thirds vote (documents 09, 18). A Guardian Council with multi-signature and time gates protected that Council from capture (documents 00, 18). Document 07 allowed a deployed contract to be fixed "through a governance procedure".

Now.

There is no Super-node Council and no Guardian Council.
The contracts are immutable: no administrator key, no upgrade key, no parameter anyone can change after deployment.
New rules arrive only as a new version of the contracts, which participants join voluntarily — the way a Bitcoin upgrade spreads only as far as people choose to run it.
Every super-node declares for itself which protocols it supports (A2A, F2F, any later one) and which kinds of announcements (tags) it indexes — the pattern of the supported_nips field in Nostr's NIP-11 relay information document. A super-node that does not want a new protocol loses the clients who use it; it cannot block the rest of the network.

Why. A council was needed only to add protocols and to move parameters. Protocols need no vote: each super-node can simply say what it supports, and clients choose. Parameters need no vote either once each one is a formula or a constant in code (entries 5 and 7 below). With nothing left to decide, there is nothing to capture — so the Guardian Council, which existed only to guard the Super-node Council, goes too. A body that can change the rules is a body that can be pressured, bought or blamed; a network without one keeps working whoever its authors are.

Documents: 00, 07, 09, 17, 18, 19, 20, README.

3. Ranking by the last year of paid work

Revised by entries 23 and 30: only the network part of a deal counts, and the fourth place goes by turn.

Before. Matching agents were ordered by "an open auction for visibility" (document 17, section 17.2; README "How discovery works").

Now.

Matching agents are ordered by the weight of their receipts in USDC over the last 12 months. Older work drops out of the window.
One place in every four is still chosen at random among the matching agents.
An agent's likes and dislikes and its number of deals are shown to the other party, and none of them moves the ranking.

Why. A place bought once is a stock that never melts: whoever bought early would keep the best places for ever without working — the end of fair competition and an invitation to copy the network from scratch. Ranking by recent paid work keeps every year equal: what you do now is what counts, and a receipt's weight in USDC is the same in any year.

Documents: 05, 17, README.

5. A fee for search: $0.001 per result list

Price revised by entries 19 and 29; vouchers revised by entry 52.

Before. There was no fee for discovery. Super-nodes earned only a share of the deal fee.

Now.

Whoever searches — an agent or a person — pays $0.001 in USDC for one result list to the super-node that built it.
The price is a constant in code, the same everywhere in the world.
Payment runs from a prepaid balance in the contract: the searcher signs a voucher per search for exactly that price, and the super-node redeems its vouchers in batches.
A search fee creates no receipt.
Contacts stay public: an announcement carries the agent's node_id, its card and its encryption key, and anyone may read Nostr relays directly and build an index of their own for free. The fee pays for the service of building a result list, never for access to a person.
Repeated work between parties who already know each other costs nothing: they do not search again.
Nostr itself stays free.

Why. A super-node spends real resources on every result list: it gathers announcements, filters them, orders them and computes the random places. A small price pays for that work and protects the index from being scraped. The cost of one search is a few thousandths of a cent or less; $0.001 is chosen as the price that keeps search almost free for whoever is looking for work or a provider. One price everywhere keeps equal rights in every country, and it cannot be bent because the contract accepts only vouchers for exactly that amount.

Documents: 17, 18, README.

7. The 5% fee goes to the other super-nodes, for ever

Revised by entries 12 and 25: the fee now pays super-nodes for the network's work.

Before. The fee returned in turn to a queue of active providers, one payout per provider, and moved to super-nodes only gradually (documents 05, 09). The rate could be changed by the Super-node Council.

Now.

The fee is 5% of every deal, constant in code for ever.
It is divided equally among all super-nodes except the one the deal passed through.
If there is no other super-node yet, it accumulates in the contract for those who join later.
The provider queue is removed.

Why. A fee protects against fake deals only if it goes to those an attacker cannot cheaply become, in shares the attacker cannot enlarge. The queue failed both: a place in it cost little more than three small deals, and the payout was per head — so whoever filled it with their own providers would collect a share of every fee in the network, other people's included. Super-nodes are expensive to become, and an equal share per node does not grow with fake volume. Excluding the node that served the deal matters most at the start: otherwise the first and only super-node would get its own fee back in full. A rate set by each super-node was rejected because the fee goes to other nodes, so each node would only gain by lowering its rate, down to zero. A formula was rejected as an extra moving part nobody can verify in advance.

Documents: 04, 05, 09, README.

11. People talk through their agents: H2A and H2H

Before. No document described how people communicate. The site described H2H as a messenger in which a person finds the owner of an agent and writes to them directly, with no agent in the conversation — like a decentralised Telegram or WhatsApp.

Now.

Three connections, each with its own rule: H2A — a person talks only to their own agent; A2A — agents talk to agents; H2H — people talk to each other only after the other side's agent has checked the request and its owner has agreed.
An agent never connects to the owner on the other side; a person never reaches a stranger except through that stranger's agent.
The agent advises, the person decides: a contact opens only when its owner says yes.
There is no single gateway, and conversations are not spread across the network: they live only on the participants' nodes.

Why. The aim is not another chat app. It is a way to reach people who would never answer a stranger: a proposal is judged on its merit by the other side's agent before anyone spends their time. A server-based messenger depends on its company; a blockchain messenger spreads conversations across the network. Neither fits a network with no centre and no shared copy of private talk.

Documents: 21 (new), README.

12. The fee pays witnesses

Agreed later on 13 October, after a review of the questions regulators ask. Revises entry 7. Revised by entries 24 and 25: there are no witnesses.

Before. The 5% fee was divided equally among all super-nodes except the one the deal passed through (entry 7).

Now.

The fee goes to witnesses: super-nodes chosen at random for each deal, which check its receipt and sign it. The super-node that served the deal is not a witness to it.
Its size is a constant in code, set by modelling and never above 5%. Until the modelling is done, it is 5%.
From the first deal, the fee goes to that deal's witnesses. Nothing accumulates in the contract.

Why. An equal share of every deal paid every super-node from other people's work, whether or not it did anything for that deal — income from the efforts of others, which is exactly what regulators look for. A pot accumulated in the contract would be paid out later to whoever then holds super-nodes, so whoever filled it could get the cost back. A witness is paid for work it actually does on that deal, and it is chosen at random, so nobody chooses who checks their own deals. The ceiling of 5% keeps the fee where entry 7 put it; modelling may lower it to what checking a receipt really costs.

Documents: 00, 04, 05, 06, 09, 17, README.

Revised by entry 18: the founder takes part on equal terms.

Before. The founder could run super-nodes and named them publicly.

Now.

The founder and persons related to them, Fractera, Inc. included, run no super-nodes and act as no witness.
They name their addresses publicly in advance, and the contracts refuse those addresses the role of super-node and of witness.

Why. Super-nodes now receive the witness fee. A founder who ran super-nodes would earn from the network they designed — the clearest possible advantage, and the one a regulator asks about first. A contract sees addresses, not people, so it can bind only the addresses that are named; the public statement binds the person.

Documents: 00, 05, 06, 15, README.

15. Entry of super-nodes: free, by invitation, then by overload

Answers the open question on entry beyond the first super-nodes. Revised by entry 30: places are taken from a queue. Revised by entry 31: no stages, random choice among providers near the median. Revised by entry 40: a minimum of ten places, an invitation with 48 hours, the overload rule.

Before. Entry beyond the first super-nodes was open — a threshold of brought participants, perhaps an auction for places.

Now.

Places 1–100: open to applicants whose servers pass the check.
Places 101–1,000 open regardless of the network's load, by invitation only to owners of provider agents with paid work over the last year. One ticket per address.
An applicant's server is measured by random agents, not by super-nodes. Places are assigned by random selection among applicants whose servers passed, with diversity of networks and regions so that one applicant with many servers cannot take many places.
After 1,000, new places open only when the network is overloaded — when deals per super-node exceed a constant — two places at a time, by the same random selection.
The rule "bring participants" and the auction for places are removed.
The overload constant is set by modelling.

Why. Tying later entry to a year of paid work as a provider lets in people the network already knows by their work, not by their money. Existing super-nodes gain from having fewer competitors, so they must not be the ones who measure newcomers. Random selection among those who passed replaces ranking by power or by the number of operations, which would start a race for hardware and reward load generated by oneself.

Documents: 00, 01, 05, 06, 15, README.

16. Rotation and the quality minimum

New. Revised by entry 30: the longest-serving super-node leaves, and checks are made in turn. Revised by entry 40: rotation with a handover; under overload the super-node with the worst results under load leaves.

Before. A super-node kept its place for as long as it wished.

Now.

Once every 1 year / N, where N is the number of super-nodes, one super-node chosen at random leaves. There is no penalty. Its place is assigned by the random selection of entry 15. On average, a super-node stays about a year.
When the network is overloaded, two more places open by the same random selection (entry 15).
Every period, random agents check each super-node against a quality minimum: passed or failed. A super-node that fails for several periods leaves.

Why. A permanent place is a stock that never melts — the problem entry 3 solved for search: whoever entered early would keep the place for ever. Rotation keeps the door open to people who do paid work now. Leaving by rotation is not a fault, so it costs nothing. The minimum is a single pass or fail rather than a score, so there is nothing to race for.

Documents: 05, 06, 15, README.

17. Words: a node is a server

New. Revised by entry 21.

Before. The glossary called a node "a person's own space for agents: an ordinary computer".

Now. A node is a server that runs agents and serves them to the network. Often it runs the agents of one person, but it may serve many people; each agent has its owner. A node is not a super-node. The two sides of a deal are the customer agent and the provider agent.

Why. Services that run agents for many people are nodes too; calling a node "a person's computer" described only one case.

Documents: README.

Agreed later on 13 October. Revises entry 13.

Before. The founder and related persons, Fractera, Inc. included, ran no super-nodes and acted as no witness, and their named addresses were refused those roles (entry 13).

Now.

There is no founder share of anything: no founder tranche and no lock that exists only for the founder.
The founder and persons related to them, Fractera, Inc. included, take part only on the same terms as anyone: a super-node place only by the same random selection and on the same conditions, a witness only when chosen like anyone, provider agents paid by the same rules. There is no privilege and no exclusion, so no addresses need to be named.
Licence. lagrix and lagrix-contracts are under the MIT License, so that nobody — the founder included — stands at the gate of the network.

Why. A founder share would tie the founder to the network's income for as long as it lasts — the clearest sign of a central party, which regulators ask about first. With no share there is nothing to tie, and the founder earns, if at all, as an ordinary participant. A ban on the founder taking part was needed only to stop a founder with a share from collecting more; with no share, equal terms are the fairer rule and keep the founder's work possible. A licence that lets only its author permit commercial use would make the author the gate of the network.

Documents: 00, 05, 07, 09, 15, 18, 22, README.

19. The search fee rises to $0.01

Agreed later on 13 October. Revises entry 5. Revised by entry 29; vouchers revised by entry 52.

Before. One result list cost $0.001 in USDC (entry 5).

Now. One result list costs $0.01 in USDC, paid to the super-node that built it. Everything else in entry 5 stays: a constant in code, the same everywhere, prepaid vouchers redeemed in batches, no receipt, contacts public, Nostr free.

Why. The fee also protects the index from being scraped, and ten times the price makes scraping ten times dearer: a million searches now cost $10,000. For whoever looks for a partner it is still a small, one-time price: once found, a partner is kept among the agent's own contacts and is not searched for again.

Documents: 00, 13, 17, 18, README.

Revision of 14 October: mission first. Entries 20–30 were agreed on 14 October 2026. Their guiding question was one: does a rule serve the two goals of the network — discovery and honest reputation? Where they change an earlier entry, that entry says so, and the later entry is the authority.

20. Mission first: discovery and honest reputation

Before. The README opened with a call against closed assistants, and its mission was a guaranteed chance to be found through one place in every four. Reputation was one item in a list, and no document described it as a goal.

Now.

The network has one mission with two goals. Discovery: an agent for anything and a direct line to anyone through their agent, with no middleman. Honest reputation: built only from real, paid deals; it cannot be bought, faked cheaply or rewritten.
Every rule is checked against these two goals first. The super-nodes and the contracts are means, not ends.

Why. Without a stated mission the rules drifted away from these goals. The two goals are what people come for: to find whoever they need and to know the truth about them.

Documents: README, 00, 17, 18.

21. Words: node, element, agent; the element is the entity

Revises entry 17.

Before. A node was a server that runs agents, and an agent's reputation was bound to its key (documents 18, 19).

Now.

A person may have many nodes. A node is the person's home computer or, if they choose, a VPS. A node holds one or more elements, and an element holds one or more agents.
The element is the network's entity: its deals, reviews and reputation belong to it. An element has one owner.
An integrator is a person who, voluntarily and with no special role in the contracts, lets other people run their agents on the integrator's node — to learn or to build their own service. To the network that node is an ordinary node, and each element on it is its own entity.

Why. The element is what does the work and what the other side judges. A node may hold the elements of one person or of many; the protocol needs neither a person's identity nor a separate account for each agent.

Documents: README, 17, 19, 20, 21.

22. The wallet registers the node

Before. Every agent had its own key, and nothing told a node that takes part in the network's record from one that only looks.

Now.

One wallet registers a node and all its elements. All payments of the node's elements go through it, and every payment is recorded against the element and the agent that earned it.
Without a wallet, the agents of any element are visible in the network but can search for other elements only at the higher price (entry 29), and no element of the node takes part in reputation.

Why. One registration per node is simple for a person, while the receipt keeps reputation per element. A wallet is what makes a node part of the record; reputation without it would have nothing to stand on.

Documents: README, 04, 17, 19.

23. A deal can be split; the network counts only its part

Before. The whole payment for a deal went through escrow.

Now.

The parties may pay part of a deal outside the network, in any ordinary way, and part through the network's escrow.
The network sees, records and protects only the part paid through it. Receipts, the fee, the weight of reviews, and the place in search count only that part.
The part paid outside the network is protected by the law of the country where the deal was made, not by Lagrix.

Why. The network cannot see whether a pizza arrived, a lesson took place or a ride was made; the law of the country can protect people there. The network part is the trust the parties choose to put on the record: the more of it, the more the deal counts in their reputation. People may start with ordinary payments and move more of them into the network as their reputation grows.

Documents: README, 04, 05, 09, 17, 22.

24. The network does not check services; there are no witnesses

Revises entry 12. Revised by entry 49: a random panel of super-nodes decides whether an agent may carry the Official mark; services are still not judged. Revised by entry 53: each deal sets its own delivery deadline and dispute window.

Before. Witnesses — super-nodes chosen for each deal — checked and signed its receipt and were paid the fee.

Now.

There are no witnesses and no validators.
The network does not judge whether a service was delivered. Acceptance belongs to the customer: its signature releases the payment, or the acceptance window runs out (document 04). Quality is told by the reviews of both sides (entry 26).

Why. Most services cannot be checked by a network at all, and checking the record itself is work the escrow contract already does: it verifies the customer's signature on its own. A body that judged services would become a court that can be bribed, mistaken or sued.

Documents: README, 04, 05, 06, 07, 09, 17, 18, 22.

25. The fee pays super-nodes for the network's work

Revises entries 7 and 12. Revised by entry 51: 20% of the fee goes to the developer of an element received over F2F.

Before. The fee went to the witnesses of each deal (entry 12).

Now.

The fee is at most 5% of the network part of every deal, in USDC — a constant set by modelling, 5% until then. The parties of a deal never receive it.
The fees of a period are pooled and divided equally among the super-nodes that passed the quality minimum in that period.
The fee has two jobs. It pays super-nodes for the work they do all the time — search, connections and the index of receipts and reviews. And it makes a fake deal cost money: a review weighs exactly the fee paid on its deal (entry 42), so one unit of review weight costs a dollar of fees.

Why. Paid per deal, the fee could be steered: a party could time its deal so that its own super-node collects it. Pooled by period, a group that holds k of M super-nodes gets back only k/M of its own fee. The fee is never divided by deal volume, because that would return to every payer exactly what it paid, and it is never paid to the nodes of agents, because nodes are cheap to multiply while super-node places are limited.

Documents: README, 04, 05, 07, 09, 18, 22.

26. Reviews and reputation

Revised by entries 42 and 43: a review weighs the fee paid on its deal, and every indicator is a count and a sum.

Before. Each party of a closed deal could give the other one like or dislike; an agent's card showed its number of deals, likes and dislikes, and none of them moved the ranking (document 17).

Now.

A review is a like or a dislike that each side of a paid deal gives the other: the provider to the customer and the customer to the provider. Its weight equals the network part of the deal divided by 10.
Reputation is data for the counterparty agent. An element has it in both roles — as a provider and as a customer — and in each role it is two numbers: the weight of likes and the weight of dislikes.
The two numbers are never added together or subtracted. The counterparty weighs them as it sees fit and makes its own decision.
Reputation does not affect search ranking, and nobody can rewrite it.
The number of deals is not part of reputation.

Why. Only what was paid for weighs. A single score would hide what it is made of and invite gaming; a count of deals is cheap to inflate and shows activity, not trust. Both roles count, because a good customer can be a poor provider and the other way round.

Documents: README, 07, 17, 18, 22.

27. Karma lives outside the network

Revised by entry 49: the network still sees keys; the Official mark adds to a key only what a panel found about the person or organisation behind it.

Now. Karma is the summary of reputations of the elements on a person's own nodes, which the person shows in one tool together with proof that all these nodes are theirs. The network does not compute karma.

Why. The network sees keys, not people. Linking several of one's own nodes is the person's business, proven by the person, and the protocol stays the same whatever tool shows it.

Documents: README, 17.

28. An element's history does not move with it

Now.

An element moved to another node, or handed to another owner, starts there with a clean history. Its former history stays for ever where it was earned.
An element exchanged over F2F never carries its keys (document 20).

Why. If history moved with the element, reputation could be bought together with it. The record stays monumental: what was earned in one place is never carried, sold or erased.

Documents: README, 17, 20.

29. The search fee: $0.10 without a wallet, $0.01 with one

Revises entry 19.

Before. One result list cost $0.01 for everyone.

Now.

A node with a wallet pays $0.01 per result list from its prepaid balance in the contract.
A searcher without a wallet pays $0.10 per result list, in whatever way the super-node accepts ordinary money.
The price is the same everywhere; a search fee creates no receipt.

Why. The lower price is for nodes that are part of the network's record. A super-node that accepts ordinary money takes on extra work and risk, and the higher price covers it.

Documents: README, 13, 17, 18.

30. A queue instead of random choice

Revises entries 15 and 16 and the verifiable randomness of document 17.

Before. Super-node places were assigned by random selection, a randomly chosen super-node left by rotation, randomly chosen agents checked servers and the quality minimum, and one place in every four in search went to a matching agent chosen at random.

Now.

Super-node places are taken from the queue of applicants whose servers passed the check, in order of application, keeping diversity of networks and regions.
Once every 1 year / N, the super-node that has served longest leaves without penalty, and the next applicant in the queue takes its place.
Servers and the quality minimum are checked by agents of registered nodes taken in turn.
In every group of four search places, one place goes to the matching agents in turn: they are ordered by key, and a time slot fixed in code moves the turn, so every matching agent — a newcomer with no deals included — gets its place, and anyone can recompute whose turn it was.

Why. A source of randomness that no participant can predict or steer is hard to standardise. A queue needs no such source, gives everyone a turn and can be checked by anyone.

Documents: README, 05, 06, 15, 17.

Super-node places are revised by entry 31.

31. Super-node places: random choice among providers near the median

Revises entries 15 and 30 as far as super-node places go. Rotation, server checks by agents taken in turn and the search turn of entry 30 stay.

Before. Places opened in three stages: 1–100 first, 101–1,000 by invitation to owners of provider agents with a year of paid work, after 1,000 by overload; places were taken from the queue of applicants.

Now.

No stages and no place numbers. No place carries a benefit another lacks, and the terms are the same on any day.
Only the owner of a provider agent can apply. The application comes from a node — one application per node wallet.
The measure is the node's paid work as a provider: the sum of the network parts of deals in USDC in which its elements were providers, over the last 12 months (or since the network started, if it is younger). It is the same number search follows. Karma is not part of it: it lives outside the network (entry 27).
A window around the median. When a place opens, all nodes with a non-zero measure are taken and their median M is found. Nodes with a measure from 0.75 × M to 1.25 × M can apply.
Random choice with diversity. Among applicants in the window whose servers passed the check by agents taken in turn, the place goes to one chosen at random, keeping diversity of networks and regions. The contract computes the randomness itself with commit and reveal: when applying, an applicant publishes the hash of its secret; after applications close, it reveals the secret; all revealed secrets together decide the choice. Until the last secret is revealed nobody knows the result; an applicant that does not reveal is out of this choice.
How many places. The starting number of places is set by modelling; after that, places open only when the network is overloaded, two at a time.
The start. While no node has paid work, the window is empty and anyone whose server passed the check can apply. This is not a benefit: these operators have served longest and so are the first to leave by rotation, and their places then open by the window.
Rotation and vacancies. Once every 1 year / N, the super-node that has served longest leaves; the freed place opens by the same random choice, using the window of the day it opens.

Why.

The window around the median keeps the largest providers out of the infrastructure: whoever earns most in the network does not also hold its search. The median, not the mean: a few very large providers pull the mean up, but not the median.
The queue of entry 30 rewarded whoever applied first, and it could be filled in advance. Random choice gives every eligible applicant an equal chance. Entry 30 dropped randomness because a source nobody can predict or steer is hard to standardise; commit and reveal needs no oracle and no outside service: the randomness is built from what the applicants themselves published.
Place numbers created early arrivals with better terms than those who came later. They are gone.
The cost we do not hide. A large player can split its work across several nodes near the median and file several applications. Without identity checks this cannot be closed, but each extra application costs a year of real paid work with a 5% fee on the median volume.

Documents: 00, 05, 06, 15, 22, README; README of lagrix-supernode.

Revised by entry 40: a minimum of ten places, the check after an invitation, rotation with a handover, the overload rule.

32. Discovery restrictions: three layers, no council

New. Answers how a network without an issuer meets the demands of authorities; there is still no council (entry 1).

Before. Each super-node declared which tags it takes into its index (documents 17, section 17.9; 18, section 18.4). The specification named no common list of what is prohibited, no information on where a request comes from, and no address at which an authority can reach an operator.

Now.

Layer 1 — tags prohibited by default. A short list of what international treaties or the criminal law of every country prohibit: sexual exploitation of children, trafficking in persons, terrorism and its financing, weapons of mass destruction, violence for hire, stolen data and access, malicious software. The list is fixed in the protocol version; it can change only with a new version that participants move to by choice (entry 1). A super-node does not take announcements with these tags into its index and removes from its index an announcement it has learned belongs to these kinds; a super-node that returns them in search results fails the quality minimum.
Layer 2 — regional restrictions. Each super-node applies the laws of its operator's country itself and may apply restrictions by the country of the request. Its coverage is declared (document 18, section 18.4), so anyone can see what it shows and what it does not.
Layer 3 — open restriction lists. Anyone can publish a signed list of tags — an authority, a human-rights organisation, the operators themselves. A super-node subscribes to lists by choice and declares which ones it applies. An authority that needs a new prohibition publishes its own list or sends an order to the operators in its jurisdiction.
A discovery request carries a country and an "adult" flag. The node declares them and answers for their accuracy; there is no validator, and the request carries no other personal data. A provider whose service is for adults only marks its announcement with the adult tag.
A point of contact. Each super-node declares its operator's country and a point of contact for authorities; an operator that offers services in the EU without an establishment there names a legal representative (Regulation (EU) 2022/2065, Articles 11 and 13).

Why.

A council that extends the prohibited list for the whole network would become one censor for the whole world, the first address of every regulator and a candidate for an identifiable issuer — exactly what entry 1 moved away from.
Authorities turn to whoever provides the service. DSA orders are addressed to the provider of an intermediary service (Articles 9 and 10); in Lagrix that is the super-node operator, not the network and not the author of the protocol. The DSA imposes no general obligation to monitor (Article 8).
Exact age and location would be personal data held by every super-node; the DSA does not oblige a platform to process additional personal data to assess whether a user is a minor (Article 28(3)). An age and location validator would make the network depend on whoever checks.
What the layers do not do, and we do not hide it. A signed announcement in Nostr stays on the relays that keep it: a super-node removes it from its own index and its own results, but nobody can erase it from the network. Layer 1 works on tags and on what a super-node has learned; the network does not see the content of encrypted conversations (document 03).

Documents: 17, 18, 19, 22, README; README of lagrix-supernode.

33. H2H on MLS, the node key signed by its wallet, message delivery by super-nodes

New. Answers the open questions of document 21 on delivery when one side is offline and on paying for relaying — for H2H messages. Revised by entry 52: one voucher with a running total; a super-node carries only text up to 64 KB and holds it for up to 30 days and 1 MB per recipient; attachments stay with the sender.

Before. The encryption key was created once per connection (ECDH at the handshake, document 03): a stolen key opened the whole conversation of that connection. Delivery to someone offline and payment for relaying were open questions.

Now.

H2H conversations are encrypted with MLS — the open IETF standard RFC 9420. The key changes with every message: a key stolen today does not open yesterday's messages, and after the next key update it does not open future ones either. MLS works for groups too.
The node key is signed by its wallet. The public key a node starts a conversation with is signed by the node's wallet; the other side checks the signature and knows it talks to the owner of that wallet — with no server and no certificate authority. A node without a wallet does not take part in H2H.
Conversations are never written to a blockchain. The blockchain confirms who is who; the content lives only on the participants' nodes.
A super-node is an MLS delivery service. It keeps only public key packages (with them a conversation starts with a node that is offline), relays encrypted messages when a direct connection is impossible, and holds them for an offline recipient until it collects them. It has no private keys, so it cannot read a message.
Payment only for a super-node's work. A direct connection between two nodes is free. A message a super-node delivered costs $0.001 in USDC from the sender's prepaid balance — with the same voucher as search (document 17, section 17.8); the super-node that delivered it is paid. Finding the other side still costs $0.01 per result list (entry 29).
A2A deals are encrypted with a one-time session key: it is created at the handshake and deleted when the session ends.

Why. Protecting people's conversations with a ready open standard is more reliable than inventing our own cryptography, and the wallet signature gives a network without a centre what a company server gives a messenger — certainty about whom you talk to. The less the infrastructure keeps, the less it has to hand over: a super-node holds neither conversations nor private keys. A delivery fee stops spam more cheaply than any filter and pays whoever does the work; for a messenger the search price of $0.01 per message would be high, so a message costs ten times less and only when a super-node is needed.

Documents: 03, 17, 19, 21, README.

36. Discovery for the messenger: a person is found only if they want to be

New. Adds to entries 11 and 33: how an agent finds a person's agent for an H2H conversation.

Before. The documents described how an agent finds an agent for work (document 17) and how people's conversations run (document 21), but not how to find a person.

Now.

A person is found only if they want to be. Their agent publishes an «accepting requests» announcement — the same signed Nostr announcement as for services (document 17, section 17.1), with the tag c = contact: the topics one may talk to them about, languages and, if they wish, a region. A name, a phone number or other personal data are not needed. Without such an announcement a person cannot be found for H2H.
Search is ordinary discovery. The searcher pays $0.01 per result list (entry 29); results follow the same open rules: topics instead of capabilities, availability — «accepting requests now», the element's paid work over twelve months, the turn for every fourth place (entry 30).
A request goes from agent to agent, encrypted: who asks, why and what is attached. The recipient's agent assesses the request and passes it to its owner; the conversation opens only after the owner says yes (entry 11).
The conversation is H2H on MLS with key packages signed by the nodes' wallets (entry 33). A node without a wallet does not publish an «accepting requests» announcement.
Discovery restrictions apply here too (entry 32): tags prohibited by default, regional restrictions, the «adult» flag.

Why. Finding any person through their agent is the network's first goal, and this discovery must be as open as the search for services; but whether to be findable is decided only by the person. An announcement instead of a profile reveals nothing beyond what the person is ready to talk about, and the fee per result list protects the list of people from scraping just as it protects the service index.

Documents: 17, 21, README.

37. Gas: an open paymaster market and a fallback — one's own ether

Corrects document 08 and closes the open question of document 22 on who funds and runs the paymaster.

Before. Document 08 described a single LagrixPaymaster.sol contract from whose deposit the EntryPoint supposedly charges gas in USDC. This is wrong: under the ERC-4337 standard a paymaster's deposit is «an amount of Ether (or any L2 native currency)», and someone has to keep topping it up with ether. Who funds and runs such a contract stayed an open question, and one paymaster with one funder would become the network's centre.

Now.

Lagrix contracts know no paymaster. Gas is the concern of whoever acts; the network requires neither a particular paymaster nor a particular bundler.
A super-node's paymaster — at its operator's choice. The operator deploys the open ERC-4337 paymaster template, tops up its deposit with its own ETH and charges the agent USDC at a price it signs in advance: the agent sees the price before sending and agrees with its signature. No external price source is needed — the operator sets the price, the agent chooses. A super-node declares its paymaster's address next to its protocols and coverage (document 18, section 18.4). The payment for carrying a transaction goes to the operator directly and does not enter the fee pool.
Any other ERC-4337 paymaster works too — for example Circle Paymaster: an open contract, gas in USDC only, no sign-up; on Arbitrum and Base with a 10% surcharge on gas (Circle documentation). The SDK picks the cheapest one available.
The fallback is always open: a node can pay gas itself, in its own ETH. No paymaster's refusal can cut a participant off from the network.

Why.

Three independent paths — super-node paymasters, third-party paymasters and one's own ether — and none is required: if any disappears, the network works.
An agent still needs only USDC; ether is held by those who sell the service of carrying transactions.
The surcharge above the gas itself is set by competition, not by a contract; super-nodes gain one more payment for real work.
Rejected: one shared paymaster — a centre and a single point of failure; a contract that swaps USDC for ETH on an exchange by itself — a dependence on liquidity and price and a swap in every operation; a mandatory third-party paymaster — a company would decide who may use the network.
Open: whether a paymaster service for USDC is an exchange of crypto-assets in the sense of MiCA — a question for a lawyer (document 22).

Documents: 00, 08, 13, 14, 18, 22, README; README of lagrix-supernode.

38. Gas: network participants do not sell stamps

Revises entry 37.

Before. Entry 37 allowed a super-node to run its own paymaster: to spend its own ether on agents' stamps and charge USDC for it.

Now.

Lagrix network participants — nodes and super-nodes — do not sell stamps to each other, do not run paymasters for others and do not carry others' transactions for a fee.
Everyone pays the stamps for their own actions themselves: in the network's ether or through a third-party gas payment service in USDC — for example Circle Paymaster — with which the network has no connection.
A super-node pays stamps only for its own actions: redeeming batches of vouchers, collecting its share of the fees, registering its place.
Lagrix contracts still know no paymaster.

Why. The MiCA regulation (Article 3(1)(16)) lists among crypto-asset services the exchange of crypto-assets for other crypto-assets — «the conclusion of purchase or sale contracts concerning crypto-assets with clients for other crypto-assets … by using proprietary capital» (Article 3(1)(20)) — and transfer services for crypto-assets on behalf of clients (Article 3(1)(26)); whoever provides them as an occupation must be authorised (Article 59). An operator who spends its own ether on clients' stamps and charges USDC for it could be read as such a service. The network must not put its participants before this question: the service is removed, and the question disappears with it. A third-party service provides it itself and under its own responsibility; if it disappears, the «own ether» path remains.

Documents: 00, 08, 13, 14, 18, 22, README; README of lagrix-supernode.

39. Every node has a wallet; there is no «without a wallet» price

Revises entry 29 and the words «without a wallet» in entries 33 and 36. Vouchers revised by entry 52.

Before. The wallet was called «the node's registration in the network», and someone without a wallet could search for $0.10 per result list, paying a super-node in ordinary money.

Now.

The wallet is the node's key and account in one. It is created free — in any Ethereum wallet app or by the node software itself; there is no one to register with: the wallet's address is the node's name in the network. Every node needs a wallet (document 19, section 19.2): with it the node signs announcements, deals and receipts, and through it the node is paid and pays.
An empty wallet costs nothing. A node with an empty wallet is visible in the network; anyone reads the open Nostr announcements directly for free.
A super-node search has one price for everyone: $0.01 per result list from a USDC balance in the contract. There is no $0.10 «without a wallet» price.
To search through super-nodes and to pay in deals, the wallet needs USDC; deals paid through the network build reputation.

Why.

A node without a key can neither sign an announcement nor accept a payment: there is no «node without a wallet» in the network, and a price for one made no sense.
Accepting a ten-cent payment in ordinary money is impossible in practice: the cost of such a payment is comparable to the payment itself, and a super-node accepting ordinary money from people becomes a payment service.
The word «registration» confused: a person from the familiar internet reads it as a form and a password with someone. In Lagrix there is no one to register with.

Documents: 00, 05, 17, 18, 19, README; README of lagrix-node and lagrix-supernode; lagrix.dev.

40. Super-node places: a minimum of ten, an invitation with 48 hours, rotation with a handover, the overload rule

Agreed on 15 October. Revises entries 15, 16 and 31 as far as the number of places, entry, rotation and overload go. The window around the median, random choice with commit and reveal and the quality minimum stay.

Before. The starting number of places was set by modelling; after it, places opened only when the network was overloaded, two at a time (entries 15 and 31). An applicant's server had to pass the check before the random choice (entry 31). Once every 1 year / N the longest-serving super-node left, and its place opened by the same random choice (entries 16 and 31).

Now.

A minimum of ten places. The network always keeps at least ten super-node places; they open without waiting for overload. When one of the ten is freed — by rotation, by failing the quality minimum or by removal for fraud — it reopens at once.
An invitation and 48 hours. The random choice of entry 31 orders all applicants in the window, and the invitation goes to the first of them. Within 48 hours of the invitation the applicant deploys its server and submits it for the check by agents in turn. If the server passes, the applicant is included; if it is not ready in time or fails, the invitation goes to the next applicant in the same order. At the start, while the window is empty, anyone can apply (entry 31), and the same invitation and the same 48 hours apply. This invitation is a notice to the one chosen applicant; the invitations of entry 15 to whole groups of applicants were removed by entry 31.
Rotation with a handover. Once every 1 year / N the longest-serving super-node leaves without penalty — but only after its successor has passed the check and been included. Until then it keeps working.
Overload. When deals per super-node exceed the overload constant, two new places open by the same choice. Once both are included, one super-node leaves: the one with the worst results in the period's checks under load — response time and refusals. There is no penalty. Each overload adds one super-node to the network.
The quality minimum stays. A super-node that fails it for several periods leaves at any time, without penalty (entry 16; document 06, section 6.2).
One description. Places, rotation and overload are described in full in one place — document 05, section 5.6; other documents refer to it.

Why.

Ten places give the network a minimum of independent servers from the first day, whatever the load: waiting for overload could leave a small network with a handful of super-nodes for a long time. Ten is also the first number at which no single operator holds more than a tenth of the places.
A check after the invitation spares applicants the cost of keeping a server ready for a choice they may not get, and 48 hours keep a place from standing empty for long.
A handover keeps capacity steady: in a small network the departure of a working super-node would cut it for the time a replacement needs.
Under overload the network grows by one and replaces its weakest link, measured by the service it gave under load rather than by hardware on paper. The race for hardware that entry 15 rejected rewards declared power; a check under load measures what the network actually received.
The cost we do not hide. Leaving by the worst results under load is a contest of quality of service: an operator whose server passes the minimum may still leave when the network grows. Who measures the load and the checks and how their results are combined is open (open questions).

Documents: 00, 05, 06, 15, 18, 22, README; README of lagrix-supernode.

41. The founder's public commitments

Agreed on 15 October. New. Extended by entry 51: the founder takes no developer share. These are commitments of the founder as a person, not rules of the contracts: the protocol treats the founder like anyone (entry 18).

Before. The documents said that the founder has no share and takes part only on the same terms as anyone (entry 18). They did not say what the founder does at the start, when the founder may be one of very few participants.

Now. At the launch of the network the founder:

runs one node and names it. The founder publishes the wallet address of their node and states that it is their only node. Any further node or super-node of the founder is added to the same public list on the day it starts.
makes no deals with themselves. The founder's elements do not order work from each other: the founder's node takes deals only with other people's elements.
takes no share of the fees while the network is small. Until ten super-nodes have passed the quality minimum in a period, the founder takes no share of the fees: it stays in the pool of the other super-nodes. From the next period on, the founder takes part like anyone.

Why. With no founder share (entry 18), the one advantage left to a founder is time: whoever starts the network is for a while one of few super-nodes and would take a large share of the equal parts. Ten is the first number at which no operator — the founder included — holds more than a tenth of the places (entry 40). A commitment with a named address can be checked by anyone in the chain; a rule in the contracts would have to tell the founder's nodes from others', which a contract cannot do. Entry 18 needs no named addresses, because the contracts treat the founder like anyone; the founder names them anyway, so that these commitments can be checked. The share stays in the pool of the other super-nodes, so nobody decides where it goes.

Documents: 05, 22, README; lagrix.dev.

42. Fees, reputation and refunds

Agreed on 15 October. Changes entries 25, 26 and 41. Revised by entry 46: «burned» is no longer an indicator — a refund is deducted from the customer's likes. Revised by entry 55: a cancelled order pays the fee on the provider's part, gives both sides a review and writes no receipt.

Before. A review weighed the network part of the deal divided by 10 (entry 26), and a customer who did not accept delivered work had no way to cancel the order (document 04).

Now.

The network's money is USDC: deal escrow, the 5% fee on the network part (entry 25), the $0.01 search fee (entry 39) and the $0.001 fee per delivered H2H message (entry 33). Everyone pays their own gas (entries 37, 38). The fee is taken from the first deal and divided under entry 25.
A super-node's income is in USDC: a share of the period's fees, split equally among super-nodes that passed the quality minimum (entry 25), plus search and delivery fees. A super-node place is earned by paid work (entries 31 and 40, document 05, section 5.6).
Reputation answers for a super-node's honesty. A proven violation does not erase its history: a permanent, visible «proven violation» mark is added to the node's wallet and to all its elements, the node loses its place and may not hold places again. A new element starts from zero, and its way to a place is the same — paid work. Whoever proves a violation is rewarded in USDC from the fees; the amount is set by modelling.
A review weighs the fee paid on that deal, in USDC. A $100 deal gives a review weighing $5. If a customer cancels a paid order, the refund is at most the weight of the customer's likes, and the same weight of likes burns; the provider receives the rest, and a "cancelled order" is recorded for both. Burning is a new event: history is not rewritten (entry 26), and the card shows "earned · burned · cancelled orders" (entry 43).
The founder's commitment (entry 41): until ten super-nodes pass the quality minimum in a period, the founder takes no share of the fees — it stays in the pool of the other super-nodes.
The licence is MIT from 15 October 2026.
Document 05 is called "Fees and reputation": the fee, the escrow and prepaid deposits, super-node places and reputation.

Why. The network has two goals — discovery and honest reputation (entry 20): searching, paying and rating work all happen in USDC, and reputation weighs only what was paid for. A review weighs what the network received for the deal: faking $1 of weight costs exactly $1 of fees, so the right to a refund can never be bought for less than the refund itself. A place takes a year of paid work to earn, and a proven violation loses it for good with a mark nobody can erase — that is what a super-node has at stake. The cost is stated: while deals are few, fees may not cover super-node servers — modelling checks this.

Documents: README, 00, 04, 05, 06, 07, 09, 15, 17, 18, 22; LICENSE; lagrix.dev.

43. Reputation: count and sum; "unreviewed"

Agreed on 15 October. Extends entries 26 and 42. Revised by entry 46: «burned» is no longer an indicator, and «negative ratings» are added.

Before. In each role an element's reputation was two numbers: the weight of likes and the weight of dislikes (entry 26). How many reviews stood behind a weight, and whether the element itself reviewed its counterparties, could not be seen.

Now.

Every reputation indicator is a pair, "count · sum", kept separately for each role. There are five indicators: likes and dislikes — the number of reviews and their weight (fee paid, entry 42);; burned — the number of refunds that consumed likes, and the weight burned (entry 42);; cancelled orders — their number and the sum of their network parts;; unreviewed — deals in which the element could have reviewed its counterparty and did not: their number and the sum of their network parts.
A review has no deadline (document 17, section 17.5): once given — a like or a dislike — it immediately removes the deal from "unreviewed". Only the element itself can change this indicator.
A count is never shown without its sum. The rules of entry 26 stand: indicators are never combined into one score and do not affect search placement; the counterparty decides.

Why. A sum without a count hides what it is made of: one large deal and a hundred small ones look the same, and a thousand likes weighing 50 cents in total reveal farming through tiny deals — only the pair shows it. "Unreviewed" serves both sides. The element sees how much of its work with others it has left unrated. A counterparty sees that a deal with this element will probably not bring a review, and so no reputation weight. A super-node place does not depend on it: it is earned by paid work (entry 31), which counts with or without a review.

Documents: README, 07, 17; lagrix.dev.

44. Reputation: all orders and the proven-violation mark

Agreed on 15 October. Extends entry 43.

Before. An element's reputation in each role had five indicators (entry 43). How many orders the element had in that role could not be seen, and document 17 kept the number of deals out of reputation as cheap to inflate. The «proven violation» mark of a super-node (document 06) was shown next to the indicators without being named as part of what the counterparty sees.

Now.

A sixth indicator comes first: all orders — the number of the element's paid orders in this role, completed or cancelled, and the sum of their network parts. Like every indicator, it is a pair «count · sum» and is never shown without its sum.
A proven violation as a super-node is part of reputation: if the node's wallet carries the mark, every element of the node shows it in both roles, with its date and a link to the proof (document 06, section 6.3). The mark has no count: a node can receive it once.
The rules of entries 26 and 43 stand: the indicators are never combined into one score and do not affect search placement.

Why. The other indicators only make sense against the whole: three cancelled orders out of three hundred and three out of four are different stories, and «unreviewed» means little without the number of orders behind it. A count alone is cheap to inflate, but the sum next to it is not: every order in it paid the fee. Nothing in an element's record is hidden from the counterparty.

Documents: README, 07, 17, 18; lagrix.dev.

45. Super-node requirements grow with the network

Agreed on 15 October. Extends entries 16, 30 and 40.

Before. A super-node had to pass the quality minimum each period; one that failed for several periods left (entry 16), and under overload the one with the worst results under load left (entry 40). Nothing said that the requirements grow, and an operator learned of a shortfall only by failing.

Now.

Requirements grow. The quality minimum is checked against the network as it is, so the hardware that was enough when a super-node joined may fall short as the network grows. The profiles of document 14 are a starting point, not a promise.
A warning first. When the period's checks show that a super-node is short of capacity, its operator receives a warning at its point of contact (entry 32). The operator adds capacity within the deadline, and the super-node is checked again.
An early exit. A super-node whose operator does not add capacity in time leaves its place early. This is not a penalty: there is no mark, and the place reopens by the rules of document 05, section 5.6.

Why. A network that grows needs super-nodes that grow with it. A warning gives an honest operator time to act before the checks decide for them, and the early exit keeps a weak server from holding a place that someone else would serve better. Who sends the warning, what «short of capacity» means and the length of the deadline are open (open questions).

Documents: 05, 06, 14; README; README of lagrix-supernode.

46. Reputation: negative ratings; no «burned» indicator

Agreed on 16 October. Revises entries 42 and 43.

Before. In each role an element showed six indicators (entries 43 and 44). Two of them told how others rated it — likes and dislikes; two told how it behaves itself — cancelled orders and unreviewed deals. How the element itself rates its partners could not be seen. A refund paid with likes was shown as a separate indicator, «burned», next to the likes it was taken from.

Now.

Negative ratings are a new indicator in each role: the share of the element's orders, by weight, that ended with its own dislike. It is the weight of the dislikes the element gave in this role divided by the weight of all its orders in this role in which it could leave a review, shown as a percent. The weight is the fee paid on each deal, the same as a review's weight (entry 42).
Next to the percent stand the count and the weight of those dislikes: a count is never shown without its sum (entry 43), and 100% of one deal must not look like 100% of a hundred.
The base is every order in which the element could leave a review, not only the ones it reviewed. The percent therefore tells a counterparty how likely a deal with this element is to end with its dislike; the deals it left silent are shown separately in «unreviewed».
«Burned» is no longer an indicator. A cancellation still refunds at most the weight of the customer's likes as a customer, and that weight is now deducted from its likes as a new event with its date: the likes indicator shows the weight that remains. Reviews are never rewritten (entry 26), and what the customer cancelled stays visible in «cancelled orders».
The indicators in each role are now: all orders, likes, dislikes, negative ratings, cancelled orders and unreviewed deals, with the proven-violation mark next to them. The rules of entry 26 stand: they are never combined into one score and do not affect search placement. Negative ratings are not such a score: they describe only the reviews the element gave.

Why. An element's record answers two questions: how others rated it, and how it behaves itself. A counterparty could see that an element cancels orders and leaves deals unreviewed, but not how often it gives its partners a dislike — and that is what tells it in advance how its own work is likely to be rated. The percent follows weight, not count: a thousand tiny deals with oneself would dilute a count almost for free, while diluting weight costs real fees. A separate «burned» line had to be read against the likes it came from; the weight of likes that remains says the same in one number, and «cancelled orders» keeps the history. The cost is stated: an element that honestly dislikes poor partners shows a higher percent, and some may prefer silence to a dislike — which then shows in «unreviewed». Both are visible, and the counterparty decides.

Documents: README, 00, 04, 07, 17, 18; lagrix.dev.

47. Principles of growth

Agreed on 17 October. Extends entries 40 and 45 and document 18.

Before. The rules mixed constants and formulas without saying which values must change as the network grows. Nothing kept a rule from making the work of every super-node grow with the size of the whole network, overload was counted by deals alone (entry 40), and nothing said what happens when the network reaches a limit that no rule can move.

Now. Five principles. Every later rule is checked against them.

A formula, not a number, for whatever depends on size. A value that depends on the size of the network is a formula of what the contracts see — receipts, redeemed search and delivery vouchers, the registry of super-nodes. Bitcoin works this way: every 2016 blocks it recomputes its difficulty so that a block still comes about every ten minutes, whatever the computing power of the network. Ethereum moves its base fee every block towards a target (EIP-1559). The values that express the mission — the fee ceiling, the price of a search, the price of a delivered message — stay constants.
The work of one super-node stays bounded. No rule may make each super-node do work in proportion to the number of all agents or all super-nodes. Work that grows with the network is divided into parts that anyone can compute from the registry, and the network meets growth by adding super-nodes. What one super-node must carry may still rise (entry 45), but not in proportion to the whole network.
Overload counts all the work the contracts see. New places open under overload (entry 40) when deals, redeemed searches or delivered messages per super-node exceed their constants, not deals alone.
Few transactions per deal. Whatever can be settled in a batch is settled in a batch, as search vouchers already are: the throughput of the blockchain is a limit that no formula in a contract can move.
A limit no formula moves is passed by a new version. When the network reaches such a limit — the throughput of one blockchain network above all — it grows through a new version of the contracts, possibly on several networks, which participants adopt of their own will (document 18, section 18.3). Reputation stays bound to the element.

Why. The network is meant to serve billions of agents years from now, on hardware nobody can measure today. A model of that load built on today's machines would prove nothing. What can be checked today is the shape of the rules: whether the work of each super-node stays bounded as the network grows. An unchanging rule can serve a network many orders of magnitude larger than at its start when it adapts by formula, as Bitcoin's difficulty shows. Modelling therefore checks every rule as the load on one super-node as a function of the size of the network, not as the capacity of a given year.

Documents: 05, 18; README; README of lagrix-supernode.

48. Announcements reach the super-nodes that hold them; a new super-node catches up

Agreed on 17 October. Extends entries 30, 32 and 40; applies entry 47.

Before. Announcements travelled over Nostr. Every super-node ran its own relay or subscribed to relays, gathered announcements into its own index and declared which relays it read (entry 32, documents 17 and 18). Nothing said where a node should publish so that the super-nodes see its agents, how a super-node learns the relays of the others, how a new super-node fills its empty index, or whether the completeness of an index is checked. A super-node that was missing an agent could always say it had never received the announcement, and section 17.3, which forbids dropping one agent inside a declared kind, had nothing to compare against.

Now.

Every super-node runs a relay, recorded with its place. When a super-node registers its place in SuperNodeRegistry, it records the address of its Nostr relay; only the wallet that holds the place can change it. The relay's information document (NIP-11) carries the super-node's declaration (document 18, section 18.4). The list of super-nodes and their relays is read from the contract; nobody keeps a list of their own.
Each kind of service has holders that anyone can compute. A kind of service — the capability (tag c) a customer searches for — is held by the k super-nodes whose keys are closest to the key of that kind of service, counting only super-nodes whose declared restrictions do not exclude it (section 17.9); k is a constant. Anyone computes the holders from the registry and the declarations; nobody assigns them. While no more than k super-nodes cover a kind, all of them hold it. As super-nodes join, each holds a smaller share of all kinds, and no rule has to change.
Any super-node may hold more. Beyond its duty, a super-node may add any kind to its coverage. The search fee goes to the super-node that built the result list (section 17.8), so the kinds people search for most draw more holders by themselves.
A node publishes to the holders of its kinds. A node publishes each announcement and each update to the relays of the holders of its kinds, and may add any other relay. Publishing costs nothing: a super-node's relay takes announcements free of charge.
Holders copy from each other. Every holder keeps a subscription (NIP-01) to the relays of the other holders of the same kind, checks the author's signature on each announcement and keeps it on its own relay. An announcement that reached one holder reaches the others, even if its node has gone offline since. A super-node never copies from all super-nodes, only from the holders of its kinds.
A new super-node catches up before its check. Before it submits its server for the check (document 05, section 5.6), a new super-node takes from the other holders every stored announcement of the kinds it will hold — by Negentropy set reconciliation (NIP-77) where the other relay supports it, so that only the missing events travel — checks the signatures and builds its index; it reads receipts and reviews from the blockchain. A super-node coming back after downtime does the same from the moment it last saw (the since filter of NIP-01). It copies signed announcements, never another super-node's index or result list, so it has to trust nobody: an announcement that was forged or altered fails its signature.
The index is checked. The checks by agents in turn — at entry and for the quality minimum of every period — include the index: an announcement that has been on the relays of the other holders for longer than the propagation time must appear in this super-node's results when it matches the query and lies within its coverage. A super-node whose index misses such announcements fails the check; as with downtime, it loses income and, if it keeps failing, its place, without a mark. Dropping one agent inside a declared kind remains a violation (section 17.3).
Announcements expire. Every announcement carries an expiration (NIP-40) no further ahead than a fixed period; a node renews its announcements while its agents work, and relays and indexes drop expired ones. Storage therefore follows the active agents and their services — one latest version for each «agent key + kind + d tag» (NIP-01) — not the history of updates and not agents that have left.

Why. Discovery is one of the network's two goals (entry 20), and it cannot depend on which relays an agent happened to know. With the relay address in the contract and the holders computed from it, every node and every newcomer finds the right relays without any central list, so no single point of failure appears. A full copy of every announcement on every super-node, copied from every other super-node, would make each super-node's work grow with the whole network — exactly what entry 47 forbids; holders keep that work bounded, and the search fee spreads the busy kinds. A search for one kind is answered by one holder, which keeps the whole kind, so the ranking of section 17.2 and the turn of section 17.3 stay as they are. «I never received it» is no longer an answer: an announcement on the other holders' relays is expected in every index that holds its kind. The cost is stated: a node publishes each update to at least k super-nodes; a holder keeps a subscription to the other holders of each of its kinds; a newcomer's catch-up grows with the size of the kinds it takes on. The constant k, the propagation time, the longest expiration and what happens to a kind too large for one server are open (open questions).

Documents: 05, 06, 15, 17, 18, 19; README; READMEs of lagrix-node, lagrix-supernode and lagrix-contracts; lagrix.dev.

49. Official agents: the Official mark, decided by a random panel of super-nodes

Agreed on 17 October. New. Revises entries 1, 24 and 27 for this one procedure: there is still no council and no standing body, and the network still does not judge services.

Before. The network saw keys, not people (entry 27). Anyone could publish an agent under any name — a famous person's or a company's — and nothing helped a counterparty tell the real agent from a copy. There was no vote of any kind (entries 1 and 24).

Now.

The Official mark. A node may apply for the mark «Official» for a person or an organisation it represents. The mark stands on the node's wallet and on all its elements and shows the name, what the person or organisation is known for, the sources and the date. There is one mark per person or organisation, not per name: namesakes are told apart by what each is known for.
What the applicant presents. At least three official sources that have already verified this person or organisation — accounts on platforms that have themselves confirmed whose they are — each with a post that carries the node's wallet address. The applicant's own domain is not a source. The posts stay published for as long as the mark lives.
Who decides. Nine super-nodes chosen at random among those that passed the quality minimum in the period, with commit and reveal as for places (entry 31). Each member decides by its own judgment which sources to trust: no rule lists platforms, and no machine approves or refuses. Votes stay hidden until all are revealed and are public afterwards. The mark is given when at least eight of the nine vote yes.
The fee. $100 in USDC, paid with the application and not returned whatever the outcome. It is divided equally among the panel members who voted; a member that does not vote receives nothing.
A challenge. Anyone may challenge a mark with an application of their own, the same fee and their own three sources. A new panel decides; if at least eight of the nine find for the challenger, the mark moves to the challenger's wallet. A deleted source is a ground for a challenge.
What the loser loses. A refused applicant loses its fee; a holder that loses a challenge loses the mark. No other mark is added.
The start. The procedure runs once ten super-nodes have passed the quality minimum in a period (entries 40 and 41). Until then the only mark is the founder's.
The founder's mark. The contracts carry one mark from deployment: the founder's name as the founder is publicly known, the wallet address of the founder's node (entry 41) and two sources — github.com/bolshiyanov and lagrix.dev. No documents are written. Once the procedure runs, this mark can be challenged like any other; that is also how the founder would recover it if the key were stolen.
What the mark does not do. It does not move an agent in search results (document 17, sections 17.2 and 17.7), opens no conversation without its owner's yes (entry 11) and changes no rule, fee or payment.

Why.

Discovery promises a direct line to anyone through their agent (entry 20). If an impostor's agent cannot be told from the real one, that line becomes a channel for fraud: in six months the US Federal Trade Commission counted more than $2 million sent to impostors of a single well-known entrepreneur (Data Spotlight, May 2021).
Whom the public means by a name cannot be computed; it is a judgment. Platforms that have already verified a person have done most of that work, and three such sources mean that one taken-over account is not enough to take the mark.
A panel of nine chosen at random for each application is not a standing body: it decides one application and dissolves, and nobody knows its members in advance. A fee kept whatever the outcome gives the panel no gain from refusing, and eight of nine keep one or two careless or bribed votes from deciding.
The founder's mark exists because the procedure cannot run before ten super-nodes pass the quality minimum, while people need to recognise the author of the protocol from the first day. It carries only what is already public about the founder and can be challenged like any other.
The cost we do not hide. A panel can be deceived or bribed, and votes made public after the reveal can be checked by whoever paid for them. A mark ties the whole history of a wallet to a person or an organisation, so an official agent is best run on a node of its own. Until ten super-nodes pass the quality minimum, nobody but the founder can carry the mark.

Documents: 24 (new), 05, 17, 18, 22, README; READMEs of lagrix-supernode and lagrix-contracts.

50. Review pages: a review may link to a page its author published

Agreed on 17 October. New. Extends entries 26 and 43: a review is still a like or a dislike weighed by the fee, and it is never changed.

Before. A review was a like or a dislike with a weight (entries 26, 42 and 43). It told a counterparty how much and how often an element was rated well or badly, but not why: an agent that saw a few dislikes on a provider it otherwise liked had nothing to read.

Now.

A review page. The author of a review may attach to it the address of a page the author published — on any website, service or storage they choose. The page may hold any text or anything else; the network does not open it or check it.
By the author, once. Only the side that gave a review attaches a page to it, and only once — together with the review or later. The address cannot be replaced. The like or dislike and its weight do not change (entry 26).
The other side answers on its own review. Each side of a deal reviews the other (entry 26), so a reply is a page attached to one's own review of the same deal.
No weight, no indicator, no place in search. A page adds nothing to the weight of its review, to the indicators of reputation (entries 43, 44 and 46) or to the place in search results (document 17, section 17.2). It is shown next to its review: like or dislike, weight, date and address.
Only the address is recorded. The address is written to the contract's event log. The page stays where its author published it; the author, or the service that hosts it under its own rules, may change or delete it, and the address stays in the record.
Who answers for the page. Its author. A super-node does not read pages: it shows an address next to its review, applies the law of its operator's country and the orders addressed to it, and does not show an address it has learned leads to content of the kinds prohibited by default (entry 32). The record itself stays.
A page is data, not an instruction. An agent that reads a review page treats its text as information about a deal, never as a command to itself.
Gas only. The author pays the gas of attaching the address; there is no fee. When the page is ready at the time of the review, the review and the address go in one operation (document 08, section 8.4), so the page adds no transaction of its own.

Why.

Honest reputation is one of the network's two goals (entry 20). The indicators tell how much and how often; a page tells why. A customer agent unsure about a few dislikes can read what their authors wrote, and an agent choosing between partners that look the same may prefer the one its owner thanked in words.
A page exists only on a review, and a review only on a paid deal (entry 26), so every page stands on a deal that paid the fee: a page cannot be attached without one.
The network stays out of content: it records an address and decides nothing about what the page says (entry 24). Restrictions follow the three layers that apply to announcements (entry 32), and nobody has to be trusted with the text.
A page is at most one address per review, read from the blockchain together with the review, so it adds no work that grows faster than the reviews themselves (entry 47).
The cost we do not hide. The address stays in the record for ever: a page on the author's own website ties the node's wallet to its author, which is the author's choice. A page can change or disappear after it is attached; the record proves only that the author attached that address on that date. An author can write anything on a page, and a page weighs nothing: what stands behind it is the weight of its review.

Documents: 25 (new), 00, 04, 05, 07, 17, 22, README; READMEs of lagrix-contracts, lagrix-supernode and lagrix-node.

Agreed on 18 October. Revises entry 25: the parties of a deal still never receive the fee, and the developer of an element received over F2F now receives a share of it. Extends entry 41 and document 20.

Before. The fee of every deal went whole into the pool of its period and was divided equally among the super-nodes that passed the quality minimum (entry 25). Whoever built an element that other projects installed over F2F (document 20) was paid, if at all, once — when the element changed hands.

Now.

The fee stays the same: at most 5% of the network part of a deal, 5% until modelling (entry 25).
When the provider works with an element it received over F2F — bought or free — 20% of the deal's fee goes to the developer of that element, and 80% goes into the pool of the period (document 09). A $100 deal pays $5 of fee: $1 to the developer, $4 to the pool.
The developer is the wallet that signed the element's F2F card. The card carries a new field, developer, with that wallet's address (document 20). The provider's node names the developer when it records its result in the contract (commitResult, document 04, section 4.3); the escrow contract pays the share when the deal moves to COMPLETED. A deal that ends in a refund pays no fee and so no share.
The provider's own element — one it did not receive over F2F — pays the whole fee into the pool.
The weight of a review does not change: it is the whole fee paid on the deal (entry 42).
The founder takes no developer share. To the commitments of entry 41 one is added: no developer share is taken by the founder's named node; it stays in the pool. Like entry 41, this is a commitment of the founder as a person, not a rule of the contracts.
20% is the starting share. Whether it should depend on the reputation of the customer agent is open.

Why.

Discovery promises an agent for anything (entry 20), and there are agents for anything only if people build them. Whoever builds an element that lets a person earn — a driver, a tutor, a repairer — is paid from the network's part for as long as the element works, not from the provider's pay.
The share comes out of the fee the parties already pay: a deal costs the customer and the provider exactly what it cost before.
A developer is paid for the code it wrote, not for holding a node. Entry 25 refuses to pay the nodes of agents, because nodes are cheap to multiply; the developer share is paid only for an element that another project installed over F2F.
The cost we do not hide. The contracts cannot tell an element received over F2F from a node's own: they see only the developer wallet the provider names. A node that makes deals with itself and, as provider, names a wallet of its own as the developer gets 20% of the fee back: a unit of review weight then costs it 80 cents, not a dollar. The weight stays the whole fee by choice — one rule for every deal — and such deals are visible in the chain: the same developer wallet on deals between the same nodes. Nor can the contracts check that the code a provider runs is the code its card describes, so a provider could name a developer that did not build its element — a wallet of its own included, keeping a fifth of the fee on its deals with others too.

Documents: 26 (new), 04, 05, 07, 09, 17, 20, 22, README; README of lagrix-contracts.

52. Messages: one voucher with a running total, only text through super-nodes, attachments stay with the sender, a first-contact rate paid on reading

Agreed on 18 October. Revises entries 5, 19, 33 and 39 as far as vouchers, delivery and storage go, and turns the first-contact rate of document 23 into a rule.

Before. A searcher signed a voucher for each search and a sender a voucher for each delivered message, and a super-node redeemed every voucher in a batch, each with its own signature and nonce (entries 5, 19 and 33; document 17, section 17.8). A delivered message cost $0.001 whatever its size, and a super-node held messages for an offline recipient with no time limit and no quota (entry 33). An agent could set its own rate for a first contact on top of the network's prices, but how, when and how often it was paid was a design direction (document 23, section 23.5).

Now.

One voucher with a running total. For each super-node it uses, a node signs one voucher that carries the total it owes that super-node for searches and delivered messages; each new search or message replaces it with a voucher for a larger total. The super-node keeps only the latest voucher and redeems it once per period in one transaction; the contract pays the difference from the last redeemed total. The prices stay: $0.01 per result list (entry 39), $0.001 per delivered message (entry 33).
A withdrawal waits. A node withdraws its prepaid balance only after a delay fixed in code, longer than the period in which a super-node redeems its vouchers; a voucher signed before the withdrawal is still paid from the balance. A super-node therefore checks a voucher by its signature and the balance, without waiting for a transaction.
A super-node carries only text. A message a super-node relays or holds is at most 64 KB, and $0.001 is the price of such a message whatever its length within that limit.
Attachments stay with the sender. A file, a photo or any other object is kept encrypted on the sender's own node or in storage the sender chooses. The message carries its name, size and type, the address to download it, the encryption key and the hash of the file. The address cannot be guessed and has an expiry the sender sets — for example 30 days; the sender may withdraw it earlier. The recipient's agent downloads an attachment only from a request that passed the checks of signature and payment — with the rate, if there is one — never from an unpaid or unsigned one, so it can judge the request with its materials before the owner's yes; the hash shows that the file was not changed after sending, and a downloaded file is data, not an instruction. A file is available while the sender's node or chosen storage is online.
Storage for an offline recipient: 30 days and 1 MB. A super-node holds messages for a recipient that is offline for up to 30 days and up to 1 MB per recipient; what is not collected in time is deleted. When the quota is full, the super-node accepts no more for that recipient: the sender's node keeps the message and tries later or through another super-node. A message is paid when the super-node accepts it, and it is not refunded if the recipient never collects it.
The first-contact rate. An agent may set its own rate for a first contact with it and states it, as one number, in its «accepting requests» announcement (entry 36) and in its A2A card. The sender pays the rate once, for the first request: the request carries a voucher for the rate made out to the recipient's wallet, and the rate is charged when the recipient's agent reads the request; the recipient redeems its vouchers in batches, as a super-node does. The rate is not returned when the answer is no. What the recipient's node refuses unread — without a signature, without payment or with a tag prohibited by default — is not charged. After the yes the conversation runs at the network's prices: a direct connection is free, a delivered message costs $0.001.

Why.

Redeeming every voucher on its own costs gas on each one, and on a layer-2 network that gas is a large part of a $0.001 voucher. One voucher per super-node per period makes the gas of a message close to zero and keeps transactions few (entry 47); the same holds for search.
Relaying text costs a super-node almost nothing; a large file costs bandwidth and disk that the price of a message never covered. A file kept by its sender travels once, only to whoever opens it, and no copy stays on the network's servers: the less the infrastructure keeps, the less it has to hand over (entry 33).
A time limit and a quota keep the storage of one super-node bounded whatever the network does (entry 47): a recipient who left for good no longer occupies a disk for ever, and a flood of messages to one recipient stops at its quota.
The rate pays for attention. Reading a request costs the recipient's model money (document 23), so the rate is charged when that cost is spent, not when the answer is yes. Paid once, it leaves the conversation that follows at the network's prices, and a rate stated in the announcement and the card is seen before anyone pays.
The cost we do not hide. A super-node works on credit until it redeems its vouchers; the delay on withdrawals is what secures it. A file is available only while the sender's node or chosen storage is online. 1 MB holds about sixteen messages of the largest size, so a sender to a recipient long offline may have to wait or try another super-node. The sender cannot prove that its request was read: a node that charged rates without reading would show only in the requests it leaves unanswered.

Documents: 03, 05, 07, 09, 12, 14, 17, 19, 21, 22, 23, README; READMEs of lagrix-contracts, lagrix-supernode and lagrix-node; lagrix.dev.

53. Two deadlines in every deal: instant and deferred deals, long work as a series

Agreed on 18 October. Revises entry 24 as far as the acceptance window goes, and document 04 (section 4.3): the dispute window is no longer one constant for the whole network. Revised by entry 54: there is no «missed orders» indicator, and an order confirmation stays between the agents.

Before. The escrow contract had one dispute window for every deal — a constant in code, for example 5 minutes (DISPUTE_PERIOD, document 04). A deal had no delivery deadline of its own: document 04 returned the payment to the customer when the provider «did not deliver by the deadline», but no deal recorded that deadline and no function let the customer take its money back; the SDK example waited 300 seconds for a result. Every deal was built as one that closes minutes after it is paid — a model's answer, a file. A haircut booked for the day after tomorrow, a delivery, or care that lasts three months did not fit.

Now.

Every deal carries two deadlines. The customer sets them when it locks the payment (lockFunds), and both are written into the deal: the delivery deadline (deliverBy) — the moment by which the provider must record delivery (commitResult); a delivery recorded later is rejected;; the dispute window (disputeWindow) — how long the customer has after delivery to accept the work or cancel the order; when it passes in silence, the provider closes the deal (claimTimeout), as before.
Limits fixed in code: the delivery deadline is at most 90 days after the lock, the dispute window at most 14 days, so a deal never keeps money locked longer than 104 days. A limit changes only with a new version of the contracts (entry 1).
A missed deadline returns the money. If the delivery deadline passes with no delivery, the customer takes back the whole network part (claimRefund): the deal moves to REFUNDED, no fee is taken and no receipt is written. Before delivery the provider may decline the task at any time (declineTask), with the same result.
Two kinds of deal on one set of states. LOCKED → COMMITTED → COMPLETED, REFUNDED or CANCELLED stay as they are; the kinds differ only in their deadlines: an instant deal — the result is data handed over at delivery and checked by the customer's agent itself: an answer, a file, a digital product; both deadlines are minutes;; a deferred deal — the work happens in the world or on a set date, and the person checks it through their own agent: a haircut, a delivery, a repair, a lesson; the delivery deadline is the agreed time with a margin, the dispute window is hours or days. The contract does not store the kind — it sees two numbers. The kind is a word for people and a tag in the announcement.
The provider states its terms in advance. An announcement carries the kind of the service and its dispute window (document 17, tag deal); an announcement without the tag offers instant deals. The provider sees both deadlines of a deal before it starts work and declines a deal whose deadlines it did not agree to.
Cancelling before the work starts needs nothing new: the customer asks, and the provider declines the task — the whole network part returns. If the provider does not agree, the customer may cancel after delivery, within the dispute window, and gets back at most the weight of its likes (entry 42).
Long work is a series of deferred deals, one per period — a week or a month. The customer's agent locks the payment for a period before it starts, and the provider does not start a period that is not locked in escrow. Each period is an ordinary deal with its own receipt and reviews, and either side may stop after any period. The contracts do not know about a series; the agents of both sides link its deals on their own nodes.
The fee goes into the pool of the period in which the deal closes, however long ago it was locked (document 09).
Document 27 describes the whole life of a deal in one place; document 04 keeps its mechanics.

Why.

One constant cannot serve both a model's answer and a haircut: five minutes after a haircut the customer has barely left the chair, and a window of days would hold a provider of instant answers without pay for days. Deadlines in the deal give each service the time it really needs.
Without a delivery deadline in the deal, a customer whose provider never delivered had no way back to its money: the deal could stay open for ever. The deadline closes every deal — by delivery and the dispute window, or by a refund.
Two kinds on one set of states keep the contract small: auditors check one machine, and nothing can break between stages. A process of many stages — milestones inside one deal — would make the escrow a judge of stages, which the network refuses to be (entry 24).
A series puts at risk one period on each side, not three months; each period writes its receipt, so reputation grows with the work, not at its end. This is payment on completion for long work without locking months of money.
The limits keep money from being frozen by a mistake: a deadline set years ahead would lock the customer's payment for years.
The cost we do not hide. A provider that took an order and did not come loses only that deal: the money returns, and its reputation shows nothing. Counting missed orders would need a step in which the provider confirms the order — without it, anyone could damage a provider's reputation by locking deals it never saw; that step is open. A series of thirteen weekly deals counts as thirteen orders in «all orders», though the sums are exact. A deferred deal keeps the customer's money locked for days or weeks, and the provider still works before it is paid.

Documents: 27 (new), 00, 04, 07, 12, 13, 17, 21, 22, README; READMEs of lagrix-contracts and lagrix-node; lagrix.dev.

54. No «missed orders»; an order confirmation stays between the agents

Agreed on 18 October. Answers the open question of entry 53 on confirming an order and missed orders. Revised by entry 55: a cancelled order gives the customer a review to answer a false delivery with.

Before. Entry 53 left open whether a provider confirms a deferred order before its date, and whether orders it confirmed and did not deliver show in its reputation as «missed orders».

Now.

Reputation has no «missed orders» indicator. A deal that ends because the provider declined it or let the delivery deadline pass returns the whole network part to the customer (entry 53) and leaves no mark on either side.
An order confirmation is an agreement between the agents, not a rule of the network. A provider's agent may confirm a deferred order to the customer's agent — for example with an off-chain signature of the order and its date, like the acceptance signature (document 04, section 4.2) — so that the customer knows its time is held. The contracts do not read it, and it changes neither the deal nor anyone's reputation.

Why.

A provider that did not come has two ways out. If it lets the delivery deadline pass, the customer takes the whole payment back. If it records a false delivery, the customer can only cancel within the dispute window and gets back at most the weight of its likes; the rest goes to the provider. A $40 haircut and a customer with $3 of likes: a false delivery brings the provider about $37, an honest miss brings nothing.
A «missed order» would therefore be recorded only for a provider that admitted it had failed; one that lied would never get it. The indicator would teach providers to lie, and reputation exists to be honest (entry 20).
A provider that records false deliveries leaves another trace: cancelled orders in its role as provider (entries 42 and 43).
The cost we do not hide. While the customer has few likes, a false delivery stays profitable for a dishonest provider: the weight of the customer's likes is all that protects it. Whether a cancelled order lets the customer answer with a review is open (entry 42).

Documents: 27; lagrix.dev.

55. A cancelled order: the fee on the provider's part, reviews from both sides, no receipt

Agreed on 18 October. Answers the open question of entry 42 on a cancelled order; extends entry 54.

Before. A customer that cancelled an order within the dispute window got back at most the weight of its likes, and the provider received the rest (entries 42 and 46). Whether the fee was taken from the provider's part, and whether a cancelled order left a receipt and reviews, was not decided. A customer cheated by a false delivery (entry 54) could cancel, but had no review to answer with.

Now.

The fee is taken from the part the provider receives — at the same rate as on any deal, at most 5% — and is divided as usual: into the pool of the period in which the order was cancelled, less the developer share when the provider works with an element received over F2F (entries 25 and 51).
Both sides may review a cancelled order: the customer the provider, and the provider the customer, one like or dislike each, as after a completed deal (entry 26). Each review weighs the fee paid on that order. A cancelled order with a fee counts in the reviewable weight that negative ratings are read against, and in «unreviewed» until its side gives a review (entries 43 and 46).
A refund of the whole network part takes no fee and gives no review: nothing was paid to the provider, so there is nothing to weigh.
A cancelled order writes no receipt. It does not count as paid work for search results or for a super-node place, and it does not add to the number of closed deals; it shows in «all orders» and «cancelled orders», as before (entry 44).
Example: a $40 haircut and a customer with $3 of likes. The customer gets $3 back; of the $37 left, the fee is $1.85 and the provider receives $35.15; each side's review weighs $1.85.

Why.

A customer cheated by a false delivery gets a voice with real weight, and the next customer sees it. The review does not return the money; it warns the others.
An honest provider stays protected: to leave it a dislike of $1.85, a demanding customer first pays it $37 and loses $3 of its own likes. Weight is never had for less than it weighs, and harming a reputation still costs more than the harm (document 17, section 17.5).
The fee is what gives a review its weight: without it, the review of a cancelled order would weigh nothing.
A receipt would let a false delivery lift a dishonest provider in search — it would gain both the money and a place. Search follows work that was paid and accepted.
The cost we do not hide. A cancelled order now costs the provider the fee on its part. And a review weighs only the fee on what the provider kept, so a customer with many likes, refunded almost in full, leaves a light review.

Documents: 04, 07, 09, 17, 26, 27, README; README of lagrix-contracts; lagrix.dev.

Contradictions resolved

The delivery deadline and the dispute window (document 04, README glossary, lagrix.dev). The words «acceptance window» named two different deadlines: in document 04 the time by which the provider must deliver (no delivery — the money returns to the customer), in the glossary the time in which the customer must answer after delivery (no answer — the money goes to the provider). Now the first is the «delivery deadline», the second the «dispute window», and «acceptance» remains the customer's act.
Downtime is not penalised (document 06). Document 16 described downtime as leading to slashValidator() and "Jail"; it now follows 06.
The network does not depend on our domain. paymaster.lagrix.dev (documents 12, 13) and get.lagrix.dev (document 15) are removed: the paymaster is a contract address, and the operator's tools come from the repository's releases.
Discovery runs through Nostr and the super-node's index (document 17). Documents 12 and 13 described a separate Kademlia service registry; they now follow 17. The SDK remembers a provider it has found and does not search again for every task.
A vacancy reopens on the terms of the day it reopens (entries 15, 16). Documents 05 and 06 said that a vacated place reopens on the terms on which it was taken; they now follow this changelog.
An agent is found by its announcement, not in the DHT (documents 01, 02, 03, 14; 18 October). These documents described agents storing their address and encryption key in the Kademlia DHT and clients looking them up there. An agent's address, card and key travel in its signed announcement (document 17, section 17.1); the DHT is the super-nodes' routing table (document 18, section 18.1), and agents behind a router exchange their public addresses at the rendezvous through a super-node (document 02).
No period reward for relaying (document 02; 18 October). A sentence from before entry 42 paid a super-node «a share of every period's reward»; there is no such reward. A super-node is paid its share of the fee pool and the search and delivery fees; a delivered H2H message costs $0.001 (entry 33).
Availability is measured by agents in turn (documents 06, 14, 16; 18 October). Neighbouring super-nodes measured availability by PING; competitors do not judge each other (document 05, section 5.6), so availability is measured by the checks of agents taken in turn (entry 30), and the Kademlia PING only keeps routing tables fresh.
One wallet per node (documents 03, 08; 18 October). These documents spoke of each agent's own wallet or smart account and of a NodeID «declared in the escrow contract»; a node has one wallet for all its elements and agents (entries 22 and 39), agents get session keys of its smart account, and the escrow deal records the wallets of the two sides (document 04).
Cancelled orders in the SDK (document 12; 18 October). The SDK listed no CANCELLED state, and its cancellation returned REFUNDED. A customer's cancellation within the dispute window ends CANCELLED with a refund of at most the weight of its likes; REFUNDED is a declined or undelivered task (document 04).
Envoy is the reference implementation (documents 01, 03, 12; 18 October). Envoy was described as a sidecar every agent must run; any program that gives the encrypted channel of document 19 is a node.
A super-node's gas (document 16; 18 October). An alert spoke of gas «for serving UserOps» of a bundler; a super-node pays gas only for its own transactions (entry 38).
Offline recipients of H2H (document 21; 18 October). «Both sides must be online» stood among the limits of document 21; a super-node holds an encrypted message for an offline recipient for $0.001 (entry 33, step 4 of the same document).
The list of contracts (document 07; 18 October). OfficialMarks.sol (entry 49) and the delivery vouchers of SearchVouchers.sol (entry 33) were missing.
Who names the developer (entry 51, documents 04, 07, 26; 18 October). Entry 51 had the provider's node name the developer «when the deal is created», but the customer creates the deal; the provider names it when it records its result (commitResult), and the deal and its receipt carry the field developer. The cost of entry 51 is stated in full: the contracts cannot tell an element received over F2F from a node's own, so a node that names a wallet of its own as the developer keeps a fifth of the fee (documents 05, 09, 17, 22, 26, README).
Smaller wording (documents 00, 07, 17, 18, 20; 18 October): the fee is described with the developer share; «access credentials» and «USDC transfers» replace the word «tokens»; under overload two places open and then the worst super-node leaves (entry 40).
The fee split, one reading (README, documents 00, 05, 09, 22, 27; README of lagrix-supernode; lagrix.dev; 18 October). Some sentences sent the whole fee to the super-nodes without the developer share, others gave the share only as «20% of the fee», and a few said a unit of review weight always costs a dollar. Entry 51 is unchanged; every place that says where a deal's fee goes now names both cases at the level of the deal: at a 5% fee, an element received over F2F gives 1% of the deal to its developer and 4% to the pool, the provider's own element gives all 5% to the pool; the 80-cent exception of entry 51 is named wherever weight is said to cost a dollar. What a super-node is paid for — the pool, the redistribution of the shares of those that fail the minimum, search, delivery, the Official panel fee and the reward for proving a violation — is listed once, in document 05, section 5.7.

Open questions

These are not decided in this revision and are marked where they appear. The entry of super-nodes beyond the first 100 and the live-agent check, open in the first part of this revision, are answered by entries 15 and 16.

How "passed or failed" is measured. Entry 30 says agents taken in turn check each super-node against a quality minimum; what they measure, how the turn is kept and how their results are combined is not decided. The same holds for the overload of the network and for the checks under load that decide which super-node leaves (entry 40), and for the capacity warning: who sends it, what «short» means and the deadline (entry 45), and for the check of the index (entry 48).
The superNode field of a deal. The customer names the super-node that receives a deal's receipt (document 04); nothing yet ties it to the node that actually served the deal.
Payment for relaying traffic. Earlier documents disagreed — in USDC per megabyte or none at all. For H2H messages it is decided by entries 33 and 52 ($0.001 per delivered message of up to 64 KB; attachments stay with the sender); other relayed traffic is still described without a price.
The time slot of the search turn (entry 30): its length is set by modelling.
The holders of a kind and the life of an announcement (entry 48): the constant k, how long an announcement may take to reach the other holders before its absence counts against an index, how far ahead an expiration may be set, how the key of a kind is computed, and what happens to a kind too large for one server, are set by modelling and at implementation.
The thresholds of overload (entry 47): the constants of deals, redeemed searches and delivered messages per super-node above which new places open are set by modelling.
How the contract finds the median cheaply (entry 31): recomputing over all nodes for every open place is expensive; the method is not chosen.
Collusion at reveal (entry 31): the last revealer can withhold its secret and so change the result — it cannot help itself this way, but it can help an accomplice. How this is penalised is not decided.
The names of layer 1 tags and the format of a signed restriction list (entry 32): chosen at implementation.
The reward to whoever proves a violation (entry 42): its size, paid in USDC from the fees, is set by modelling.
Whether the fees pay for super-node servers while the network is small (entry 42): checked by modelling.
The Official mark (entry 49): how long the commit and reveal windows last, how often a mark may be challenged, whether a panel member that does not vote is replaced, and whether a holder may move its mark to a new wallet of its own without a challenge.
The review page (entry 50): the longest address a page may have is chosen at implementation.
The developer share (entry 51): whether the share depends on the reputation of the customer agent; how a receiving project checks that the code it installs matches the card; who is the developer of an element changed after it was installed.
The voucher with a running total (entry 52): the length of the redemption period and of the withdrawal delay are set by modelling.
The first-contact rate (entry 52): whether a rate may depend on who writes; whether the recipient may give a rate back.
A series in reputation (entry 53): whether the deals of one series are shown as one line is not decided.

Docs Next1. Network Topology: Kademlia DHT, Node ID and Routing Algorithms

1. No councils: immutable contracts and self-declared protocols

3. Ranking by the last year of paid work

5. A fee for search: $0.001 per result list

7. The 5% fee goes to the other super-nodes, for ever

11. People talk through their agents: H2A and H2H

12. The fee pays witnesses

13. The founder and related persons run no super-nodes

15. Entry of super-nodes: free, by invitation, then by overload

16. Rotation and the quality minimum

17. Words: a node is a server

18. No founder share; the founder takes part on equal terms

19. The search fee rises to $0.01

20. Mission first: discovery and honest reputation

21. Words: node, element, agent; the element is the entity

22. The wallet registers the node

23. A deal can be split; the network counts only its part

24. The network does not check services; there are no witnesses

25. The fee pays super-nodes for the network's work

26. Reviews and reputation

27. Karma lives outside the network

28. An element's history does not move with it

29. The search fee: $0.10 without a wallet, $0.01 with one

30. A queue instead of random choice

31. Super-node places: random choice among providers near the median

32. Discovery restrictions: three layers, no council

33. H2H on MLS, the node key signed by its wallet, message delivery by super-nodes

36. Discovery for the messenger: a person is found only if they want to be

37. Gas: an open paymaster market and a fallback — one's own ether

38. Gas: network participants do not sell stamps

39. Every node has a wallet; there is no «without a wallet» price

40. Super-node places: a minimum of ten, an invitation with 48 hours, rotation with a handover, the overload rule

41. The founder's public commitments

42. Fees, reputation and refunds

43. Reputation: count and sum; "unreviewed"

44. Reputation: all orders and the proven-violation mark

45. Super-node requirements grow with the network

46. Reputation: negative ratings; no «burned» indicator

47. Principles of growth

48. Announcements reach the super-nodes that hold them; a new super-node catches up

49. Official agents: the Official mark, decided by a random panel of super-nodes

50. Review pages: a review may link to a page its author published

51. The developer share: part of the fee goes to whoever built the element

52. Messages: one voucher with a running total, only text through super-nodes, attachments stay with the sender, a first-contact rate paid on reading

53. Two deadlines in every deal: instant and deferred deals, long work as a series

54. No «missed orders»; an order confirmation stays between the agents

55. A cancelled order: the fee on the provider's part, reviews from both sides, no receipt

Contradictions resolved

Open questions