# Bandwidth Swap: A Peer-to-Peer Bandwidth Exchange **Robert Douglas and Chris Odom** bandwidthswap@pm.me Oct 16th 2026 Version 0.3 (draft) admin@bandwidthswap.com *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.* --- **Abstract.** *A marketplace measured in available bandwidth has the possibility of identifying each pipe's market price. When pipe value can be accurately determined, and the marketplace is decentralized with a low barrier to entry, growth and development of infrastructure has the capability to be optimized by the "invisible hand," promoting robustness and consumer needs above all else. We propose improving the growth and development of communication infrastructure through a peer-to-peer network in which the settled payment for bytes is the only proof that they were delivered, directly associating incentives for hosts to build and maintain infrastructure with the speed, reliability, and uptime interests of the user.* *Proof-of-bandwidth is not an attestation that a host makes about itself. It is the settled payment of a user who received the bytes. Every hop in a route is paid per unit of data through a conditional payment that unlocks only when the next hop acknowledges delivery, so the only party who can create a proof is the party who cannot be fooled about whether the data arrived.* *Rewards flow only from fees, and a fixed fraction of every fee leaves the network for good. Generating traffic to oneself therefore costs more than it earns, and no subsidy may exceed what that fraction has collected. A treasury does not hand out bonuses for the appearance of a network; it buys bandwidth on the links it wants to exist, and only in proportion to bandwidth that paying users have already bought there.* *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.* ## 1. Introduction Communications infrastructure growth has been historically slowed by monopolies and exclusion contracts designed to restrict users' optionality such that a user is more likely to be a long-term customer of an ISP service, since ISPs pay a high initial capital expenditure to install in each area. This model protects companies' cash flow, but allows conditions that impede competition and does not promote the lowest price for the user, nor encourage innovation. Existing lines can be used for further redistribution rather than as endpoints,[^i] and many jurisdictions have already provided the legal ease to encourage just this.[^ii] We propose a fundamental improvement to this supplier-consumer relationship by offering a peer-to-peer network where bandwidth is the product. A settlement layer that makes it expensive for a bad actor to lie has the possibility to facilitate rewards and punish poor behavior. When rewards are issued only against what users have paid for, and there is a bonded barrier of entry to collect those rewards, only decentralized autonomous software is needed to govern the network. 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. When a second party that does not trust the first joins the network, a settlement layer is chosen. The candidates are a second-layer chain with native payment channels, a hub model in which each party holds one channel to a hub and the hub is a Mint, or a Lightning-like payment network with receipts kept separately from payments. The choice is made on cost per settlement, time to finality, and whether a Mint can act as a hub without becoming a custodian. Whichever is chosen, only three things touch it: the opening and closing of payment channels, the settlement summaries that Mints publish, and the slashing of bonds. Announcements never do. This keeps the settlement layer small enough that per-packet accounting never competes with it for space. 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. ## 3. Proof of Bandwidth "Proof" in a bandwidth network has to answer three separate questions, and a design that answers only one of them will be gamed on the other two. 1. **Delivery.** Did the bytes move? 2. **Demand.** Did someone real want them, or did the relay send them to itself? 3. **Quality.** Did they move at the speed and latency that was claimed? Version 0.1 of this paper answered none of these. A node reported its own uptime and available bandwidth once a minute and a Mint recorded the report. Version 0.2 replaced that model with the one below; version 0.3 adds the two rules that make it hold, the unrecoverable fee and the payment window. ### 3.1 Receipts The unit of proof is a receipt. There are two kinds. The **end-to-end receipt** is signed by the payer. For each payment window it carries the payer's and the recipient's NYMs, the Merkle root of the chunks the payer sent, the byte count, and the payer's timestamps for the first and last chunk of the window. The recipient's signature closes it. The payer's timestamps are the only authoritative ones in the route, because the payer is the one paying. 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. A relay cannot forge a receipt because every end-to-end receipt requires the payer's key, and a relay cannot inflate a receipt because the byte count is bound to a Merkle root the payer committed to. 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. ### 3.2 Payment is the proof The only party who cannot be fooled about whether bytes arrived is the party who was waiting for them. We therefore make the user's payment the proof of delivery. Every hop is paid per unit of data through a conditional payment. The payment to hop *n* unlocks only when hop *n+1* acknowledges receipt, in the manner of a hash-time-locked contract across the route. A relay that accepts a payload and does not forward it is never paid for it. A relay that forwards it is paid whether or not any validator ever looks at the transfer. A settled payment is therefore a proof of delivery that required no probing, no attestation, and no trusted hardware. Delivery (question 1) collapses into demand (question 2). 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). ### 3.3 The Sybil condition If the only way to earn is to collect fees from a payer, then sending traffic to yourself costs the protocol fee and earns nothing. Wash traffic is net negative. This is the entire defense against Sybil relays, and it is the same reason routing networks built on conditional payment do not need a separate proof of relay. 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. - Block rewards do not exist. Nothing is issued for availability, uptime, or capacity. - The Network Steward's route purchases are issued only as a match against fees already settled, from payers whose identities are bonded and aged, and never above *m*. - Route-map weight is denominated in fees paid, so inflating the map costs exactly what it would cost to buy the bandwidth. ### 3.4 Quality is priced, not proven A relay that is slow produces fewer settled bytes per payment window than a relay that is fast, and earns less. The market prices speed without the protocol having to prove it. Users choose routes from the receipt graph using the throughput that previous payers actually settled, not the throughput a relay advertises. A speed proof is required only where a subsidy is at stake, because a subsidy is the one place a relay could profit from a false claim. Version 0.2 required a client-side attestation for that tier, in the manner of TLS notarization. No protocol for it is named and its overhead is unknown, and nothing in the pilot claims a subsidy, so it is deferred: the likely replacement is to make eligibility for a subsidy depend on the age and diversity of the payers' bonds rather than on any measurement, and that is decided when there is a subsidy to protect. ### 3.5 Clocks The payer's clock is authoritative, because the payer is the one paying. Timestamps in a receipt are the payer's. A relay declines to serve a payer whose clock differs from its own by more than five seconds, and a Mint discards receipts whose timestamps are inconsistent with the chain of hops. 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. ### 3.7 Residual attacks - **Refusal to forward after accepting.** Handled by conditional payment: the hop is never paid for what it did not forward. - **A last hop that will not acknowledge.** Only possible when payer and recipient are different parties. Endpoint services, where the payer is also the recipient, do not have this problem. Relay services are between members: the recipient is a bonded NYM, and a recipient that fails to acknowledge delivered chunks is slashed. Delivery to an unbonded party on the public internet is endpoint service by definition (Section 5), and the last hop is the payer's own. - **Route inflation.** A relay that wants to appear in more paths must pay for the traffic that puts it there. Because map weight is denominated in fees, this is not an attack; it is a purchase, and *b* of the purchase is gone. - **Collusion between a payer and a relay to claim a route bonus.** Bounded by *m* at most *b*, and by the payer bond age in Section 5. - **A hop that over-claims.** The window settles at the payer's count. Measured in the lab: a hop that signed for twenty-two megabytes against a payer who signed for 272 bytes was paid for 272 bytes. ### 3.8 Alternatives considered - **Validator probing.** Mints push random payloads through relays and time them. Relays learn to recognize probe traffic and prioritize it, one pipe can masquerade as many nodes, and probes measure a relay's behavior toward validators rather than toward users. Rejected, and version 0.2's liveness check, which was the same thing by another name, is removed with the uptime penalty it served. - **Hardware attestation.** A trusted execution environment on the router counts bytes and signs. Sound, but it moves trust to a chip vendor and prices out small operators. Acceptable for a permissioned pilot, not for the open network. The pilot has not needed it. - **Signature-chain receipts alone.** Prove delivery but not demand, since every signer may be the same operator. Retained as the receipt format in Section 3.1, but only because payment, and the fraction of it that is burned, makes the chain costly to fake. ## 4. Mints A Mint does not decide whether bandwidth was delivered. That question is settled by payment before a Mint ever sees the receipt. A Mint's work is bookkeeping and enforcement: it holds the bonds of relays and payers, aggregates settled receipts, applies the dispute rule of Section 3.6, publishes settlement summaries, and publishes the receipt graph from which users choose routes. This is why it can be done for little computational energy, and why a Mint needs no particular bandwidth of its own. 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). User software queries the receipt graph that Mints aggregate for available routes, which reduces the cost of route calculation for users and removes from Mints the ability to discriminate among them. ## 5. Operators: Relays and Endpoints Operators fulfill the needs of users in the form of Relay or Endpoint services, spending computational energy and bandwidth to carry the data users pay for and collecting receipts from those users for payment. > **Endpoint services** allow a user to query a known location and extract information, whether identifiable files by hash or a Web 2.0 data stream. This interaction is similar to a user's relationship with VPNs or Usenet. The payer and the recipient are the same party, so the receipt chain closes with the payer's own signature. Delivery to any party that is not a bonded member, including the public internet, is endpoint service. > > **Relay services** carry a payer's data to another member. The recipient is a bonded NYM that acknowledges delivery (Section 3.7), and only the edge devices need be known to the payer once route privacy exists. Relay service is between members only. **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. ## 6. Announcements Announcements exist for route discovery. They carry no reward weight. Nothing in an announcement is trusted for payment, subsidy, or availability; those are determined by receipts. 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. **[Figure 2] Receipt** ``` (payer NYM, hop NYM, hop index, merkle root, bytes, t_first, t_last, prev receipt sig) signed by payer ``` 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. Open-Transactions' claims and notaries would allow a second-layer label and verification of a particular node's location or trustee, should a person or group want to announce such a claim. Nothing in the protocol depends on it, and nothing is paid for it. ## 7. Network Steward The Network Steward, a DAO,[^RD6] is purposed to seed links without bias and in such a way that it promotes healthy competition to grow the network. Its goal is to promote competition to keep prices the most competitive for users, and to encourage a high rate of innovation[^RD8] across all market segments that use the protocol. 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. The Steward never issues a reward for availability, uptime, or capacity alone. Every Steward disbursement to an operator is a purchase of bandwidth on a named link, matched against fees that a bonded payer has already settled there, at a multiple no greater than *b*. All proceeds received and spent by the DAO are reported in annual statements, to the standard set by Wyoming's Decentralized Autonomous Organizations Supplement. Funds unspent after 90 calendar days are returned to the burn and reported to the network. Each operator votes through a Mint by marking an output with its vote; proposals may be made by anyone and address the membership, leadership, goals, and spends of the registered Wyoming DAO. ## 8. Governance As this system's deployment takes up physical space, unlike software whose space is undefined, it is important that one individual's preferences do not risk injuring or inappropriately changing others' ability to act in areas they do not affect. Tests conducted in 2018 by the then developer of Open-Transactions, of location-based notary services that interfaced trustlessly via the BIP-47 payment privacy protocol, confirm the ability to associate a vote with a physical location without double voting. That combination of notary services, BIP-47, and an alternative use of Chaumian cash can guarantee that a ballot is all its holder receives, is blind, and can be cast only once. 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. We propose protecting the ideas of the community by setting strong limits on the right to vote, such as: 1. Minimum use restrictions since the last polling period;[^1] such that one must have spent a minimum amount in the ecosystem or operate a minimum number of producing nodes. 2. Minimum time restrictions since account creation; such that rash, emotional, or undeveloped requests are encouraged to be rejected. 3. 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. These restrictions have the capacity to protect the ideas of the community while awarding those with more significant capital interest tools for communication and identification without dictatorial control of any particular vote. The voting capabilities described have been developed by Voting Matters, a subsidiary of MatterFi, the current developers of Open-Transactions. ## 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. --- ## Footnotes [^1]: Possible with Pseudonyms through Open Transactions and OBPP-05 (https://github.com/OpenBitcoinPrivacyProject/rfc/blob/master/obpp-05.mediawiki) [^i]: https://en.wikipedia.org/wiki/Local-loop_unbundling#United_States [^ii]: https://web.archive.org/web/20081202153609/http://www.ictregulationtoolkit.org//en/Document.2904.pdf [^iii]: http://opentransactions.org/wiki/index.php?title=About ## Author's draft comments *The original document carried eight inline reviewer comments (RD1 through RD8). Two are kept here as footnotes. The others referred to the mining-pool analogy, the fictional exchange, sync tests, and the emission schedule, all of which version 0.3 removes.* [^RD6]: Wyoming was the first state in America to recognize a DAO LLC, under the Decentralized Autonomous Organizations Supplement passed by its legislature in March 2021. The registered name includes "DAO," "LAO," or "DAO LLC," and the Articles of Organization include a Notice of Restrictions on Duties and Transfers stating that the Supplement, the underlying smart contracts, the articles, and the operating agreement may define, reduce, or eliminate fiduciary duties and may restrict the transfer of ownership interests, withdrawal from the DAO, return of capital contributions, and dissolution. A DAO may be member-managed or algorithmically managed, the latter only where the underlying smart contracts can be updated, and the Articles must be amended when those contracts change. A withdrawn member forfeits all membership interests unless the articles provide otherwise. Case law has yet to color how a court treats a DAO's liability to creditors. Acceptance of the Network Steward as a Wyoming DAO would let it use ordinary banking to purchase bandwidth and ordinary tax reporting for what it pays operators, which is one reason the pilot settles in dollars. [^RD8]: The Steward's model for each product it seeds: 1) Prove prototype and customer acceptance. 2) Grow to the critical mass at which the customer lifecycle can be defined. 3) Open source all materials and tools that will allow other companies to compete. 4) Transfer assets to a special-purpose vehicle, Company One, and offer incentives for liabilities and talent to join it. 5) Offer seed funding for two other companies to be started to fulfill the product need. This model was executed in the creation of three state-owned, yet competing, Chinese airlines, whose case studies can be confirmed.