Version 0.3 resolves the open questions recorded against version 0.2, using the defaults set down for each and the first measurements from the Phase 0 lab. It removes what the receipt model made obsolete: the token emission and its decay schedules, the validator election, the uptime penalty, sync tests, and the self-reported fields of the announcement. It adds the unrecoverable fee and the payment window to Section 3, rewrites Sections 2 and 4 through 8 around a pilot that settles in dollars, and adds Section 9 on the pilot and Section 10 on what remains open. Appendix A restates the protocol without constants, as parameters of a link, so that the same receipt serves a link with any light delay. Section 5.1 defines purchase commitments, the bounties of the roadmap: a prepaid purchase with a minimum rate, a refund on shortfall, a bounded allowance for third parties to prove a route by using it, and places bought as service rather than presence.

A lab of three nodes has run the receipt mechanism since October 2026. It settles hourly windows at the smaller of two signed counts, resolves a forced disagreement from the receipt data alone, and declines a payer whose clock has drifted. What it has not yet shown is a second party, a subsidy that moves anyone, or a settlement layer other than an invoice. Those are stated as open.

A network whose proof of delivery is a signed receipt can keep moving bytes while its settlement layer is unreachable, and settle later. That is a narrower claim than surviving a continental outage, and it is a claim to be tested rather than assumed: Section 9 says how.

2. Settlement

The pilot settles in dollars. A payer and a relay agree a posted price per unit of data, the relay carries the data in hourly windows, each window closes with signed receipts, a Mint settles the window from those receipts, and the Mint issues a monthly invoice. There is no token and no chain in the pilot. The receipt mechanism is what is being proved, and it does not need either.

A token, if one is issued, is denominated and settled under the rules in force at the time, and only after there is paying traffic to denominate. Nothing in this paper depends on it. Where version 0.2 said that rewards were issued by the chain, they are not: nothing is minted for availability, uptime, or capacity, and there is no block reward. Mints are paid from a share of the settlement fee on the receipts they publish. The Network Steward is paid from the unrecoverable fee defined in Section 3.3.

Identity on the network is a key pair registered with a Mint against a bond. We call it a NYM, after the term Open-Transactions uses, and Open-Transactions remains one candidate for the notary and claims layer.^[iii] It is a notary system, which is to say a trust system, and the paper no longer presents it as anything else; the pilot runs without it.

The unit of proof is a receipt. There are two kinds.

A forwarding receipt is signed by each pair of adjacent hops. It carries the two hops' NYMs, the hop's index in the route, the Merkle root, the byte count the hop forwarded, and the signature of the previous forwarding receipt, forming a chain from the payer's edge to the recipient's. Hop timestamps are advisory. A payer who cannot see a hop cannot timestamp it, and does not need to: the chain is anchored at both ends by signatures the hops cannot produce.

The pilot runs without route privacy. The payer sees every hop and signs every receipt, which collapses the two kinds into one: in the Phase 0 lab, with a single hop, the receipt is the tuple in Figure 2, signed by the payer and countersigned by the hop with the hop's own byte count. Whether a Mint can verify a chain of forwarding receipts without learning the route is an engineering question the pilot does not answer.

In the pilot, acknowledgement is the hop's countersignature on the receipt and payment is the invoice. The conditional payment proper arrives with the settlement layer in Section 2. On a link whose light time exceeds a threshold the membership sets, windows are prepaid and no lock is used (Appendix A).

It is only true if part of every fee leaves the colluding set. Version 0.2 did not say what part, or where it went. Version 0.3 does: a fixed fraction b of every fee is burned, and b is 5% until a simulation says otherwise. An operator who runs payer, relay, and Mint in one hand still loses b of every fee it pays itself. Routing the fraction to the Steward or to the settling Mint was considered and rejected, because both can leak back to the attacker when the attacker is also the Steward's grantee or the Mint.

The defense then holds under one condition: no reward may exceed the fee that produced it, and no subsidy may exceed the burn. If the Steward matches settled fees at a multiple m, self-dealing is unprofitable only while m is at most b. The Steward can never subsidize more than users were taxed. This bounds the bridge-node bonus that Section 5 describes, and it bounds it hard: at b of 5%, the most the Steward can add to a link is five cents on every dollar paid across it. Whether a bonus that small still moves anyone to build a link is the first question the pilot's economics must answer (Section 10). The alternatives, paying bonuses out of a treasury that does not depend on traffic, or lifting the cap by charging for payer identity rather than counting fees, are recorded there and not adopted.

Five seconds is generous for a node that keeps a time source and fails safe for one that does not. In the Phase 0 lab, three nodes synchronized on one network agree within a millisecond. Left free-running, the fastest of their oscillators gains 0.76 seconds a day and crosses the tolerance in about a week; the slowest takes three weeks. A node that has been alone that long is declined, its window is lost, and nothing is paid. Drift between sites has not been measured. On a link with a light time, the tolerance widens by the light time both ways and the drift expected since the last contact; it is a parameter of the link (Appendix A).

3.6 Payment windows

A payment window is one hour on the pilot's links; on a link that exists only during contacts, it is the contact (Appendix A). Before the window's bytes move, the payer locks the window's value; in the pilot, where there is no payment rail, the lock is the invoice and the exposure is bounded by membership. A relay therefore never fronts more than one window of bandwidth on credit, and a payer who consumes a window and leaves forfeits what was locked.

A window settles at the smaller of the two signed byte counts, the payer's and the hop's. When the two counts are within one percent of each other the window is recorded as settled; when they differ by more it is recorded as disputed and settles by the same rule. Nothing else is needed to resolve a dispute: no probe, no testimony, no judgement. The rule was chosen because each party can only lower the number the other party is paid or paid for, and neither gains by doing so. A hop that declines a receipt loses the window: its next acknowledgement covers both windows, and the payer's count governs. A hop also declines a receipt whose timestamps disagree with what it observed by more than the tolerance of Section 3.5, since a payer that shortened its own window could otherwise claim a rate it did not get.

Streaming payments per chunk, which interactive traffic would need, are not in the pilot, which carries bulk traffic settled by the hour.

The Mint is modeled on the notary of Open-Transactions. There, a transaction server signs every receipt it processes and the client keeps the signed copy, so that the client's proof of its own balance is a receipt in its hand and not the server's word; a server that signed something it later denies has signed its own conviction. A Mint is that notary applied to a batch: it signs what it settles, every party keeps the signed receipts, and the summary it publishes commits it to them.

A settlement summary is a Merkle commitment over the receipts it settles. Anyone holding a receipt can prove that it was included, or that it was not, and a Mint whose summary is shown to omit or alter a receipt forfeits a greater share of its bond than the fee it collected for that summary. This is the only penalty a Mint faces, and it works with a single Mint, which is what the pilot has.

A Mint is compensated by a share of the settlement fee on the receipts it publishes. There is no block reward and no election. Version 0.2 carried both from version 0.1, together with a committee of five validators reaching a three-of-five consensus every minute and a minimum stake of one ten-thousandth of all assets in circulation; the committee and the election contradicted each other, and the minimums referred to assets that do not exist. The pilot runs one Mint. The target, when more than one party operates a Mint, is one proposer and four attesters per summary, with three of five required to finalize, and a proposer that is offline or inconsistent collecting nothing for that summary. Until then, a Mint's bond is set by the membership. A Mint settles the links of one settlement domain; where a link crosses domains, the Mints on each side reconcile their published commitments whenever a link between them allows (Appendix A).

5. Operators: Relays and Endpoints

Price. A relay posts a price per unit of data, and that price governs every payment made to it. The opportunity-cost figure of the next paragraph is not a price; it is used only to divide a Steward purchase among the relays on a path. In the pilot the posted price is ten cents a gigabyte.

Route purchases. The Network Steward buys bandwidth on links it wants to exist, by defining a clear start point and endpoint and matching the receipts that bonded payers have already settled on that path, at a multiple m that is never above the burn b (Section 3.3). Payers whose bonds are younger than the program do not count. Relays on the path divide the purchase by opportunity cost, computed from the receipt graph: the fewer paid, disjoint paths that reach the endpoint without a relay, the greater that relay's share. A relay with five acceptable alternatives in a possible chain receives one fifth of that location's purchase, while a single relay connecting a bridge receives all of it. The attestation that version 0.2 required of traffic claiming a purchase is deferred (Section 3.4); eligibility is by bond age and diversity.

Bonds. An operator stakes a small bond with a Mint to be provisioned a NYM, which it broadcasts in its header so that other devices can connect to it securely. The bond's size is set by the membership in the pilot. The reference to a fictional exchange that version 0.2 used to size it is removed.

Availability. Version 0.2 kept an uptime penalty from version 0.1, which deferred part of a relay's earnings to the Steward in proportion to the seconds of a week it was not seen in a receipt or by a Mint's liveness check. It measured demand, not uptime, since a healthy relay with no customers at night was penalized, and the liveness check was the validator probing that Section 3.8 rejects. It is removed. A relay that is offline earns nothing, and quality is priced (Section 3.4). For the subsidy tier only, a relay must be seen by its peers to be eligible: availability is a gate on Steward purchases, measured by signed heartbeats between neighboring relays, with no reward attached to the heartbeat and no Mint involved.

5.1 Purchase commitments

A purchase commitment, a bounty in the roadmap's word, is a payer's prepaid offer to buy bandwidth that does not exist yet, or that exists and must be kept in use. It is the protocol's only instrument for causing a link to be built, and it is a purchase: every unit it pays out traces to a settled receipt, and the burn of Section 3.3 is taken from every fee paid out of it.

A commitment names a route, from a node to a node or to a place; a minimum rate, stated as bytes per window (forty megabits a second is eighteen gigabytes an hour); a premium per byte above the relay's posted price; a number of windows; a deadline; and, optionally, a proving allowance. Its value is escrowed with the poster's Mint, which is the prepayment of Section 3.6 made in bulk, and it is announced on the gossip layer like any announcement (Section 6). Any relay, or chain of relays, that serves the route carries the poster's windows and collects.

A committed window settles as every window does, at the smaller of the two signed counts, and then the Mint applies one more rule. At or above the minimum, the relay is paid the posted price and the full premium. Below it, the relay is paid the posted price on what moved and the premium in proportion to what moved over the minimum, and the rest of that window's premium returns to the poster. The rate is the receipt's byte count over the payer's first and last timestamps; nothing new is measured, and a shortfall is resolved from the receipts alone. The posted price on committed windows is the poster's to lose whether or not the poster sends, as a reservation is. Whether an unused reservation pays the relay anything is a term of the commitment, and the default is that it does not.

Proving. Validators do not probe (Section 3.8), so a route is shown to be open by being used. A commitment may carry a proving allowance: the escrow reimburses the posted price of up to a stated number of windows per period bought on the route by payers other than the poster, provided the payer's bond is older than the commitment and not owned by the relay. The testers keep the bandwidth; the receipt graph keeps the record, and the poster can see the route settling at the rate before relying on it. The allowance is bounded, so a relay that proves its own route through a second identity gains at most the allowance less the burn, out of the poster's escrow and nothing else.

Pipes. A commitment with no end date keeps a pipe open the only way the protocol can: it guarantees that carrying traffic across it is paid at the premium, and its proving allowance guarantees a minimum of traffic. A pipe nobody uses earns nothing, and a relay that lets it go dark stops earning when the receipts stop.

Places. A commitment may name a place instead of a far node, to pay for people being served there. It cannot buy presence. Nothing in Section 3 can tell a hotspot in the square from the same box in a closet, and a premium for being available is the reward Section 3.3 forbids. It can buy service: the commitment reimburses part of every fee that independent payers settle with an access point over a short-range radio, up to a cap per payer and per period, and the access point earns only by serving them. The place is the poster's anchor, a node the poster operates there. The access point must hold control-plane exchanges with the anchor over radio during each period it claims (Section 6); a radio exchange is a physical fact, so the access point is within the anchor's radio range, and its customers within its own. The medium and range class of each link are parameters the relay publishes and can be slashed for misstating (Appendix A). That is a location with the resolution of a radio, not a coordinate, and the paper claims no more: a high-gain antenna widens it, a short-range anchor narrows it.

The Steward. The Network Steward's route purchases, above and in Section 7, are purchase commitments funded from the burn, with the premium capped at the burn. There is no second mechanism.

A relay announces to its peers, over a gossip layer or distributed hash table that never touches the settlement layer, its NYM, its posted price, the routes it will accept, and the parameters of each link it offers (Appendix A). On a link that exists only during contacts, the announcement is a contact plan: when the link will exist, for how long, and at what price. A purchase commitment (Section 5.1) is announced the same way. An anchor's control-plane exchanges with an access point are announcements signed on both sides; they earn nothing and gate a purchase. Version 0.2's announcement also carried the relay's own report of its uptime and its maximum available bandwidth, and a sync test by which a relay measured and reported its own throughput. All three were self-reports of the kind Section 3 exists to replace, and they are removed. A user's software ranks relays by the throughput previous payers actually settled, which the receipt graph records and an announcement cannot inflate.

In the pilot the hop countersigns the same tuple with its own byte count and with prev receipt sig set to the payer's signature, and both signed copies go to the Mint. The Merkle root in the lab is the payer's commitment to its own meter readings, since nothing is chunked yet; the field is kept so that the chunked form of Section 3.1 is a change of content, not of format.

The Steward is funded by the burn: it receives, as its income, an amount equal to the fraction b of every fee that the network destroys, so that its income scales with the traffic the network carries and with nothing else. Version 0.2's funding, ten percent of each block reward declining by a point a year, is deleted with the block reward; under those numbers the Steward's income would have been under a third of its launch level by the third year and near zero by the ninth, for no stated purpose.

Governance is for bonded, identified members. Relays and payers may remain pseudonymous NYMs and use the network without it; a member who wishes to vote identifies itself to the DAO. Version 0.2 relied on that identification to restrict whales while describing the network as semi-anonymous; the two are reconciled by making identification a condition of governance membership and of nothing else.

1. Anti-private-interest restrictions, by weighting votes as the logarithm of stake: one unit staked is one vote, ten units are two, a hundred are three, a thousand are four, and so on. Version 0.2's scale of one, two, four, and five was not logarithmic.

9. The pilot

The pilot is permissioned: two or three sites with real spare backhaul, dollars not tokens, one Mint, no onion routing, hourly prepaid windows, signed receipts, a monthly invoice. It answers directly which price governs, who pays and for what, the receipt structure without route privacy, the payment window, the last-hop rule, the place of announcements, settlement by invoice, the clock tolerance, and the narrow resilience claim of Section 1. It answers by simulation alongside the unrecoverable fee, the subsidy bound, emissions, the Steward's funding, availability, and Mint fraud proofs. It defers, honestly, the lifting of the subsidy cap, the Mint committee, attestation, open relays, the token, and governance.

Success looks like: two parties who are not the authors settle a month of real traffic on receipts, dispute at least one receipt, and the dispute resolves from the receipt data alone.

Phase 0, October 2026. Three single-board computers on one home network: a gateway that is the payer, a relay that is the hop, and a Mint. The payer and the hop share a tunnel; at the top of every hour the payer reads the tunnel's byte counters, builds the Figure 2 receipt, signs it, and asks the hop to acknowledge. The hop checks the signature and the clock rule, countersigns with its own count, and both copies go to the Mint, which verifies the signatures, refuses NYMs it was not told about, appends everything to its ledger, and settles the window by the rule in Section 3.6. The posted price is ten cents a gigabyte and the invoice is by month. The code is published.

Three forced tests were run on the first day, each by resetting a counter on one side so that the two signed counts would disagree.

• The hop under-claims. Twenty megabytes crossed the tunnel; the payer signed 21,938,052 bytes and the hop 21,939,460, within one percent, and the Mint settled the window at the smaller count. Twenty more megabytes crossed; the hop's counter was reset; the payer signed 21,945,428 bytes and the hop 1,712; the Mint recorded a dispute and settled at 1,712.
• The hop over-claims. The same two windows with the counter reset on the payer's side instead: the payer signed 272 bytes against the hop's 21,947,428, and the window settled at 272 bytes. A hop cannot be paid for more than the payer signed for.
• The clock rule. The hop's clock was stepped ten seconds; it declined the payer's receipt, and the window was lost, not paid. The declined receipt stays on the Mint without an acknowledgement. The hop's next acknowledgement covered both windows and settled at the payer's count.

In every case the Mint resolved the window from the two signed receipts alone, with no measurement of its own. In sync, the three clocks agree within a millisecond (Section 3.5).

What Phase 0 did not show. A second party. A payment rail, since the invoice is the settlement. Route privacy, since there is one hop. Any subsidy, since there is no Steward. Any adversary, since one person operates all three nodes. It showed that the receipt mechanism works between machines that are not trusted to agree, which is the part a whitepaper cannot show on paper.

Phase 1 replaces the bench cable between the gateway and the relay with a radio link and moves receipts and liveness onto a low-rate control channel. Its test is to cut the gateway's connection to the internet mid-window and show that the window still settles when the connection returns, which is the claim in Section 1. Phase 2 puts the relay outdoors on its own power and, with it, a second operator who is not the authors, which is the success criterion above.

10. What version 0.3 leaves open

• Whether a bounded subsidy moves anyone. With m at most b, the most the Steward can add to a link is b of what users pay across it. If that does not move an operator to build a link, the alternatives are to fund links from a treasury that does not depend on traffic, which is grant-making, or to lift the cap by charging for payer identity rather than counting fees, which requires knowing what a Sybil payer costs to manufacture. A simulation of one operator running payer, relays, and Mint, sweeping b, decides between them.
• The customer. Site-to-site backhaul between locations that already overbuy capacity is the pilot's use case because the authors can supply both sides of it. Whether anyone chooses this over a carrier contract, a satellite, or a VPN is a market question that only paying traffic answers.
• Forwarding receipts under route privacy. Whether a Mint can verify the chain of Section 3.1 without learning the route.
• The settlement layer. Chosen among the three candidates in Section 2 when an untrusted party joins; the cost of each has not been measured.
• The Mint committee. One proposer and four attesters is the target; the pilot has one Mint and fraud proofs.
• Attestation for the subsidy tier, or its replacement by bond age and diversity.
• Open relays. Relay service is between members. Carrying third-party traffic for the public internet raises liability the paper does not address, and is not in the pilot.
• The token, its status, and the Steward's legal form, all deferred until there is traffic to denominate, and all to be reviewed with counsel against the rules in force then.
• Clock drift between sites, measured once the relay leaves the bench.
• Reconciliation between Mints in different settlement domains, and the price of custody across a contact that may never come (Appendix A).
• Whether proving allowances attract real testers (Section 5.1), or only a relay's second identities; and what an unused reservation should pay, if anything.
• Payers at a place. Whoever connects at an access point has to be a payer with a NYM, or the poster pays on their behalf through the commitment. That is an application as much as a rule, and it is the Phase 2 work.

Appendix A. Links with delay

The protocol has no constants. The hour, the five seconds, the one Mint, and the monthly invoice are the pilot's choices for a link whose light time is nothing and whose contact is continuous. Each of them is a parameter of a link, published by the relay in its announcement and accepted by the payer when it opens a window. Written that way, the same receipt serves a bench, a relay in lunar orbit, and a link whose other end is years away; the differences are numbers, and the thing that proves delivery is the same two signatures on every link.

A.1 Link parameters. For each link it offers, a relay publishes: the one-way light time of the link; its contact plan, which is when the link exists, for how long, and the bytes it expects to carry in each contact; its posted price per byte; its clock tolerance; the kind of window it accepts, an hour, a contact, or a transmission; its medium and range class, a wire, a point-to-point radio, LoRa, or a short-range hotspot; and the settlement domain it settles in, which is the Mint that holds its bond. A payer that opens a window accepts those parameters for that window. Nothing in them is trusted for payment. The receipt graph records what each announced contact actually settled, and a relay whose contacts persistently settle less than it announced ranks below one whose contacts match, exactly as Section 6 ranks announcements on a continuous link.

A.2 Windows and custody. On a link with a contact plan the window is the contact: it opens when the link does, closes when it does, and the receipt is per contact. The window is prepaid (Section 3.6). A relay that stores bytes during one contact in order to carry them to the next is in custody of them, and custody is nothing more than a window on the next link: the relay is paid for it by the next link's receipt, not by this one. Delay-tolerant networking removed custody transfer from the core of its bundle protocol for want of a way to make it reliable; this is that mechanism with the reason to accept custody attached. A relay accepts the bundle because the next contact's window is already paid for.

A.3 Clocks. The tolerance of Section 3.5 is a link parameter: the base tolerance, plus the link's light time both ways, plus the drift expected since the last contact. The relay's check becomes whether the payer's timestamp is plausible for a signal that left when the payer says it did. It is still the payer's clock, and a receipt outside the tolerance is still declined and its window lost.

A.4 Payment. Below a light time the membership sets, the conditional payment of Section 3.2 applies, with lock timeouts no shorter than the route's round trip. Above it, windows are prepaid and no lock is used: a lock that must run for days ties a relay's capital to a timer, and a prepaid window bounded by the payer's bond does the same work without one. The pilot is already on the prepaid side of that line.

A.5 Settlement domains. A Mint settles the links of its domain, in practice a world. A relay on a link between two domains posts a bond with the Mint on each side, and a dispute on that link is resolved by either Mint from the two receipts, since the rule of Section 3.6 needs no other input. Mints reconcile their published commitments (Section 4) whenever a link between them exists. A Mint whose commitments do not reconcile, or that has burned less than Section 3.3 requires, is slashable by the other from its own publications. The burn is enforced by the settling Mint and audited at reconciliation; the reconciliation protocol itself is open (Section 10).

A.6 Route discovery. A route between domains is not discovered; it is computed from the contact plans, as delay-tolerant networks compute routes from a contact graph, and ranked by what each relay settled in past contacts. A relay's announcement therefore says when it will be reachable, not whether it is. Liveness has no meaning on such a link, and earns nothing on any link.

A.7 What this does not change. What the protocol rewards: bytes a payer signed for and a relay carried. What it refuses to pay for: everything else. What proves delivery: two signatures on one receipt. Distance changes how long it takes to make one, not what it is.