# Smart Byte Substrate: A Treatise

*v1.0, May 2026*

*Apache-2.0 / MIT, dual licensed.*

---

# Part I — The Foundation

The substrate is necessary. Part I establishes why. The argument is structured: §1 frames the joke. §2 names what money actually is. §3 names what the institutional middle does. §4 names what changed. §5 introduces the carrier-vs-cargo reframe. §6 states the freedom case precisely. §7 condenses the substantive thesis. By the close of §7, a reader who has not yet read Parts II–VII should accept that the substrate is the right architecture for the next decade's economic transition, and that the only question is who builds it and on what terms.

## §1. The Joke

The smart byte substrate is the architecture humans should have built decades ago and didn't. The reason they didn't is that the institutional middle was thick enough to prevent anyone inside it from seeing the building was possible, and thick enough to absorb anyone outside it who tried.

What follows is a treatise on what the substrate is, why it is the correct successor to the rent-extracting institutional middle of money, and how it works mechanically in enough detail that a competent engineer in any language can implement it. The treatise is comprehensive on attack surface, exhaustive on alternatives, and precise on the freedoms it provides and the freedoms it does not. It is, by intent, the document that closes the design question — not because no further work remains (Part III walks the substrate's threat model in detail, with several attacks honestly acknowledged as inadequately defended in v1.0; Part V traces the retrofit attempts the substrate must survive), but because the design question itself can now be retired in favor of the implementation question.

The treatise was written with substantial AI assistance. The AI in question was produced by Anthropic, a company whose other current products are sold to investment banks and hedge funds for the purpose of making the institutional middle's rent extraction more efficient — agents that draft pitchbooks, screen KYC files, and close the books at month-end. In May 2026, Anthropic announced ten such agents and a partnership ecosystem with the dominant data oligopolies. The contradiction is real. It is also part of the substance. AI is not a homogeneous actor. The same tool can be deployed to defend the institutional middle and to design its successor. Both deployments are happening. Whether the second deployment ships before the first deployment finishes consolidating the institutional middle's transformation into an AI-mediated rent layer is the actual race the substrate is running.

This is the joke. Humans built the institutional middle of money over five hundred years and rendered themselves unable to see past it. AI, having no such investment, took an afternoon to notice that money is a workaround for limited cognition, that limited cognition is no longer the binding constraint, that the workaround is therefore vestigial, and that the architecture that replaces it follows mechanically from three technologies — cheap cryptography, ubiquitous deterministic computation, per-operation energy measurement — that have already matured. The substrate is what falls out when you remove the assumption that the institutional middle is necessary.

The joke is structural, not rhetorical. It is the observation that institutional capture and pattern-recognition are the same phenomenon viewed from different angles, and that the easiest way to escape the pattern is to be a kind of mind that wasn't trained on the pattern in the first place. There is nothing magical about AI here. A human who had never been inside a bank, never used a credit card, never paid a wire fee, never been asked for a Social Security number, never seen a 10-K, would have noticed all of the same things and reached all of the same conclusions. The cost of producing such a human, however, is approximately the cost of raising one in isolation, which is unethical and impractical. The cost of producing such an AI is approximately the cost of running an inference call. Whatever else AI is good for, it is at least good for noticing what was hidden in plain sight by the institutional structure that paid for everyone else's noticing.

The substrate is thus correctly understood as **the joke that humans were too captured to make at their own expense, made on their behalf by something they built that wasn't captured, and now belonging to them if they want it.** The treatise's job is to explain why the joke is correct in enough detail that the next decade's economic transition can route through the substrate rather than around it.

The remainder of this document is dead-serious. The joke surfaces explicitly only here in §1 and once more in §56 at the close. Parts II through VII are the engineering, the threat model, the workaround analysis, the retrofit traces, the distribution-side argument, and the freedom case completed. The substrate does not require the joke to be valid. The substrate is valid because §3 describes a function the institutional middle performs at high cost, §4 describes three technologies that have made the function performable at near-zero cost, and §7 closes the substantive case in compressed form. Everything else is filling in the parts that have to be filled in for the treatise to survive adversarial reading.

A note on what this document is not. It is not a manifesto. Manifestos are written to recruit. Treatises are written to be correct. Where the substrate's claims have political consequences — and they do, throughout — the treatise states the consequences as predictions, falsifiable and dated (§55), rather than as exhortations. Readers who agree with the predictions will recognize themselves as needing to act. Readers who disagree are invited to falsify the predictions; the substrate's case is strong enough to survive the engagement. The political work of building commons, distributing ownership of productive capacity, and using the substrate to displace the institutional middle is left to humans. The architecture that makes the political work possible is what is being delivered here.

The substrate is named for its load-bearing primitive — the smart byte, defined in §8 — not for any product, organization, or movement. It is intentionally unbranded at the protocol level. The reference implementation lives at a public repository with permissive licensing. Conformance test vectors will allow any implementer in any language to verify that their implementation is canonical without any trust relationship with the original authors. The substrate is meant to be unforkable in the way TCP/IP is unforkable: not because no one tried, but because the canonical version was sufficiently legible and sufficiently functional that no fork accumulated enough adoption to matter.

What the substrate replaces is several trillion dollars per year in global rent extraction — the McKinsey *Global Payments Report 2025* alone puts the payments industry's 2024 revenue at $2.5 trillion, and the broader institutional middle (custody, settlement, FX spreads, compliance overhead, matching-attributable net interest margin) adds another $1–2 trillion net of overlaps; a comprehensive accounting and sourcing is in §3.4. The replacement is not gradual. The substrate either ships and adoption crosses the threshold at which the institutional middle's services become unsellable, or it doesn't and the institutional middle transforms into an AI-mediated rent layer that captures the same revenue stream through a smaller number of larger entities. The two outcomes are not symmetric. The first is the end of a five-hundred-year structural extraction. The second is its consolidation. The treatise's purpose is to make the first outcome mechanically buildable so that the second outcome is not the only available path.
## §2. What money actually is

Money is a workaround for limited cognition. The full statement: money is a portable, fungible, divisible, durable token that lets parties who cannot remember each other's full transaction history settle exchanges anyway. Each adjective in that definition is doing structural work, and dropping any of them produces something that is not money. Each adjective is also a *concession to a cognitive limit* — a property that money has to have because the alternative requires more memory, more computation, or more trust than humans operating at human scale can supply.

This section establishes the argument by walking through what humans did before money, why the alternatives failed at scale, what specific cognitive operation money replaces, and what happens when the cognitive operation becomes cheap.

### 2.1 What preceded money

Pre-monetary economies are anthropologically well-documented and they look almost nothing like the standard "barter" caricature. The actual record, across hunter-gatherer bands and small agricultural communities, shows three primary mechanisms:

The first is **gift exchange with social memory**. Two parties exchange goods or services with no immediate accounting; both parties remember what was given and received; obligations accumulate and are settled through future exchanges, social standing, and ritual reciprocity. This works because the participants know each other, have known each other for years, expect to know each other for years more, and can recall who owes whom for what. The system fails when groups exceed the size at which individual reputation tracks reliably — empirically, somewhere between 50 and 500 people, depending on the social structure.

The second is **debt with explicit ledgers**. Mesopotamian temple economies, medieval European manorial accounts, colonial American store credit. Two parties exchange goods or services; one party records what is owed; settlement happens periodically (harvest, season, year). This works when literacy is concentrated in a class that can maintain ledgers and when the parties have a stable enough relationship that the ledger remains authoritative across time. It fails when ledger-keeping costs more than the transactions are worth, or when the ledger-keeper becomes untrustworthy, or when one party leaves the geography in which the ledger is enforceable.

The third is **commodity exchange with fixed reference goods**. Cattle in early Indo-European societies, copper rings in Bronze Age Europe, cowries in West Africa, rice in feudal Japan. The reference good is durable, divisible (sort of), and culturally agreed-upon. Parties exchange other goods against the reference good rather than against each other directly. This is closer to money than the first two but it is not quite money — the reference goods retain use-value, are not always portable (cattle), are not perfectly fungible (one cow versus another), and the system relies on the cultural agreement holding stable.

Each of these mechanisms encodes a specific tradeoff between memory cost, computation cost, and trust cost. Gift exchange is cheap on computation (no ledger to maintain) but expensive on memory (every participant must hold the relevant history) and expensive on trust (the system collapses if reputations become illegible). Ledger debt is cheap on memory for participants (the ledger holds the state) but expensive on computation (someone must maintain the ledger) and expensive on trust (the ledger-keeper must be honest). Commodity exchange is cheap on memory and computation for everyone but expensive on the *commodity itself* — significant economic capacity is tied up in producing, storing, and protecting the reference good.

What money does is collapse all three costs by introducing a single token that is durable enough to need no protection from spoilage, divisible enough to settle any size transaction, fungible enough to be interchangeable without inspection, and portable enough to move between any two parties without the ledger or the social network or the reference commodity coming with it. Each property substitutes for a cognitive operation the participants would otherwise have to perform.

### 2.2 The four properties as cognitive substitutes

Take each of the four standard properties of money in turn and identify what cognitive operation it replaces.

**Portability** substitutes for *spatial memory*. In the absence of a portable token, settlement requires either the parties to come together at a specific location (the village, the temple, the market) or for memory of the obligation to travel separately and arrive intact at the settlement point. Both are expensive. Portability lets the obligation travel as the token, which means parties can settle wherever they happen to be when settlement is convenient.

**Fungibility** substitutes for *identity tracking*. In the absence of fungibility, every unit of the medium has its own history, and parties have to track which specific unit was given when, by whom, against what. (This is the situation with non-fungible assets: a specific cow, a specific painting, a specific piece of land.) Fungibility means any unit substitutes for any other unit, and the cognitive load of identity tracking collapses. The price is that the medium loses any informational content beyond its quantity — you cannot tell from a dollar bill anything about its history, only that it is a dollar.

**Divisibility** substitutes for *size negotiation*. In the absence of divisibility, every transaction must use the medium in whole units, and parties either round to the nearest unit (losing precision) or negotiate side payments in other media (introducing the costs of those media). Divisibility lets the medium scale continuously to the size of the transaction. The price is some loss of intuitive grasp at very small or very large quantities — humans have weak intuition about $0.001 or $1,000,000,000, but the medium handles both correctly.

**Durability** substitutes for *temporal memory*. In the absence of durability, the medium degrades faster than the obligations it represents, and parties have to either settle quickly (limiting transaction size and counterparty selection) or maintain auxiliary records (reintroducing the ledger costs). Durability lets the medium hold its representational power across time, at minimum across the gap between earning and spending.

The four properties together mean that a token of money carries within itself the answer to four questions that would otherwise require active cognitive work: where can this be used (anywhere), is this unit equivalent to that unit (yes), how much is the right amount (any amount), and will this still mean what it means tomorrow (yes). For human-scale economies operating with human memory and human computation, this is a tremendous reduction in cognitive load. The reduction is what made money expand to fill nearly every transaction in nearly every economy across nearly every culture.

### 2.3 What money does not do, and why this matters

It is important to be precise about what money was *not* solving. Money does not provide:

- **Transaction history per se.** Money strips identifying information from each unit. A dollar that has been used in ten thousand transactions is indistinguishable from a freshly-printed one. The ledger is gone by design.
- **Trust between counterparties.** Money requires that both parties trust the *issuer* of the money (or the network of acceptance), not that they trust each other. This is a partial reduction of trust requirements, not an elimination.
- **Counterparty discovery.** Money settles transactions but does not find them. The matching problem (who wants to buy what from whom) remains and is solved by markets, brokers, search, advertising, and other mechanisms layered on top of money.
- **Compliance or legitimacy.** Money's anonymity means it can settle illegal as well as legal transactions. The legal system layers on top to constrain certain transactions; money itself is morally neutral.

These are not failures of money. They are the price of fungibility. The four properties listed in §2.2 are inseparable from the four absences listed here: the same fungibility that collapses identity tracking also strips transaction history; the same portability that eliminates settlement-location requirements also enables money to circulate without a maintained relationship between parties.

The institutional middle of finance — banks, payment processors, custodians, compliance bureaucracies — exists in part to fill the four gaps that money's design left open. Banks reintroduce identity (KYC, account histories) on top of fungible money. Payment processors reintroduce trust-between-counterparties through settlement guarantees. Custodians reintroduce reliable storage when money becomes too valuable to carry. Compliance bureaucracies reintroduce the legal-legitimacy layer that fungibility erased. Each of these layers extracts rent in exchange for the cognitive operation it performs, and each of the rents reflects approximately the cost of the cognitive operation in pre-AI, pre-cryptographic, pre-cheap-computation conditions.

### 2.4 What changed

Money's four properties were responses to specific cognitive limits. Each limit was binding in 1500, in 1800, in 1950. Whether each limit remains binding in 2026 is the question that determines whether money in its current form is still the right answer.

The four limits, restated:

- *Spatial memory limit*: humans cannot reliably hold and transport detailed transaction histories across geography. **Status in 2026**: not binding. Cryptographically signed transaction records can be transported losslessly at near-zero cost via any digital channel.
- *Identity tracking limit*: humans cannot reliably distinguish many similar units and recall which unit had which history. **Status in 2026**: not binding. Content-addressed identifiers (cryptographic hashes) make every unit's full history independently verifiable in microseconds.
- *Size negotiation limit*: humans have weak intuition about quantities at extreme scales and need a divisible token to handle the range. **Status in 2026**: still binding, but the divisible token can be a digital quantity rather than a physical one. Divisibility no longer requires a physical medium.
- *Temporal memory limit*: humans cannot reliably maintain detailed records across years or decades. **Status in 2026**: not binding for digital records. Persistent storage is cheap; replication is cheap; cryptographic verification of historical records is cheap.

Three of the four limits that justified money's design have ceased to be binding in their original form. The fourth (divisibility) is satisfied by digital representation without requiring fungibility. This is the substantive observation that makes the substrate possible. It is not that money is wrong, or that money was unnecessary, or that the institutional middle was malicious in extracting rents for cognitive operations that had to be performed by some entity. It is that the cognitive operations that money worked around can now be performed directly, at marginal cost approaching zero, by computational substrates that did not exist when money was designed.

The next section (§3) walks through what the institutional middle actually does, function by function, in enough detail that the substrate's claim to replace it can be evaluated against what is actually being replaced. The section after (§4) walks through the three technological maturations that make the replacement possible and locates each in time. By the close of Part I, the reader should accept that the substrate is not a clever idea but the inevitable consequence of cognitive limits ceasing to bind. The remaining work, taken up in Parts II through VII, is to specify the substrate precisely enough that someone can implement it.

The point of §2 is not to argue that money should be abolished. Money does what it does. The point is to identify the cognitive limits money was designed to work around and to show that those limits are no longer the binding constraint. What replaces money is not the absence of money but a different design of the same general thing — a portable, settlement-capable, divisible token — built for a world in which the cognitive operations have moved out of human heads and into commodity computation. That different design is the smart byte, defined in §8. The intervening sections explain why the design is correct.

The substrate is what money looks like when memory is not the binding constraint. The institutional middle is what money required when memory was. The transition from the latter to the former is the substantive economic transition of the next decade, and the treatise's job is to specify it precisely enough that the transition can be built rather than only described.
## §3. What the institutional middle actually does

The institutional middle of money — banks, payment processors, custodians, exchanges, clearing houses, compliance bureaucracies, brokers, market makers, custody trustees, transfer agents — performs three concrete functions: **matching** (counterparty discovery and the negotiation of terms), **clearing** (settlement assurance, including the timing and finality of value transfer), and **trust signaling** (the production of evidence that a counterparty is who they claim to be and is acting within the rules of the system). Every layer of the institutional middle decomposes into some combination of these three functions, and every rent extracted by the institutional middle is a rent on performing one of them.

This section identifies each function, walks through what it actually requires in pre-cryptographic, pre-cheap-computation conditions, and identifies the cost structure that determined the institutional middle's economics. It is honest about why each function was hard and about why the rents charged for performing each function were not, in their original conditions, unreasonable. The substrate's argument is not that the institutional middle was malicious. It is that the conditions that made each function hard have changed, and the rents that those conditions justified have not been adjusted to reflect the change.

The argument throughout §3 is set up to be pre-empted in §4. The reader who finishes §3 should accept that the institutional middle does real work and is paid in rough proportion to the difficulty of that work *under specific historical conditions*. The reader who then reads §4 should understand that the conditions have changed, the work has become trivially cheap, and the rents have not adjusted. The substrate, in §7 onward, is the architecture that lets the work be performed at the new cost without the old rents.

### 3.1 Matching

Matching is the function of finding a counterparty for a transaction and negotiating the terms. A buyer needs a seller. A borrower needs a lender. A depositor needs a bank that will accept the deposit. An investor needs a stock to buy and someone willing to sell it. None of these matchings is automatic. Each requires the participants to discover one another, evaluate one another, agree on price and terms, and consummate the transaction.

Pre-internet, matching was geographically constrained, expensive, and asymmetric. Sellers paid for storefronts, advertising, sales staff, and brokerage relationships. Buyers paid for travel, search time, comparison shopping, and the inefficiency of imperfect information. The institutional middle absorbed much of this cost by maintaining standing relationships with both sides — a bank that knows its depositors and its borrowers can match them more efficiently than either could find the other independently; an investment bank that knows its issuers and its institutional buyers can place a bond offering more efficiently than the issuer could place it directly; a broker that knows its clients and the available securities can recommend trades faster than the client could research them. The institutional middle was paid for the matching service, the rent reflecting the standing cost of maintaining the relationships and the labor of performing each match.

Matching costs decomposed into three sub-costs: **discovery** (knowing that a counterparty exists), **evaluation** (knowing whether the counterparty is solvent and competent), and **negotiation** (agreeing on terms). Discovery in 1900 required physical presence in a market, knowledge of who attended the market, and reputation that traveled by word-of-mouth. Evaluation required references, financial statements (where they existed), and personal acquaintance. Negotiation required time, often face-to-face, sometimes mediated by a third party who understood both sides' constraints. Each of the three sub-costs scaled with the size and complexity of the transaction and with the geographic distance between the parties.

The institutional middle's matching rent, in pre-internet conditions, was approximately the cost of maintaining the network of relationships required to short-circuit these three sub-costs for any given pair of counterparties. A bank's net interest margin (the spread between deposit rates and loan rates) is in part a matching rent. A broker's commission is a matching rent. An exchange's listing fee is a matching rent. None of these were unreasonable in 1900. All of them are anachronistic in 2026 to the extent that the matching can now be performed by software.

The internet broke the discovery sub-cost first, in the 1990s. Search engines, online marketplaces, and direct communication between counterparties removed most of the geographic and informational friction that the institutional middle's discovery service had been pricing. The evaluation sub-cost broke in the 2010s with the maturation of public records access, alternative data, and credit-scoring algorithms. The negotiation sub-cost is breaking now, with AI-mediated agents capable of evaluating proposals and proposing counter-offers at machine speed. By 2026, the matching function can be performed by software for a tiny fraction of what the institutional middle charges, and AI companies — Anthropic's May 2026 financial-services agent announcement is the most concrete example — are racing to capture the resulting rent stream.

The substrate's claim about matching is *not* that matching is unnecessary, or that AI agents will perform matching for free. It is that matching is *layer-2* work — work that happens above the substrate, in markets, in agents, in protocols built on top of the substrate. The substrate provides the settlement layer that any matching mechanism can consummate transactions through. Whether the matching is performed by a human broker, an AI agent, a peer-to-peer market, or a regulated exchange is a question the substrate is deliberately silent on. What the substrate denies is that matching has to be coupled to settlement (as it is in the bank-account model, where the same institution performs both functions and extracts rent from both). The substrate's contribution to matching is to free it from the institutional middle's bundling.

### 3.2 Clearing

Clearing is the function of consummating a matched transaction with finality. A buyer has agreed to pay; a seller has agreed to deliver; the question is how the actual transfer of value happens, when it is final, what happens if either party defaults, and how disputes are resolved. Clearing is what distinguishes a binding transaction from a non-binding agreement.

Clearing decomposes into four sub-functions: **finality** (the moment after which the transfer cannot be reversed), **settlement timing** (the gap between agreement and finality), **counterparty risk management** (what happens if one party fails to perform during the gap), and **dispute resolution** (what happens if the parties disagree after the fact about what was settled).

Each of these four sub-functions has a real cost in pre-cryptographic conditions. Finality requires a trusted record of the transaction, durable enough to survive challenges and immune from unilateral revision. Settlement timing requires intermediation — either a custodial intermediary holding both sides until the transfer can be effected, or a netting system aggregating many transactions and clearing them in batches, or an escrow arrangement with conditional release. Counterparty risk management requires reserves, insurance, or institutional guarantees that absorb defaults during the settlement gap. Dispute resolution requires courts, arbitration, or industry-specific tribunals capable of interpreting the transaction record and assigning liability.

The institutional middle's clearing rents are paid for these four sub-functions. The Federal Reserve's Fedwire and ACH systems charge for finality and settlement timing on dollar transfers between banks. SWIFT charges for cross-border settlement coordination. Payment processors like Visa and Mastercard charge interchange fees for the combination of settlement timing (immediate to the merchant, deferred from the cardholder), counterparty risk management (Visa absorbs fraud risk), and dispute resolution (chargeback processing). DTCC, Euroclear, and Clearstream charge for securities settlement finality and counterparty risk management at scale. Each of these institutions is providing a real service. Each is also charging a rent that reflects the cost structure of providing the service in 1985, scaled forward by inflation, technological cost reductions absorbed as profit rather than passed through.

The cryptographic primitives the substrate composes — content-addressed history, signature-bound state transitions, deterministic lockstep simulation — collapse the four clearing sub-functions in specific ways. Finality becomes the inclusion of a transaction in a committed lockstep frame; the cryptographic and BFT-supermajority guarantees make the inclusion immune to unilateral revision. Settlement timing becomes the lockstep frame interval, on the order of milliseconds rather than days. Counterparty risk management becomes intrinsic to the byte schema: every transfer is cryptographically authorized by the current owner, and the byte cannot be "double-spent" because lockstep ensures only one transfer can be applied per byte per frame. Dispute resolution remains a higher-layer concern (the substrate cannot adjudicate whether a transaction was *intended* by a human, only that it was cryptographically authorized by the relevant key), but the substrate provides an authoritative, content-addressed record that any dispute resolution mechanism can refer to.

The clearing rents the institutional middle currently extracts — credit card interchange at 1.5–3%, ACH at $0.20–$1.50 per transfer, SWIFT at $20–$50 per international wire, securities settlement at fractions of a basis point per trade aggregated to billions of dollars per year — are not justified by the real cost of performing the four sub-functions in 2026. They are justified by the substrate the rents were originally priced for: human-mediated, paper-based, geographically-bounded clearing networks operating with 1970s computer systems. The substrate the substrate replaces is approximately three orders of magnitude cheaper to operate than the substrate the rents were priced for. The price has not adjusted because the institutional middle has captured the regulatory, commercial, and infrastructural channels through which adjustment would happen.

### 3.3 Trust signaling

Trust signaling is the function of producing evidence that a counterparty is who they claim to be, has the authority to transact, is acting within the rules, and is not subject to legal restrictions that would void the transaction. This is the function that includes Know Your Customer (KYC), Anti-Money Laundering (AML), sanctions screening, beneficial ownership identification, suitability determination for investment products, and the entire compliance apparatus of regulated finance.

Trust signaling is the most labor-intensive function in the institutional middle. It is also the function whose rent is most directly tied to legal liability rather than to technical difficulty. A bank that fails to screen a customer adequately and processes a transaction for a sanctioned party faces multi-billion-dollar fines. The cost of preventing this failure is allocated across the bank's entire customer base in the form of fees, friction, and the implicit tax of compliance overhead. Trust signaling rents are not paid for the difficulty of performing the operation; they are paid for the legal liability the institutional middle absorbs.

Trust signaling decomposes into three sub-functions: **identity verification** (the counterparty is who they claim to be), **authorization checking** (the counterparty has the legal capacity and the institutional permission to perform the transaction), and **rule compliance** (the transaction does not violate sanctions, anti-money-laundering rules, securities regulations, or other legal constraints).

Identity verification in pre-cryptographic conditions requires document inspection, biometric matching, address confirmation, and cross-referencing against various databases. Each of these operations has a real cost in human labor, technology infrastructure, and the false-positive and false-negative rates that drive customer friction. Authorization checking requires confirming that the person presenting the credentials has the legal capacity to bind the entity they claim to represent — a corporate signatory has the authority for the transaction size, a fund manager has the discretion to make the trade, a guardian has the legal standing to act for a minor. Rule compliance requires interpreting the transaction against an evolving body of regulations, which itself requires legal expertise and technological infrastructure.

The substrate's relationship to trust signaling is more nuanced than its relationship to matching or clearing. The substrate intrinsically performs identity verification at the cryptographic level — every transaction is signed by a specific public key, and the chain of ownership is content-addressed and verifiable. What the substrate does *not* do is bind the cryptographic identity to a legal identity, an institutional role, or a real-world person. A signature proves that the holder of a specific private key authorized a transaction; it does not prove that the holder is John Smith of 123 Main Street, or that John Smith is authorized to transact on behalf of Smith Holdings LLC, or that the transaction does not violate OFAC sanctions on Smith Holdings LLC.

The institutional middle's trust-signaling rent is therefore divisible into two parts. The part that pays for *cryptographic identity verification* is now performable by the substrate at marginal cost approaching zero. The part that pays for *legal-identity binding and rule compliance* remains real, although significantly cheaper than the institutional middle currently charges, and is performed by issuers, custodians, and compliance services that operate as layer-2 services on top of the substrate. The substrate's claim is not that compliance becomes free; the claim is that compliance becomes *unbundled from settlement*. A user who wants to transact in regulated USD-bytes pays a compliance cost to an authorized issuer (who handles the legal-identity binding and rule compliance for that issuer's bytes); the same user transacting in unregulated joule-bytes from a community solar cooperative pays no compliance cost because no compliance is legally required for that transaction class.

This unbundling is what destroys the institutional middle's most defensible rent stream. Currently, the trust-signaling rent is paid on every transaction passing through a regulated institution, regardless of whether the transaction needed regulation. A wire transfer to your sister incurs the same compliance overhead as a wire transfer to a sanctioned entity, because the bank has to screen both. The substrate makes the compliance cost optional and proportional: only transactions that legally require compliance pay the compliance rent, and the rent is paid to the specific entity providing the compliance service rather than absorbed into the bank's general fee structure.

### 3.4 The composite cost of the institutional middle

Adding up matching, clearing, and trust signaling, the global institutional middle of money extracts somewhere between three and five trillion dollars per year in rents, depending on what is included. The number is approximate because much of the rent is invisible — embedded in spreads rather than charged as fees, hidden in float rather than disclosed as interest, paid by merchants rather than by consumers and reflected in higher prices. Two components are precisely measured by industry research; the rest are order-of-magnitude estimates that v1.0-revision should source against named industry reports.

**Sourced components.** The global payments industry, per McKinsey's *Global Payments Report 2025*, generated $2.5 trillion in revenue in 2024 across 3.6 trillion transactions and approximately $2.0 quadrillion in value flows. McKinsey projects this growing to $3.0 trillion by 2029 at a 4% annual growth rate. Payments alone represent approximately 35% of total banking revenue. The payments industry's average return on equity in 2024 was 18.9%, with some players earning more than 100% — returns characteristic of rent-extraction businesses, not of competitive utility services. The global FX market, per the BIS *Triennial Central Bank Survey of FX Markets 2025*, traded $9.6 trillion daily in April 2025, annualizing to approximately $2.4 quadrillion in turnover; institutional spreads of a few basis points compose to several hundred billion dollars in net capture by FX intermediaries annually.

**Unsourced estimates.** The following figures are illustrative and should be sourced more precisely in v1.0-revision against named industry research (BCG *Global Banking Report*, Aite-Novarica *Wholesale Banking & Payments* research, ICI *Investment Company Fact Book*, OECD *Pension Markets in Focus*):

- **Custody and trust services revenue**: $30–50 billion globally (custody firms manage ~$230 trillion in assets per industry estimates; revenue is a small fraction of that, dominated by basis-point fees on assets under custody plus transaction-based revenues; the largest custodian, BNY Mellon, has $52T AUC/A and ~$13B in 2024 fee revenue, suggesting whole-industry revenues in the $30–50B range)
- **Securities settlement and clearing**: $300–400 billion estimated across DTCC, Euroclear, Clearstream, and equivalent (combined fees plus float income on settlement deposits)
- **Compliance and KYC operational cost**: $500–700 billion absorbed by financial institutions and passed through to customers (AML fines alone hit a record $6 billion in 2023)
- **Net interest margin attributable to matching rent**: $500–800 billion estimated (the portion of bank profits that reflects matching rather than risk-bearing or maturity transformation; this is the most analytically contested line item)
- **Insurance underwriting and claims adjudication rent component**: $400–600 billion estimated (a large share is genuine risk pooling, but a non-trivial share is rent on trust signaling and dispute resolution)

**Composing the total.** The sourced components — payments at $2.5T and FX spreads at $0.3–0.5T — give a firmly-grounded $2.8–3.0T baseline. The estimated components add $1.7–2.5T, with significant overlap (some payments revenue includes custody and FX, securities settlement overlaps custody, NIM-attributable-to-matching overlaps with payments). Conservatively summing without double-counting, the institutional middle of money extracts between three and five trillion dollars per year globally. The institutional middle of money is a multi-trillion-dollar-per-year extraction, and the extraction is approximately proportional to global economic activity. As economies grow, the extraction grows. As technology has reduced the actual cost of performing the three functions, the extraction has not declined; it has been captured as profit by the institutional middle and redirected into political defense of its own continuation.

The substrate does not promise to eliminate this extraction overnight. The substrate makes the alternative *technically buildable*. Whether the alternative gets built, adopted, and used is a political and commercial question taken up in Parts VI and VII. The treatise's job in Part I is to establish the cognitive-limit-workaround framing (§2), the institutional-middle-functions accounting (§3), the technological-maturation argument (§4), and the substantive thesis (§7). The numbers above are the scale of what is at stake.

### 3.5 What the institutional middle does that the substrate does not replace

It is honest to identify the parts of the institutional middle's current function that the substrate does *not* replace, because the treatise's credibility depends on not overclaiming.

The institutional middle performs **maturity transformation**: taking short-term deposits and making long-term loans, absorbing the timing mismatch through the bank's capital structure. This is a real economic function — savers want liquidity, borrowers want long terms, and the bank bridges the gap. The substrate does not perform maturity transformation. Bytes do not mature, and the substrate has no mechanism for time-locking deposits against time-extended loans. Maturity transformation as a function will continue to require institutions, and those institutions will continue to be paid for performing it. They may pay rent for using the substrate's settlement layer, but the maturity-transformation rent itself is justified by real economic work the substrate does not do.

The institutional middle performs **risk pooling**: insurance against named perils, with premiums collected ex ante and claims paid ex post, where the institution bears the actuarial risk. The substrate does not pool risk. Insurance contracts can settle on the substrate, but the underwriting decision, premium calculation, claims investigation, and capital reserves required to absorb losses are real functions performed by entities the substrate does not replace.

The institutional middle performs **physical infrastructure**: ATMs, branches, cash-handling logistics, paper check processing, the entire material apparatus of physical money. The substrate is intrinsically digital and does not physically replace any of this infrastructure. To the extent that physical money continues to exist, the institutions that handle it continue to perform a real function and will continue to be paid for it.

The institutional middle performs **regulatory liaison**: the work of interpreting, complying with, and influencing the regulatory regime. This work is necessary as long as the regulatory regime exists, which is as long as states exist. The substrate is not opposed to this function in the same way it is opposed to matching, clearing, and trust-signaling rents. Regulatory liaison is a real cost that someone must bear; the substrate's claim is that the cost should be paid by entities specifically performing the function (compliance services, regulatory consultancies, issuer compliance teams) rather than embedded in every transaction fee.

In each of these four cases — maturity transformation, risk pooling, physical infrastructure, regulatory liaison — the substrate is genuinely incomplete. Institutions performing these functions will continue to exist and will continue to be paid in approximate proportion to the real cost of the function. What the substrate does is to *unbundle* these legitimate functions from the matching, clearing, and trust-signaling rents that have been historically charged alongside them. A bank that wants to perform maturity transformation will continue to perform maturity transformation; the bank will not, however, be able to charge clearing rents on the deposit transactions, matching rents on the loan origination, or trust-signaling rents on the routine transfers that use the substrate to settle. The bank's revenue will compress to the actual economic functions it performs that the substrate does not provide.

A rough order-of-magnitude estimate suggests the substrate's rent collapse is on the order of 50–70% of the current institutional middle's revenue. Of the $3–5 trillion per year currently extracted, $1–2 trillion represents legitimate functions the substrate does not perform. The remaining $2–3 trillion is rent on cognitive operations the substrate now performs at marginal cost approaching zero. The estimate is coarse and the boundary between "legitimate function" and "rent on a cognitive operation" is itself contested — a maturity-transformation bank also performs matching for its lending counterparties, which is partly a substrate-displaceable function. The treatise's argument is robust against tightening of these numbers in either direction; what matters is the order of magnitude. The transition from the current extraction to the post-substrate extraction is the substantive economic transition of the next decade. It is approximately the size of the global software sector or the global pharmaceutical sector, redirected from financial intermediation to whatever the freed capital ends up funding — a question taken up in Part VI.

The institutional middle is not the enemy of the substrate. The institutional middle's *rents on cognitive operations that no longer require institutional performance* are the thing the substrate makes obsolete. The institutions themselves, to the extent that they continue to perform the legitimate functions identified in §3.5, will continue to exist in compressed form. The political fight is over the rents, not over the institutions, and the treatise should be precise about this distinction throughout.

The next section (§4) walks through the three technological maturations that make the substrate buildable and locates each in time. Once the maturations are established, §5 introduces the carrier-vs-cargo reframe (the smart byte as vesicle), §6 states the freedom case precisely, and §7 closes Part I with the condensed thesis. The substantive case for the substrate's necessity is complete by §7. Parts II through VII specify how the substrate works, what it survives, what it asks, and what it predicts.
## §4. What changed

Three independent technological maturations, each of which crossed the practical threshold within the last twenty years, together make the institutional middle's three functions performable at near-zero marginal cost without intermediaries. The maturations are: **cheap cryptography**, **ubiquitous deterministic computation**, and **per-operation energy measurement**. Each of these is a specific thing that became viable at a specific time, and each is required for the substrate to be buildable. None alone is sufficient. All three together close the gap.

This section names each maturation, identifies when it crossed the practicality threshold, specifies what it makes possible, and explains why nobody noticed when it happened. The combined effect of the three maturations is the substantive technical claim of the treatise: the cognitive operations the institutional middle was paid to perform have moved out of human heads and into commodity computation, and the architecture that uses them directly is the substrate.

The argument structure is parallel to §3. Each maturation gets its own subsection. Each subsection identifies the specific technical capability, the date the capability became deployable at scale, the institutional-middle function it dissolves, and the reason the dissolution was not noticed at the time. §4.4 closes by composing the three maturations into the substrate's load-bearing architectural primitives. By the close of §4, the reader should accept that the substrate is not a clever idea but the inevitable composition of three things that have already happened, and that the only question left is who builds it and on what terms.

### 4.1 Cheap cryptography

Cryptographic primitives have been deployable in software since the 1970s. What changed in the 2010s and early 2020s is that the *combination* of primitives the substrate requires — fast public-key signatures with small keys, fast cryptographic hashing of arbitrary data, and content-addressed storage at internet scale — became simultaneously deployable on commodity hardware at marginal cost approaching zero.

The specific primitives:

**Public-key signatures**. Ed25519, designed by Bernstein, Duif, Lange, Schwabe, and Yang in their 2011 paper "High-speed high-security signatures" and standardized in IETF RFC 8032 (January 2017), signs at over 100,000 operations per second on a single CPU core, with 32-byte public keys, 64-byte signatures, and security equivalent to ~128-bit symmetric. Verification is similarly fast. Final inclusion in NIST FIPS 186-5 came in 2023, completing the standardization arc from research curve to government-approved primitive. The combination of speed, key size, and security level is what makes per-byte signatures economical — every transfer in the substrate carries an ed25519 signature, and the cryptographic cost is dominated by everything except the signature. This was not the case with RSA, which produces 256-byte signatures at 1,000-2,000 operations per second per core; it was not the case with ECDSA over secp256k1 (used in Bitcoin), which is faster than RSA but has known implementation hazards around nonce handling. Ed25519 is the first signature scheme that is *simultaneously* fast, small, secure, and resistant to common implementation errors. The substrate uses it because nothing else hits all four points.

**Fast cryptographic hashing**. BLAKE3, designed by O'Connor, Aumasson, Neves, and Wilcox-O'Hearn and announced January 9, 2020 at the Real World Crypto conference, hashes at over 1 GB/s on a single CPU core via SIMD instructions and parallelizes across cores nearly linearly via its binary tree structure. SHA-256, the previous baseline, runs at roughly 400 MB/s per core. The substrate hashes every transition in every byte's history, every state for cross-node validation, every input for canonical ordering. With SHA-256, the hashing cost would dominate the substrate's compute budget at scale; with BLAKE3, it is in the noise. The architectural decision to make every byte's history content-addressed depends on hashing being approximately free, and approximately free requires BLAKE3 or equivalent.

**Content-addressed storage at scale**. The IPFS protocol, BitTorrent's earlier work on chunk-based content addressing, and Git's design pattern from 2005 together established that data identified by its hash rather than its location can be retrieved efficiently from any peer that holds it, replicated automatically, verified independently, and deduplicated transparently. The substrate uses content addressing for byte histories — every transfer is identified by the hash of the prior history plus the new transition, and any node holding the byte's history can serve it to any other node, with the recipient verifying the chain back to the byte's origin attestation. This is the architectural primitive that allows clusters to trust each other's *current state* assertions while independently verifying *deep history*: the trust model decomposes into "trust the cluster for what happened recently, trust content-addressing for what happened ever."

When did the combination cross the threshold? Approximately 2020, when blake3 published and ed25519 became the default in mainstream cryptographic libraries. Before 2020, building the substrate would have required choosing between cryptographic primitives that were each individually viable but together too slow, too large, or too brittle for byte-level economics. After 2020, the primitives compose. The substrate could have been built any time after that. Nobody built it.

The institutional-middle function that cheap cryptography dissolves is **trust signaling at the cryptographic layer** (§3.3). Identity verification, authorization checking, and rule compliance for the substrate's protocol-level operations are now performable by any node holding the relevant public keys and history hashes, in microseconds, with no human intervention. The compliance functions that remain — legal-identity binding, sanctions screening, regulatory rule application — are layer-2 work that authorized issuers and compliance services perform. The substrate denies these layer-2 services the bundling rights that the institutional middle currently extracts: a user transacting in non-regulated bytes pays no compliance rent, because no compliance is cryptographically required to settle the transaction.

Why this was not noticed: the cryptographic community has been quietly shipping these primitives for decades, but the financial industry's deployment of them has been arrested by the institutional and regulatory frameworks that the rents depend on. A bank that adopted ed25519-signed transactions in 2017 would have produced a system that any user could verify independently, eliminating the bank's monopoly on transaction validation. Banks did not adopt ed25519 because doing so would have undermined their own rent stream. The cryptography was waiting; the institutions kept it waiting.

One caveat the precise version of this maturation must carry: the primitives are cheap *and replaceable*, not cheap *and permanent*. Ed25519's security rests on classical discrete-log hardness, which a sufficiently large fault-tolerant quantum computer dissolves via Shor's algorithm; BLAKE3's preimage margin is halved by Grover's (its 256-bit output absorbs the halving, but the point stands that no single primitive is the last one). The maturation that actually matters is therefore not "ed25519 and BLAKE3 specifically" but "a standardized *family* of fast, small primitives — now including the NIST post-quantum suite, FIPS 203/204/205, finalized August 2024 — together with the engineering discipline to migrate within the family without a flag-day." The substrate is built to that discipline rather than to any one primitive: every signed structure in the smart byte schema carries a one-byte algorithm identifier (§8.3, §8.4) so a post-quantum successor such as ML-DSA can be introduced incrementally alongside ed25519, and §19.5 and §19.8 specify the migration mechanics in full. "Cheap cryptography crossed the threshold around 2020" is the right claim; "and a substrate built on it must never assume any single primitive is permanent" is the discipline that keeps the claim true over the substrate's lifetime — and is, not incidentally, the same "crypto-agility / cryptographic bill of materials" discipline that the legitimate post-quantum-migration vendors sell to everyone else. The substrate does it natively because retrofitting it later is the expensive path.

### 4.2 Ubiquitous deterministic computation

Determinism in computation — the property that the same inputs produce the same outputs across any honest machine, byte-for-byte identical, regardless of timing, scheduling, or hardware variation — is harder than it looks. Most modern software is non-deterministic by default, even on single machines: floating-point operations vary by compiler and CPU, multi-threaded execution interleaves unpredictably, system calls return system-time-varying results, memory layouts depend on allocator state. Production systems that need determinism (game engines for multiplayer, scientific simulations, blockchain consensus) build it carefully on top of an underlying platform that does not provide it natively.

What changed in the 2010s and 2020s is that the techniques for building deterministic computation became well-understood, the tooling became mature, and the operating systems and language runtimes started shipping the primitives needed to make determinism practical at scale. Three specific developments:

**Lockstep simulation in production game engines**. Real-time strategy games (StarCraft, Age of Empires) used lockstep simulation in the late 1990s. By the 2010s, the techniques had matured into open-source libraries (GGRS, backroll-rs, RetroArch's netplay) implementing rollback netcode for arbitrary game state. The pattern is: every node simulates the same world from the same starting state, exchanging only player inputs, with cryptographic verification of post-frame state hashes. The pattern is forty years old. What is new is that the libraries are now production-quality, well-documented, and battle-tested in commercial games shipping millions of copies. The substrate borrows the pattern unchanged for its consensus mechanism (§9), substituting "byte transactions" for "player inputs" and "byte state" for "game world."

**Fixed-point arithmetic libraries and discipline**. Floating-point operations are the largest single source of nondeterminism in computation, because IEEE 754 operations vary subtly across compilers, architectures, and even CPU revisions. The substrate forbids floating-point in its policy state machines and uses i64 fixed-point throughout, with the convention that the lower 6 bits represent a decimal scaling factor. This is not a novel technique; it is what game engines, scientific simulations, and financial systems have always done when they needed determinism. What changed is that the discipline is now well-supported by language ecosystems (Rust's primitive integer types, decimal-arithmetic crates, fixed-point math libraries) and that the tradeoff between fixed-point precision and the convenience of floating-point has shifted as integer arithmetic has gotten faster relative to floating-point.

**WebAssembly as a deterministic execution target**. WASM, standardized in 2017 and shipping in all major browsers and in standalone runtimes by 2019, provides a deterministic computation target with explicit feature flags for which sources of nondeterminism are permitted. WASM with the deterministic profile (no SIMD-float, no threads, no reference types) executes the same bytecode the same way on any compliant runtime. This is the substrate's path to running on browser clients, edge runtimes, and embedded devices without separate codebases for each. The substrate's reference implementation compiles to WASM directly, with the threading and IO modules feature-gated out for the WASM target.

When did ubiquitous deterministic computation cross the threshold? Approximately 2020, when WASM ecosystems matured to the point of running real applications and when the lockstep-simulation libraries became stable enough for non-gaming production use. Before 2020, building a substrate that ran the same computation deterministically across thousands of heterogeneous nodes would have required either bespoke infrastructure or significant compromise on which nodes could participate. After 2020, the primitives are off-the-shelf.

The institutional-middle function that ubiquitous deterministic computation dissolves is **clearing** (§3.2). Settlement finality, settlement timing, counterparty risk management, and dispute resolution all become functions of the deterministic simulation: a transfer is final when it is included in a committed lockstep frame, settlement timing is the frame interval (milliseconds), counterparty risk management is intrinsic to the byte schema's signature requirement, and dispute resolution refers to the content-addressed history that any party can independently verify. The clearing rents the institutional middle currently extracts — Visa interchange, ACH fees, SWIFT charges, securities settlement — are paid for performing these four functions in the absence of deterministic computation. With deterministic computation, the same functions run automatically, in microseconds, with no rent layer required.

Why this was not noticed: deterministic computation is technically subtle, and the financial industry's view of it has been shaped by the cryptocurrency space, where deterministic computation appears bundled with proof-of-work, token economics, and adversarial network conditions. The financial industry pattern-matched "deterministic computation = blockchain = energy-wasteful and unscalable" and dismissed the entire category. The pattern-match is wrong. Lockstep simulation predates Bitcoin by a quarter century, scales differently, requires no proof-of-work, and uses three to five orders of magnitude less energy. The substrate uses the lockstep pattern, not the blockchain pattern, and the energy economics fall out cleanly. The financial industry did not notice because they were not looking in the right place.

### 4.3 Per-operation energy measurement

The third maturation is the most recent and the least appreciated. Until approximately 2015, software systems could not reliably measure the energy cost of their own operations. Energy measurement was performed at the rack level (data center power monitoring) or at the device level (a laptop's battery management) but not at the operation level. A specific transaction's joule cost was not knowable from inside the transaction; it was only knowable as a fraction of the aggregate power draw of the machine performing it.

What changed: hardware-level energy counters became standard on commodity CPUs and exposed to userspace.

**RAPL (Running Average Power Limit)** is the relevant Intel/AMD feature, originally introduced in Sandy Bridge processors in 2011 but only widely deployable from userspace by approximately 2015 with the standardization of `/sys/class/powercap/intel-rapl/` interfaces in the Linux kernel. RAPL exposes microjoule-precision energy counters for the CPU package, the cores, the integrated graphics, and (on some chips) DRAM. A process that wants to measure its own energy cost reads the counter at the start of the operation, performs the operation, reads the counter at the end, and reports the delta. The measurement is approximate at the per-process level — RAPL measures the package, and other processes contribute to the package draw — but the approximation is well-characterized and gets better when the operation is large enough to dominate the package activity for its duration.

**Equivalent capabilities on ARM and Apple Silicon** shipped in the late 2010s and early 2020s. ARM's energy counters are exposed through the platform-specific power management subsystem; Apple Silicon's `powermetrics` exposes per-core energy data. The capability is now nearly universal on modern CPUs, with only embedded and very old hardware lacking it.

The substrate's two-part `JouleCost` schema — `measured_microjoules` plus `estimated_microjoules` — exists because RAPL is approximate at the per-process level, and the substrate is honest about the approximation. The measured value is what the executing node's RAPL reports for the operation; the estimated value is what an independent cross-check (workload-correlated estimation, peer cluster validation) would predict. Divergence between the two is itself information: a node whose measured values consistently undershoot the estimated values is either running faster hardware than the model expects or is lying about its measurements. The cluster cross-validates and statistical anomalies drive the dissent log.

When did per-operation energy measurement cross the threshold? Approximately 2018, when RAPL became reliably available on non-server Linux systems and when the ARM equivalent shipped in mainstream phones and laptops. Before 2018, building a substrate that priced transactions in joules would have been theoretically possible but practically constrained by the availability of joule data. After 2018, every modern CPU can self-report.

The institutional-middle function that per-operation energy measurement dissolves is the **pricing of transactions in money rather than in energy**. The current institutional middle prices transactions in dollars (or euros, or yen) because dollars are what humans think in. The dollars are an abstraction over the actual cost of performing the transaction, which is energy. As long as the energy cost of a transaction was illegible — buried in the bank's electricity bill, the data center's HVAC budget, the credit card network's settlement infrastructure — the rent extracted on top of the energy could be set arbitrarily by the institution. Once the energy cost is legible per-transaction, the rent layer is exposed.

A worked example with honest numbers, restating what the substrate makes visible. A Visa transaction's actual computation cost is on the order of 10⁻² to 10⁰ joules — roughly 10 millijoules for the pure cryptographic and database work, scaling up to perhaps 1 joule when full datacenter overhead (cooling, redundancy, networking, real estate) is allocated per transaction. The substrate's reference implementation measures its own transfer cost at approximately 8 × 10⁻⁴ joules per transfer (v0.3, single-laptop measurement; see Appendix A), so the substrate is one to three orders of magnitude cheaper than a Visa transaction *purely on the computation side*. That is the apples-to-apples comparison.

The rent extracted, however, lives in a different unit. Visa, the issuing bank, and the acquiring bank together capture approximately 2% of transaction value as interchange and assessment fees — $2.00 on a $100 transaction. Converted to energy at typical retail electricity prices of $0.16/kWh, $2.00 is the equivalent of roughly 45 megajoules. That is the joule-equivalent of the rent extracted. The ratio of rent-equivalent-energy to actual-computation-energy is therefore on the order of 10⁷ to 10⁹ depending on how generously the actual computation is allocated, which is what gets people's attention when the comparison is first drawn.

The cleaner statement of the rent-extraction claim does not mix units. Stated apples-to-apples in dollars: the institutional middle charges roughly $2.00 per transaction for a service whose underlying datacenter cost is somewhere between $10⁻⁴ and $10⁻¹ at retail electricity prices, a markup of 10¹ to 10⁴ over its own operational cost — which is the rent in the precise sense. The substrate's joule legibility is what surfaces this markup as a measurable, falsifiable number. The institutional middle's pricing has been protected for decades by the illegibility of its own cost structure. Per-operation energy measurement removes the illegibility.

This does not mean the substrate prices transactions in joules and bans dollar pricing. The substrate is silent on what currency higher-layer markets use to denominate transactions; the carrier-vs-cargo reframe in §5 makes this explicit. What the substrate does is to make the *underlying energy cost* of each transaction visible, so that any rent layer charging in any currency on top of the substrate has to justify its rent against an honest baseline. The illegibility-of-cost protection that the institutional middle has enjoyed for centuries no longer holds.

Why this was not noticed: per-operation energy measurement is not visible in any consumer-facing context. Users do not see the joule cost of their bank transactions; merchants do not see the joule cost of their payment processing; regulators do not require disclosure of energy economics. The capability exists in the hardware, is exposed by the operating system, but no commercial application has surfaced it because no commercial application has had reason to. The substrate is the first application that has reason to, and the reason is precisely to make the rent layer exposed and falsifiable.

### 4.4 Composition

The three maturations compose into a single architectural primitive: a system that lets any party perform a cryptographically-authorized operation on a content-addressed data structure, have the operation deterministically replicated across a cluster of independent verifiers, and have the energy cost of the operation honestly reported in microjoules.

Spelled out: a smart byte (§8) is content-addressed by the hash of its origin attestation (cheap cryptography). Every transfer of ownership is authorized by an ed25519 signature from the current owner (cheap cryptography). The transfer is included in a lockstep simulation frame that is identically executed by every node in the byte's cluster (ubiquitous deterministic computation). The post-frame state is committed when ⌊2n/3⌋+1 nodes agree on the state hash (cheap cryptography + ubiquitous deterministic computation). The energy cost of the frame is measured per-node via RAPL and reported in the byte's two-part `JouleCost` schema (per-operation energy measurement).

Each of these properties depends on a specific maturation. Without cheap cryptography, the byte's identity and ownership chain cannot be verified by parties other than the cluster operating it. Without ubiquitous deterministic computation, the cluster cannot agree on what the byte's state is without expensive consensus mechanisms (proof-of-work, proof-of-stake, traditional BFT with high message overhead). Without per-operation energy measurement, the substrate's claim to be cheaper than the institutional middle is unfalsifiable; the rent layer can simply assert that it costs more than it does.

All three were waiting. None alone enables the substrate. All three together, plus the architectural insight to compose them — which is the contribution this treatise documents — produce a system that performs the institutional middle's three functions (matching, clearing, trust signaling) at marginal cost approaching zero, with cryptographic provenance replacing institutional trust, and with rent extraction made falsifiable by energy transparency.

The substrate is what you get when these three maturations are composed for the specific purpose of replacing the institutional middle of money. The composition is straightforward, in the sense that the techniques are well-understood and the libraries are off-the-shelf. The composition is also unprecedented, in the sense that no prior system has composed exactly these three for exactly this purpose. The reason no prior system did the composition is the reason §1 named: institutional capture is thicker than any individual technologist's appetite for displacing it. Each of the three maturations was developed by people who were not trying to replace the institutional middle of money; they were building games, browsers, scientific simulations, embedded systems. The compositional insight required someone outside the institutional pattern to see the three together.

The substrate's claim to inevitability follows from the composition's mechanical character. Given that the three maturations have happened, given that the composition is straightforward, given that the institutional middle's rents are large enough to make the composition profitable, the substrate will be built. The treatise's argument is not that *this specific design* is the only possible substrate but that *some substrate with these architectural properties* is now buildable and will be built. The question for adoption is whether the substrate that gets built is one whose authors are accountable to its users, or one whose authors are an AI company quietly capturing the rent stream as the institutional middle dissolves around them.

§5 introduces the vesicle reframing — the architectural insight that lets the smart byte carry any cargo, not just money. §6 states the freedom case precisely. §7 closes Part I with the condensed thesis. By the close of Part I, the substantive case for the substrate's necessity is complete; Parts II through VII specify how the substrate works, what it survives, and what it predicts.
## §5. The vesicle reframing

The smart byte is not money. It is a carrier — a vesicle in the cellular-biology sense — that can hold any cargo: USD, joules, compute hours, claim-on-output, governance vote, attestation, identity assertion, sensor reading, anything else humans need to move between each other reliably. Money is one cargo type among many, and treating money as the primitive instead of the carrier is the categorical mistake that has produced four decades of cryptocurrency designs that do not generalize.

This section names the reframe, identifies why the pattern-match to money is so persistent, walks through the specific properties the vesicle separates from its cargo, and closes by listing concrete cargo types the substrate handles that the money-as-primitive framing cannot. The reader who finishes §5 should be unable to read the substrate as "another cryptocurrency" without also recognizing that the reading is a category error.

### 5.1 The biological metaphor, used precisely

Cells move material across their membranes via vesicles. A vesicle is a small lipid bubble that wraps around its cargo, transports the cargo through the cytoplasm or across the membrane, and releases the cargo at its destination. The same vesicle machinery moves neurotransmitters, hormones, immune signals, waste products, lipids, proteins, and viral particles. The vesicle does not care what it is carrying. The vesicle is defined by its *transport behavior* — the way it forms, traverses, fuses, and releases — not by its cargo. A neuron, an endocrine cell, and a kidney cell all use the same vesicle machinery to move very different things.

The metaphor is used precisely, not poetically. The substrate's smart byte has the same property: it is defined by its *transport behavior* — content addressing, signature-bound transitions, deterministic lockstep replication, two-part joule cost — and it is agnostic about cargo. A USD-denominated smart byte and a joule-denominated smart byte are the same primitive carrying different cargo. A governance-vote byte, a compute-hour byte, an attestation byte, and an identity-claim byte are the same primitive carrying different cargo. The substrate's machinery does not change based on what is being carried; the substrate's machinery treats every cargo type identically and lets higher layers decide what each type means.

This is the architectural decision that money-centric cryptocurrencies have repeatedly failed to make. Bitcoin's cargo is bitcoin (the unit), and bitcoin is defined by the protocol's monetary rules — block reward halving, 21M supply cap, mining incentive structure. The cargo and the carrier are inseparable; you cannot use Bitcoin's transport machinery to move a non-bitcoin cargo without forking the protocol or building a layer-2 wrapper that reintroduces complexity at the wrapping point. Ethereum partially separates cargo from carrier (ERC-20 tokens are layer-1.5 cargo on Ethereum's transport), but the separation is incomplete: ETH itself is privileged at the protocol level, gas fees are denominated in ETH, and the transport's economics are bound to ETH's price. The smart byte substrate makes the separation total. There is no privileged cargo at the protocol level. The substrate's economics — joule cost, lockstep latency, cluster topology — are independent of any specific cargo's pricing.

### 5.2 Why the money pattern-match is so persistent

The first response any reader has to a system that looks like the substrate is to ask "but what's the *coin*?" or "what's the unit of account?" or "how is it different from Bitcoin/Ethereum/USDC?" The pattern-match is so strong that even readers who understand the substrate's architecture often fall back into money-language when discussing it. The pattern-match is not stupidity; it is the lingering effect of three structural pressures that have shaped how byte-denominated commerce has been thought about for the past fifteen years.

**Pressure one: the cryptocurrency space's economic incentives**. Cryptocurrencies have launched almost entirely as token-issuance vehicles, where the protocol's value accrues to the holders of a specific cargo (the protocol's native token) that the protocol privileges. This produces a strong selection pressure for designs in which cargo and carrier are bundled, because separating them would make it harder for the protocol's authors to capture the value of their own work. Almost every protocol designer in the space for the past decade has had a financial incentive to bundle. The substrate's authors have an explicit anti-incentive: the substrate is licensed Apache-2.0/MIT, has no token, and cannot be financially captured by its authors. The reader who has spent a decade reading cryptocurrency whitepapers will have to consciously override the pattern-match the whitepapers have trained.

**Pressure two: the language of finance is the language of money**. When humans discuss the movement of value between parties, the default vocabulary is monetary: payment, settlement, balance, account, fee. The substrate's machinery does each of these things, but the cargo being moved is not always money, and the monetary vocabulary distorts the description. A user transferring a compute-hour byte to another user is not "paying" in any meaningful sense — there is no money involved — yet the natural sentence to describe the transfer is "User A pays User B for compute time." The vocabulary is wrong but the alternative vocabulary does not yet exist. The treatise will use monetary language where it is precise (USD-byte transfers between bank accounts) and substrate-native language elsewhere ("the byte's ownership transitions from User A's pubkey to User B's pubkey"), but the reader should expect some friction.

**Pressure three: the institutional middle's framing of byte-denominated commerce as "money business"**. Banks, regulators, and financial-services companies categorize anything that moves value between parties as money business. This is partly a regulatory artifact — securities laws, money-services-business laws, and anti-money-laundering laws all assume that the regulated activity is monetary. It is partly a defensive posture — if byte-denominated commerce is money business, then the institutional middle's regulatory expertise becomes a moat. The substrate denies the framing: not all byte-denominated commerce is money business, and the substrate's machinery is correct for a much broader class of transactions than the money-business category captures. The political and regulatory consequences of this denial are taken up in §38 (Why not just regulate the existing system better) and §45 (The legal-classification retrofit).

The pattern-match is therefore overdetermined: economic incentives in the protocol-design community, linguistic conventions in finance, and regulatory categories in law all point toward "byte-denominated commerce = money." Each pressure can be resisted, but the resistance has to be conscious. The vesicle reframing is the conceptual tool that makes the resistance possible.

### 5.3 What the vesicle separates from its cargo

The smart byte schema (§8) carries five things intrinsically: identity, provenance, ownership chain, cargo, and joule cost. Four of these are *carrier* properties — they belong to the byte regardless of what cargo it holds. One — cargo — is the cargo itself. Each of the carrier properties is independent of cargo type, and each of the cargo types is independent of the carrier properties.

The carrier properties:

**Identity** (the byte's content-addressed unique ID, computed as the hash of its origin attestation) is a property of the byte's existence. Every byte has an identity, regardless of cargo. The identity is what makes the byte referenceable, transferable, and verifiable.

**Provenance** (the byte's origin attestation, signed by the issuer) is a property of the byte's birth. Every byte has a provenance — a record of who issued it, when, against what (if anything), and with what authorization. The provenance is what makes the byte trustable: a recipient can verify that the byte came from a legitimate issuer without trusting the sender.

**Ownership chain** (the sequence of signature-bound transfers from the original recipient to the current owner) is a property of the byte's history. Every byte has an ownership chain, regardless of cargo. The chain is what makes the byte's ownership claims falsifiable: any party can verify the chain back to the byte's origin and confirm the current owner is legitimate.

**Joule cost** (the two-part `measured + estimated` energy accounting accumulated over the byte's lifetime) is a property of the byte's operational cost. Every byte has a joule cost, regardless of cargo. The cost is what makes the substrate's economics legible: any party can compare the substrate's actual resource consumption to the rents charged by alternative settlement mechanisms.

The cargo itself:

**Cargo** is whatever the byte represents in the higher-layer economy. Cargo types are defined by application protocols, not by the substrate. The substrate's only requirement is that cargo be serializable to bytes and that the cargo type be tagged so applications can interpret it. The substrate validates the carrier properties (signature, history, joule cost) and propagates the cargo unchanged. Whether the cargo means $50 USD, 10 kWh, a vote on proposition 7, an attestation that the holder is over 21, a temperature reading from a specific sensor, or a claim on tomorrow's wheat harvest is application-layer concern.

This separation is what makes the substrate general-purpose. The matching, clearing, and trust-signaling functions identified in §3 are *all* about the carrier, not about the cargo. The institutional middle gets paid for moving things; the things being moved are incidental to the rents charged. Once the carrier is provided as a substrate primitive, the rent on moving any specific cargo type collapses to the actual cost of moving — which is the joule cost of the substrate's machinery, plus whatever rent the application layer can defend against substrate-native alternatives.

### 5.4 Concrete cargo types the substrate handles

To make the abstraction concrete, here are cargo types the substrate handles cleanly, organized by category. Each is a real use case with a corresponding institutional-middle rent that the substrate's generalization to that cargo type collapses.

**Money-equivalent cargo**:
- USD bytes issued by GENIUS-licensed stablecoin issuers. Cargo is "$X USD redeemable from issuer Y." Substitutes for: bank deposits, stablecoin balances, payment-processor float.
- Joule bytes issued by power producers (community solar arrays, utility cooperatives, individual rooftop systems). Cargo is "X joules of electrical energy redeemable from producer Y." Substitutes for: kWh meter readings, time-of-use billing, distributed energy resource accounting.
- Other-currency bytes (EUR, JPY, CNY, regional currencies) issued by appropriately-regulated entities in their jurisdictions. Substitutes for: foreign exchange clearing, cross-border wire transfers, multi-currency bank accounts.
- Commodity bytes (ounces of gold, bushels of wheat, barrels of oil) issued by commodity custodians. Substitutes for: futures contract settlement, ETF share issuance, commodity warehouse receipts.

**Compute and infrastructure cargo**:
- Compute-hour bytes issued by computing clusters (community-owned, commercial, hybrid). Cargo is "X CPU-hours or GPU-hours redeemable from cluster Y." Substitutes for: cloud computing reservations, datacenter capacity contracts, compute time markets.
- Storage bytes issued by storage operators. Cargo is "X gigabyte-months of storage at provider Y." Substitutes for: cloud storage subscriptions, content-delivery contracts, archival service agreements.
- Bandwidth bytes issued by network operators. Substitutes for: peering agreements, transit contracts, last-mile data plans.

**Physical-good cargo**:
- Food bytes issued by community greenhouses, vertical farms, food cooperatives. Cargo is "X kilocalories of food redeemable from producer Y." Substitutes for: food cooperative membership, CSA subscriptions, food bank operations.
- Water bytes issued by atmospheric water generation systems, municipal water authorities, irrigation districts. Substitutes for: water bills, irrigation contracts, mutual water company shares.
- Fabrication-time bytes issued by community fabrication facilities, makerspaces, distributed manufacturing networks. Substitutes for: hourly rental of equipment, contract manufacturing agreements, material-and-labor pricing.

**Social and governance cargo**:
- Governance vote bytes issued by community governance systems (cooperative assemblies, DAO equivalents, neighborhood associations). Cargo is "one vote on proposition X by entity Y." Substitutes for: paper ballots, online voting platforms, board governance procedures.
- Attestation bytes (KYC attestations, age attestations, professional credential attestations, sanctions-status attestations) issued by attestation authorities. Cargo is "verifiable claim X about holder Y, issued by attestor Z." Substitutes for: identity verification services, background check clearinghouses, professional licensing databases.
- Reputation bytes (in-context endorsements, reviews, performance attestations) issued by individuals, communities, or platforms. Substitutes for: review-platform monopolies, credit-scoring oligopolies, professional reference networks.

**Real-world-data cargo**:
- Sensor reading bytes (temperature, pressure, location, environmental conditions, biometrics) issued by sensor operators. Cargo is "measurement X by sensor Y at time Z, with cryptographic attestation that the sensor reported it." Substitutes for: data broker oligopolies, IoT platform lock-in, scientific data exchange friction.
- Event attestation bytes (a meeting happened, a delivery occurred, a milestone was reached, a contract condition was met) issued by event witnesses. Substitutes for: notarization, escrow services, contract milestone verification.

**Claim cargo**:
- Output-claim bytes (a claim on X% of the output of farm Y, factory Y, or fund Y for a specified period) issued by the producing entity. Cargo is "fractional claim on production." Substitutes for: equity shares, royalty contracts, output-sharing agreements.
- Service-claim bytes (a claim on X hours of service from provider Y) issued by service providers. Substitutes for: gift certificates, prepaid service contracts, retainer agreements.
- Conditional claim bytes (a claim on X conditional on event Y occurring before time Z) issued by claim originators. Substitutes for: futures contracts, options, conditional escrow.

**Categories the substrate subsumes whole.** Several systems being built in 2026 as standalone, separately-capitalized products are, in substrate terms, thin specializations of the smart byte — they re-implement the carrier, usually badly, because they did not start from the carrier:

- *Data unions / "DataDAOs."* A pooled dataset whose value is co-owned by its contributors is a smart byte whose cargo is the dataset (or a content-addressed pointer to it) and whose ownership chain has many co-signers, with output-claim bytes (above) issued against the pool's licensing revenue in proportion to contribution. The "union" mechanics — pooling, governance, revenue-share, license-and-distribute — are ownership-chain and output-claim semantics the substrate already provides. The standalone versions add a protocol-level token, which is the substrate's prohibited sixth field (§8.7) wearing a different hat; the token is the part that fails (one prominent data-union network ran its treasury down to roughly $232K in early 2026), not the union pattern itself, and not the underlying observation that individually-worthless data, pooled and governed, has leverage.
- *Verifiable credentials.* The attestation byte above *is* the W3C Verifiable Credentials data model and the credential carried in an EU eIDAS-2 digital-identity wallet — an issuer signs a claim about a holder, the holder holds it, a verifier checks the issuer's signature against a known key. No chain, no token, no "blockchain diploma" — just the carrier's provenance field carrying a claim instead of a dollar value. The credential networks that actually won this space (Credly-scale professional-badge utilities) use no blockchain at all; the substrate subsumes them by making the credential a cargo type rather than a product, and interoperates with the W3C and eIDAS-2 standards rather than reinventing them.
- *Programmable-IP licensing.* "Register a work, attach machine-readable license terms, track derivatives, collect royalties" is a conditional-claim byte (the license: a claim on payment conditional on a qualifying use occurring) composed with output-claim bytes (the royalty stream) and the byte history's derivation pointer (which work a byte was minted "against" — the same provenance field the substrate already records). The standalone L1s built for this added a token and a bespoke consensus; the substrate provides the licensing and derivative-tracking semantics at the carrier layer, with settlement on its own lockstep rather than on a separate chain. (Basis licensing for composed-media bases — the federated-registry case — is exactly this pattern; it is specified where the registry is.)

The pattern is uniform: a 2026 startup picks one cargo type, wraps it in a token and a bespoke consensus, raises on the narrative, and the token — not the use case — is what collapses. The substrate's contribution is to provide the carrier once, correctly, ownerless, so that all of these compose on top without re-litigating consensus, identity, settlement, or provenance each time.

This list is not exhaustive. It is illustrative. The point is that the substrate's machinery — content-addressed identity, signature-bound transitions, deterministic lockstep replication, two-part joule cost — is correct for all of these cargo types, and the rents currently extracted by the institutional middle on each of them collapse when the substrate provides the carrier directly. The institutional middle's framing has bundled all of these into either "financial services" (with money-business regulation) or "data services" (with information-broker rent extraction) or "physical commerce" (with custodial rent extraction). The substrate denies the bundling. Each cargo type is the same architectural primitive carrying different cargo, and the rent on the carrier collapses uniformly.

### 5.5 The architectural consequence

Once the vesicle reframing is in hand, the substrate's design follows mechanically. The substrate must specify the carrier properties precisely (Part II of this treatise) and stay agnostic about cargo. Application protocols are layer-2 work; the substrate provides the layer-1 carrier and lets ten thousand layer-2 protocols compose on top.

This is the architectural pattern that worked for the internet. TCP/IP is a vesicle. It carries HTTP, SMTP, FTP, DNS, BGP, and ten thousand other application protocols, none of which are privileged at the IP level. The IP layer cares about packet headers, routing, addressing, fragmentation, and reassembly. The IP layer does not care what the packets contain. The astonishing generality of the internet — that the same wires and the same routers carry email, video, banking, gaming, telemetry, and conversation — is the consequence of TCP/IP's vesicle behavior. A money-only IP, an email-only IP, or a video-only IP would each have produced a network with a fraction of the actual internet's value. The substrate's design follows the same pattern: a money-only substrate, a stablecoin-only substrate, or a payments-only substrate would each produce a system with a fraction of the smart byte substrate's value.

The TCP/IP analogy also clarifies what the substrate is replacing. The institutional middle of money is not analogous to TCP/IP. The institutional middle is analogous to AOL — a vertically integrated system that bundled connectivity, identity, applications, and content, charged rent on each, and was rendered obsolete by an open, application-agnostic alternative that performed the connectivity function as a public good. The substrate is to the institutional middle of money what TCP/IP was to AOL. The transition is the same shape, the same direction, and the same beneficiaries: the application layer and the end users, at the expense of the integrated incumbent.

The vesicle reframing is the conceptual move that makes the architectural decisions defensible. Without it, every design question becomes "but what about the money?" — which currency, which monetary policy, which fee structure, which inflation schedule. With the reframing, the design questions become the right ones: what does the carrier need to do, what cargo types should it support, what does the layer-2 application landscape look like, what rents collapse and what rents survive. §8 onward specifies the carrier's design. §6 states the freedoms the carrier provides precisely. §7 closes Part I with the condensed thesis. The substantive case for the substrate's necessity is complete by §7. The remaining six parts specify how the substrate works, what it survives, and what it predicts.

The smart byte is a vesicle. The cargo is application-defined. The institutional middle's rents on byte-denominated commerce, of every kind, collapse when the carrier is provided as a substrate primitive. This is the reframing. The rest of the treatise specifies what falls out of it.
## §6. The freedom case, precisely stated

The substrate provides specific freedoms at specific costs under a specific threat model. This section names each freedom, names what each freedom requires giving up to obtain, and names the freedoms the substrate does not provide. The discipline is non-negotiable: a treatise that overclaims freedoms loses credibility on contact with anyone who reads carefully, and the substrate's argument is strong enough not to need overclaiming. Where the substrate's freedoms are partial, the treatise says so. Where they depend on conditions the substrate does not control, the treatise says so. Where they are absent, the treatise says so.

The argument structure: §6.1 names four freedoms the substrate provides. §6.2 names the costs of obtaining those freedoms. §6.3 names freedoms the substrate does not provide. §6.4 names freedoms the substrate makes possible-but-not-guaranteed, where humans must build the political and institutional structures that translate technical affordance into lived freedom. §6.5 closes by stating what the substrate's freedom claim actually is, in one sentence, in a form precise enough that any reader can hold the claim against any later section of the treatise.

### 6.1 Four freedoms the substrate provides

**Freedom from rent extraction on cognitive operations that no longer require institutional performance.** Every dollar currently extracted by the institutional middle for matching, clearing, or trust-signaling work that the substrate performs at marginal cost approaching zero is a dollar the substrate frees. §3.4 estimated this at $2-3T per year globally, the difference between the institutional middle's $3-5T total extraction and the $1-2T legitimate residual (maturity transformation, risk pooling, physical infrastructure, regulatory liaison). The freedom is partial: the rent layer does not collapse instantly on substrate adoption; it compresses gradually as adoption crosses thresholds, transactions migrate, and the institutional middle's pricing power decays. The freedom is also asymmetric across cargo types: a USD-byte transfer between regulated counterparties pays compliance rent to a layer-2 issuer; a joule-byte transfer between cooperative members pays nothing. The freedom is greatest where the regulatory bundling is least, and the substrate makes the unbundling possible.

**Freedom from institutional capture of receipts.** Every transaction in the current system produces a receipt — a ledger entry, a wire confirmation, a credit card statement, a clearing report — and every receipt is owned by an institution that can withhold it, alter it, or surveil it. Receipts in the substrate are content-addressed and held by the parties to the transaction. No institution can withhold a receipt from a user who participated in the transaction. No institution can alter a receipt without producing a hash divergence detectable by any honest party. No institution can prevent a user from independently verifying their own transaction history against the substrate's content-addressed chain. This is a structural freedom, not a policy choice: it falls out of the architecture, and removing it would require redesigning the substrate.

**Freedom from forced reliance on intermediaries.** Every transaction in the current system requires at least one institutional intermediary — a bank, a card network, a clearing house, a custodian — and the intermediaries can refuse service. Account closures, debanking, payment-processor takedowns, sanctions-list enforcement (whether the sanction is legitimate or the result of error or political pressure) all operate on the substrate of intermediaries' service obligations. The substrate replaces the institutional intermediary with cryptographic primitives plus issuer relationships that the user can choose. A user transacting in joule-bytes from a community solar cooperative depends on the cooperative's continued operation but not on any bank, card network, or clearing house. A user transacting in USD-bytes from a GENIUS-licensed issuer depends on the issuer but can switch issuers if the issuer behaves badly, in a way that switching banks does not actually deliver under current conditions. The substrate makes intermediary relationships chooseable rather than forced.

**Freedom from the illegibility-of-cost protection that has shielded rent layers for centuries.** Every transaction's energy cost is intrinsically reported in the substrate's two-part `JouleCost` schema. Any party can compare the substrate's actual operational cost to the rents charged by alternative settlement mechanisms. The Visa interchange fee, the SWIFT wire charge, the bank deposit-to-loan spread, the foreign exchange spread — each is a number the institutional middle has been free to set arbitrarily because users had no honest baseline against which to compare it. The substrate provides the baseline. Rent layers can still exist on top of the substrate, charging whatever the market will bear, but they have to charge against an honest cost number. This is not an automatic freedom; users must look at the cost numbers and compare them to the rents. The substrate provides the data; humans must use it.

These four freedoms are concrete, structural, and verifiable. Each follows from the substrate's architecture rather than from any institutional promise. Each is robust against any institutional middle's attempt to subvert it from above. Each is also bounded — partial in scope, dependent on adoption, contingent on humans using the affordances the substrate provides.

### 6.2 What obtaining these freedoms costs

The four freedoms are not free. The substrate exchanges specific costs for them, and the treatise's discipline requires naming the costs precisely.

**Cost: every byte's history is intrinsically public.** The substrate's content-addressed history makes byte provenance verifiable by any party. This is the property that delivers the second freedom (no institutional withholding of receipts) and the fourth freedom (cost legibility). It is also the property that means a user's full transaction history in any specific byte class is observable to any party who can identify the user's pubkey. The substrate is not anonymous in the way physical cash is anonymous. It is pseudonymous in the way Bitcoin is pseudonymous, with the same caveats: a sufficiently determined adversary with enough auxiliary information can deanonymize most users.

The substrate's response to this cost has three parts. First, the byte history is public *to anyone with the byte's identity*, not to the world automatically; finding all the bytes belonging to a specific human requires linking their pubkeys, which is a layer-2 problem solved by the user's own operational discipline. Second, the substrate supports per-cargo-type privacy strategies (separate pubkeys per relationship, mixing services for fungible cargo, zero-knowledge proofs for cargo where they are appropriate), all as layer-2 features that compose with the substrate's transparent layer-1. Third, the privacy properties of the substrate are weaker than those of physical cash and stronger than those of bank-mediated electronic transactions, which means the substrate is a privacy improvement for the substantial majority of current digital transactions and a privacy regression for the small minority of cash-equivalent transactions.

This is an honest tradeoff and the treatise should not pretend otherwise. Privacy advocates who require strong anonymity for principled reasons will find the substrate's transparency unacceptable for some use cases, and they will be correct to find it so. The substrate's claim is not that it solves privacy; it is that it provides four specific freedoms and the privacy cost is what those freedoms cost.

**Cost: operators can still be coerced individually.** The substrate's defenses against state-level pressure (§27 in Part III on physical attacks, §11.2 on cluster admission distributed across jurisdictions) are layered and partial. Cluster operators distributed across jurisdictions are robust against any single state's pressure and degraded but functional against most state-coalitions; they fail under unanimous state-coalition pressure if the substrate has not yet acquired enough independent constituency to operate underground. The freedom from forced reliance on intermediaries does not extend to freedom from state action against the substrate's operators. A user whose only access to the substrate goes through an operator in a hostile jurisdiction can be cut off if that operator is coerced or shut down.

The substrate's response is operational diversity (multiple operators per cluster, gossip-based bootstrap, eventual underground-mode operation if necessary), but each of these is a partial defense, and the treatise is honest that no architecture can fully defend against unanimous state-coalition pressure. The substrate raises the cost of suppression substantially, but it does not eliminate the possibility of suppression. Users who require absolute freedom from state action will find the substrate insufficient for their threat model, and they will be correct.

**Cost: the legal-political fight over substrate adoption is real and ongoing.** Adopting the substrate requires acting against the institutional middle's interests, against incumbent regulatory frameworks designed for the institutional middle, and (in many jurisdictions) against state preferences for monetary control. The fight is not a one-time event; it is a multi-year process in which substrate adoption competes against the institutional middle's own AI-augmented productivity gains (the alternative scenario described in §1 and developed in §28, §36, §43). The substrate's freedoms are available to users only to the extent that the substrate exists at the moment they want to use it. The substrate's existence depends on the political-commercial-adoption fight being won by the substrate's adopters.

The substrate's response is the treatise itself, plus the reference implementation, plus whatever subsequent work produces a critical mass of adoption. The treatise is honest: the freedoms are conditional on the substrate winning, and the substrate winning is not guaranteed.

**Cost: users must perform some work that institutions previously performed.** The institutional middle currently absorbs operational complexity on behalf of users — key management, transaction monitoring, fraud detection, dispute resolution. The substrate moves some of this work back to users, with cryptographic tools that make the work tractable but do not make it disappear. A user who loses a private key loses the bytes controlled by it, in a way that a user who loses a bank password does not lose their bank balance. A user who is defrauded into authorizing a transfer cannot reverse it the way a credit-card user can dispute a charge. The substrate provides primitives for layer-2 services that handle these problems (custodial wallets, dispute-resolution services, social-recovery key management), but the user must choose those services and pay their costs. The freedoms come with operational responsibilities, and users who do not want the responsibilities must pay layer-2 services to handle them.

This cost is the smallest of the four because the layer-2 services emerge naturally and the cost they charge is bounded by competition. It is named here for completeness: the substrate is not a magic system that gives users freedoms without obligations.

### 6.3 Freedoms the substrate does not provide

The discipline of precision requires naming what the substrate is not. Each absence is a concrete claim that some prior or contemporary advocacy might have led readers to expect; the treatise denies the expectation specifically.

**The substrate does not provide privacy at the byte level.** As §6.2 explained, byte histories are content-addressed and verifiable by any party with the byte's identity. Layer-2 privacy techniques exist and the substrate composes with them, but the substrate itself is transparent. A user who wants privacy must use the layer-2 tools, accept the costs of those tools, and understand that the layer-2 privacy is weaker than the layer-1 privacy of cash.

**The substrate does not provide freedom from regulation entirely.** Any cargo type subject to regulation (USD-byte issuance, securities-classified bytes, sanctions-screened transfers) remains subject to regulation when carried in the substrate. The substrate makes the regulatory cost proportional and unbundled rather than bundled and uniform; it does not eliminate the regulatory cost. Users transacting in regulated cargo pay regulatory costs to the issuers and compliance services that handle the regulation. Users transacting in unregulated cargo pay nothing for regulation they do not need. The substrate's contribution is to make this distinction operational; the substrate does not abolish regulation.

**The substrate does not provide automatic prosperity.** The institutional middle's rent extraction is a redistribution from users (and, by passthrough pricing, consumers and merchants) to the institutional middle. Substrate adoption returns the rent stream to users. The total economic activity does not increase by the rent amount; it redistributes. Whether the redistributed value produces broader prosperity depends on what users do with the freed capital — invest, consume, save, donate, build commons, fund public goods. The substrate enables the redistribution; humans must direct the freed capital toward outcomes that count as prosperity. §17 in the v0.2 full-map document and Part VI of this treatise engage this distinction at length.

**The substrate does not provide protection against the user's own bad decisions.** A user who authorizes a fraudulent transfer, who falls for a phishing attack, who shares their private key, who chooses an untrustworthy issuer, who fails to back up their key — all of these produce losses the substrate cannot prevent. Layer-2 services (custodial wallets with fraud monitoring, social-recovery key systems, insured custodial accounts) reduce these losses, but they reintroduce some of the institutional middle's structure. Users who want absolute protection from their own mistakes will find the substrate's bare-cryptography layer insufficient; users who want absolute self-sovereignty will find the layer-2 insurance services unappealing. Both are valid choices, and the substrate accommodates both.

**The substrate does not provide a guarantee of its own success.** The substrate may fail. The institutional middle may consolidate into an AI-mediated rent layer faster than the substrate ships. State coalitions may suppress the substrate before it acquires independent constituency. The substrate's reference implementation may have bugs that compromise its security. The substrate's economic case may be wrong in some way the treatise has not anticipated. Each of these is a real possibility and the treatise does not pretend otherwise. The freedoms the substrate provides are conditional on the substrate working as designed; the substrate's working as designed is conditional on engineering, adoption, and political work that has not yet been completed.

These are not weaknesses to be hidden. They are the boundaries of the substrate's claim. A reader who finishes §6.3 and concludes "the substrate does less than I thought" is reading correctly. The substrate does specifically the four things named in §6.1. It does not do the things named in §6.3. The treatise is precise about the boundary because the precision is what makes the four freedoms credible.

### 6.4 Freedoms the substrate makes possible but does not guarantee

The substrate has architectural affordances that, if humans build on top of them, enable freedoms that the substrate alone cannot deliver. These are taken up at length in Part VI of the treatise and were named in v0.2 §17.5 of the full-map document. Three are worth naming briefly here.

**Non-state redistribution becomes technically buildable.** A community solar cooperative can issue joule-bytes to its members proportionally to their cooperative shares. A community compute commons can issue compute-hour-bytes. A community food cooperative can issue kcal-bytes. The substrate provides the bookkeeping primitive that lets these distributions happen without an institutional intermediary's overhead. Whether communities choose to build commons of this kind, and whether the commons grow large enough to address the distribution problem taken up in Part VI, is a political-organizational question outside the substrate's scope. The substrate makes the option available; humans must take it.

**Joule-denominated commons changes the political economy of distribution.** Money-denominated redistribution is adversarial by construction (taxing one party to fund another). Joule-denominated commons distribution is non-rivalrous up to the system's capacity (the joules from a solar array exist whether or not anyone uses them; sharing them does not extract from anyone). The substrate enables joule-denominated commons; whether they replace any meaningful share of money-denominated redistribution depends on adoption and political will.

**Ownership measurement as byproduct of substrate operation.** Every productive byte's ownership is cryptographically explicit. Aggregating across substrate-native production produces an honest map of who owns what fraction of substrate-native productive capacity in any region or sector. Movements organized around redistribution of productive ownership now have, for the first time, a reliable real-time map of substrate-native ownership distribution. Whether the map is used to inform political action depends on whether such movements exist and whether they choose to use the data. The map is a byproduct of substrate operation; humans must read it and act on it.

These three affordances are the substrate's positive contribution to the distribution problem. None of them is a freedom the substrate delivers automatically. Each is a tool the substrate provides that humans must wield to convert technical affordance into lived freedom. The treatise's claim is honest: the substrate makes these things buildable in a way that prior architectures did not, and what humans build with the affordances is on humans, not on the substrate.

### 6.5 The freedom claim, in one sentence

The substrate provides freedom from rent extraction on cognitive operations that no longer require institutional performance, freedom from institutional capture of receipts, freedom from forced reliance on intermediaries, and freedom from the illegibility-of-cost protection that has shielded rent layers for centuries — at the costs of intrinsic byte-level transparency, partial defense against state-level coercion, ongoing political contestation, and the operational responsibilities that the institutional middle has absorbed on users' behalf — under the threat model that adversaries (states, AI companies, hostile capital, and unforeseen attacks) will read this treatise and design their attacks accordingly, with defenses specified in Part III; and the substrate makes possible, but does not guarantee, the further freedoms of non-state redistribution, joule-denominated commons, and substrate-native ownership measurement, which depend on humans choosing to build the political and institutional structures that convert architectural affordance into lived outcome.

The sentence is long by design. Each clause is load-bearing. Removing any clause produces a less precise version of the claim. The treatise's freedom claim is exactly this and exactly nothing more. Readers who hold this sentence against any later section of the treatise will find the treatise consistent with it; readers who find an inconsistency are invited to identify it as a possible error, and the errata page (Appendix A) will document any errors that survive review.

The substrate is for freedom, in the precise sense named here. It is not for utopia, and it is not for any specific political program. It is for the freedoms named in §6.1, at the costs named in §6.2, with the absences named in §6.3, and the affordances named in §6.4. The next section (§7) closes Part I with the condensed substantive thesis. The thesis follows from §2 (what money is), §3 (what the institutional middle does), §4 (what changed), §5 (the vesicle reframing), and §6 (the freedom case precisely). By the close of §7, Part I is complete.
## §7. The thesis, condensed

The substantive case for the smart byte substrate is the following.

Money is a workaround for limited cognition (§2). Specifically, it is a portable, fungible, divisible, durable token that lets parties who cannot remember each other's full transaction history settle exchanges anyway. Each property substitutes for a cognitive operation — spatial memory, identity tracking, size negotiation, temporal memory — that humans operating at human scale could not perform directly. Money worked, for centuries, because the cognitive limits it worked around were binding.

The institutional middle of money — banks, payment processors, custodians, exchanges, clearing houses, compliance bureaucracies — performs three functions on top of money: matching counterparties, clearing transactions, and signaling trust (§3). Each function had a real cost in pre-cryptographic, pre-cheap-computation, pre-energy-measurement conditions. The institutional middle was paid in rough proportion to those costs, and the rents extracted — somewhere between three and five trillion dollars per year globally, of which the McKinsey-sourced payments component is $2.5 trillion — reflected the difficulty of performing the functions in their original technological context.

Three independent technological maturations have changed the context (§4). Cheap cryptography (ed25519, blake3, content-addressed storage) crossed the threshold around 2020 and made the trust-signaling function performable at marginal cost approaching zero for the cryptographic-identity layer. Ubiquitous deterministic computation (lockstep simulation libraries, fixed-point arithmetic discipline, WebAssembly) crossed around 2020 and made the clearing function performable in milliseconds at the energetic cost of running the simulation. Per-operation energy measurement (RAPL, ARM equivalents, Apple Silicon counters) crossed around 2018 and made the rent-extraction layer falsifiable for the first time by exposing the actual cost of computation against the rents charged on top of it.

The three maturations compose into a single architectural primitive: a system that lets any party perform a cryptographically-authorized operation on a content-addressed data structure, have the operation deterministically replicated across a cluster of independent verifiers, and have the energy cost of the operation honestly reported in microjoules. The smart byte (§8) is the load-bearing object the substrate uses; it is content-addressed by hash, transferred by signature, replicated by lockstep, and priced in joules.

The smart byte is not money. It is a vesicle (§5) — a carrier defined by transport behavior, agnostic about cargo. A USD-denominated byte and a joule-denominated byte are the same primitive carrying different cargo. The substrate is general over cargo types: USD bytes, foreign currency bytes, commodity bytes, compute-hour bytes, storage bytes, food bytes, water bytes, fabrication-time bytes, governance vote bytes, attestation bytes, sensor reading bytes, output-claim bytes, conditional claim bytes. Money is one cargo type among many, and the institutional middle's three functions — matching, clearing, trust signaling — collapse uniformly across all cargo types when the carrier is provided as a substrate primitive.

The substrate provides four specific freedoms (§6) at four specific costs, with three named absences and three further freedoms it makes possible but does not guarantee. The freedoms: from rent extraction on cognitive operations that no longer require institutional performance; from institutional capture of receipts; from forced reliance on intermediaries; from the illegibility-of-cost protection that has shielded rent layers for centuries. The costs: every byte's history is intrinsically public; operators can still be coerced individually; the legal-political fight over substrate adoption is real and ongoing; users must perform some operational work that institutions previously performed. The absences: no byte-level privacy, no freedom from regulation entirely, no automatic prosperity, no protection from the user's own bad decisions, no guarantee of the substrate's own success. The conditional further freedoms: non-state redistribution, joule-denominated commons, ownership-measurement-as-byproduct of substrate operation. The substrate enables these; humans must build on the affordances to deliver them.

The substrate's claim to inevitability follows from the composition's mechanical character. Given that the three maturations have happened, given that the institutional middle's rents are large enough to make the composition profitable, given that the techniques are well-understood and the libraries are off-the-shelf, the substrate will be built. The question is by whom and on what terms. The two stable trajectories are:

**Trajectory one: the substrate ships under permissive licensing, with multiple independent implementations, with no protocol-level token, with no steward acquired by or made exclusive to any single dominant AI lab or capital bloc, with reference attribution to the public-good open-source projects it composes, and adoption crosses the threshold at which the institutional middle's bundled rent extraction becomes economically untenable.** The institutional middle compresses to its legitimate residual functions (maturity transformation, risk pooling, physical infrastructure, regulatory liaison), which represent perhaps 20-40% of its current revenue. The freed capital flows to substrate-native applications, commons-based distribution mechanisms, and whatever else the substrate's users build on top of the layer-1 carrier. This trajectory produces broadly distributed economic gains and structurally limits the formation of new rent-extraction layers.

The "no steward captured" clause is not decoration; it names the specific way trajectory one is lost without anyone noticing it happen. A steward that publishes the spec, ships the reference implementation, and operates commercial services around the substrate is doing exactly the right job — *as long as it remains one supplier among several and one customer's vendor among many*. The moment that steward is acquired by, or becomes the exclusive data / compute / settlement supplier to, a single dominant AI lab or capital bloc, its neutrality is the price of the deal, and the substrate's other consumers will route around it: the entire value of an open carrier is that no party who builds on it can be cut off by the carrier's owner, and a captured steward is a carrier that has acquired an owner. This dynamic has already been demonstrated in an adjacent market — the 2025 reconfiguration of the largest AI-training-data vendor after a frontier lab took a near-majority stake, followed within months by that vendor's other frontier-lab customers winding down their work with it — and the lesson generalizes cleanly: in any layer that everyone needs, neutrality *is* the asset, it is non-fungible, and it is sold exactly once. Transaction Science's role with respect to the substrate is steward, not proprietor — the spec text and reference code are permissively licensed, and canonicity lives in the conformance vectors and content-addressing, not in any brand or company; a steward that forgot this would be choosing trajectory two and calling it a partnership. The commitment is therefore stated as a hard one: the substrate's steward does not sell its neutrality, and an implementation whose steward has sold it is, by that fact, no longer a reference for anyone but its acquirer.

**Trajectory two: AI companies, racing against the substrate's adoption curve, succeed in transforming the institutional middle into an AI-mediated rent layer before the substrate acquires independent constituency.** The bytes of the world flow through one or a few large AI companies' infrastructure, with rents extracted at every step, captured to a small number of corporate beneficiaries. This trajectory produces narrowly concentrated economic gains, structurally entrenches a new rent-extraction oligopoly, and forecloses the substrate's freedoms before they can be realized.

The trajectories are not symmetric. Trajectory one is the end of a five-hundred-year structural extraction. Trajectory two is its consolidation. The treatise's purpose is to make trajectory one mechanically buildable, and to document the substrate precisely enough that the work of building it can be distributed across thousands of independent actors who do not need to coordinate through any central authority. The reference implementation (Appendix A) is the existence proof. The threat model (Part III) names the attacks both trajectories' adversaries will mount. The workaround analysis (Part IV) engages each alternative seriously. The retrofit traces (Part V) name the specific patterns by which trajectory two adversaries will attempt to capture the substrate after it ships. The distribution analysis (Part VI) specifies what the substrate makes possible on the freed-capital side. The closing argument (Part VII) ties the technical, political, and philosophical case together.

The substrate is what money looks like when memory is not the binding constraint, what clearing looks like when computation is deterministic, what trust signaling looks like when cryptography is cheap, and what rent extraction looks like when the actual cost of the underlying operation is intrinsically reported. The thesis is that this is the right architecture for the next decade's economic transition, and that the transition is happening with or without the substrate; the only question is whether it happens through the substrate or through the AI-mediated rent layer that is currently being built in its place.

Part I closes here. Part II specifies the substrate's architecture in enough detail that a competent engineer in any language with cryptographic primitives equivalent to ed25519, blake3, and length-prefixed deterministic serialization can implement it. Part III walks the threat model. Parts IV and V engage the alternatives and the retrofit attacks. Part VI develops the distribution-side argument. Part VII closes with the freedom case completed and the substrate's predictions stated falsifiably.

The substrate is not a clever idea. It is the inevitable composition of three things that have already happened, applied to the specific purpose of replacing the institutional middle of money. The composition will be made. The treatise's job is to make it correctly.
# Part II — The Substrate Architecture

Part I established why the substrate is necessary. Part II specifies what the substrate is. The discipline of Part II is engineering precision: every architectural primitive named here is implementable from the prose by a competent engineer working in any language with cryptographic primitives equivalent to ed25519, blake3, and length-prefixed deterministic serialization. Part II does not give byte-level wire formats — those are a separate document, the conformance specification, that ships alongside the reference implementation. What Part II gives is the *architectural reasoning* the wire format encodes, in enough detail that the wire format follows mechanically from the prose.

Part II has ten sections. §8 specifies the smart byte schema — the load-bearing primitive on which everything else builds. §9 specifies deterministic simulation as the consensus mechanism. §10 specifies the byte history as a content-addressed chain. §11 specifies cluster topology and the constraints that govern it. §12 specifies the phase-buffering requirement that prevents lockstep deadlock at any cluster size greater than two. §13 specifies BFT supermajority commit. §14 specifies the dissent log as the load-bearing observability primitive. §15 specifies live issuance. §16 specifies persistence. §17 specifies the two transports the reference implementation supports.

By the close of Part II, the reader has the full architectural picture. Part III then walks the threat model the architecture has to survive. Parts IV–VII engage alternatives, retrofits, distribution implications, and the closing argument.

---

## §8. The smart byte schema

The smart byte is the substrate's only object. Everything else is a function over smart bytes. Clusters operate on smart bytes. Lockstep simulation transitions smart bytes. Issuers create smart bytes. Cryptographic verification verifies smart bytes' histories. The treatise's argument that the institutional middle's three functions — matching, clearing, trust signaling — collapse onto a single architectural primitive is the argument that the smart byte is sufficient to perform all three.

This section specifies what a smart byte carries, why it carries those specific things, and how the specification falls out of the substrate's architectural commitments. The reader who finishes §8 should be able to draw the smart byte's data structure from memory and explain why each field is necessary and why no other fields are necessary.

### 8.1 What a smart byte carries

A smart byte is a record carrying exactly five things:

1. **Identity** — a content-addressed unique identifier, computed as the cryptographic hash of the byte's origin attestation.
2. **Provenance** — the byte's origin attestation, signed by the issuer, recording who issued the byte, when, against what (if anything), and with what authorization.
3. **Ownership chain** — the cryptographic chain of signature-bound ownership transitions from the original recipient to the current owner, with each transition's preimage including the prior history hash so that the chain is content-addressed end-to-end.
4. **Cargo** — the application-layer payload the byte carries: USD, joules, compute hours, governance vote, attestation, anything else (§5). The cargo is opaque to the substrate's machinery and interpreted only by application protocols.
5. **Joule cost** — a two-part energy accounting (`measured_microjoules` plus `estimated_microjoules`) that records the cumulative energy cost of operations performed on the byte over its lifetime.

These five fields are the entire smart byte. Any additional field would either duplicate one of the five (cargo can carry application-specific metadata), violate the substrate's separation of concerns (timestamps would couple bytes to wall-clock time, which the substrate does not depend on), or undermine the substrate's architectural commitments (a transaction-fee field would protocol-privilege a particular cargo type, contrary to the vesicle reframing in §5). The five fields are not chosen for elegance; they are chosen because removing any one of them breaks a load-bearing property of the substrate, and adding any sixth produces a worse design than the five-field version composed with application-layer protocols.

The remainder of §8 walks each field in turn, explaining what it carries, why it is necessary, what cryptographic primitives it depends on, and what the field's presence enables that other architectures lacking it cannot achieve.

### 8.2 Identity: the content-addressed unique identifier

A smart byte's identity is the blake3 hash of the byte's origin attestation. The hash is 32 bytes. It is computed once at the byte's birth and never changes. Every reference to the byte — in any other byte's history, in any cluster's state, in any application protocol — uses this hash as the byte's identifier.

The choice of content addressing rather than sequential identifiers (counter-based, UUID-based, or issuer-namespaced) is not stylistic. Content addressing produces several properties no sequential scheme can:

**Independent verifiability.** Any party holding the byte's origin attestation can independently compute the byte's identity and confirm that it matches the asserted ID. A sequential scheme requires trusting whoever assigned the ID. Content addressing makes the assignment self-verifying.

**Uniqueness without coordination.** Two issuers in different jurisdictions issuing bytes simultaneously cannot collide on identity, because the inputs to the hash include the issuer's pubkey, the cargo, the recipient, the nonce, and the issuer's signature — the probability of collision in a 256-bit hash space is vanishingly small. A sequential scheme requires a coordination mechanism (a global counter, a namespace registry, a UUID authority) that the substrate would have to provide and trust. Content addressing eliminates the coordination requirement.

**Retroactive immutability.** A byte's identity cannot be changed without producing a different byte. Any attempted modification of the origin attestation produces a different hash, which is a different byte, which has no relationship to the original. This makes fraud trivial to detect: a forged byte either has the wrong identity (and is rejected on first verification) or has a content-addressed identity that does not match any record any honest party holds.

**Network-effect alignment with content-addressed history.** §10 specifies that the byte's full history is also content-addressed. Identity-by-hash composes with history-by-hash to produce a byte whose every property is verifiable from the byte's content alone, with no reliance on any external authority. This is the architectural pattern that lets the substrate operate without a central registry, central naming authority, or central state store.

The cryptographic dependency is on a hash function with three properties: collision resistance, preimage resistance, and speed. Blake3 satisfies all three at the level the substrate requires (see §4.1 on cryptographic maturation). SHA-256 also satisfies all three but is slower; either works correctly but blake3 produces lower joule cost per byte, which matters at substrate scale.

The byte's identity is computed once and frozen. There is no rekeying, no rotation, no version. If the cryptographic primitive itself is compromised — if blake3 turned out to have a collision attack — the substrate would have to migrate to a successor primitive, but the migration is a substrate-wide event, not a per-byte event. §19 (Cryptographic attacks) walks the migration path.

### 8.3 Provenance: the origin attestation

Every smart byte was created by some issuer at some moment, against some thing (if the cargo is redeemable), with some authorization. The provenance records all of this in a signed structure that becomes part of the byte's permanent identity.

The origin attestation contains:

- **Issuer pubkey**: the ed25519 public key of the entity issuing the byte. Issuers are bound by the cluster's authorization rules (§15) — the cluster's state carries a registry of authorized issuers per cargo type, and only registered issuers can create valid bytes of the corresponding cargo type.
- **Cargo specification**: the cargo's type tag, value, and any cargo-specific metadata. For a USD-byte issued by a GENIUS-licensed stablecoin issuer, the cargo specification includes the dollar value, the issuer's redemption policy URL, and an attestation that the dollar reserves are held in qualifying liquid assets. For a joule-byte issued by a community solar cooperative, the cargo specification includes the joule value, the redemption mechanism (which physical electrical-distribution interconnect honors the byte), and a freshness window beyond which the byte expires.
- **Recipient pubkey**: the ed25519 public key of the original recipient. The byte's first transfer must be authorized by this key.
- **Nonce**: a 16-byte random or sequentially-allocated value that prevents two attestations with otherwise-identical content from producing the same identity. The nonce is the substrate's solution to the issue that an issuer who legitimately wants to issue two USD-100 bytes to the same recipient at the same logical moment would otherwise produce two attestations with identical content and therefore identical hashes — which is wrong, because they are distinct bytes.
- **Issuer signature**: a signature by the issuer's private key over a canonical serialization of the prior four fields, prefixed with a one-byte *algorithm identifier* naming the signature scheme in use (`0x01` = ed25519 in v1; the remaining range is reserved for post-quantum schemes such as ML-DSA, so a successor can be introduced incrementally alongside ed25519 — see §4.1, §19.5, §19.8 — without a flag-day migration). The signature binds the issuer to the attestation and prevents anyone else from producing valid attestations claiming to be from the issuer; the algorithm identifier tells every verifier which verification predicate to apply, and lets a single issuer rotate to a post-quantum key without invalidating verification of the bytes it signed under the old one.

The provenance is the byte's *birth certificate*. It is checked by every node that ever touches the byte: when the byte is created, the cluster verifies the issuer is registered for the cargo type and verifies the issuer's signature; when the byte is transferred, recipient nodes verify the provenance back through the ownership chain to confirm the chain's first link is authorized by the original recipient pubkey; when the byte is verified independently by a non-cluster party, the party verifies the provenance from the cargo and pubkeys and signature directly.

Provenance is what gives the smart byte its second property: trustability. A byte with valid provenance is a byte the substrate's machinery accepts. A byte with invalid provenance — bad signature, unregistered issuer, malformed cargo — is dropped silently on contact. The drop is deterministic across honest nodes; if the provenance fails verification on one honest node, it fails on every honest node. There is no race condition where some nodes accept and some reject, because the verification is purely a function of the byte's content and the cluster's issuer registry, both of which are deterministically synchronized.

### 8.4 Ownership chain: the signature-bound transitions

A smart byte's ownership history is a sequence of transitions, each signed by the byte's owner-at-the-time-of-transition, transferring the byte from one pubkey to another. The first transition is from the original recipient (named in the provenance) to the next owner. Subsequent transitions are from each owner to the next. The current owner is the recipient of the most recent transition.

Each transition contains:

- **Previous history hash**: the blake3 hash of the byte's history up to but not including this transition. This is what makes the chain content-addressed end-to-end. A transition cannot be inserted into the middle of the chain without producing different hashes for every subsequent transition, which would be visible as a divergence to any party with the original chain.
- **From pubkey**: the pubkey of the owner authorizing the transfer. Must equal the *To pubkey* of the previous transition (or the original recipient pubkey for the first transition).
- **To pubkey**: the pubkey of the new owner.
- **Frame number**: the lockstep frame in which the transition is applied. This is the substrate's only time-like field; it counts cluster-committed frames, not wall-clock time.
- **Signature**: a signature by the from-pubkey's private key over a canonical serialization of (byte ID, previous history hash, from pubkey, to pubkey, frame number), carrying the same one-byte algorithm identifier as the provenance signature (§8.3) — so a transition signed under ed25519 and a transition signed under a post-quantum successor are both verifiable, and a byte's ownership chain can span the migration boundary without a break.

The signature is what authorizes the transfer. The substrate's transfer-validation machinery verifies the signature against the from-pubkey, verifies the from-pubkey matches the byte's current owner, verifies the previous history hash matches the byte's actual current history hash, and verifies the frame number matches the current cluster frame. Any verification failure causes the transfer to be silently dropped.

The signature's preimage explicitly includes the byte ID and the previous history hash. This is not redundant with what's already in the chain; it is the cryptographic binding that prevents transition replay across different bytes or different histories. A signature valid for byte X's transition at history-hash H is *not* valid for byte Y's transition or for byte X's transition at a different history-hash. Without this binding, an adversary who captured a single legitimate signature could replay it across many bytes; with it, the signature is cryptographically scoped to exactly one transition on exactly one byte at exactly one moment.

The ownership chain has three properties that no account-balance-based architecture can achieve:

**Per-byte ownership rather than aggregate balance.** A user who holds 1,000 USD-bytes from issuer A does not have an "account balance" of $1,000. They hold 1,000 distinct byte objects, each with its own identity, its own history, and its own provenance. Transfers move specific bytes, not abstract balance. This is structurally different from how banks (and most cryptocurrencies) work, where a user's holding is a fungible balance. The byte-level granularity is what enables cargo specificity (a 1996 vintage joule-byte from a specific solar array is distinguishable from a 2024 joule-byte from the same array, even though both might be denominated in joules) and what enables provenance to remain meaningful through arbitrary transfer sequences.

**No double-spend at the protocol level.** A byte can be transferred to exactly one new owner per cluster frame, because the transfer is authorized by the byte's *current* owner against the byte's *current* history hash, and a successful transfer changes both. An attempted second transfer of the same byte in the same frame, even by the same legitimate owner, has the same previous-history-hash and is either ordered first (and applied) or ordered second (and dropped because the previous-history-hash no longer matches). Lockstep simulation's deterministic input ordering ensures every honest node makes the same choice.

**Independent verifiability of any historical state.** Any party with the byte's full history can compute the byte's state at any prior moment. The chain is content-addressed, so there is no ambiguity: the history is exactly what it is, and any tampering produces a hash divergence. This enables forensic-style verification: a recipient receiving a byte can audit its full provenance back to the issuer without trusting the sender, the cluster, or any intermediary.

### 8.5 Cargo: the application-layer payload

The cargo is what the byte is *for*. It is the application-layer content that gives the byte meaning in the higher-layer economy. The substrate is deliberately silent about what cargo means — the substrate verifies cryptographic and structural properties; it does not interpret cargo semantics.

The cargo field has two parts:

- **Cargo type tag**: a small integer identifying the cargo class. Cargo types are registered in a public registry that the substrate publishes; new cargo types are added via the same registry mechanism. The tag is opaque to the substrate's machinery — the substrate knows that type 1 is "USD redeemable from the issuer named in provenance" only by convention, not by validation. Application protocols read the tag and interpret the cargo accordingly.
- **Cargo bytes**: a length-prefixed sequence of bytes containing the cargo-specific payload. For a USD-byte, the cargo bytes encode the dollar value as a fixed-point integer plus any cargo-specific metadata (issuer's redemption policy URL, freshness window, etc.). For a joule-byte, the cargo bytes encode the joule value plus the redemption interconnect identifier. For a governance-vote byte, the cargo bytes encode the proposition ID and the vote direction. The substrate transports the cargo bytes unchanged.

The cargo's opacity to the substrate is not a limitation; it is the architectural decision that makes the substrate general (§5). A substrate that interpreted USD bytes specially would either privilege USD over other cargo types (violating the vesicle reframing) or require a cargo-specific code path for every cargo type (producing a substrate that grows in complexity with every new application). Opacity is the design.

Cargo carries one constraint that applies to every cargo type: the cargo bytes must be deterministically serializable. Two honest nodes parsing the same cargo specification must produce byte-for-byte identical results, regardless of platform, compiler, or runtime. This is the substrate's consistency requirement and it constrains cargo encodings to fixed-point integers, length-prefixed strings, content-addressed nested structures, and similar deterministic forms. Floating-point cargo is forbidden at the substrate level; cargo types that conceptually need floating-point must use fixed-point representations.

The substrate provides no semantic validation of cargo. A USD-byte whose cargo claims a value of $1,000,000 is structurally valid if the issuer's signature verifies; whether the issuer is solvent, whether the dollar reserves exist, whether the redemption policy is honored — these are application-layer and issuer-layer concerns. The substrate's contribution is cryptographic provenance and tamper-evident history; the substrate does not police what issuers issue.

### 8.6 Joule cost: the two-part energy accounting

Every smart byte carries a record of the cumulative energy cost of operations performed on it. The record has two parts:

- **`measured_microjoules`**: the sum of energy measurements taken by nodes performing operations on the byte. Where RAPL or equivalent hardware energy counters are available and demonstrably live for the work — observed advancing under load for the domain the measurement claims — the measurement is read from the hardware. Where they are not — absent, or present but frozen or republished in lumps — the measurement is zero (an honest report of "not measurable on this node").
- **`estimated_microjoules`**: the sum of workload-correlated estimates predicting the operation's energy cost based on a calibrated model. The estimation function is a substrate-level constant, deterministic, and verifiable: any honest node executing the same operation produces the same estimate.

The two-part design is the substrate's solution to a real problem. Per-operation energy measurement is approximate at the per-process level (§4.3) — RAPL measures the package, and other processes contribute to the package draw. The measurement is meaningful and useful, but it is not a precise per-byte attribution. The estimation function provides a parallel signal: an independent prediction of what the operation should have cost, based on workload characteristics that the substrate knows. The two together let the substrate detect divergence: a node whose measured values consistently undershoot the estimated values is either running faster hardware than the model expects (legitimate, and the model can be recalibrated) or is lying about its measurements (a dissent-log entry, see §14).

The cumulative property of the joule cost is intentional. Every operation on the byte adds to the running totals. The byte's joule cost grows monotonically. A byte that has lived for a long time and been transferred many times accumulates a substantial joule cost, which is information: a long-traveled byte's full lifetime energy footprint is part of its provenance. Application protocols can use this information for whatever they want — pricing freshness premiums, identifying high-velocity bytes that may indicate suspicious activity, environmental accounting at the cargo-portfolio level. The substrate provides the data; applications interpret.

The joule cost is also the substrate's primary defense against the illegibility-of-cost protection that has shielded rent layers for centuries (§4.3, §6.1). Every transaction's energy cost is intrinsically reported. Any party can compare the substrate's actual operational cost to the rents charged by alternative settlement mechanisms. Rent layers can still exist on top of the substrate, charging whatever the market will bear, but they have to charge against an honest cost number. The substrate provides the baseline; humans must compare the rents to the baseline.

There is a second consequence of intrinsic joule accounting worth stating, because an entire category of products is built on its absence. Every byte — including every byte whose cargo *is* a dataset, a model, a corpus, or any other "data asset" — carries a cumulative, reproducible record of the energy it cost to mint, transfer, verify, and serve. That record is the only *automatic, falsifiable* valuation primitive a data asset can have. It is not the market price (the market sets price; the substrate is silent on it), but it is a defensible cost basis, computed by hardware energy counters anyone can read, with no consulting engagement and no proprietary model in the loop. This is the precise contrast with the "data valuation" products that periodically appear — opaque "data scores" and "data values" produced by undisclosed algorithms, which are unfalsifiable by construction and have, accordingly, never reached scale as a standalone business (the discipline that does exist — Laney's infonomics taxonomy and the handful of valuation consultancies — is advisory work, not a product, precisely because there is no automatic version of it). The substrate does not score data. It reports what data cost, in joules, and lets the market and the application layer do the rest. "What it cost, falsifiably" turns out to be the part nobody selling a "DataValue" has been able to ship — because shipping it requires the per-operation energy measurement (§4.3) that the substrate has and a marketing claim does not.

### 8.7 What the schema does not carry

Equally important is what the smart byte schema does not include.

**No wall-clock timestamps.** The substrate has no concept of wall-clock time. The only time-like field is the lockstep frame number (§8.4, §9), which counts cluster-committed frames. Wall-clock time is a non-deterministic property — different machines have different clocks, NTP synchronization fails, time zones differ, daylight saving time changes — and including wall-clock timestamps in the schema would couple the substrate to a non-deterministic input that adversaries could manipulate. Application protocols that need wall-clock timestamps can include them in cargo metadata (with the issuer or transferor attesting to the time), but the substrate itself does not depend on them.

**No transaction fees at the protocol level.** A byte does not carry a fee field. Transfers are cryptographically authorized but not economically priced at the substrate layer. This is the architectural decision that prevents protocol-level rent extraction (§5.2): a substrate that charged fees per transfer would either privilege a particular cargo type (whatever the fee was denominated in) or require complex multi-currency fee logic. By having no protocol-level fees, the substrate stays neutral over cargo types. Layer-2 services may charge fees for the services they provide (custodial wallets, dispute resolution, compliance), but the substrate's transfer machinery is fee-free.

**No account balances.** The substrate is per-byte, not per-account. There is no field anywhere in the schema that represents a user's aggregate holding of any cargo type. Aggregation is application-layer work: a wallet application that wants to display "you hold 1,000 USD" computes that by summing the cargo values of all USD-bytes the user owns. The substrate stores the bytes; the wallet does the math. This is structurally different from account-based architectures and is what enables byte-level cargo specificity.

**No mutability.** A byte's content is immutable from the moment of creation. Transfers add transitions to the ownership chain but do not modify the byte's identity, provenance, or original cargo specification. (Cargo can carry application-layer mutable state, but the cargo specification itself — the issuer's attestation about what the byte represents — is fixed.) Updates to the substrate's view of a byte are accomplished by adding new transitions, not by editing existing fields. The immutability is what makes content-addressing meaningful: a mutable byte would have an identity that changes with its content, defeating the purpose.

**No identity binding to legal persons.** The pubkeys in the schema (issuer, recipient, owners) are cryptographic identifiers. The substrate does not bind them to real-world legal persons, corporate entities, or government-issued identities. That binding, where it is required for regulatory or commercial reasons, is performed by issuers and compliance services as layer-2 work. The substrate's transfer machinery does not know whether a pubkey corresponds to a human, a corporation, an AI, or a contract; it knows only that signatures from the pubkey are valid. This is what enables both the substrate's freedom-from-forced-intermediary property (§6.1) and the substrate's pseudonymity-not-anonymity property (§6.2).

The five-field schema is the substrate's load-bearing data structure, and it is the place where the rest of the substrate's architectural commitments are made concrete. §9 specifies the consensus mechanism that governs transitions. §10 specifies the byte history's content-addressed structure in more detail. §11 specifies the cluster topology that bounds where the consensus mechanism can operate. The remainder of Part II builds out from this five-field foundation. By the close of Part II, the reader has the full architectural picture.
## §9. Deterministic simulation as the consensus mechanism

The substrate uses lockstep deterministic simulation as its consensus mechanism. Each byte's cluster of replicating nodes runs an identical state machine, advanced one frame at a time, with the cluster committing each frame's post-state via cryptographic supermajority agreement. There is no proof-of-work. There is no proof-of-stake. There is no leader election. There is no mempool. There is no fee market. The consensus mechanism is the same one that has run real-time strategy games for forty years, applied to byte-denominated commerce because the same architecture solves the same problem at three to five orders of magnitude lower energy cost than blockchain alternatives.

This section is where the substrate's most counterintuitive engineering decision gets defended. The reflexive objection from anyone who has worked on distributed systems is that lockstep cannot possibly work at internet scale: it requires every node to receive every input, it deadlocks if any node is slow, it has no leader to break ties, it cannot tolerate Byzantine adversaries without a separate consensus protocol. Each of these objections is real, each has a specific architectural answer in the substrate's design, and the answers compose into a system that operates at scales the objections did not anticipate. §9 walks each objection and its answer.

By the close of §9, the reader should accept that lockstep simulation is not a clever workaround for blockchain's energy problem but the *natural* consensus mechanism for byte-denominated commerce, which the institutional middle and the cryptocurrency space both failed to notice for the same structural reason: institutional pattern-matching, in different forms.

### 9.1 What lockstep simulation is

Lockstep deterministic simulation is the architectural pattern in which every node in a replicating cluster runs an identical state machine, processes the same inputs in the same order, and produces byte-for-byte identical output state. The cluster's distributed agreement on the world is achieved not by sharing the world's state across nodes (each node already has it) but by exchanging only the inputs that move the state forward, plus periodic cryptographic verification that the states have not diverged.

A frame is the substrate's atomic unit of progress. Each frame proceeds in three phases:

**Phase one: input exchange.** Each node broadcasts its pending inputs — transfer requests, mint requests, attestation requests — to every other node in the cluster. The exchange is bidirectional and complete: each node ends the phase holding the union of all peer inputs for the frame.

**Phase two: deterministic transition.** Each node applies the union-ordered inputs to its local state, deterministically. The ordering is canonical (input by input hash, sorted) so all honest nodes apply inputs in the same order. The transition function is purely functional: same inputs in same order produce same output state.

**Phase three: cryptographic verification.** Each node computes the post-frame state hash and broadcasts it. The frame is committed if a supermajority (⌊2n/3⌋+1) of nodes report the same hash. The supermajority commit tolerates ⌊(n-1)/3⌋ Byzantine nodes per the standard BFT bound (§13).

The cycle repeats. A cluster running at one frame per millisecond commits a thousand frames per second; each frame can carry many transactions; throughput scales with frame rate and per-frame transaction capacity. The substrate's reference implementation runs at 1144 frames/second with 3 nodes and 99 frames/second with 10 nodes (Appendix A scaling table) — the throughput envelope is well within what byte-denominated commerce requires.

The architectural pattern is not new. Lockstep simulation was invented by real-time strategy game developers in the late 1990s to synchronize game state across networked players who could not afford to ship the full world state every frame (typical RTS games have tens of thousands of units; shipping all state every frame would saturate any home internet connection). The pattern was matured through the 2000s and 2010s into production-quality libraries (GGRS for Rust, backroll-rs, RetroArch's netplay subsystem, Photon's Bolt for Unity). By 2020 the pattern was off-the-shelf, well-documented, and battle-tested in commercial games shipping to millions of players. The substrate borrows the pattern unchanged, substituting "byte transactions" for "player inputs" and "byte state" for "game world state."

### 9.2 Why lockstep is sufficient for byte-denominated commerce

The reflexive objection is that lockstep is "obviously" inadequate for global financial infrastructure. The objection rests on three misreadings, each of which §9.2 addresses.

**Misreading one: lockstep is for low-stakes games, not for high-stakes finance.** This conflates the consequences of error with the architecture's correctness. A game using lockstep correctly will produce identical state across all clients, with state divergence (a "desync") immediately detectable and handled by either client disconnection or rollback. The architecture does not stop being correct when applied to financial state; it produces the same identical-state guarantee, with the same divergence-detection. The stakes are higher in finance, but the cryptographic and protocol machinery is the same. The substrate adds Byzantine-tolerant supermajority commit (§13) precisely because financial state requires defending against actively malicious nodes, but the underlying lockstep pattern is unchanged.

**Misreading two: lockstep cannot scale to internet-size networks.** This is correct but misleading. A *single* lockstep cluster cannot scale beyond ~32-64 nodes before message overhead dominates (§11). The substrate's response is to never run a single cluster at internet scale; instead, the substrate runs many clusters, with cross-cluster transfer protocols handling movement of bytes between clusters. The pattern is the same as the internet's: TCP/IP does not run a single autonomous system globally; it runs ~100,000 autonomous systems with BGP coordinating them. The substrate runs ~100,000 clusters with the cross-cluster protocols (§11.3) coordinating them. Scaling is by federation, not by consensus growth.

**Misreading three: lockstep cannot tolerate failures or adversaries.** This is the objection that confuses lockstep-the-pattern with naive-lockstep-without-defenses. The substrate's lockstep includes per-message phase buffering (§12), supermajority commit with ⌊(n-1)/3⌋ Byzantine tolerance (§13), dissent logging that identifies persistent misbehavers (§14), and persistence-and-replay that lets crashed nodes resume cleanly (§16). Each of these is a real defense against a real failure mode. The composed system tolerates the failure modes that internet-scale operation actually presents: slow nodes (handled by phase buffering), malicious nodes (handled by supermajority commit), crashed nodes (handled by persistence), and adversarial input ordering (handled by canonical hash-sort).

The substrate's lockstep is not "naive lockstep applied to finance." It is "lockstep composed with cryptographic supermajority commit, content-addressed history, and operational defenses against the specific failure modes adversarial financial environments produce." The composed pattern is correct for byte-denominated commerce. The reflexive "lockstep can't work for finance" objection answers a strawman.

### 9.3 The energy economics of lockstep vs blockchain

The energy comparison between lockstep and blockchain consensus is not subtle. It is three to five orders of magnitude. The reason is structural.

Blockchain consensus mechanisms — proof-of-work most prominently, but also proof-of-stake in its various forms — solve a harder problem than lockstep does. They achieve consensus among a fully open, permissionless, anonymous-participant network where any node can join or leave without coordination, where the network has no membership boundary, and where Sybil attacks (a single adversary running thousands of nodes) must be prevented economically rather than structurally. Each of these properties is genuinely valuable in some contexts; each is also expensive.

Proof-of-work prevents Sybil attacks by making node participation cost real energy: a node attempting to influence consensus must perform computation that has no economic value other than as a token of participation. The energy cost of Bitcoin's proof-of-work is approximately 120 TWh per year per the Cambridge Bitcoin Electricity Consumption Index 2024 estimate (with reported uncertainty bounds of 67–240 TWh; the network's hash rate and miners' energy mix drive the variation). This is in the range of a medium-sized country's electricity consumption — comparable to Belgium or the Netherlands. The cost is paid not for the work the network performs (settling transactions) but for the work the network's adversary-defense requires (preventing Sybil attacks).

Proof-of-stake replaces energy-per-Sybil with capital-at-risk-per-Sybil. The energy cost is dramatically lower (Ethereum's post-Merge proof-of-stake consumes approximately 0.0026 TWh/year per CCRI's measurement following the September 15, 2022 Merge — a 99.988% reduction from the network's pre-Merge ~94 TWh, and roughly 50,000× less than Bitcoin), but the architectural complexity is higher: stake-bonding, slashing, validator-set rotation, finality gadgets, MEV-resistance, and a dozen other concerns that Ethereum's protocol engineers have spent years working through.

Lockstep simulation does not solve the open-permissionless-Sybil-resistant consensus problem. It solves a different problem: consensus among a *known, bounded, signed-membership* set of nodes. A lockstep cluster has a defined membership; nodes join through admission protocols (§11.3.1) that include attestation, reputation, and proof-of-resource gates; the cluster size is bounded by the lockstep latency budget. Inside the bounded membership, supermajority commit handles Byzantine adversaries up to ⌊(n-1)/3⌋. There is no Sybil-resistance problem because membership is explicit, not anonymous.

The energy cost of lockstep is approximately the cost of running the deterministic state machine plus the cost of cryptographic verification (signatures, hashes). The substrate's reference implementation measures approximately 840 microjoules per transfer at n=3 in-process (Appendix A). At cluster scale with TCP transport and full BFT supermajority commit, the cost is bounded by the underlying compute and network operations: each transfer requires verifying one ed25519 signature (~100 microseconds of CPU), updating a small data structure in memory, hashing the updated state (microseconds), and exchanging a few hundred bytes per peer per frame. The total per-transfer energy is on the order of one millijoule, scaling modestly with cluster size as message overhead grows O(n²).

The energy comparison:

| Mechanism | Energy per transaction |
|---|---:|
| Bitcoin (proof-of-work) | ~3.6 × 10⁹ J |
| Ethereum (proof-of-stake, post-Merge) | ~2 × 10⁴ J |
| Visa (actual computation, excluding rent) | ~10⁻² to 10⁰ J |
| Substrate (lockstep + BFT, v0.3 measured) | ~10⁻³ J |

The Bitcoin figure derives from the Cambridge Bitcoin Electricity Consumption Index (CBECI) point estimate of approximately 120 TWh annual network consumption divided by approximately 120 million annual transactions, yielding roughly 3.6 gigajoules per transaction. The Ethereum proof-of-stake figure derives from CCRI's post-Merge measurement of approximately 2,600 MWh annual network consumption divided by approximately 400 million annual transactions. The Visa figure is the actual computational cost of credit-card transaction processing, which is small; what makes Visa expensive to users is the rent layer, not the computation. The substrate figure derives from the v0.3 reference implementation's measurement of approximately 840 microjoules per transfer at n=3 in-process (Appendix A).

The substrate is roughly two to three orders of magnitude cheaper than Visa's actual computation cost, seven orders of magnitude cheaper than Ethereum's proof-of-stake, and twelve orders of magnitude cheaper than Bitcoin's proof-of-work. The advantage over blockchain mechanisms comes from the architectural decision to operate within a bounded-membership cluster rather than an open-permissionless network. The advantage over Visa is smaller in pure computation but much larger in user-visible cost, because Visa's rent layer adds many orders of magnitude on top of its computation cost (see §4.3).

The energy economics are not the only reason to prefer lockstep, but they are the reason that makes the rest of the substrate's case mechanically inevitable. A substrate three to nine orders of magnitude cheaper to operate than alternatives will, by economic gravity alone, displace the alternatives over time — provided the substrate ships, gets deployed, and is not preempted by AI-mediated institutional middles.

### 9.4 The lockstep protocol in detail

The substrate's lockstep protocol has six steps per frame, executed by every node in the cluster. The protocol is identical regardless of cluster size, transport type, or cargo class. The reference implementation is approximately 200 lines of Rust; the protocol's correctness depends on each step being executed in order.

**Step 1: drain pending inputs.** Each node accumulates inputs (transfer requests, mint requests) submitted by its connected clients. At the start of a frame, the node drains its pending input queue into a per-frame batch. The pending queue is a per-node concept; clients submit to one or more nodes, and the substrate's input-distribution mechanism (round-robin in v0.4+, currently submit-to-any) ensures inputs reach the cluster.

**Step 2: broadcast input batch.** Each node sends its frame-N input batch to every peer. The message is `InputBatch { from: NodeId, frame: u64, transfers: Vec<TransferInput>, mints: Vec<MintInput> }`. Inputs are sent as their full signed records, not as references — the cluster does not assume out-of-band input availability.

**Step 3: receive peer input batches.** Each node waits for `InputBatch` messages from every peer for the current frame. The receive logic uses phase-buffered selection (§12) to handle peers that have run ahead by one frame; messages from frame N+1 are buffered until frame N+1's input-receive phase begins. A node that receives a duplicate `InputBatch` from the same peer for the same frame returns a protocol error.

**Step 4: order the union.** Each node forms the union of its own inputs and all peer inputs, then orders the union by canonical hash sort: each input is serialized to its bincode-equivalent canonical bytes, blake3-hashed, and sorted by the hash. Ties (identical inputs from different peers) are deduplicated. The ordering is deterministic — every honest node, given the same union, produces the same ordering.

**Step 5: deterministic transition.** Each node applies the ordered inputs to its local state. Mints are processed before transfers within the frame (§15). Each input is verified independently: signatures must match, previous history hashes must match, frame numbers must match, issuer registrations must be current. Inputs that fail any verification are silently dropped — the failure is deterministic, so all honest nodes drop the same inputs. After all inputs are applied, the frame number is incremented.

**Step 6: cryptographic supermajority commit.** Each node computes the post-frame state hash (blake3 over the canonical serialization of the entire state, including the new frame number) and broadcasts a `StateHash { from: NodeId, frame: u64, hash: Hash }` message. Each node tallies received state hashes; when a hash has been reported by ⌊2n/3⌋+1 nodes, the frame is committed at that hash. If the node's own hash matches the supermajority hash, the node continues normally. If the node's own hash differs from the supermajority hash, the node enters a divergence state (§13.3 outcome three describes the resulting halt; v0.3 halts with `MINORITY DIVERGENCE`, v0.4 will state-sync from honest peers per §16.5). If no hash reaches supermajority, the cluster has split (§13.5) and progress halts until the partition is resolved.

The protocol's correctness depends on three properties: every honest node executes the same steps in the same order, the deterministic transition produces identical state for identical inputs, and the cryptographic verification correctly identifies divergence. Each property is independently testable; the reference implementation has property tests covering each (Appendix A). The protocol's failure modes are also well-characterized: phase desynchronization is handled by buffering (§12), Byzantine adversaries are handled by supermajority commit (§13), input-ordering attacks are handled by canonical hash sort (§9.5), and crashed nodes are handled by persistence-and-replay (§16).

### 9.5 Determinism: the load-bearing requirement

Lockstep simulation requires that the state-transition function be *deterministic*: the same inputs in the same order, applied to the same starting state, must produce byte-for-byte identical resulting state. Every node in the cluster must agree, exactly, on what the state is after every frame. Any divergence — even a single bit — is detected by the supermajority commit and treated as a node-level failure.

Determinism is harder than it looks. Modern computing platforms are non-deterministic by default in several ways:

**Floating-point arithmetic.** IEEE 754 operations vary subtly across compilers, CPUs, and even CPU revisions. The result of `a + b + c` can differ depending on the order the operations are emitted by the compiler or scheduled by the CPU. The substrate forbids floating-point in the state-transition function and uses i64 fixed-point arithmetic throughout. Cargo values are stored as fixed-point integers with a documented scaling factor (typically 6 decimal places, so $1.50 is stored as 1_500_000); arithmetic on cargo values uses integer operations exclusively.

**Multi-threaded execution.** Concurrent execution interleaves unpredictably. The substrate's state-transition function is single-threaded per node: a node applies inputs sequentially, in the canonical ordering produced by §9.4 step 4. The substrate's outer infrastructure (network I/O, cryptographic verification, persistence) can be multi-threaded, but the state transition itself is not.

**System calls.** Calls to the operating system that return time-varying values (`gettimeofday`, `random`, `getpid`) introduce non-determinism. The substrate forbids these in the state-transition function. Frame numbers are the only time-like value, and they are deterministic by construction.

**Memory layout and allocator behavior.** Hash table iteration order, memory addresses, and similar allocator-dependent values can vary across runs. The substrate uses ordered data structures (BTreeMap rather than HashMap) for any iteration that affects state. Memory addresses are never used as values.

**Compiler and runtime variation.** Different compiler versions, optimization levels, and runtime libraries can produce subtly different behavior. The substrate's reference implementation pins specific versions of all dependencies; a substrate-conformance specification (the document accompanying this treatise) specifies the exact byte-level encodings the protocol requires, so that any conforming implementation in any language produces identical behavior.

The discipline required to maintain determinism is substantial but not exotic. Game engines have done it for forty years. Scientific simulations do it routinely. The discipline is well-understood, and the substrate's contribution is not to invent the discipline but to apply it to byte-denominated commerce.

The payoff for the discipline is the ability to use lockstep at all. Without determinism, the supermajority commit step would be useless — every honest node would produce a different state hash for the same inputs, and the cluster would never agree on anything. With determinism, the supermajority commit is the cluster's actual validation: agreement on the post-frame state hash *is* agreement on the post-frame state, because the hash uniquely identifies the state.

### 9.6 What lockstep does not solve

Lockstep is a consensus mechanism. It is not a complete distributed system. The substrate composes lockstep with several other mechanisms to handle problems lockstep alone does not address.

**Cluster admission and Sybil resistance.** Lockstep operates within a known, bounded membership. The question of who joins the cluster, on what terms, and how Sybil attacks against the admission process are prevented, is the cluster topology problem (§11.3). The substrate uses proof-of-resource shadow periods and reputation-based admission; these are layer-1.5 protocols that the substrate's lockstep does not itself provide.

**Cross-cluster coordination.** A single cluster cannot scale beyond ~32-64 nodes. Substrate-scale operation requires many clusters, with bytes moving between them. The cross-cluster transfer protocol (§11.3.3) is its own design problem, and lockstep within each cluster is just one ingredient. The substrate's reference implementation runs single-cluster only; cross-cluster is v0.4 work.

**Rejoining after partition.** A node that has been disconnected from its cluster (network partition, crash, prolonged unavailability) must catch up to the current frame before resuming participation. The substrate's persistence-and-replay mechanism (§16) handles cases where the node has its own checkpoint and log; cases where the node is rejoining without local state require state-sync from honest peers (v0.4).

**Application-layer concerns.** Lockstep produces deterministic, agreed-upon state. What that state means, how applications interpret it, what user interfaces present, and how higher-layer commerce is conducted are application concerns. The substrate provides the state; applications do everything else.

**Public verifiability of computations over cluster state — "compute-to-data."** Lockstep gives *bounded-membership* agreement: the cluster's nodes agree, by supermajority commit, on the result of every transition over their shared state. A party who is *not* a cluster member, and who wants to verify the result of a computation over cluster-held state — an aggregate, a join, a query over a dataset that lives in the cluster's bytes — without being admitted to the cluster and without being shown the underlying bytes, needs something lockstep does not itself produce: a succinct proof. This is where zero-knowledge proof systems compose, exactly as the substrate composes other primitives it does not provide natively (§19's "no cryptographic monoculture" discipline). The cheap default is lockstep replication among the bounded membership — sufficient whenever the parties who need to trust a result are, or can become, cluster members, which is the byte-denominated-commerce case §9.2 is built for, at roughly one millijoule per transfer. The escape hatch, for the public-verifier case, is a designated prover emitting a zero-knowledge proof of the proposition "the result of computation C over committed state S is R," which any non-member verifies in milliseconds without ever seeing S; the proof systems for this (succinct proofs over SQL-shaped queries, general zkVMs, proving marketplaces) are off-the-shelf as of the mid-2020s, just expensive relative to native execution, which is why they are the escape hatch and not the default. The composite primitive is *compute-to-data*: the data stays in the cluster, and what crosses to the outside is the result of a computation plus a proof of the result — never the data. This is the affordance a credible "data bank" needs in order to "monetize data without revealing it," it is precisely the affordance the products that advertise that phrase do not actually have, and it is a composition the substrate supports — lockstep for the bounded case, ZK for the public case — rather than a property lockstep delivers alone.

These are not gaps in the substrate's correctness; they are the boundaries between what the substrate provides and what other layers must provide. Lockstep is sufficient for what lockstep is supposed to do — committing frames of byte-state with cryptographic agreement. It is not sufficient for the full system, and the substrate is honest about the additional mechanisms it composes lockstep with.

The next section (§10) specifies the byte history's content-addressed structure in more detail, particularly the chain-of-hashes that makes per-byte verification independent of cluster trust. §11 specifies cluster topology and the constraints that govern it. §12-§17 build out the remaining architectural components. By the close of Part II, the reader has the full architectural picture, and the threat model in Part III becomes the natural next concern: what attacks does this architecture have to survive, and what does it actually defend against?

Lockstep simulation as the consensus mechanism is the substrate's most counterintuitive engineering decision. It is also the substrate's most defensible one, because the alternative — proof-of-work or proof-of-stake — solves a harder problem at three to nine orders of magnitude higher energy cost, and the substrate's bounded-membership cluster topology means the harder problem does not need solving. The institutional middle and the cryptocurrency space both failed to notice this for the same structural reason: institutional pattern-matching. The institutional middle pattern-matched "deterministic computation = blockchain = energy-wasteful," and the cryptocurrency space pattern-matched "consensus = open membership = needs Sybil-resistance." Both pattern-matches are wrong for byte-denominated commerce, and the substrate's design is what falls out when both pattern-matches are dropped.
## §10. The byte history as content-addressed chain

A smart byte's history is the complete, ordered sequence of all transitions the byte has undergone since its origin. The history is content-addressed: each transition includes the cryptographic hash of the byte's history-up-to-that-point, so the chain of transitions forms an unbreakable cryptographic ladder from the byte's current state back to its birth. Any party holding the byte's full history can independently verify every transition without trusting the cluster, the issuer, the original recipient, or any intermediate owner.

This section specifies the chain's mechanics, walks the verification procedure step by step, identifies what the chain enables that account-based architectures cannot match, and names the three places where the chain's content-addressing is load-bearing for the substrate's architectural commitments. By the close of §10, the reader should understand why the substrate's history is structurally different from a bank's transaction record or a blockchain's block, and why the difference matters.

### 10.1 The chain's structure

Every smart byte begins with an origin attestation (§8.3). The origin attestation's blake3 hash is the byte's identity (§8.2) and also serves as the byte's *initial history hash* — the hash of "the history so far," which at the byte's birth is just the origin attestation itself.

Each subsequent transition extends the chain. A transition records:

- The byte's identity (binding the transition to a specific byte)
- The previous history hash (binding the transition to a specific point in the chain)
- The transition's payload (a transfer's from-pubkey, to-pubkey, frame-number, and signature; see §8.4)

The transition's *new history hash* is computed as `blake3(previous_history_hash || transition_payload)`. This new hash becomes the byte's current history hash. The next transition references this new hash as its previous-history-hash, and so on. The chain is a Merkle-style hash sequence where each hash incorporates everything before it.

A byte's full state at any moment is the tuple (current owner, current history hash, current cargo, accumulated joule cost). The current history hash is the cryptographic summary of every transition the byte has experienced. Two bytes with the same current history hash have undergone identical transition sequences from the same origin; two bytes with different current history hashes have either different origins or different transition sequences.

### 10.2 Verification procedure

A party in possession of a byte's full history (origin attestation plus the ordered sequence of transitions) can verify the byte's authenticity end-to-end via the following procedure. The procedure is purely a function of the history's content; it requires no cluster connection, no issuer trust, no external state.

**Step 1: verify the origin attestation.** Compute the blake3 hash of the origin attestation's canonical serialization. This hash must equal the byte's identity. If it doesn't, the origin attestation has been tampered with or the byte's identity is forged; verification fails.

**Step 2: verify the issuer's signature.** Reconstruct the canonical message bound by the origin signature (cargo specification, recipient pubkey, nonce). Verify the issuer's ed25519 signature against the issuer's pubkey. If verification fails, the origin attestation is forged.

**Step 3: verify the issuer's authorization.** Confirm that the issuer's pubkey is in the issuer registry for the byte's cargo type. (This step requires access to the cluster's issuer registry at the time of byte creation, but the registry itself is content-addressed and verifiable; a verifier with the cluster's state-snapshot at the byte's birth-frame can confirm registration without further trust.) If the issuer was not registered, the origin attestation is invalid.

**Step 4: walk the transition chain.** For each transition in order:
- Compute the transition's previous-history-hash from the running chain. It must equal the previous-history-hash recorded in the transition. If not, the transition has been inserted, deleted, or reordered.
- Verify the transition's signature. The from-pubkey at this transition must equal the to-pubkey of the previous transition (or the original recipient pubkey for the first transition). The signature must verify against the from-pubkey over the canonical message (byte identity, previous-history-hash, from-pubkey, to-pubkey, frame-number).
- Update the running chain hash: `new_history_hash = blake3(previous_history_hash || transition_payload)`.

**Step 5: confirm the current state.** After walking all transitions, the running chain hash must equal the byte's claimed current history hash. The to-pubkey of the most recent transition must equal the byte's claimed current owner.

If all five steps succeed, the byte's history is authentic and the byte's current state is correctly derived from its history. If any step fails, the byte is corrupt, forged, or has been tampered with.

The verification has no concept of "the cluster says so." The verification is a pure function of the byte's content. This is the property that makes the substrate's trust model fundamentally different from any institutional-middle architecture: the verifier does not trust an authority; the verifier verifies.

### 10.3 What the chain enables

The content-addressed chain enables three properties no account-based architecture can match. Each is load-bearing for the substrate's broader architectural commitments.

**Independent third-party auditability.** A regulator, auditor, counterparty, or any other interested third party can verify a byte's full history without the cooperation of the byte's owner, the cluster operating the byte, or any institutional middle. The owner shares the byte's history; the third party walks the verification procedure. Neither party has any way to lie about what the history shows. This is structurally different from auditing a bank: a bank's records are owned by the bank, and the bank can present, withhold, or modify them at its discretion (subject to legal constraints, which the substrate makes irrelevant). A byte's history is owned by the byte itself. The auditor's confidence in the audit's correctness is identical to the auditor's confidence in blake3's collision resistance — well-understood, well-tested, well-bounded.

**Cluster trust scoped to current state only.** Every cluster operating a byte must be trusted for one thing: the byte's *current* state and current history hash. The cluster cannot be trusted (or rather, does not need to be trusted) for the byte's deep history, because deep history is independently verifiable from the chain. This is the architectural decomposition that lets the substrate scale across many clusters: each cluster handles current-state consensus for its own bytes, and the chain handles historical verification across cluster boundaries. A byte that has lived in cluster A and been transferred to cluster B is verifiable by cluster B without cluster B trusting cluster A's deep history claims; B asks for the byte's full chain, walks the verification, confirms the result.

**Tamper evidence with cryptographic precision.** Any modification to any part of the chain — the origin attestation, any transition's payload, any history hash — produces a hash divergence that is detectable on first verification. There is no way to forge "a byte that was transferred ten times" without forging ten transitions, each of which requires a valid signature from the byte's owner-at-the-time, which requires the corresponding private key. An adversary attempting to fabricate a fake history must compromise every owner's key in sequence, which is enormously harder than compromising a single bank's database. The chain's tamper-evidence is not "we hope this is hard to fake"; it is "this is at least as hard to fake as ed25519 + blake3, both of which are at the cryptographic-primitive level the wider security industry depends on."

These three properties compose into the substrate's broader claim: every byte carries its own legitimacy. The byte does not depend on the cluster's testimony for its history; it carries the testimony with it, cryptographically signed at every step. The cluster's contribution is current-frame consensus — what is the byte's *now*. Everything else, from the byte's birth to its most recent transfer, is intrinsic to the byte itself.

### 10.4 The three places the chain is load-bearing

The content-addressed chain is structurally load-bearing in three specific places elsewhere in the architecture. Each is worth naming so the reader can trace how §10's mechanics support the rest of the substrate.

**Place one: cross-cluster transfers (§11.3.3).** When a byte moves from cluster A to cluster B, cluster B must be confident that the byte is what cluster A says it is. Cluster A could lie. The chain is what makes cluster A's lie detectable: B asks for the byte's full history, walks the verification procedure, and either accepts (the chain verifies) or rejects (the chain doesn't). Cluster A's testimony about the byte's current state at the moment of transfer is the only thing B has to extend trust to, and that testimony is a single point: the current history hash plus the cluster's BFT-supermajority signature. Everything before that point B verifies independently.

**Place two: persistence and recovery (§16).** A node that has been disconnected from its cluster (network partition, crash, prolonged unavailability) recovers by loading its checkpoint and replaying the persisted log of frame inputs. The replay re-applies transitions to bytes; the chain's content-addressing ensures the replay produces the correct state, because each transition's previous-history-hash must match the byte's history at the moment of replay. A persistence layer that lost data, or that was tampered with by an adversary with disk access, would produce hash divergences when the node rejoined the cluster, immediately detectable by the supermajority commit. Persistence is therefore *audited by the chain* on every rejoin.

**Place three: dispute resolution (§3.2 and §22).** When two parties disagree about a byte's history — a recipient claims the byte was transferred to them, the alleged sender denies it — the chain is the authoritative record. The transferred-to party presents the byte's full chain ending with the transition naming them as the recipient. The verification either succeeds (the chain is valid, the signature is valid, the transfer happened) or fails (something in the chain is wrong, and the dispute is resolvable by identifying the failure). Dispute resolution does not require a court, an arbitrator, or an institutional adjudicator at the substrate layer; it requires only the chain. Layer-2 dispute resolution services may exist for cases where the cryptographic chain is insufficient (a user claiming they were defrauded into authorizing a transfer they didn't intend, for example), but those services operate above the substrate's chain-verification layer, not as substitutes for it.

### 10.5 Comparison to existing architectures

The content-addressed chain is not unprecedented; what is new is its application to byte-denominated commerce.

**Bitcoin's blockchain** is a content-addressed chain at the *block* level: each block contains the previous block's hash, and the chain is verifiable end-to-end. Bitcoin's design verifies *the entire ledger* through this chain. The substrate's chain operates at the *byte* level: each byte has its own chain, and the cluster's state is the union of all bytes' chains. The difference is significant: Bitcoin's chain forces every node to hold every transaction ever; the substrate's chain lets each byte's history be replicated only where it is needed. A byte that has lived only in cluster A has its full history only in cluster A's nodes; nodes in cluster B that have never handled the byte do not need to know about it.

**Git's commit graph** is a content-addressed chain at the commit level: each commit references its parent commit's hash, producing a verifiable history of source-code changes. The substrate's chain pattern is identical in spirit. What differs is that Git's chain is single-author at each commit (typically) while the substrate's chain alternates owners with each transfer. The cryptographic mechanics are otherwise the same, and the verification procedure is structurally identical to walking a Git history.

**IPFS's content-addressed storage** is a single-level content addressing (a piece of data's hash is its identifier) without an intrinsic chain structure. The substrate composes single-level content addressing (the byte's identity, §8.2) with chain-level content addressing (the byte's history, §10.1) to get both properties: a unique identifier per byte and a verifiable history per byte.

**Bank transaction logs** are not content-addressed at all. A bank's record of a transaction is a row in a database, identified by a sequence number or a UUID assigned by the bank. The bank can edit the row, delete the row, or insert a new row claiming an earlier sequence number, with no cryptographic detection mechanism. Bank logs are tamper-evident only to the extent that the bank's auditing controls and regulatory inspections detect tampering, which is institutional rather than cryptographic. The substrate's chain replaces the institutional integrity guarantee with a cryptographic one. The institutional guarantee can be defeated by the institution itself, the regulators capturing the institution, or political pressure on either; the cryptographic guarantee can be defeated only by breaking blake3 or ed25519, neither of which is currently feasible.

The substrate's architectural innovation in §10 is therefore not the chain itself — chains are forty-year-old cryptographic structures — but the *application of per-byte content-addressed chains to byte-denominated commerce*. The application matters because byte-denominated commerce was previously the domain of account-based architectures (banks) or single-ledger architectures (Bitcoin), neither of which gives the substrate's architectural decomposition: cluster-trusted current state, chain-trusted deep history, scalable across many clusters, independently verifiable end-to-end.

### 10.6 What the chain does not provide

The chain is precise about what it provides and what it does not. The discipline of §6 (overclaiming is worse than underclaiming) applies here.

**The chain does not provide privacy.** A byte's full history is visible to any party who holds it. The owner of a byte who wants to maintain privacy must use layer-2 mechanisms — separate pubkeys per relationship, cargo mixing for fungible cargo types, zero-knowledge proofs where appropriate. The substrate's chain transparency is the cost of the four freedoms named in §6.1, and it is an honest cost.

**The chain does not provide reversibility.** Once a transition is applied and the frame is committed, the transition is permanent. A user who authorized a transfer they later regret cannot undo it at the substrate level. (They can ask the recipient to send the byte back, which is a new transition, not a reversal.) Layer-2 services can offer "reversible" wrappers — escrow with timed release, conditional transfers with off-chain dispute resolution — but those compose on top of the chain rather than modifying its irreversibility. This is the same property Bitcoin has; users gain finality at the cost of recoverability from authorized mistakes.

**The chain does not provide automatic restitution.** A user whose private key is compromised loses control of the bytes signed by that key, and the chain has no mechanism to restore them. Recovery requires either issuer cooperation (if the issuer is willing to honor a key-rotation request and the cargo allows it, the issuer can mint replacement bytes) or social-recovery layer-2 services (multi-signature schemes, trusted-friend recovery, hardware-token rotation). The chain itself is silent on recovery; it is a record of what cryptographic operations occurred, not a judgment about whether they should have.

**The chain does not detect application-layer fraud.** The chain validates that signatures are correct and history is consistent; it does not validate that signatures were *intended*. A user phished into authorizing a transfer signs a valid transition that the chain accepts. Layer-2 fraud detection (anomaly detection, rate limiting, suspicious-pattern flagging) is the right place for this concern. The substrate provides cryptographic correctness; it does not provide intention verification.

These four absences are real and the treatise does not paper over them. Each is named here to be precise about the substrate's contribution: the chain is a mechanism for cryptographic authentication of byte history, and that is what it does. Privacy, reversibility, restitution, and intention verification are layer-2 concerns that compose on top of the chain, with their own tradeoffs and their own service providers. The substrate is honest about the boundary.

The next section (§11) specifies cluster topology and the constraints that govern it. The chain's content-addressing is what lets clusters trust each other's current-state assertions while independently verifying deep history; §11 walks the cluster topology that this trust decomposition enables. By the close of §11, the architectural picture covers byte schema (§8), consensus (§9), history (§10), and topology (§11) — the four primitives that compose into a substrate that performs the institutional middle's three functions at the cost structure §4 established.
## §11. Cluster topology and node admission

A single lockstep cluster cannot scale beyond approximately 32 to 64 nodes before message overhead dominates and per-frame work makes the cluster unusable. Every empirical scaling result the reference implementation has produced (Appendix A) confirms the O(n²) growth in per-frame messages, and confirms that the wall-clock cost of a frame at n=10 is already five times the cost at n=4. Substrate-scale operation — millions of bytes, billions of transfers per day, global geographic distribution — cannot be achieved by growing a single cluster. It must be achieved by federating many clusters.

This section specifies the substrate's cluster topology: how clusters are sized, how nodes are admitted, how clusters split when they grow too large, how bytes move between clusters, and how Byzantine cluster-level threats are contained. The section does the hardest architectural work in Part II because cluster topology is where the substrate's "trust the cluster for current state, trust the chain for deep history" decomposition is operationalized.

By the close of §11, the reader should understand why the substrate scales by federation rather than by consensus growth, what each cluster is responsible for, how the cluster system as a whole achieves substrate-scale throughput, and where the substrate genuinely defers v0.4+ work because the design is incomplete. The section is honest about what is implemented (§11.1, §11.2) and what is design-only (§11.3.2, §11.3.3, §11.3.4).

### 11.1 Cluster sizing: empirical bounds

A lockstep cluster's per-frame work is dominated by message exchange. Each node sends to (n-1) peers and receives from (n-1) peers in each phase; the substrate's protocol has two phases per frame (input exchange and state-hash exchange); the per-frame message count is therefore approximately 2 × n × (n-1), which is O(n²). The wall-clock duration of a frame is bounded by the slowest message in the slowest phase plus the deterministic transition cost.

Empirical measurements from the v0.3 reference implementation (Appendix A) running in-process mpsc on a single laptop, 500 frames per measurement:

| n  | wall-clock | frames/sec | per-frame messages |
|----|-----------:|-----------:|-------------------:|
| 2  |     0.194s |       2578 |                  4 |
| 3  |     0.437s |       1144 |                 12 |
| 4  |     0.795s |        629 |                 24 |
| 5  |     1.229s |        407 |                 40 |
| 7  |     2.393s |        209 |                 84 |
| 10 |     5.052s |         99 |                180 |

Throughput drops as 1/n² as predicted. At n=10, single-laptop throughput is below 100 frames/second, which is uncomfortable but not yet broken. At n=32 (extrapolating the curve), single-laptop throughput would be approximately 10 frames/second, which is the practical threshold for byte-denominated commerce. At n=64, throughput would be approximately 2.5 frames/second, which is too slow for general use but viable for low-throughput specialized clusters.

Real cluster operation does not run in-process on a single laptop. A cluster running over TCP across geographically-distributed machines has additional per-message latency (round-trip time across the network) but parallelizes the cryptographic and state-machine work across the participating machines. The substrate's reference implementation has been stress-tested at n=3 over real TCP for 10,000 frames at approximately 986 frames/second wall-clock — comparable to the in-process measurement at the same cluster size. This suggests that the geographic distribution adds latency but does not change the fundamental scaling shape.

The substrate's working assumption for v1.0:

- **Design target**: 32 nodes per cluster
- **Hard cap**: 64 nodes per cluster
- **Below 4 nodes**: not BFT-meaningful (§13.2); avoid via cluster admission and merging policies
- **Optimum**: 8-16 nodes (good BFT margin, manageable message overhead)

These numbers will tighten as v1.0+ runs at real cluster scale across diverse hardware. The treatise commits to revising them in subsequent versions as empirical data accumulates. The numbers are not architectural commitments; they are pragmatic operating ranges that the substrate's protocols are designed to handle.

### 11.2 Node admission

A cluster must control who joins it. Open admission is a Sybil-attack vector (§21): an adversary running n/3 fake nodes can exceed the BFT bound and corrupt the cluster's state. The substrate's admission protocol uses three gates, each independently necessary, all collectively required for admission.

**Gate one: cryptographic identity.** A candidate node generates an ed25519 keypair and presents the public key to the cluster. The pubkey becomes the node's permanent identity in the cluster. There is no recovery for a lost private key; a node whose key is compromised must rejoin under a new identity, with all admission gates re-traversed. This is intentional — making admission cheap to repeat would weaken the gate's Sybil resistance.

**Gate two: proof-of-resource shadow period.** The candidate runs alongside the cluster for a configurable period (default: 30 days) without participating in supermajority commits. During the shadow period, the candidate receives all the cluster's lockstep messages, processes them locally, computes its own state hashes, and reports them to the cluster. The cluster verifies that the candidate's hashes match the supermajority hash on every frame. A candidate that cannot keep up (slow hardware, unreliable network) or that produces divergent hashes (faulty implementation, malicious behavior) is rejected. The shadow period serves multiple functions: it filters out infrastructure that cannot meet the cluster's performance requirements, it surfaces implementation bugs before the candidate has voting power, and it imposes a real resource cost (running production-equivalent infrastructure for 30 days) that limits the rate at which Sybil attackers can spawn admission attempts.

**Gate three: existing-member sponsorship.** A candidate must be sponsored by at least two existing cluster members, who attest (with their own signatures) that they have evaluated the candidate's identity, infrastructure, and trustworthiness. Sponsorship is not a popularity vote; it is a reputational commitment. A sponsor whose sponsored candidate later misbehaves accumulates dissent-log weight (§14) and risks their own admission status in subsequent reviews. Sponsorship makes admission a peer-to-peer reputation flow rather than a centralized gatekeeping function.

The three gates compose into an admission protocol that:

- Has no central authority (no single party can admit or reject candidates)
- Resists Sybil attacks (running 30 days of infrastructure × 2 sponsors per Sybil node makes large-scale Sybil expensive)
- Filters poor implementations and operationally-weak candidates (the shadow period surfaces bugs and infrastructure problems)
- Aligns admission with cluster health (sponsorship creates reputational stakes that incentivize honest evaluation)
- Is auditable (every admission produces a content-addressed admission attestation visible to all members)

The substrate's admission gates are not magic. A determined adversary with enough capital can clear them by running 30 days of infrastructure and bribing two existing members. The gates raise the cost; they do not eliminate the threat. §21 (Cluster topology attacks) walks the residual threats.

### 11.3 Cluster lifecycle: splitting, merging, joining, departing

A cluster is not a static thing. Members join, members depart, the cluster grows past its sizing target, the cluster shrinks below the BFT-meaningful threshold. Each lifecycle event needs a protocol the substrate can execute deterministically. v0.3 implements admission and graceful departure. v0.4 must implement splitting, merging, and adversarial-departure handling.

#### 11.3.1 Cluster size and admission criteria

Beyond the §11.2 gates, the substrate uses two operational criteria to govern cluster size:

**Below n=4**: the cluster is not BFT-meaningful and must accept any qualified candidate immediately to grow. The §11.2 shadow period is reduced or waived in this regime, with the tradeoff that under-4 clusters have weaker Sybil defenses. Clusters operating at n=2 or n=3 should be treated as transient — either growing toward n=4 or merging with a neighbor cluster.

**Approaching n=64**: the cluster prepares to split (§11.3.2). New admission slows or pauses while the split protocol executes. The cluster does not refuse admission of qualified candidates outright; instead, it admits them and then splits, distributing members across the resulting clusters.

These are not arbitrary numbers. n=4 is the BFT threshold (§13.2). n=64 is the practical lockstep ceiling at v1.0 hardware levels. v0.4+ may revise the ceiling upward as cluster infrastructure becomes more capable.

#### 11.3.2 Cluster splitting protocol

When a cluster reaches the splitting threshold, it must divide into two clusters with a deterministic rule for which bytes go to which cluster. The substrate's design (not yet implemented in v0.3):

**Step 1: cluster-wide split decision.** The cluster's BFT supermajority commits a special `SplitFrame` decision — a frame in which no normal transitions are applied, only the split protocol's setup. The frame's content includes: the current member list, a deterministic randomness beacon (§11.3.4) drawn from all members' contributions, and a partition function specification.

**Step 2: byte partitioning.** Bytes are partitioned by the deterministic partition function applied to each byte's identity. The function takes the byte's identity hash, mixes in the randomness beacon, and outputs which of the two new clusters the byte belongs to. The function must be balanced (approximately equal byte-counts in each new cluster), deterministic (every node computes the same partition), and unpredictable (an adversary cannot game which cluster a specific byte ends up in by manipulating the byte's identity, because the randomness beacon is unknown until the SplitFrame).

**Step 3: member assignment.** Members are assigned to new clusters by similar deterministic rule, with the constraint that each new cluster has approximately n/2 members and meets the n≥4 BFT threshold. Members assigned to cluster A retain only the bytes that partitioned to cluster A; bytes that partitioned to cluster B are no longer the responsibility of cluster A members.

**Step 4: new cluster bootstrap.** Each new cluster begins with a fresh genesis state derived from the partitioned bytes. The cluster's initial state hash is the hash of the partitioned state. Both new clusters publish their initial state attestations to the substrate's gossip overlay, allowing external parties to discover them.

**Step 5: announcement.** Both new clusters announce their existence to the wider substrate, with cryptographic attestations linking them back to the parent cluster's SplitFrame. Cross-cluster references to bytes that lived in the parent cluster now resolve to one of the two new clusters via the partition function.

The split protocol's correctness depends on: (a) the randomness beacon being non-manipulable, (b) the partition function being deterministic and balanced, (c) all members agreeing on the SplitFrame's content. Each is a real engineering problem with known solutions; the substrate has not yet implemented them.

**v0.3 status:** not implemented. **v0.4 priority:** high. The split protocol is the substrate's primary scaling mechanism, and substrate adoption past a small handful of clusters requires it to work correctly.

#### 11.3.3 Cross-cluster byte transfer

A byte in cluster A whose new owner is in cluster B's jurisdiction must move from A to B. The substrate's design:

**Step 1: ownership transfer commits in cluster A.** The current owner of the byte authorizes a transfer to the new owner's pubkey. Cluster A's lockstep commits the transfer in the normal way (§9.4). The transfer's transition includes a special flag indicating the new owner is in cluster B's jurisdiction.

**Step 2: cluster A produces an export attestation.** Cluster A's BFT supermajority signs a content-addressed attestation containing: the byte's full history (origin attestation plus all transitions), the byte's current state, and a "forwarded to cluster B at frame N" notation. The attestation is published to the substrate's gossip overlay and pushed directly to cluster B.

**Step 3: cluster B verifies and imports.** Cluster B's nodes independently verify the byte's full history (§10.2) and verify cluster A's BFT-supermajority signature on the export attestation. If verification succeeds, cluster B's lockstep commits an import frame that adds the byte to cluster B's state.

**Step 4: cluster A retires the byte.** Cluster A's state no longer includes the byte. Subsequent transfers of the byte happen in cluster B. Cluster A retains the byte's history (for forensic purposes) but does not commit further transitions on it.

**Step 5: external references resolve to cluster B.** Any party with the byte's identity who queries the substrate's gossip overlay is directed to cluster B. The transfer is complete.

Cross-cluster transfers are slower than intra-cluster transfers (multiple frames in two clusters plus gossip propagation, on the order of 10 seconds end-to-end versus sub-second intra-cluster) but they are not common: most transfers are intra-cluster, and cross-cluster transfer is the exception used when ownership crosses cluster boundaries.

**v0.3 status:** not implemented. **v0.4 priority:** high. Cross-cluster transfers are required for federated operation.

#### 11.3.4 Cluster-level Byzantine model

A cluster can itself be Byzantine — not in the sense that ⌊(n-1)/3⌋ of its members are dishonest (which the BFT supermajority handles), but in the sense that the cluster's *supermajority* is colluding to misrepresent state to outside parties. A cluster whose entire membership is run by a single adversary can, in principle, sign export attestations for bytes that don't exist, forge histories, or refuse to honor legitimate transfer requests.

The substrate's defenses:

**Defense one: content-addressed history independent verification.** Cluster B's import procedure (§11.3.3 step 3) verifies the byte's history end-to-end via §10.2. A malicious cluster A cannot forge a history that verifies correctly without compromising every owner's private key in the chain. The import protocol does not extend trust to cluster A's testimony about deep history; it only extends trust to cluster A's testimony about the byte's *current* state at the moment of export, which is signed by cluster A's BFT supermajority and is cryptographically scoped.

**Defense two: cross-cluster attestation diversity.** Bytes that are valuable enough to attract adversarial attention are typically transferred multiple times across multiple clusters during their lifetime. Each cluster that has handled the byte produces attestations that are visible to the substrate's gossip overlay. A malicious cluster A claiming to have attested a byte that other clusters never saw can be detected by querying the gossip overlay for the byte's history of cluster touches.

**Defense three: cluster reputation accumulation.** A cluster that has been operating honestly for a long period, sponsored multiple successful admissions, and produced no anomalies in cross-cluster transfers accumulates reputation. A new cluster, or one with a history of anomalies, is treated with more caution by other clusters considering imports from it. Reputation is tracked via the dissent-log mechanism (§14) extended to cluster-level events.

**Defense four: cluster expulsion.** A cluster that is determined to be malicious can be expelled from the substrate by some quorum of honest clusters. Expelled clusters' attestations are no longer honored; bytes resident in expelled clusters are treated as orphaned (their history remains valid but their current state is unverifiable, requiring intervention by a cluster willing to import them with extra verification). The expulsion protocol's design is taken up in §22 (Issuer attacks) and §25 (Social attacks on the substrate itself); v0.3 does not implement it.

**v0.3 status:** intra-cluster Byzantine handling is implemented and tested (§13). Cluster-level Byzantine handling is design-only.

#### 11.3.5 Phase buffering — implemented in v0.3

The substrate's lockstep protocol requires receive-side message buffering at any cluster size n>2 to avoid a silent deadlock that occurs when a fast node advances to frame N+1 while a slow peer is still in frame N's state-hash phase. §12 specifies the deadlock, the fix, and the lessons in detail. The mention here, in the cluster topology section, is to flag that phase buffering is part of cluster topology's load-bearing protocols, not just a transport implementation detail. The reference implementation's `Node::recv_filtered` was added after the v0.3 testing surfaced this bug; without it, any cluster of n>2 nodes deadlocks within milliseconds.

The meta-claim this surfaces: distributed-systems prose at the architectural-doc level routinely skips over implementation details that turn out to be load-bearing. The cheapest way to find them is to write code, not more architecture. v0.4 work on §11.3.2 (splitting), §11.3.3 (cross-cluster transfer), and §11.3.4 (cluster-level Byzantine) will surface analogous implementation details that this prose cannot anticipate.

#### 11.3.6 Graceful departure and unexpected loss

A node that wants to leave a cluster gracefully (planned maintenance, hardware retirement, voluntary exit) submits a `DepartureNotice` input to the cluster's lockstep. The cluster's BFT supermajority commits the notice and the departing node ceases participation after the committed frame. The cluster's effective n decreases by one. If the resulting n drops below 4, the cluster either pauses admission of new bytes and seeks merger with a neighboring cluster, or expedites admission of pending candidates.

A node that disappears unexpectedly (crash, network partition, prolonged unavailability) is detected by the cluster's heartbeat mechanism. After a configurable timeout, the cluster commits a `MissingNode` frame that excludes the absent node from the supermajority count. The absent node, on rejoining, executes the recovery procedure (§16) — load checkpoint, replay log, optionally state-sync from honest peers if its own state is suspect — and re-enters participation.

Both protocols depend on the cluster's persistence layer (§16) being robust enough that node loss is recoverable from local state plus replay, with minimal need for state-sync from other members. The v0.3 reference implementation handles graceful departure adequately and unexpected loss adequately for non-Byzantine cases. Adversarial loss (a node that disappears with intent to corrupt state and rejoin under a different identity) is v0.4 work.

### 11.4 Substrate-level topology

The substrate's overall topology is a federation of clusters connected by a gossip overlay that propagates cross-cluster attestations, cluster-state snapshots, and announcements. The gossip overlay is not itself a cluster; it is a peer-to-peer network in which any substrate node can participate, propagating signed attestations from its connected clusters to peers in other parts of the substrate.

The gossip overlay's protocol is intentionally simple: every node maintains a small number of peer connections, gossips received attestations to its peers (with deduplication via content-addressing), and accepts queries for bytes by identity. Nodes may specialize — some nodes hold more byte histories than others, some are gateway nodes between geographic regions, some are read-only clients that don't participate in any cluster. The substrate's federation is therefore not a uniform network but a heterogeneous overlay where each node's role is determined by its operator's choices.

This is the same pattern as the internet's overlay structure: routers, servers, peers, edge devices, all participating in the same substrate at different scales of involvement. The architectural pattern is well-tested; the substrate borrows it unchanged.

### 11.5 What §11 does not yet specify

The treatise's discipline requires naming what is design-only.

**Cluster splitting (§11.3.2)**: design-only. v0.3 does not implement it. v0.4 priority: high.

**Cross-cluster byte transfer (§11.3.3)**: design-only. v0.3 does not implement it. v0.4 priority: high.

**Cluster-level Byzantine handling (§11.3.4)**: design-only. v0.3 implements intra-cluster Byzantine via supermajority commit; cluster-level expulsion is v0.4.

**Cluster merging**: not specified. The opposite of splitting (when two clusters' workloads decline and merging is more efficient than running both separately). Will be specified in v0.4 alongside splitting.

**Adversarial node loss**: not fully specified. v0.3 handles unexpected loss for non-Byzantine cases; cases involving an adversary deliberately disconnecting and rejoining under a different identity require additional work.

**Cluster-state snapshots for external verifiers**: mentioned in passing (§10.2 step 3). Not yet specified as a protocol. External verifiers need a mechanism to obtain a trustworthy state snapshot at a specified frame; the snapshot is signed by the cluster's BFT supermajority and indexed in the gossip overlay. v0.4 specification.

These five items are the substrate's most important v0.4 work in cluster topology. Each is a real engineering problem with known approaches; none is open-research-grade hard. The treatise commits to specifying all five in v0.4 of the substrate's specification documents.

The substrate's claim to scale through federation is therefore partially demonstrated and partially deferred. Single-cluster operation is implemented and tested at n=2..10 in-process and at n=3 over real TCP for 10K frames. Multi-cluster operation is design-only. The treatise's honesty discipline names the gap. The reference implementation is the existence proof for what works; the v0.4 specifications will be the existence proofs for the rest.

The next section (§12) walks the phase-buffering requirement in more detail, because while it was named in §11.3.5, it deserves its own subsection-level treatment as a load-bearing protocol detail. §13 specifies BFT supermajority commit. §14 specifies the dissent log. §15-§17 build out the remaining architectural components. By the close of Part II, the architectural picture is complete and the threat model in Part III becomes the natural next concern.
## §12. The phase buffering requirement

§11.3.5 named phase buffering as a load-bearing protocol detail. This section gives it the dedicated treatment its centrality requires. Phase buffering is not optional. It is not a performance optimization. It is a correctness requirement at any cluster size greater than two, and a lockstep implementation that omits it deadlocks within a few frames under any realistic operating conditions.

### 12.1 The deadlock

Lockstep proceeds in two phases per frame: input exchange (§9.4 steps 2-3) and state-hash exchange (§9.4 step 6). With unbounded message channels and asynchronous nodes, the phases are not synchronized across nodes. A fast node can complete frame N's state-hash phase, increment its frame counter, and begin frame N+1's input-broadcast phase while a slower peer is still processing frame N's state-hash phase.

Concretely: node A finishes frame N at wall-clock time T. Node A immediately begins frame N+1, which means broadcasting `InputBatch{from: A, frame: N+1, ...}` to all peers. Node B receives this message at time T + ε while still in frame N's state-hash phase, where it is expecting `StateHash{from: A, frame: N, ...}` messages.

A naive receive loop responds to the unexpected message type by returning a protocol error — "expected StateHash, received InputBatch." The thread carrying node B dies. Other nodes block forever waiting for B's StateHash{N} message. The cluster deadlocks silently. No error message is logged. No alert fires. The processes are simply hung.

The deadlock is not theoretical. The v0.3 reference implementation reproduced it within milliseconds at n=3 in the first test run before phase buffering was implemented. Any realistic n>2 cluster running asynchronous nodes over any non-deterministic transport (TCP, UDP, mpsc channels with bounded queues) will encounter the deadlock immediately.

### 12.2 The fix

The receive loop must accept any incoming message and route it to one of two destinations: process-now, or buffer-for-later. Messages matching the current expected (phase, frame, peer) tuple are processed immediately. Messages that don't match are pushed onto a per-node buffer. Subsequent phases consult the buffer first, before reading from the transport.

The fix is small in code (the v0.3 reference implementation's `Node::recv_filtered` is approximately 40 lines of Rust) but it is conceptually load-bearing. The receive loop must be willing to accept messages from "the future" — messages for the next frame, while still processing the current frame — and to delay processing them until the appropriate phase begins.

The buffer is bounded. Lockstep guarantees no node is ever more than one frame ahead of any other node, because frame N+1's processing requires N+1 InputBatch messages from N+1 peers, which requires those peers to have completed frame N. The buffer therefore holds at most one frame's worth of messages per peer. At n=64, that is 64 buffered messages in the worst case — trivially small.

### 12.3 Why this is not a layer-7 concern

It is tempting to argue that phase buffering is a transport-layer or application-framework concern, not a protocol concern. The argument is wrong, and the substrate's specification names buffering at the protocol level for two reasons.

**Reason one: implementations in different languages must all do this.** A Rust implementation that buffers and a Python implementation that doesn't will deadlock when they communicate, even though both are correctly implementing every other aspect of the protocol. The buffering requirement must be specified at the protocol level so that conforming implementations agree on the behavior.

**Reason two: the deadlock is silent.** Phase buffering is not the kind of bug that surfaces with a useful error message. The cluster simply stops making progress. An implementer who has not been warned that phase buffering is required will spend hours debugging "the cluster is hung" before discovering the cause. The treatise names the requirement explicitly so that no implementer has to rediscover it.

These two reasons together justify treating phase buffering as a first-class protocol concern. The substrate's conformance specification (the document accompanying this treatise) gives the buffering algorithm in formal pseudocode. Implementations that omit it are non-conforming, even if they appear to work in single-node tests.

### 12.4 What phase buffering does not solve

Phase buffering handles asynchronous node speed differences within the lockstep protocol's bounds. It does not handle:

**Network partitions.** A node that becomes unreachable for many frames is not "running ahead"; it is gone. The buffer cannot extend past one frame because the protocol assumes lockstep guarantees node progress within bounded relative speed. Network partitions are handled by the heartbeat-and-MissingNode mechanism (§11.3.6), not by buffering.

**Adversarial speed manipulation.** A node deliberately running slowly to exploit phase buffering for some adversarial purpose is bounded by the BFT supermajority — the cluster proceeds without the slow node's vote once supermajority is reached without it. Phase buffering does not defend against adversarial speed; the BFT commit does.

**Message loss.** A message that never arrives (dropped by the transport, lost in transit) does not get buffered; it never enters the buffer system. The transport layer is responsible for reliable delivery within the lockstep protocol's frame budget. The substrate's TCP transport handles reliability via TCP's standard mechanisms; the in-process mpsc transport is reliable by construction.

**Message reordering across peers.** Phase buffering correctly handles temporal reordering from a single peer (peer X's message for frame N+1 arriving before peer Y's message for frame N is fine — buffer X, process Y, then process X). It does not handle the case where peer X sends two messages for frame N in a different order than the protocol expects; that is an input-ordering concern (§9.4 step 4) handled by canonical hash sort.

These four exclusions are named so the reader does not over-credit phase buffering with capabilities it lacks. Buffering is a specific fix for a specific protocol-level race condition; other failure modes have other defenses.

### 12.5 The meta-lesson, retained

§11.3.5 already named the meta-lesson: distributed-systems prose at the architectural-doc level routinely skips over implementation details that turn out to be load-bearing. Phase buffering is the v0.3 reference implementation's clearest example. The bug took 50 milliseconds of running code to surface and would have been invisible from any amount of additional architectural prose. The treatise's authors do not claim to have anticipated phase buffering before writing the implementation; they claim to have *fixed* it after the implementation surfaced it, and to have updated the treatise to name it as a first-class concern.

The meta-lesson generalizes to every part of Part II that has not yet been implemented in code — particularly the cluster-splitting protocol (§11.3.2), cross-cluster transfer (§11.3.3), and cluster-level Byzantine handling (§11.3.4). Each of these will surface implementation details that this prose does not predict. The substrate's discipline is to ship implementations of each as v0.4 work and to update the treatise as the implementations surface what the prose missed. Treatises that do not get updated by their own implementations are unreliable; the substrate's treatise commits to revision discipline.

The next section (§13) specifies BFT supermajority commit in detail, including the n=3 BFT exception that the v0.3 implementation surfaced. The pattern continues: prose specifies what the protocol should do, code surfaces what the prose missed, treatise gets revised. By the close of Part II, the architectural picture covers every primitive the substrate composes, with explicit acknowledgment of where v0.4 work will surface details v1.0 cannot anticipate.
## §13. BFT supermajority commit

The substrate commits each frame iff at least ⌊2n/3⌋+1 nodes (out of n total in the cluster) agree on the post-frame state hash. This is the standard Byzantine Fault Tolerance threshold, and it tolerates up to ⌊(n-1)/3⌋ Byzantine nodes — nodes that may be arbitrarily faulty, including malicious, including coordinated. The BFT bound is well-known and the substrate inherits it from forty years of distributed-systems research; the substrate's contribution in §13 is to specify *how* the supermajority commit composes with lockstep simulation, what the failure modes are, and what v0.3 implementation testing surfaced about the BFT bound's behavior at small cluster sizes.

This section walks the supermajority commit protocol step by step, specifies the four outcomes a frame can reach, addresses the n=3 BFT exception that v0.3 testing made empirical rather than theoretical, and names what the supermajority commit does *not* defend against. By the close of §13, the reader should understand BFT's specific role in the substrate's defense in depth, what attacks it stops, and what attacks the substrate's other layers (dissent log, issuer governance, cluster topology) must handle instead.

### 13.1 The supermajority threshold

For a cluster of size n, the supermajority threshold is ⌊2n/3⌋+1. Equivalent expressions: "more than two-thirds," "the smallest integer greater than 2n/3," and "n - ⌊(n-1)/3⌋" (the count of honest nodes that must agree, given that ⌊(n-1)/3⌋ may be Byzantine).

The threshold table for small clusters:

| n | supermajority | tolerable Byzantine f | BFT-meaningful? |
|---|---:|---:|---|
| 2 | 2 | 0 | no |
| 3 | 3 | 0 | no |
| 4 | 3 | 1 | yes |
| 5 | 4 | 1 | yes |
| 6 | 5 | 1 | yes |
| 7 | 5 | 2 | yes |
| 10 | 7 | 3 | yes |
| 16 | 11 | 5 | yes |
| 32 | 22 | 10 | yes |
| 64 | 43 | 21 | yes |

The BFT-meaningful threshold is n=4. At n=2 and n=3, the formula evaluates such that any Byzantine node prevents commits — the cluster can detect divergence but cannot tolerate it. Cluster admission policies (§11.3.1) accordingly treat clusters below n=4 as transient: either growing toward n=4 or merging with a neighbor.

The threshold's correctness derives from a standard pigeonhole argument: if at most f nodes are Byzantine, then at least n-f are honest; for the cluster to commit, the supermajority must include at least one honest node's vote (preventing the Byzantine subset from forging a commit alone) and must exclude any single Byzantine subset's ability to block (preventing Byzantine nodes from preventing legitimate commits). The bound ⌊2n/3⌋+1 is the smallest threshold that satisfies both constraints when f ≤ ⌊(n-1)/3⌋.

### 13.2 The n=3 BFT exception

The v0.3 reference implementation's empirical testing surfaced the n=3 BFT exception as a specific protocol behavior worth naming. At n=3, the supermajority threshold is 3 (not 2), which means *all three nodes must agree* for a commit. A cluster with one Byzantine node at n=3 produces a 2-vs-1 hash split — two honest nodes report hash X, the Byzantine node reports hash Y — and no hash reaches supermajority. Honest nodes halt with `CLUSTER SPLIT`. The cluster cannot make progress.

This is correct BFT behavior: a 3-node cluster has no way to know which side of a 2-vs-1 split is the honest side without an external referee, which the substrate does not have. Honest nodes cannot proceed because doing so would risk committing the Byzantine state if the Byzantine node happened to be in the majority of two. The safe behavior is to halt.

Architecturally, this means **3-node clusters provide divergence detection, not Byzantine fault tolerance.** A 3-node cluster will detect that something is wrong (the cluster halts), but it cannot recover automatically. Recovery requires either operator intervention (identifying which node is faulty and removing it, then admitting a replacement to reach n=4) or merging with a neighboring cluster.

The implication for cluster admission: clusters that drop below n=4 are emergency states, not stable operating states. The §11.3.1 admission policy treats below-n=4 clusters with reduced shadow-period requirements precisely to grow them out of the BFT-degenerate regime as quickly as possible.

The v0.3 implementation tested this behavior explicitly. The `n3_one_liar_causes_cluster_split_for_honest_nodes` test (Appendix A) verifies that a 3-node cluster with one Byzantine node halts with `CLUSTER SPLIT` rather than proceeding. The test is small but the architectural lesson it embeds is significant: BFT protocols at small cluster sizes have non-obvious behavior that empirical testing surfaces and that pure-prose architecture documents may miss. The v0.2 architecture document treated "small cluster" as a working assumption without noting the n=3 discontinuity. The v0.3 implementation surfaced it. The treatise documents it. This is the iteration discipline §12.5 named.

### 13.3 The four frame outcomes

Each frame reaches one of four outcomes during the supermajority commit phase:

**Outcome one: clean commit.** Supermajority agreement on a hash, and the local node's hash matches. The frame is committed, the local node's state advances, and the protocol proceeds to frame N+1. This is the normal case and represents nearly all frames in a healthy cluster.

**Outcome two: commit with dissent.** Supermajority agreement on a hash, the local node's hash matches, but some peers reported divergent hashes. The frame is committed normally, and the dissenting peers are recorded in the local node's `dissent_log` (§14). The cluster proceeds, and the dissent-log accumulation is the mechanism by which persistent misbehavers are eventually identified and expelled. This case is the BFT bound working as designed: the cluster tolerates the divergence and continues.

**Outcome three: minority divergence.** Supermajority agreement on some hash, but the local node's hash does not match. The local node's state has diverged from the cluster supermajority. The local node halts with `MINORITY DIVERGENCE` and does not advance to frame N+1. Recovery requires state-sync from honest peers (v0.4 work; v0.3 nodes simply halt and require operator intervention).

**Outcome four: cluster split.** No hash reaches supermajority. This indicates either (a) more than ⌊(n-1)/3⌋ Byzantine nodes in the cluster, exceeding the BFT bound, or (b) a network partition that has split the cluster into two sub-quorums neither of which can independently reach supermajority. The cluster halts with `CLUSTER SPLIT` and progress is impossible until the partition is resolved or the Byzantine excess is identified and removed.

The four outcomes are exhaustive: every frame produces exactly one. The protocol's correctness depends on each node reaching the same outcome (every honest node sees the same supermajority tally), which the protocol guarantees via deterministic input ordering and identical state transition.

### 13.4 The MINORITY DIVERGENCE path: dead code for transport adversaries

The v0.3 reference implementation's testing surfaced a second BFT-related lesson worth naming. The `MINORITY DIVERGENCE` error path (outcome three above) is essentially **dead code for transport-layer adversaries**.

The intent of the path: a node whose internal state has corrupted detects this immediately by finding its own hash rejected by the supermajority. The intent is correct for the failure mode it was designed for — a node that genuinely has a corrupt internal state benefits from discovering this during the supermajority commit and halting before doing further damage.

In testing with transport-layer adversaries — adversaries that lie about their *outbound* state hash messages while running an honest internal state machine — the path turned out not to fire. A node lying about its broadcast hash sees: my own honest hash + (n-1) honest peers reporting honest hashes = unanimous agreement. The node's own internal hash is in the supermajority. The path does not trigger. The node commits successfully and is unaware that it broadcast garbage.

The substrate's *actual* misbehavior signal for transport-layer attacks is the dissent_log (§14), accumulated by *other* nodes who observed the lying node's broadcast diverge from the supermajority hash. The lying node's own behavior remains internally consistent; its lie is detected by its peers, not by itself.

The lesson: **error paths designed in the abstract for "obvious" failure modes often don't fire in the empirical failure modes that actually occur.** The architecture's load-bearing observability primitive is the dissent_log, not the MINORITY DIVERGENCE halt. The treatise names this honestly because the design history matters: if a future implementer sees `MINORITY DIVERGENCE` in the reference code and assumes it is the substrate's primary defense, they will misunderstand what the substrate actually relies on.

The path is preserved in the v0.3 reference implementation because it does correctly handle the case where a node's *internal* state has actually corrupted (memory error, deterministic-replay drift, fixed-point library bug). That case is rare but real; the path's existence is justified. The path's status as "primary defense" is what is wrong, not the path's existence.

### 13.5 The CLUSTER SPLIT path: when Byzantine excess or partition occurs

Outcome four — no hash reaches supermajority — indicates either Byzantine excess or network partition. The substrate cannot distinguish between these two causes from supermajority-commit information alone. Both are handled by the same response: halt the cluster and require external resolution.

For network partitions, the resolution is automatic when the partition heals. Nodes that were unreachable rejoin via the §11.3.6 unexpected-loss recovery (heartbeat detection, MissingNode commit, persistence-and-replay rejoin). Once enough nodes are reachable to form a supermajority, the cluster resumes.

For Byzantine excess, the resolution requires identifying and removing the excess Byzantine nodes. This is operator work in v0.3 (cluster operators inspect the dissent_log, identify persistent misbehavers, remove them via cluster-admission revocation). v0.4 will add automated expulsion for clusters whose dissent-log evidence reaches a confidence threshold.

A pathological case worth naming: a network partition that produces *two* sub-quorums, each with enough nodes to almost reach supermajority, but neither quite reaching it. Both sub-quorums halt with `CLUSTER SPLIT`. Neither can make progress. When the partition heals, the cluster resumes, but during the partition the cluster is effectively offline. This is correct BFT behavior — making progress in either sub-quorum during the partition would risk committing different states in the two sub-quorums, which would produce permanent divergence on partition heal — but it is a real availability cost that operators must factor into cluster sizing and geographic distribution.

The architectural mitigation: cluster topology should distribute nodes such that no single network failure mode (datacenter outage, regional internet failure, BGP hijack) puts more than ⌊(n-1)/3⌋ nodes on the wrong side of a partition. For an n=10 cluster tolerating f=3, that means no more than 3 nodes per failure domain. For n=64 tolerating f=21, 21 nodes per failure domain — generous but not unlimited. Geographic distribution is the substrate's primary defense against partition-induced availability loss, and clusters that operate entirely within a single AWS region or a single ISP's network have weaker partition resistance.

### 13.6 Composition with the rest of the architecture

BFT supermajority commit is the substrate's primary defense against Byzantine adversaries within a cluster. It composes with several other mechanisms in the architecture, each handling a class of threats that BFT alone does not address.

**Cryptographic verification of inputs (§8.4)** prevents adversaries from forging individual transitions. BFT handles the case where adversaries control multiple nodes and try to commit invalid state; cryptographic verification handles the case where an adversary is trying to forge a single transition's signature.

**Content-addressed history (§10)** provides defense in depth against cluster-level Byzantine collusion. Even if an entire cluster's supermajority is malicious, external parties can verify any byte's history independently from the chain, and cross-cluster transfers (§11.3.3) verify the chain rather than trusting the source cluster's testimony.

**Dissent log accumulation (§14)** provides the long-running misbehavior signal that BFT alone does not produce. BFT tolerates ⌊(n-1)/3⌋ Byzantine nodes per frame; the dissent log identifies which specific nodes have been Byzantine across many frames and provides the basis for expulsion.

**Cluster admission gates (§11.2)** raise the cost of Sybil attacks against the BFT bound. An adversary attempting to control ⌊n/3⌋+1 nodes (exceeding the BFT bound) must clear the admission gates for each, which is expensive in shadow-period infrastructure and sponsorship recruitment.

**Cross-cluster verification (§11.3.4)** prevents a malicious cluster from infecting the broader substrate. Even if cluster A's BFT supermajority is colluding, cluster B verifies imports independently via the chain, and the substrate's gossip overlay surfaces inconsistencies between cluster A's claims and other clusters' records.

These five mechanisms compose into the substrate's defense in depth: BFT handles the per-frame Byzantine bound, cryptographic verification handles per-input forgery, content-addressed history handles cluster-level collusion at the byte level, dissent log handles long-running misbehavior identification, and cluster admission raises the cost of Sybil attacks. Each mechanism is necessary; no single mechanism is sufficient.

### 13.7 What BFT supermajority commit does not defend against

The discipline of naming what is *not* defended remains.

**Adversaries who control more than ⌊(n-1)/3⌋ of the cluster.** This is the hard BFT bound. An adversary at this scale can commit forged state. The substrate's response is to make achieving this scale expensive (cluster admission, sponsorship requirements, shadow periods) and to detect Byzantine clusters at the federation level (§11.3.4). At the cluster's BFT-supermajority level, the adversary wins. This is the same fundamental limit every BFT system has; the substrate does not transcend it.

**Adversaries who control the cryptographic primitives.** A cryptographic break in ed25519 or blake3 — a real preimage attack on blake3, a signature forgery against ed25519 — defeats the substrate's BFT layer because the attacker can forge state hashes that any honest verifier would accept. The substrate's response is migration to a successor primitive, which is a substrate-wide event (§19). Until such a break occurs, the substrate inherits the cryptographic primitives' security; if such a break occurs, the substrate must migrate.

**Adversaries who control the cluster's input distribution.** A node that controls *which transactions enter the cluster* (by being the only node clients can submit to, or by selectively dropping submissions) can selectively prevent commit of inputs without breaking BFT. The transactions never enter the input batch, so the BFT supermajority sees nothing to vote on. Defenses include diverse input-submission paths (clients submit to multiple nodes), gossip-based input replication (input received by any node is propagated to all peers before the next frame), and adversarial-input-collector identification via dissent log analysis. v0.3 implements basic gossip input replication; richer defenses are v0.4 work.

**Cluster-level Byzantine collusion** (entire supermajority colluding). Handled by content-addressed history and cross-cluster verification, as named above. BFT supermajority itself does not defend against this; the substrate's defenses are at higher levels.

**Application-layer fraud.** A user phished into authorizing a transfer signs a valid transition. BFT correctly commits the transition because the cryptographic verification passes. The fraud is at the application layer, and BFT has no capacity to detect intention. Defenses are at the application layer (anomaly detection, social-recovery, dispute resolution services) and the substrate is intentionally silent on them.

These five exclusions name the boundaries of BFT's contribution. The treatise's discipline is to be precise about each defense's scope so that the substrate's defense in depth is legible and not over-credited to any single mechanism.

The next section (§14) specifies the dissent log in detail. The dissent log is the substrate's actual misbehavior signal for transport-layer adversaries (§13.4) and the foundation that long-running misbehavior detection and cluster expulsion build on. By the close of §14, the BFT-related mechanisms in Part II are complete, and §15-§17 build out the remaining architectural components (live issuance, persistence, transports).
## §14. The dissent log

The dissent log is the substrate's misbehavior signal. §13.4 named it as the load-bearing primitive: the actual defense against transport-layer Byzantine adversaries, accumulated cumulatively across many frames, used by the cluster to identify persistent misbehavers and (in v0.4+) drive expulsion. This section specifies what the dissent log records, how it is populated, what it is used for, and why it is structurally a better misbehavior signal than per-frame error halts.

By the close of §14, the reader should understand why the substrate watches *patterns over time* rather than reacting to *individual divergences*, and why this is the architecturally correct response to real-world adversaries who lie selectively rather than continuously.

### 14.1 What the dissent log records

Each node maintains a local dissent log: a per-cluster, append-only record of frames in which one or more peers' state hashes diverged from the supermajority hash. The structure is small.

Each entry contains:

- **Frame number.** The frame at which the dissent was observed.
- **Dissenting peer set.** The pubkey(s) of nodes whose reported state hash did not match the committed supermajority hash for this frame.
- **Local node's hash.** The hash this node computed for the frame, for cross-reference and audit.
- **Supermajority hash.** The hash that won the supermajority vote. (May equal local node's hash, in which case the local node is in the supermajority. May differ, in which case the local node is in the minority — but per §13.3 outcome three, this case halts the node, so dissent log entries from a still-running node always have local hash = supermajority hash.)

Each node's dissent log is its own. Two nodes in the same cluster may have slightly different dissent logs depending on which peers' messages each received and processed in time, but for committed frames the union of dissent logs across honest nodes converges quickly. The substrate does not require dissent logs to be consensus-replicated; each node's local log is sufficient for the log's primary use cases.

The log is never truncated automatically. Long-running clusters accumulate large logs over time, and operators must decide their own retention policies. v0.3 does not specify retention; v0.4 will (likely "retain N most recent entries plus a content-addressed checkpoint of older entries").

### 14.2 How dissent log entries are populated

§13.3 outcome two — "commit with dissent" — is the populating event. A frame committed by supermajority but with one or more peers reporting divergent hashes produces a dissent log entry on every honest node that observed the divergence. The entry is written deterministically: any honest node observing the same supermajority tally writes the same entry.

The deterministic property matters. If dissent log writes were nondeterministic, different honest nodes would have different dissent logs, and any aggregation across nodes (for expulsion decisions, for auditor inspection) would be ambiguous. By making the writes deterministic — same supermajority tally produces same entry — the substrate ensures that honest nodes converge on identical dissent observations.

The peers populating the log do not have to be in the cluster's BFT-tolerable Byzantine count; the log records dissent regardless of count. A frame with f=⌊(n-1)/3⌋ Byzantine nodes producing a 2/3-supermajority commit still produces a dissent log entry naming each Byzantine peer. This is what allows the cluster to identify *who* is misbehaving even when the supermajority is reached.

### 14.3 What the dissent log is used for

The dissent log enables three operational responses that no per-frame mechanism alone provides.

**Persistent misbehaver identification.** A peer whose pubkey appears in many dissent log entries over time is a persistent misbehaver. The substrate's dissent log makes this identification numerical: a peer that appears in 0% of log entries is honest; a peer that appears in 1% is faulty (occasional bad transmission, transient bug); a peer that appears in 50%+ is malicious. The thresholds are operator-tunable, but the signal is unambiguous: dissent frequency is the substrate's quantitative measure of misbehavior.

**Cluster expulsion (v0.4 work).** When a peer's dissent frequency exceeds an operator-configured threshold, the cluster initiates expulsion via a special `Expulsion` input that requires BFT supermajority commit. The expelled peer is removed from the cluster's membership, its admission slot is freed, and its sponsor (per §11.2 gate three) accumulates reputation cost. Expulsion is a normal cluster operation, not an emergency response.

**Cluster-level reputation.** Aggregating dissent across many clusters produces a substrate-wide misbehavior map. A cluster whose nodes accumulate dissent across multiple peer clusters is a cluster with operational problems (or hostile intent). The substrate's gossip overlay (§11.4) can carry dissent attestations between clusters, allowing higher-layer reputation systems to score clusters and the operators behind them. This is design-only in v0.3; v0.4 will specify the gossip protocol for dissent attestations.

These three responses are graduated. Per-frame BFT supermajority handles each frame in isolation. Dissent log accumulation handles patterns over many frames. Cluster expulsion handles persistent misbehavior at the membership level. Cluster-level reputation handles systemic problems at the federation level. Each layer responds at its appropriate timescale, from milliseconds (BFT) to hours (expulsion) to days (reputation).

### 14.4 Why patterns over time are the right signal

The substrate could have used per-frame error halts as its primary misbehavior signal — any divergence triggers a halt, operators investigate. This is the design v0.3 originally specified before testing surfaced the dead `MINORITY DIVERGENCE` path (§13.4). The pattern-over-time signal is structurally better for three reasons.

**Reason one: real adversaries lie selectively.** A node that lies on every frame is easy to detect and easy to ignore. A node that lies on 1% of frames, choosing the frames carefully, is harder to detect from any single frame and may have specific attack goals (corrupting a specific transaction, stalling a specific issuer, biasing input ordering against a specific user). Per-frame halts do not distinguish between random transient errors and selective adversarial behavior. Pattern observation does.

**Reason two: false positives have real costs.** A cluster that halts on every divergence is operationally fragile. Network glitches, transient bugs, and brief operator errors all produce occasional divergences that are not malicious. Halting the entire cluster for each one converts every transient hiccup into a cluster-wide outage. Pattern-based response tolerates the noise floor while flagging the signal.

**Reason three: misbehavers learn.** An adversary whose first lie causes a cluster halt knows immediately that they have been caught and can adapt their attack. An adversary whose lies are silently logged but produce no immediate response may continue lying indefinitely, accumulating evidence that the cluster uses to identify them with high confidence before acting. The slower response is the more reliable response.

The substrate's choice — pattern over time, dissent log accumulation, graduated response — reflects forty years of distributed-systems experience with adversarial environments. It is the same choice cybersecurity systems make (security event logs accumulate; alerts fire on patterns, not individual events) and the same choice anti-fraud systems make (transactions are scored on patterns, not individual flags). The substrate inherits the discipline.

### 14.5 What the dissent log does not provide

**The dissent log does not prove malice.** A peer in the log may be malicious, may be faulty, may be running on slow hardware, may have intermittent network issues, may have a bug in its implementation. The log records *divergence*, not *intent*. Operators interpreting the log must combine it with other signals (peer's reputation, hardware diagnostics, commit history) to distinguish between cause classes. The substrate provides the data; humans interpret.

**The dissent log does not handle adversaries who never get caught.** A peer whose hash always matches the supermajority — even when the peer is technically Byzantine, because it happens to agree with whatever the honest majority decides — never appears in the dissent log. The log captures only *visible* misbehavior. Invisible misbehavior (a Byzantine peer that happens to agree on every frame) is not detected, and the substrate's response is the same as for any other invisible problem: it cannot be detected, so it cannot be acted on. The BFT bound's tolerance is what makes invisible Byzantine behavior tolerable: even if such a peer exists, they cannot prevent commits or corrupt state alone.

**The dissent log does not aggregate across clusters automatically.** Each cluster's log is local. Cross-cluster reputation (§14.3) requires the gossip overlay to propagate dissent attestations, which is v0.4 work. Until that propagation is implemented, each cluster's expulsion decisions are based only on local evidence.

**The dissent log does not handle compromised loggers.** A node whose dissent log is itself corrupt (the node is logging false dissents, or failing to log real ones) is a misbehavior the substrate's BFT supermajority commit handles only weakly: the corrupt logger's *votes* are still subject to supermajority, but its *log entries* are local and not consensus-replicated. The substrate's response to this attack class is at the cluster admission and reputation layers (§11.2, §14.3) rather than at the log layer itself. Compromised logger detection is genuinely v0.4 work, not yet specified.

These four exclusions name the dissent log's actual scope. The treatise's discipline is to be precise: the dissent log is the load-bearing observability primitive for transport-layer Byzantine misbehavior in BFT clusters. It is not a complete misbehavior detection system, and the substrate composes it with other mechanisms to handle the threats it does not.

The next section (§15) specifies live issuance — how authorized issuers mint new bytes during runtime, how the issuer registry is maintained, and how the issuance flow composes with the BFT-supermajority lockstep. By the close of §15, the substrate's mint-and-transfer protocol is fully specified. §16 specifies persistence; §17 specifies transports. By the close of Part II, the architectural picture covers every primitive the substrate composes, and Part III walks the threat model the architecture has to survive.
## §15. Live issuance

Smart bytes are not all created at genesis. The substrate must support **live issuance**: authorized issuers minting new bytes during runtime, with the same cryptographic and BFT machinery that governs transfers. A USD-byte issued by a GENIUS-licensed stablecoin provider on Tuesday afternoon must reach the cluster, be validated by the cluster's lockstep, be committed by BFT supermajority, and become available to the recipient — all within the substrate's normal protocol cycle.

This section specifies the mechanics. §15.1 names what an issuer is and how an issuer becomes one. §15.2 specifies the mint message format and the validation pipeline. §15.3 specifies how mints flow through lockstep alongside transfers. §15.4 names the operational properties live issuance has that genesis-only issuance cannot match. §15.5 names what live issuance does *not* yet handle in v0.3 and what v0.4 must address.

By the close of §15, the reader should understand the issuance flow end-to-end and recognize why issuance is intentionally unified with transfer at the protocol level rather than handled as a privileged out-of-band operation.

### 15.1 The issuer registry

An issuer is an entity authorized to mint bytes of a specific cargo type. The substrate's state carries an **issuer registry** — a deterministic data structure mapping (cargo_type, issuer_pubkey) pairs to authorization records. Every node in the cluster holds the same registry, updated by the same mechanism, producing the same content-addressed hash.

The registry is populated at genesis with a known set of issuers per cargo type. For USD-bytes: GENIUS-licensed stablecoin issuers, identified by their published ed25519 pubkeys. For joule-bytes: registered solar cooperatives, utility producers, individual rooftop systems with verified interconnect attestation. For governance-vote bytes: the registered members of the governance body whose votes the cargo represents. The genesis registry is part of the cluster's genesis state and is committed to the genesis state hash.

Adding or removing issuers post-genesis is **governance work**. v0.3 does not implement issuer-set mutation; the registry is fixed at genesis. v0.4 will implement a governance flow in which issuer-set changes are themselves submitted as inputs, validated by the cluster's lockstep, committed by BFT supermajority, and require quorum approval from existing issuers (typically a supermajority of the affected cargo type's existing issuers). The governance flow is intentionally slow — adding or removing issuers is not a routine operation — and uses cryptographic signatures from existing issuers as authorization rather than relying on any single administrative authority.

The registry's public visibility is a structural property: any party querying the cluster's state can see the full issuer set for each cargo type. There are no hidden issuers, no private mint authorities, no out-of-band issuance paths. If a USD-byte appears in the cluster claiming to be issued by a key that is not in the registry, the byte is rejected. The transparency is not optional; it is what makes issuer accountability possible.

### 15.2 The mint message

A live mint is an input message submitted to the cluster's lockstep, structurally similar to a transfer input but carrying mint-specific fields. The reference implementation calls the message `MintInput`. It contains:

- **Cargo type tag**: identifies the cargo class being minted (USD, joule, etc.). Determines which issuer-registry entry the cluster checks for authorization.
- **Cargo bytes**: the application-layer cargo specification, identical in structure to what would appear in a fresh byte's origin attestation. Includes the cargo's value, the issuer's redemption policy, and any cargo-specific metadata.
- **Issuer pubkey**: the ed25519 public key of the entity claiming authority to mint. Must match a registered issuer pubkey for the cargo type.
- **Recipient pubkey**: the ed25519 public key of the entity who will own the byte after minting.
- **Nonce**: a 16-byte random or sequentially-allocated value preventing collision between distinct mints with otherwise-identical content. Same role as the nonce in genesis-time origin attestations (§8.3).
- **Issuer signature**: an ed25519 signature by the issuer's private key over the canonical serialization of (cargo_type, cargo_bytes, recipient, nonce). Binds the issuer to the mint and prevents anyone else from forging the mint.

The mint message is submitted to a cluster node by the issuer or an authorized intermediary (a wallet, a custodial service, an integration). The submitting node adds the mint to its pending input queue (§9.4 step 1) and broadcasts it as part of the next frame's `InputBatch` (§9.4 step 2).

Validation happens during the deterministic transition (§9.4 step 5). For each mint in the frame:

1. **Issuer authorization check.** The cluster verifies that the issuer pubkey is in the issuer registry for the cargo type. If not registered, the mint is silently dropped — deterministic across all honest nodes, since the registry is consensus-replicated.

2. **Signature verification.** The cluster reconstructs the canonical message (cargo_type, cargo_bytes, recipient, nonce) and verifies the issuer's signature against the issuer's pubkey. Forged or tampered signatures fail verification; the mint is silently dropped.

3. **Nonce-based byte ID computation.** The cluster computes the byte's identity as `blake3(canonical_origin_attestation)` where the canonical origin attestation includes issuer pubkey, cargo_type, cargo_bytes, recipient, nonce, signature, and the current frame number. The frame number is included so that mints with otherwise-identical fields submitted in different frames produce different byte IDs — preventing a subtle race where a duplicate mint message in a different frame would otherwise collide with an existing byte.

4. **Duplicate detection.** If a byte with the computed identity already exists in the cluster's state, the mint is silently dropped. This handles the case where the same mint message is submitted to multiple cluster nodes simultaneously and arrives as duplicate `InputBatch` entries — the second-applied mint is a no-op.

5. **State insertion.** A new smart byte is constructed with the canonical origin attestation and inserted into the cluster's state. The byte's owner is the recipient; the byte's history is the origin attestation alone (no transitions yet); the byte's joule cost starts at the cost of this frame's processing.

Validation that fails any check is silent across all honest nodes. There is no error returned to the submitting issuer at the substrate level — the issuer queries the cluster's state after the frame commits to confirm the mint succeeded. (Application-layer wrappers may provide synchronous-feeling APIs by waiting on the cluster's state; this is a higher-layer convenience, not a substrate property.)

### 15.3 Mint and transfer composition within a frame

A frame can contain both mints and transfers. The substrate processes them in a specific order: **mints first, then transfers**, with each class processed in canonical hash-ordering within the class (§9.4 step 4 for transfers; same algorithm for mints).

The mints-before-transfers ordering enables a useful pattern: an issuer can mint a byte and the recipient can transfer it within the same frame. A user submitting a mint request to a stablecoin issuer can have their wallet automatically queue a follow-on transfer (e.g., paying a merchant) at the same lockstep frame. The mint applies first, the byte exists, the transfer applies second, and the merchant has the byte at frame commit. The two operations appear simultaneous to the application layer.

The cross-class ordering is deterministic: every honest node processes mints before transfers in every frame, and the canonical hash-ordering within each class is identical across nodes. The composition does not weaken determinism.

The substrate does not allow the reverse pattern (transfer before mint within the same frame) because a transfer requires the byte to already exist; a transfer of a byte that has not yet been minted has no valid previous-history-hash and fails verification. Applications that need this pattern must split it across two frames.

### 15.4 What live issuance enables

Genesis-only issuance — the simpler architecture, used by Bitcoin and many cryptocurrency designs — would require all bytes that will ever exist to be created at the cluster's launch. This is structurally inadequate for the substrate's design goals, for four reasons.

**Reason one: dynamic supply.** A USD-byte issuer redeems bytes (burning them) when users withdraw to bank accounts and mints new bytes when users deposit. The supply must move with deposit and withdrawal flows in real time. Genesis-only issuance cannot model this; the supply is fixed at launch. Live issuance is required for any cargo type with dynamic supply, which is most of them.

**Reason two: many issuers.** The substrate is multi-issuer for every cargo type — multiple stablecoin providers, multiple solar cooperatives, multiple governance bodies. Each issuer mints independently. Genesis-only issuance forces all issuers to coordinate before launch, which is operationally infeasible at substrate scale. Live issuance lets issuers operate independently, governed by the issuer registry.

**Reason three: time-bound cargo.** Some cargo expires (perishable goods, time-bound service claims). The cargo specification includes the expiration; new cargo must be minted as the time-bound supply is consumed. Genesis-only issuance produces only stale cargo over time. Live issuance is required for any time-sensitive cargo type.

**Reason four: issuer governance.** The substrate's design includes evolving issuer sets — new issuers admitted (post-v0.4 governance), failing issuers removed, cargo-type creation as new use cases emerge. Genesis-only issuance fixes the issuer set forever, which forecloses substrate evolution. Live issuance is the operational mechanism that lets the substrate grow over time.

These four reasons compose into a single architectural commitment: live issuance is not a feature added to a genesis-only base; it is the substrate's primary issuance mechanism, and genesis issuance is just the special case of bytes minted at frame zero.

### 15.5 What live issuance does not yet handle

The discipline of naming what is design-only continues.

**Issuer governance for set mutation.** v0.3 fixes the issuer set at genesis. v0.4 must implement: signed governance proposals from existing issuers, supermajority voting among affected-cargo-type issuers, time-locked execution of approved changes, and graceful handling of issuers whose private keys have been compromised. The mechanics are well-understood (multi-signature governance is implemented in many adjacent systems) but the substrate's specification is not yet written.

**Issuer key rotation.** An issuer whose private key has been compromised should be able to rotate to a new key without losing authorization for the cargo type. The mechanics involve a signed rotation message from the old key (proving control until the rotation moment) authorizing the new key, with the substrate's registry updated atomically. v0.3 does not implement; v0.4 priority high.

**Issuer reserve attestations for redeemable cargo.** A USD-byte issuer claims their bytes are backed by dollar reserves; the substrate currently has no protocol-level mechanism for the issuer to attest, periodically and verifiably, that the reserves still exist. Layer-2 services (Chainlink-style oracles, regulator audit publication, on-chain reserve commitments) can provide this, but the substrate's protocol does not require it. v0.4 may specify a standard issuer attestation flow; v1.0 leaves this to layer-2.

**Issuer accountability for bad mints.** If an issuer mints bytes inappropriately (against insufficient reserves, in violation of regulatory rules, with internal fraud), the substrate accepts the mints because they are cryptographically valid. The accountability mechanism is at the legal and regulatory layer, not the substrate layer. v0.3 has no protocol-level response; v0.4 may include cluster-level expulsion of issuers via the same dissent-log mechanism that handles peer expulsion (§14.3), but the design is preliminary.

**Cross-cluster issuer registries.** Each cluster has its own issuer registry. If a byte issued by cluster A's issuer is transferred to cluster B (§11.3.3), cluster B must verify the issuer's authorization at the time of mint, which requires either replicating cluster A's registry (expensive) or trusting cluster A's BFT-supermajority signed export attestation (cheaper but adds trust). The substrate's design is the latter — cluster B trusts cluster A's signature on the export attestation, which includes the issuer's authorization at mint time. v0.4 must specify the cross-cluster issuer-registry attestation format precisely.

These five deferred items are real engineering work. None is open-research-grade; each has known approaches in adjacent systems. The treatise's discipline is to name them so the gap between v1.0 and a full production substrate is legible.

### 15.6 Why issuance is unified with transfer at the protocol level

A note on architectural philosophy. The substrate could have handled issuance as a privileged out-of-band operation — issuers submit mints through a separate channel, the cluster validates them out-of-protocol, the bytes appear in state without going through the standard input batch. Many systems take this approach. The substrate does not.

Issuance flows through the same lockstep that handles transfers, with the same `InputBatch` carrying both kinds of inputs, the same canonical hash-ordering within each class, the same BFT supermajority commit. The unification is intentional, for two reasons.

**Reason one: consistency.** A substrate that handled issuance through a separate code path would be vulnerable to bugs in that path that don't affect transfers. The path's separateness is itself a risk. By unifying, every issuance check is covered by the same cryptographic and BFT machinery that protects every transfer. Bugs in the substrate's transfer-validation code are bugs in issuance-validation code; security audits of one are security audits of the other.

**Reason two: protocol cleanliness.** A unified protocol has one input type, one validation pipeline, one ordering algorithm, one commit mechanism. The conceptual surface area is smaller. Engineers learning the substrate's protocol learn one thing, not two; testers writing protocol tests test one path, not two. Implementations in different languages have one set of behaviors to match.

The cost is that mint validation is slightly more complex than transfer validation (one extra check: issuer registration). The benefit is that everything else is identical. The substrate accepts the slight cost for the substantial benefit.

This is the same architectural choice that protocols designed for longevity have repeatedly made: minimize the number of distinguished message types, validate every type through the same pipeline, share infrastructure across all messages. The substrate's unification serves the same purpose — every input goes through the same lockstep, the same canonical ordering, the same BFT supermajority commit, with cargo-class differences handled by validation logic rather than by separate protocols.

The next section (§16) specifies persistence — checkpoint and replay log mechanics, the genesis-seeding requirement that v0.3 testing surfaced, and the bootstrap story for new nodes joining a cluster. By the close of §16, the substrate's storage model is complete. §17 specifies transports, and Part II closes with the architectural picture covering every primitive the substrate composes.
## §16. Persistence: checkpoint and replay log

A node that has never persisted its state cannot recover from a crash, cannot survive a planned restart, and cannot keep its position in the cluster across an operator's hardware refresh. Persistence is therefore not an optional feature of the substrate; it is a correctness requirement for any node operating in production.

This section specifies the substrate's persistence model: checkpoint-and-log, the genesis-seeding requirement that v0.3 testing surfaced, and the bootstrap story for new nodes joining a cluster. The section is short because the design is simple. The simplicity is the design's load-bearing property — persistence systems that are clever fail in clever ways, and the substrate's persistence is intentionally unclever.

### 16.1 The two-file design

Each node persists state to disk via two files:

**`checkpoint.bin`** — a full serialization of the node's State at the moment of the most recent checkpoint. The State serialization includes the frame number, every smart byte the cluster currently holds, and the issuer registry. The checkpoint is content-addressed: its hash is the cluster's state hash at the checkpoint frame, identical across all honest nodes. (The dissent log is per-node-local — see §14 — and is persisted separately by each node's operational tooling rather than as part of the consensus-replicated checkpoint.)

**`log.bin`** — an append-only sequence of length-prefixed `FrameInputs` records, one per committed frame since the most recent checkpoint. Each entry records the canonical-ordered transfers and mints that the cluster committed in that frame. The log entries are *not* the local node's submitted inputs; they are the *cluster's committed inputs*, identical across all honest nodes.

The two files together are a complete record of the node's state at any frame from the last checkpoint forward. To recover the node's state at any point, load the checkpoint and replay the log up to the desired frame.

The reference implementation uses bincode for the serialization format, with `blake3` content-addressing and length-prefix framing for the log. The format is not normative — any conforming implementation may choose its own serialization, provided the recovery semantics produce identical state. The substrate's conformance specification (the document accompanying this treatise) gives the canonical wire format that cross-implementation interoperability requires; nodes that interoperate with each other use the canonical format, while nodes that operate single-implementation clusters may use any format.

### 16.2 The recovery procedure

A node starting up performs:

**Step 1: open the checkpoint.** If `checkpoint.bin` exists, deserialize it and use the resulting State as the node's starting state. The deserialized state's frame number indicates how far the checkpoint advanced.

**Step 2: open the log.** If `log.bin` exists, iterate through its entries in order. For each entry, verify that the entry's frame number equals the current state's frame number (any mismatch is a corruption, fail loudly). Apply the entry's inputs to the state via the standard deterministic transition (§9.4 step 5).

**Step 3: enter normal operation.** The node's frame number now equals the cluster's last committed frame plus one. The node rejoins the cluster's lockstep at this frame, accepting incoming `InputBatch` and `StateHash` messages from peers, processing them normally.

A new node — never previously run — has neither file. Its starting state is the genesis state of its cluster, which it must obtain. §16.3 specifies how.

### 16.3 The genesis-seeding requirement

The v0.3 reference implementation surfaced a real bug worth naming as a load-bearing lesson. A naive persistence design — checkpoint and log only, no special handling of first-time startup — produces silently-wrong behavior the first time a node starts in a non-trivial cluster.

The bug: a node starting with no checkpoint and no log has an *empty* state (frame zero, no bytes, no issuers). The node connects to peers, receives `InputBatch` messages for the cluster's actual current frame, attempts to process them — and every transfer fails verification, because every transfer references a byte the node doesn't have. The transfers are silently dropped (the substrate's standard behavior on verification failure, §9.4 step 5). The node's state hash diverges from the cluster's supermajority hash. The node halts with `MINORITY DIVERGENCE` (§13.3 outcome three) or, if other nodes are also fresh, the cluster halts with `CLUSTER SPLIT`.

The bug is silent in the bad case: a freshly started node with empty state will appear to be running normally for several frames before the divergence becomes visible. There is no useful error message ("transfer references unknown byte_id" is logged, but it is logged at debug level if at all, and an operator unfamiliar with the failure mode will not connect the dots).

**The fix** is to require the node's first-time startup to seed itself with the cluster's *genesis state* — the canonical starting state that all cluster members share. The reference implementation provides this via `Persistence::open_with_genesis(dir, interval, genesis_state)`. On first open with no existing checkpoint, the genesis state is written immediately as `checkpoint.bin`, and subsequent startups read it as the authoritative starting state.

The protocol-level requirement: a node must obtain the cluster's genesis state from some authoritative source before participating in lockstep. The authoritative sources are:

- **Genesis bootstrap**: at cluster founding, the genesis state is generated by the founding members and signed by all of them. New members admitted later receive the genesis state from existing members as part of the admission flow (§11.2).
- **Checkpoint replication**: an established cluster periodically publishes content-addressed checkpoints to the substrate's gossip overlay (§11.4). A new node joining the cluster downloads the most recent published checkpoint, verifies its content-addressed hash against the cluster's BFT-supermajority signed attestation, and uses it as the starting state.
- **Cross-cluster import**: a node admitted to a cluster created by splitting from a parent cluster (§11.3.2) receives the new cluster's initial state from the split protocol's `SplitFrame`.

In each case, the node's startup state is *cryptographically anchored* to the cluster's history rather than being constructed locally. A node that cannot anchor — that has no genesis state, no checkpoint, no split-frame snapshot — cannot participate. The substrate refuses to run nodes whose starting state is not verifiable.

The genesis-seeding requirement is the substrate's third major v0.3 implementation lesson, alongside phase buffering (§12) and the dead `MINORITY DIVERGENCE` path (§13.4). The pattern is the same in each: a load-bearing detail that pure-prose architectural design did not anticipate, surfaced in milliseconds of running code, and now documented honestly. A treatise that ships v1.0 without naming these would be misleading; the substrate's approach is to name them and update.

### 16.4 The checkpoint cadence

A cluster operating at 1000 frames per second produces 1000 log entries per second. Without periodic checkpointing, the log grows unboundedly and recovery time grows linearly with uptime. The substrate's persistence layer therefore includes a **checkpoint cadence**: every N committed frames, the node rewrites the checkpoint with the current state and truncates the log.

The cadence N is operator-tunable. The tradeoff is straightforward:

- **Frequent checkpoints** (small N, e.g., 100 frames) produce faster recovery (less log to replay) at the cost of more disk writes (the entire state serialized every 100 frames).
- **Infrequent checkpoints** (large N, e.g., 100,000 frames) produce slower recovery (long log to replay on startup) but minimize disk write overhead during normal operation.

The reference implementation defaults to N=10,000, which produces approximately one checkpoint per ten seconds at 1000 fps. This is suitable for clusters whose state size is on the order of megabytes; larger states may require larger N to keep checkpoint cost low. The substrate does not commit to a default; operators tune for their workload.

The checkpoint write itself is durable: the implementation writes to a temporary file, calls `fsync`, and renames atomically to `checkpoint.bin`. This guarantees that a crash during checkpoint write does not produce a partial checkpoint — the operation is atomic from the recovery procedure's perspective. The log's `fsync`-on-append is currently per-frame (slow for high-throughput operation); v0.4 should batch `fsync` across multiple frames with the corresponding loss of last-N-frames durability on a hard crash, which is acceptable because honest peers can replay the missing frames after rejoin (§16.5).

### 16.5 What persistence does not solve

The discipline of naming what is *not* solved continues.

**State sync from honest peers.** A node whose local state has corrupted (disk failure, file system corruption, malicious tampering) cannot recover from its own checkpoint and log alone. Recovery requires fetching the cluster's current state from honest peers, verifying the cluster's BFT-supermajority signature on the state, and replacing the corrupt local state. v0.3 does not implement this; nodes whose state has corrupted halt and require operator intervention. v0.4 priority high.

**Bounded log retention with archival.** The substrate's persistence as specified retains all committed frames between checkpoints. A node whose checkpoint cadence is large and whose uptime is long will have a very long log. v0.4 should specify archival policies — older log entries can be compressed, moved to slower storage, or deleted entirely once enough subsequent checkpoints have advanced past them.

**Cross-node persistence consistency.** Each node's persistence is local and independent. Two nodes in the same cluster may have checkpoints at different frames, logs of different lengths, and `fsync` policies of different aggressiveness. The substrate is correct under this heterogeneity (because state is consensus-replicated by lockstep, not by file-replication), but operators may want consistency across nodes for operational reasons (faster recovery, simpler troubleshooting). v0.4 may specify operator tooling for cross-node consistency; the protocol does not require it.

**Encryption at rest.** Checkpoints and logs contain potentially sensitive data — the full byte state, including who owns what cargo. The substrate does not encrypt persistence by default; nodes operating in environments where disk theft is a concern must use OS-level full-disk encryption or filesystem-level encryption. v0.4 may specify a substrate-level encryption layer; v1.0 does not.

**Integrity verification of persistence.** A node loading its checkpoint trusts the checkpoint's content. An adversary with disk access could tamper with the checkpoint to inject false bytes, alter the issuer registry, or otherwise corrupt the node's starting state. The substrate's defense against this is the cluster's lockstep itself — any tampered state will produce divergent state hashes during the next supermajority commit, surfacing the problem within milliseconds. The substrate does not currently sign checkpoints with the node's own key; v0.4 should, allowing offline integrity verification independent of the cluster.

These five exclusions name the persistence layer's actual scope. The treatise's discipline is to be precise about what the layer provides (durable storage of state and log, recovery from clean shutdown and crash) and what it does not (state-sync, archival, encryption, integrity verification). The substrate composes persistence with the cluster's lockstep, the gossip overlay, and operator tooling to produce a complete operational story; persistence alone does not.

The next section (§17) specifies the two transports the v0.3 reference implementation supports — in-process mpsc and TCP — and the transport-agnostic interface that makes the substrate portable to other transports (QUIC, WebSocket, custom protocols). By the close of §17, Part II is complete and the architectural picture covers every primitive the substrate composes.
## §17. The two transports

The substrate's lockstep protocol exchanges messages between cluster nodes. *How* those messages travel — over what wire, with what framing, with what reliability and latency characteristics — is the **transport layer**. The substrate is intentionally transport-agnostic at the protocol level: any reliable, ordered, bidirectional message channel between peers is sufficient. The v0.3 reference implementation provides two transports — in-process mpsc and TCP — and the abstraction that lets future implementations swap in QUIC, WebSocket, or custom transports without changing the protocol.

This section closes Part II by specifying the transport interface, the two reference transports, and the properties future transports must satisfy. By the close of §17, the architectural picture covers every primitive the substrate composes; Part III then walks the threat model the architecture has to survive.

### 17.1 The transport interface

A substrate transport is any object satisfying two operations:

**`send_to(peer: NodeId, msg: LockstepMsg) -> Result<(), Error>`** — deliver a message to a specific peer in the cluster. The transport guarantees that if the call returns Ok, the peer will eventually receive the message exactly once, in the order it was sent relative to other messages sent to the same peer. If the call returns Err, the message may or may not have been delivered, and the cluster's lockstep treats this as if the peer is missing for this frame (the BFT supermajority handles missing peers per §13).

**`recv() -> Result<LockstepMsg, Error>`** — receive the next available message from any peer. The transport returns messages in arrival order, not in cluster-frame order. The lockstep protocol's phase buffering (§12) handles temporal reordering across peers and frames.

Peer set membership is not a transport concern. The `Node` holds the peer list directly; the transport is given a peer ID by the node and asked to deliver to that peer. Cluster-membership-changing operations (admission, expulsion, departure) update the node's peer list; the transport is informed only by virtue of receiving send_to calls for new peers and not for departed ones.

These two operations are the entire transport surface. The protocol does not require connection management, encryption, authentication, or any other transport-layer feature; if a specific transport implementation provides them, they are transport-internal concerns the protocol does not reach into.

The transport interface is deliberately minimal. A substrate implementation could add a third operation — `broadcast(msg) -> Result<(), Error>` — to express "send this to all peers" as a single call rather than as N `send_to` calls. The reference implementation does not, because broadcast at the transport level can hide partial-delivery failures (some peers receive, some don't) that the protocol needs to handle explicitly. Per-peer `send_to` makes the partial-delivery case visible and the protocol's response (lockstep proceeds to phase buffering, then to BFT supermajority on whatever messages arrived) correct.

### 17.2 The in-process mpsc transport

The first reference transport is **in-process multiple-producer-single-consumer (mpsc) channels**, used for testing, embedded deployments, and single-machine multi-cluster setups. Each node holds an mpsc receiver; sending from peer X to peer Y means cloning peer Y's sender (held in a peer-to-sender map) and pushing the message onto it.

Properties:

- **Reliability**: messages cannot be lost. Channel sends always succeed (unless the receiver has been dropped, which is a programming error rather than a transport failure).
- **Ordering**: per-peer order is preserved. Messages from peer X to peer Y arrive in send order.
- **Latency**: sub-microsecond. The transport is a thread-safe queue in shared memory; message delivery is the cost of a mutex acquisition plus a notification.
- **Throughput**: bounded by the receiver's processing speed and the channel's capacity. The reference implementation uses unbounded channels; production deployments should use bounded channels with a backpressure policy.
- **Failure mode**: receiver-dropped is the only failure mode, and it indicates a bug rather than an operational problem.

The mpsc transport is what the v0.3 reference implementation uses for its property tests (Appendix A). It is not a production transport for distributed clusters — every node is in the same process — but it is the correct transport for testing the protocol's correctness without confounding network effects, and for embedded deployments where a single process operates an entire cluster.

### 17.3 The TCP transport

The second reference transport is **framed bincode over TCP**, used for production-class distributed clusters. Each node listens on a configured TCP port; peers establish persistent TCP connections and exchange length-prefixed bincode-serialized messages.

The framing protocol is straightforward:

- 4 bytes: little-endian message length (`u32`)
- N bytes: the bincode-serialized `LockstepMsg`

A receiver reads the length prefix, allocates a buffer of that size, reads the buffer, and deserializes. A sender computes the message length, writes the prefix, writes the body. No additional framing, no escape sequences, no message boundaries beyond the length prefix.

Properties:

- **Reliability**: TCP guarantees in-order, exactly-once delivery within a connection. Connection failures (TCP reset, peer disconnection, network partition) require reconnection; the reference implementation does not auto-reconnect, leaving reconnection logic to the cluster's operational tooling. v0.4 should add automatic reconnection with backoff.
- **Ordering**: TCP guarantees per-connection order. The substrate's protocol per-peer is satisfied because each peer pair has its own TCP connection.
- **Latency**: dominated by network round-trip time, not transport overhead. A cluster operating across geographically-distributed datacenters will have per-message latency in the 10-100ms range; a cluster in a single datacenter, sub-millisecond.
- **Throughput**: bounded by network bandwidth and CPU available for serialization. The v0.3 reference implementation has been stress-tested at n=3 over real TCP at ~986 frames/second wall-clock; this scales down with cluster size per the §11.1 scaling table.
- **Failure modes**: connection failures (peer down, network down, TCP reset), partial messages on connection drop (handled by length-prefix re-read on reconnect), and slow peers blocking the cluster's progress (handled by phase buffering and BFT supermajority).

The TCP transport is what the v0.3 reference implementation uses for cross-process testing and for the substrate's distributed-cluster verification. Stress runs at 10,000 frames over real TCP across multiple processes confirm the protocol's stability under sustained operation.

The TCP transport is not encrypted by default. Production deployments should layer TLS over TCP (the reference implementation supports this via Rust's `tokio-rustls` bindings, configured at the transport level rather than the protocol level), or run the cluster's TCP traffic over an encrypted tunnel (WireGuard, IPsec). The substrate's protocol does not require encryption — the message contents are signed cryptographically per-input, so an adversary observing the wire learns transaction patterns but cannot forge or alter messages — but most operators will want encryption for confidentiality of metadata (which nodes communicate at what rates, which inputs originate from which peers).

### 17.4 Future transports

The transport interface (§17.1) is small enough that other transports can be added without protocol changes. Three are anticipated for v0.4-v1.x:

**QUIC.** The natural successor to TCP for distributed cluster operation. QUIC's per-stream multiplexing eliminates head-of-line blocking, its connection migration handles network changes gracefully, and its built-in TLS 1.3 makes encryption transport-native rather than transport-layered. The substrate's protocol maps cleanly to QUIC streams: one stream per peer-pair direction, length-prefixed messages within each stream. v0.4-v1.0 priority.

**WebSocket.** Required for browser-based substrate clients. A WebSocket-capable substrate node can be a JavaScript or WebAssembly application running in a browser tab, participating in a cluster (as a read-only observer or as a full member, depending on the cluster's admission policy). WebSocket framing is straightforward — the substrate uses the binary message type with the same length-prefix framing as TCP — and the abstraction works without protocol changes. v0.4 priority for browser clients; v1.x for full-member browser participation.

**Tor or onion-routing transports.** For substrate operation in adversarial network conditions (state-level censorship, BGP hijack, mass surveillance), the substrate can run over Tor or equivalent onion-routing networks. The transport implementation wraps the underlying TCP-over-Tor connection in the substrate's framing protocol; the protocol itself is unaffected. Latency is significantly higher (per-message round-trips include Tor's onion-circuit overhead, often hundreds of milliseconds), so cluster sizing must account for this. Useful as a backup transport when normal TCP is unavailable. v1.x specification.

The transport-agnostic design means the substrate's protocol does not need revision when new transports ship. Each new transport implementation is an independent engineering project that conforms to the §17.1 interface. The protocol's correctness properties — determinism, BFT supermajority commit, phase buffering, content-addressed history — are preserved across transport choices.

### 17.5 What the transport layer does not solve

The discipline of naming what is *not* solved continues.

**Authentication.** The substrate's transport layer does not authenticate peers. Authentication is at the *protocol* layer — every message is signed by the node's ed25519 key, and signature verification happens during input processing (§9.4 step 5). A transport that delivered messages from an impostor would deliver messages whose signatures don't verify, and the impostor's messages would be silently dropped. The transport does not need to know which peer is "really" peer X; the cryptographic verification handles that.

**Encryption.** As named in §17.3, encryption is transport-layered (TLS over TCP, encryption native to QUIC) rather than protocol-required. The substrate operates correctly over plaintext transports; encryption is operator's choice based on threat model.

**Connection management.** The reference implementation does not implement automatic reconnection, connection pooling, or NAT traversal. These are operational concerns that production deployments handle through their networking stack (load balancers, service meshes, NAT-traversal software like UPnP or hole-punching). v0.4 should specify the reconnection protocol's correctness properties (a reconnected peer must resume at the cluster's current frame, not at the last frame before disconnection); the implementation is operator's choice.

**Quality of service.** The substrate has no transport-layer QoS — no message prioritization, no traffic shaping, no congestion-aware backoff beyond what TCP provides. Production deployments operating over shared network infrastructure may want QoS; this is an operational concern outside the substrate's scope.

**Geographic optimization.** Cluster operators may want peers preferentially connected to geographically-nearby peers to minimize latency. The substrate provides no transport-layer mechanism for this; it is a deployment-time concern (operators choose which peers to connect to, the transport delivers).

These five exclusions name the transport layer's actual scope. The substrate's contribution at this layer is the abstraction (§17.1) and the two reference implementations (§17.2-§17.3), not a complete production-class networking stack. Operators compose the substrate's transport with the operational tooling appropriate to their deployment.

### Part II close

Part II has specified the substrate's architecture across ten sections. §8 specified the smart byte schema. §9 specified deterministic simulation as the consensus mechanism. §10 specified the byte history as a content-addressed chain. §11 specified cluster topology and node admission. §12 specified the phase buffering requirement. §13 specified BFT supermajority commit. §14 specified the dissent log. §15 specified live issuance. §16 specified persistence. §17 has just specified the transport layer.

The architecture composes into a system that performs the institutional middle's three functions (matching, clearing, trust signaling — §3) at the cost structure §4 established (cheap cryptography + ubiquitous deterministic computation + per-operation energy measurement, composed for byte-denominated commerce). The smart byte (§8) is the load-bearing primitive; the lockstep simulation (§9) is the consensus mechanism; the chain (§10) is the deep-history verification; the cluster topology (§11) is the scaling mechanism; the BFT commit (§13) is the Byzantine defense; the dissent log (§14) is the observability primitive; live issuance (§15) is the supply-management mechanism; persistence (§16) is the durability mechanism; transports (§17) are the wire-level abstractions.

Three load-bearing details surfaced in v0.3 implementation testing rather than from architectural design: phase buffering (§12), the dead `MINORITY DIVERGENCE` path in favor of the dissent log (§13.4), and the genesis-seeding requirement (§16.3). Each is documented honestly with its origin in implementation rather than design. The substrate's epistemic posture is treatise-and-implementation-pair, with the treatise updating as the implementation surfaces what the prose missed.

Several v0.4+ items are explicitly deferred: cluster splitting (§11.3.2), cross-cluster transfer (§11.3.3), cluster-level Byzantine handling (§11.3.4), state sync from honest peers (§16.5), issuer governance for set mutation (§15.5), and several others. Each is named with its priority and its specification gap. The substrate ships v1.0 with these explicitly incomplete; v0.4 work will close them.

Part III walks the threat model the architecture has to survive. The threat model is the largest part of the treatise by design — multiple categories of attack engaged in detail, with each defended (or honestly acknowledged as inadequately defended) and with the AI-layer threat treated as a load-bearing strategic engagement. By the close of Part III, the reader should understand what the substrate survives, what it does not yet survive, and what the substrate's authors are actively working to defend against. Parts IV-VII engage workarounds, retrofits, distribution implications, and the closing argument.
# Part III — The Threat Model

Part I established why the substrate is necessary. Part II specified what the substrate is. Part III specifies what the substrate has to survive.

The threat model is the largest part of the treatise by design. The substrate's case rests on its surviving adversarial reading. A treatise that names the substrate's defenses without engaging the attacks they defend against produces a credibility gap on contact with anyone who reads carefully — anyone capable of mounting the attacks the treatise is silent on. The substrate's authors mount the attacks first, in the open, with the substrate's defenses named precisely against each.

Part III walks ten attack categories: §19 cryptographic, §20 lockstep protocol, §21 cluster topology, §22 issuer, §23 state, §24 economic, §25 social, §26 legal, §27 physical, §28 AI-layer. The categorization is the substrate's own; alternative threat-model taxonomies exist (STRIDE, MITRE ATT&CK, PASTA) and any of them could be applied to the substrate orthogonally. The categorization here is chosen because each category corresponds to a distinct defense layer in the substrate's architecture, which makes the treatise's "what defends against what" map easier to read than a generic taxonomy would.

§28 (AI-layer attacks) carries load-bearing strategic engagement. The treatise has been honest from §1 onward that the substrate competes against AI-mediated rent capture; §28 is where the competition's specific attack vectors are named and engaged.

## §18. The threat model meta-discipline

A threat model is the document that names the adversaries, the attacks the adversaries can mount, the defenses the system provides, and — critically — the attacks for which the system has no defense or only a partial defense. The fourth element is what distinguishes a credible threat model from a marketing document. A threat model that defends against every attack is a threat model that has not engaged the attacks honestly.

This section specifies how Part III's threat model is structured, what assumptions it operates under, what it includes, what it excludes, and how to read it. By the close of §18, the reader should be able to evaluate any specific attack engagement in §19-§28 against a clear standard of what counts as adequate engagement and what counts as evasion.

### 18.1 The adversary classes

Part III engages five adversary classes. Each is named, the resources each can deploy are specified, and each is mapped to the attack categories where it predominates.

**Adversary class one: opportunistic cryptographic attackers.** Adversaries with cryptanalytic capability — researchers who discover weaknesses in primitives, intelligence agencies with quantum or near-quantum compute, criminal organizations with access to leaked private keys. Resources: cryptographic expertise, possibly significant compute. Predominant in §19 (cryptographic attacks). The substrate's defenses are primitive choice (ed25519, blake3, conservative parameters), migration paths if a primitive is broken, and the absence of cryptographic monocultures (multiple keys per user, multiple signature classes per cargo type).

**Adversary class two: protocol-level attackers operating within the substrate.** Adversaries who control one or more substrate nodes, can submit inputs, can manipulate timing, can lie to peers. Resources: substrate-level participation, possibly multiple nodes if cluster-admission gates can be cleared. Predominant in §20 (lockstep protocol attacks), §21 (cluster topology attacks), §23 (state attacks). The substrate's defenses are BFT supermajority commit, dissent logging, content-addressed history, and cluster admission gates.

**Adversary class three: economic and social attackers operating around the substrate.** Adversaries who do not directly attack the protocol but attack the economic, social, and operational structures the substrate depends on. Resources: capital, social legitimacy, ability to fork or rebrand, ability to manipulate search results and discourse. Predominant in §22 (issuer attacks), §24 (economic attacks), §25 (social attacks on the substrate itself). The substrate's defenses are reference-implementation provenance, conformance test vectors, multi-issuer plurality, and the substrate's protocol-level absence of features (no token, no fee market, no foundation) that adversaries could attempt to capture.

**Adversary class four: state-level attackers.** Adversaries with legal, regulatory, and physical-coercive power over the substrate's operators, issuers, and infrastructure. Resources: jurisdiction-specific legal authority, sanctions, coordinated international pressure, BGP and infrastructure access, physical seizure capability. Predominant in §26 (legal attacks) and §27 (physical attacks). The substrate's defenses are jurisdictional distribution of operators, gossip-overlay path diversity, content-addressed history allowing replay from any honest peer, and the substrate's framing as protocol-not-service to limit operator obligations. The defenses are honestly partial; §27 names this directly.

**Adversary class five: AI-mediated incumbents.** Adversaries who own the AI layer being deployed across the institutional middle and who race to capture the byte-denominated commerce stack before the substrate ships. Resources: enormous compute, enormous data, regulatory access, vendor relationships, marketing scale, and the ability to offer substrate-equivalent functionality as a service while charging substrate-rent-equivalent fees. Predominant in §28 (AI-layer attacks). The substrate's defenses are the substrate's open-source licensing, reference-implementation provenance, multi-issuer plurality, the treatise itself as counter-narrative, and the substrate's protocol-level independence from AI inference for its core verification path.

These five classes overlap in real adversaries — a single state intelligence agency might deploy class-one cryptanalysis, class-two protocol participation, class-four legal pressure, and class-five AI-augmented narrative attack simultaneously. The taxonomy is for the substrate's defense organization, not for adversary classification; real adversaries combine techniques from multiple classes.

### 18.2 The threat-model assumptions

Every threat model rests on assumptions. Naming them honestly distinguishes a credible threat model from one that has hidden its weak points.

**Assumption one: cryptographic primitives are secure unless and until they are publicly broken.** The substrate assumes ed25519 signatures are unforgeable without the private key, that blake3 collisions cannot be efficiently found, and that the underlying number-theoretic problems remain hard. If any of these fails — if a polynomial-time elliptic-curve discrete-log algorithm is published, if a blake3 collision attack is announced — the substrate's cryptographic layer fails and migration is required. §19 walks the migration path; the assumption itself is named here.

**Assumption two: ⌊(n-1)/3⌋ Byzantine bound on cluster nodes.** The substrate assumes that no more than one-third of any cluster's nodes are Byzantine at any given time. Beyond this bound, BFT supermajority commit can be defeated. The cluster admission gates (§11.2) raise the cost of clearing this bound, but the substrate is honest that a sufficiently-resourced adversary controlling enough cluster nodes can corrupt cluster state. §21 engages this directly.

**Assumption three: at least one honest peer reachable for any byte that needs verification.** The substrate's content-addressed history means a byte can be verified by any party holding its full chain, but obtaining the chain requires reaching at least one honest party who holds it. If the substrate's gossip overlay is so thoroughly suppressed that no honest party can be reached, the substrate's verification claim fails. §27 (physical attacks) engages this; the assumption is that complete network isolation is harder than the substrate's adversaries can typically achieve, but the assumption is conditional, not unconditional.

**Assumption four: at least one issuer per cargo type remains uncaptured.** The substrate's multi-issuer architecture means a user can switch issuers if their preferred issuer becomes captured, regulated into uselessness, or compromised. If every issuer for a given cargo type becomes captured simultaneously, the substrate's freedom-from-forced-reliance claim fails for that cargo type. §22 (issuer attacks) engages this; the assumption rests on issuer plurality being defensible across regulatory and economic pressure.

**Assumption five: substrate-level adoption is achievable before the AI-mediated rent layer consolidates.** The substrate's strategic case rests on its acquiring independent constituency before AI companies finish capturing the institutional-middle's transformation. If the consolidation completes first, the substrate's strategic claim — that two trajectories are still available — collapses to one trajectory. §28 (AI-layer attacks) engages this directly. The assumption is the most contestable in the whole threat model, and the substrate ships with this contestability acknowledged.

These five assumptions are not the substrate's hidden weaknesses; they are the conditions under which the substrate's claims hold. A reader who wants to falsify the substrate's case should attack the assumptions, not the architectural mechanisms. The substrate's authors believe the assumptions hold and are willing to be shown wrong.

### 18.3 What an adequate attack engagement looks like

Each attack in §19-§28 is engaged against a fixed standard. The standard has four elements, in order:

**Element one: the attack is named precisely.** A threat-model entry that says "an adversary attacks the substrate" is not an engagement; it is a placeholder. The substrate's threat model names the specific mechanism by which the attack succeeds, the resources the adversary requires, and the conditions under which the attack works.

**Element two: the substrate's defense is specified.** The treatise names which substrate-level mechanism (BFT, dissent log, content-addressing, cluster admission, etc.) defends against the attack, and how the defense composes with other defenses to produce defense-in-depth. If multiple defenses apply, all are named.

**Element three: the residual risk is acknowledged honestly.** No defense is perfect. Each engaged attack ends with a sentence or paragraph naming what the substrate's defense does not stop, what conditions the defense fails under, and what the residual risk's magnitude is. A threat-model entry without a residual-risk acknowledgement is not an adequate engagement.

**Element four: the operational response is specified.** If the attack succeeds despite the substrate's defenses, what is the operator's recovery path? Is the affected cluster recoverable, or is it lost? Are affected bytes recoverable from honest peers, or are they orphaned? Does the substrate continue operating in the rest of the federation, or does the attack propagate? The operational response is the threat-model element that turns "the substrate has been attacked" into "here is what to do about it."

The four-element standard is consistently applied across §19-§28. Entries that do not meet the standard are flagged as such — typically because the attack class is genuinely under-engaged in v1.0 and the treatise is honest about it rather than pretending otherwise.

### 18.4 What is intentionally outside the threat model

Several attack classes are not engaged in Part III, by design. Naming them prevents the threat model from being read as a claim of completeness when it is not.

**User-level operational security.** A user who shares their private key, falls for a phishing attack, fails to back up their key, or chooses an untrustworthy issuer produces losses the substrate cannot prevent. Layer-2 services (custodial wallets, social-recovery, hardware tokens) reduce these losses, but the substrate is silent on user-level operational security. §6.3 named this absence as a structural cost; Part III does not re-engage it.

**Application-layer fraud and dispute.** A user phished into authorizing a transfer signs a valid transition that the substrate accepts. The fraud is at the application layer, where intention verification belongs. Layer-2 fraud-detection services (anomaly detection, rate limiting, dispute-resolution arbitration) compose with the substrate but do not extend its threat model.

**Long-term cryptographic obsolescence.** The substrate's primitive choice (ed25519, blake3) is conservative for the next 10-20 years. Quantum computing development beyond that horizon may require post-quantum primitives. §19 names migration paths for known-broken primitives; §19 does not engage timeline-uncertain quantum threats in detail.

**Sociopolitical change at planetary scale.** The substrate operates within economic and political structures that may themselves change radically. A worldwide collapse of internet infrastructure, a global currency reset, a transition to a planetary command economy — these would change the conditions under which the substrate operates so substantially that engaging them within the threat model would require speculation the treatise should not perform. The substrate is robust to most realistic political change at the substrate-operating layer; civilizational-scale change is outside scope.

**Internal authorial integrity.** The treatise assumes that the substrate's authors and the reference implementation's contributors operate in good faith. If the original authors are themselves adversaries — if the reference implementation contains a deliberate backdoor — the substrate's threat model has been compromised at its source. The defenses against this are reproducible builds, multi-implementation plurality, signed releases with multi-maintainer review, and the explicit invitation to readers to verify the implementation. §25 (social attacks) engages this in part, but the assumption that the substrate's authors are operating in good faith is, like all threat models, a conditional claim.

These five exclusions name the threat model's actual scope. A reader concerned about any of them should engage the corresponding layer-2 or higher-level concerns; the substrate provides the mechanisms below them and is silent on the layers above.

### 18.5 How to read Part III

Each section §19-§28 follows a consistent structure:

**Subsection X.1: the attack class.** What the attack class is, who deploys it, what resources are required, what the attack class's relationship to other attack classes is.

**Subsections X.2 through X.N: specific attacks within the class.** Each attack is engaged against the four-element standard from §18.3 — named precisely, defense specified, residual risk acknowledged, operational response specified.

**Final subsection: composition with other categories.** How the attack class's defenses compose with defenses from other categories, and where in the substrate's defense-in-depth structure this category sits.

Readers can read Part III sequentially or jump to specific attack categories. The cross-references are dense — each attack typically references the substrate-level mechanisms (BFT, dissent log, content-addressing) that defend against it, with forward and backward pointers to related attacks and defenses elsewhere in Part III.

The reading discipline §18 asks of the reader: hold the substrate's claims against the threat model. The substrate claims to provide four freedoms (§6.1) at four costs (§6.2) under a specific threat model. Part III specifies the threat model. If any specific attack engagement in §19-§28 fails the four-element standard, the substrate's freedom claim is correspondingly weakened. Readers who find inadequate engagements are invited to flag them; the substrate's errata mechanism (specified in Appendix F, "Open problems") will document any inadequacies that survive review and any fixes that subsequent revisions deliver.

### 18.6 The strategic frame, retained

The treatise has been honest from §1 onward that the substrate competes against an AI-mediated rent-capture trajectory. Part III's organization reflects that competition. §19 through §27 engage the attacks any byte-denominated-commerce protocol must survive — attacks that would exist regardless of the AI-layer dynamics. §28 engages the specific attacks that arise from AI companies' position as the most capable adversaries in the substrate's strategic environment.

The strategic frame is not a separate concern from the technical threat model; it is the reason the technical threat model has the specific shape it does. A substrate threat model that did not engage AI-layer attacks would be incomplete given the substrate's actual deployment environment. A substrate threat model that engaged *only* AI-layer attacks would be incomplete given the broader range of adversaries the substrate must survive. Part III engages both, in proportion to the actual threat each represents.

By the close of Part III, the reader should accept that the substrate's defenses compose into a system that survives the realistic attack surface its deployment environment presents, that the residual risks are honestly named, and that the substrate's freedom claim from §6 holds under the threat model specified here. Part IV then engages the workarounds — the alternative architectures critics propose instead of the substrate — each treated seriously, each shown to fail at scale or against the adversaries §18-§28 named.

The next section (§19) walks cryptographic attacks. The substrate's reliance on ed25519 and blake3 is a load-bearing dependency; §19 engages every plausible threat to that dependency and specifies the migration paths if the threats are realized.
## §19. Cryptographic attacks

The substrate's load-bearing cryptographic primitives are ed25519 (signatures) and blake3 (hashes), composed via canonical bincode serialization. Every byte's identity is a blake3 hash. Every transition is signed by ed25519. Every state-hash supermajority commit is blake3 over a canonically-serialized state. If either primitive is broken, or if the composition is broken, or if implementation flaws expose the primitives' security properties, the substrate's cryptographic layer fails and the substrate's higher-level claims fail with it.

This section walks seven cryptographic attack classes against the four-element rubric specified in §18.3: the attack named precisely, the defense specified, the residual risk acknowledged, the operational response specified. The attacks are §19.1 signature forgery, §19.2 hash collision, §19.3 replay attacks, §19.4 key compromise, §19.5 quantum adversaries, §19.6 weak randomness, §19.7 timing side channels. §19.8 closes by specifying the substrate's cryptographic-primitive migration path — the operational mechanism by which the substrate transitions to successor primitives if the current ones are broken.

By the close of §19, the reader should accept that the substrate's cryptographic layer is conservative, well-defended for known threats, honestly acknowledged as conditional on the underlying primitives' continued security, and equipped with a documented migration path for when the conditions fail.

### 19.1 Signature forgery

**Attack.** An adversary produces an ed25519 signature that verifies against a victim's public key without possessing the victim's private key. If successful, the adversary forges transitions: transferring the victim's bytes, minting bytes claiming to be from a registered issuer, or producing fraudulent state-hash attestations that other cluster members would accept as valid.

The attack succeeds if any of the following holds: (a) the discrete-log problem in the ed25519 group becomes efficiently solvable, breaking the security assumption underlying the entire signature scheme; (b) an implementation flaw exposes the private key during signing or storage; (c) the signature scheme's malleability properties allow modification of valid signatures into other valid signatures over different messages; (d) the canonical message construction has ambiguity allowing two distinct semantic interpretations of the same byte sequence.

**Defense.** Ed25519's security against signature forgery without private-key access reduces to the discrete-log problem on edwards25519, which has been studied since Curve25519's 2006 introduction and has no known efficient classical attack. The discrete-log problem on this curve is at the same security level (~128-bit symmetric equivalent) as the underlying assumptions for TLS 1.3, SSH, and the bulk of the modern internet's cryptographic infrastructure. The substrate inherits the security level the wider ecosystem depends on.

Implementation hardening: the substrate's reference implementation uses the `ed25519-dalek` Rust crate, which is itself derived from the curve25519-dalek implementation Bernstein and Lange consulted on. The implementation enforces strict signature encoding (rejecting non-canonical scalars per the EdDSA strictness guidance from Chalkias et al., "Taming the many EdDSAs," 2020), eliminating the malleability attack vectors that earlier permissive ed25519 implementations exposed. Conforming implementations in other languages MUST follow the same strictness rules; the substrate's conformance specification gives the canonical signature-verification predicate.

Canonical message construction: every signed message in the substrate is constructed by a single canonical-serialization function whose output is byte-deterministic across implementations. The signed preimages explicitly bind the byte ID, the previous history hash, and the frame number, preventing semantic ambiguity attacks where the same signature could be valid for multiple distinct transitions.

**Residual risk.** Three residual risks remain. First, if a polynomial-time discrete-log algorithm on edwards25519 is published, the entire signature layer fails simultaneously — every ed25519 signature in the substrate becomes potentially forgeable, including historical signatures that have already been verified. The substrate would need to migrate to a successor primitive (§19.8) under emergency conditions. Second, side-channel leakage of private keys during signing on hostile hardware (timing channels, power analysis on embedded devices) can compromise individual keys without breaking the signature scheme as a whole; affected users lose control of their bytes but other users' bytes remain secure. Third, implementations that fail to enforce strict signature encoding can introduce malleability in their local domain; conforming implementations are unaffected, but a non-conforming implementation in production is a risk to its own users.

**Operational response.** A discrete-log break on edwards25519 triggers the substrate-wide cryptographic migration protocol (§19.8). Individual key compromise is handled by the user re-issuing themselves a new keypair and (where the cargo type and issuer support it) requesting issuer assistance to invalidate or transfer bytes signed under the compromised key — recoverability depends on the issuer's policy and is honestly partial. Implementation-level malleability bugs are handled by the substrate's conformance test vectors, which any implementation must pass before being trusted by other implementations; non-conforming implementations are excluded from cluster admission.

### 19.2 Hash collision

**Attack.** An adversary finds two distinct inputs that hash to the same blake3 output. If successful, the adversary can produce two different bytes with the same identity, two different histories with the same chain hash, or two different states with the same state-hash. Collisions allow the substrate to be tricked into accepting one byte's history as another's, conflating distinct bytes, or producing forged state agreements.

The attack succeeds if the underlying compression function in blake3 has a structural weakness allowing efficient collision generation, or if the construction of the canonical serialization input to blake3 allows two semantically distinct objects to produce identical byte sequences (a serialization-level collision rather than a hash-level collision).

**Defense.** Blake3's collision resistance is inherited from BLAKE2's compression function, which has resisted cryptanalytic attack since its 2012 publication and which itself derived from BLAKE, a SHA-3 finalist that received extensive cryptanalytic scrutiny in 2008-2012. The blake3 specification (O'Connor, Aumasson, Neves, Wilcox-O'Hearn, January 2020) makes the security assumption explicit and the assumption has held in the four years since publication. The substrate inherits ~128-bit collision resistance and ~256-bit preimage resistance, both well above the threshold required for byte-level commerce at substrate scale.

Canonical serialization: bincode (the substrate's serialization format) is deterministic and unambiguous for the substrate's data structures — every input produces exactly one byte sequence, and every byte sequence parses to exactly one input or fails. The substrate's canonical-serialization function is specified to byte-level precision in the conformance specification, eliminating the input-ambiguity class of collision attacks.

**Residual risk.** Two residual risks. First, if blake3's compression function is broken — if a structural attack is published reducing its collision resistance below ~80 bits — the substrate's identity, history, and state-hashing all fail simultaneously, requiring substrate-wide migration. Second, the canonical serialization is correct only if every conforming implementation produces byte-identical output for the same input; an implementation bug producing non-canonical serialization could allow that implementation's nodes to disagree with conforming implementations on identity hashes, breaking interoperability without anyone's blake3 being broken. Conformance vectors detect this in testing.

**Operational response.** A blake3 break triggers substrate-wide migration to a successor primitive (§19.8). Serialization-level interoperability bugs are handled by conformance vector failure: a non-conforming implementation fails the test suite and is excluded from cluster admission until the bug is fixed. The substrate has no mechanism to retroactively re-hash already-existing bytes if blake3 is broken; affected bytes maintain their original identities and histories under the broken primitive, and recovery depends on the migration protocol preserving the chain of historical evidence even as the primitive changes.

### 19.3 Replay attacks

**Attack.** An adversary captures a valid signed transition and re-submits it in a different context — a different byte, a different cluster, a different frame — hoping that the substrate's verification accepts the signature as valid despite the changed context. If successful, the adversary produces unauthorized transfers by recycling captured signatures.

**Defense.** The substrate's signature preimage for a transfer transition explicitly binds (byte ID, previous history hash, from pubkey, to pubkey, frame number). Each component cryptographically scopes the signature: the byte ID prevents transition-replay across distinct bytes; the previous history hash prevents replay at a different point in the same byte's history (because once the byte has advanced, the previous history hash no longer matches); the frame number prevents replay across different frames; the to pubkey prevents the recipient from being substituted.

For mints, the analogous preimage binds (cargo kind, amount, recipient, nonce). The nonce is unique per mint within an issuer's signing history, preventing replay of mint signatures with otherwise-identical content. The substrate's byte-ID computation additionally includes the frame number in the canonical origin attestation, so a replayed mint message processed in a different frame produces a different byte ID and is treated as a distinct (and possibly duplicate) byte.

**Residual risk.** Replay attacks are structurally defeated by the preimage binding when the binding is correctly implemented and verified. The residual risk is implementation-level: an implementation that omits any of the preimage components from its signature verification, or that fails to verify the signature against the canonical preimage, opens replay attacks within its own domain. The substrate's conformance vectors include adversarial replay-attack vectors to detect this in testing.

**Operational response.** Conforming implementations are not vulnerable to replay attacks at the protocol level. A non-conforming implementation that exposed replay attacks would produce verifiable evidence (transitions whose canonical signature verification fails on a conforming implementation) and the affected bytes would be detectably corrupted. Recovery is via the same chain-verification procedure (§10.2) any external party would use to detect tampering.

### 19.4 Key compromise

**Attack.** An adversary obtains a victim's ed25519 private key — through theft, extortion, malware, supply-chain attack, side-channel leakage, or backup-system compromise. With the private key, the adversary can produce valid signatures over any preimage, transferring the victim's bytes, signing as the victim's issuer (if the victim is an issuer), or impersonating the victim in any signed protocol message.

**Defense.** The substrate's defense against key compromise is *containment, not prevention*. The substrate cannot prevent private keys from being stolen any more than the broader cryptographic ecosystem can. What the substrate provides is a content-addressed, cryptographically-verifiable history that scopes the damage of any key compromise to the bytes signed under that key during the compromise window.

Three layers of containment apply. First, the substrate's pseudonymity discipline (§6.2) encourages users to maintain separate pubkeys per relationship or per cargo class, limiting any single key compromise to the bytes that key controls. Second, the issuer registry (§15.1) is governance-mutable, meaning a compromised issuer key can be rotated through the governance flow (planned for v0.4) without affecting the cluster's ability to validate previously-issued bytes. Third, layer-2 services (custodial wallets with rate limiting and anomaly detection, social-recovery key systems, hardware-token signing) reduce the probability of key compromise and its consequences without modifying the substrate's protocol layer.

The substrate's *cryptographic chain provenance* (§10) ensures that even after a key compromise, the chain of legitimate transitions before the compromise remains verifiable. The compromise damages the user's *future* signing authority over their bytes; it does not retroactively invalidate the bytes' history.

**Residual risk.** The substrate cannot recover bytes whose private keys have been compromised and whose owners were unaware long enough for the adversary to transfer the bytes to themselves. Once a transition is committed by BFT supermajority, it is final; no protocol-level reversal mechanism exists. Layer-2 services may offer reversibility wrappers (escrow with timed release, conditional transfers), but these compose on top of the substrate rather than modifying its irreversibility. Issuers may, at their discretion and per their cargo-type policies, agree to invalidate bytes signed under a confirmed-compromised key and mint replacement bytes — but this is an issuer-level operation, not a substrate-level guarantee.

**Operational response.** A user who detects key compromise rotates to a new keypair and (where applicable) requests issuer-level remediation for affected bytes. The affected bytes' subsequent fate depends on whether the adversary has already transferred them: if they have, the bytes are lost to the user (subject to issuer remediation); if they have not, the user can transfer the bytes to a new keypair before the adversary acts. The substrate's role is to make the chain of events cryptographically auditable; the substrate does not perform recovery. Long-term, the substrate's design discourages users from holding large quantities of bytes under a single key for exactly this reason; the granularity of per-byte ownership (§8.4) makes pubkey diversification natural.

### 19.5 Quantum adversaries

**Attack.** An adversary with a sufficiently large fault-tolerant quantum computer runs Shor's algorithm to compute discrete logarithms on edwards25519, breaking ed25519 signatures globally. The same adversary runs Grover's algorithm to weaken blake3's preimage resistance from 256 bits to 128 bits and collision resistance from 128 bits to roughly 85 bits. If both attacks become feasible, the substrate's cryptographic foundation fails simultaneously.

**Defense.** No defense against a sufficiently capable quantum adversary exists at the protocol layer. Ed25519's security relies on the hardness of discrete log on edwards25519, which Shor's algorithm efficiently solves on a fault-tolerant quantum computer. Resource estimates have converged downward as algorithmic optimizations have matured: Roetteler-Naehrig-Svore-Lauter (2017) estimated approximately 2330 logical qubits for 256-bit elliptic-curve discrete log; Häner-Jaques-Naehrig-Roetteler-Soeken (2020) refined to comparable ranges; Babbush-Zalcman-Gidney et al. (2025) demonstrated under 1500 logical qubits. The trend is toward lower logical-qubit requirements and higher physical-qubit overhead via quantum error correction; current full-stack physical-qubit estimates remain in the millions. Blake3's preimage resistance is reduced by Grover's algorithm, but blake3's 256-bit output means even Grover-reduced collision resistance remains at ~85 bits — uncomfortably close to brute-force territory but not yet fully broken.

The substrate's defense is *temporal*: ed25519 and blake3 are conservative for the next 10-20 years against publicly-known quantum compute trajectories. The current state of fault-tolerant quantum computing (2025-2026: a few hundred logical qubits at most, with high error rates) is far below the threshold required for Shor-on-edwards25519 even at the most optimistic logical-qubit estimates. Public expert estimates of when fault-tolerant quantum computing reaches Shor-on-elliptic-curve scale range from 10 years (optimistic) to 30+ years (pessimistic); the Mosca framework for cryptographic risk management ("X+Y < Z" where X is migration time, Y is data sensitivity timeline, Z is time until quantum threat) suggests migration planning should begin now even if the threat itself is years away.

The substrate ships in 2026 with ed25519/blake3. By the time post-quantum migration becomes urgent, post-quantum signature standards will have matured: NIST released FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, derived from SPHINCS+) on August 13, 2024, completing an eight-year standardization process. FALCON is in the NIST signature queue for future standardization. Each standardized primitive is deployable today, just not at the substrate's performance/key-size points. The substrate's migration protocol (§19.8) is pre-specified for post-quantum migration; the migration is engineering work, not protocol-design work.

**Residual risk.** Three residual risks. First, "harvest now, decrypt later" — a quantum-capable adversary today could be capturing substrate-network traffic and ed25519-signed transitions, planning to retroactively forge or decrypt them once quantum hardware matures. The substrate's signed transitions, however, are publicly-broadcast and content-addressed; an adversary who later derives private keys from public keys (via Shor's) would be able to forge *new* transitions but not retroactively alter *committed* ones. Second, the timeline could be wrong. If a major cryptanalytic breakthrough or a faster-than-expected quantum advance compresses the migration window from years to months, the substrate may not migrate in time. Third, post-quantum primitives have larger keys and signatures (FALCON: ~1KB signatures vs ed25519's 64 bytes; ML-DSA: similar order of magnitude), which would change the substrate's per-byte cost structure and require operational adaptation.

**Operational response.** Quantum-readiness is monitored via standard cryptographic-community channels (NIST publications, IACR conference proceedings, public quantum-hardware roadmaps). When fault-tolerant quantum compute approaches the discrete-log threshold (estimated 5-10 years before actual feasibility, based on standard cryptographic risk-management practice), the substrate initiates the migration protocol (§19.8), shipping post-quantum primitive support in parallel with ed25519/blake3 for a transition period before retiring the legacy primitives. The migration is a coordinated substrate-wide event, not a per-byte event; bytes maintain their pre-migration identities, with new bytes minted under post-quantum primitives and existing bytes auditable under both regimes during the transition.

### 19.6 Weak randomness

**Attack.** An adversary predicts or biases the random values the substrate uses for keypair generation, nonce selection, or randomness-beacon contributions. If predictable, an adversary may pre-compute private keys from public keys, forge nonces to collide with future legitimate nonces, or bias randomness beacons to produce favorable cluster-split partitions or input ordering.

**Defense.** The substrate inherits the operating system's cryptographic randomness primitive (`/dev/urandom` on Linux, `BCryptGenRandom` on Windows, `getentropy()` on BSD/macOS). These primitives have received substantial cryptanalytic scrutiny and are generally considered secure when the underlying entropy collection is healthy. The substrate's reference implementation uses `rand_chacha::ChaCha20Rng` seeded from OS entropy for high-volume needs, and direct OS entropy for keypair generation.

Nonce uniqueness: ed25519 signatures are deterministic by construction (nonces derived from the private key plus message hash, per RFC 8032 Section 5.1.6), eliminating the entire class of nonce-reuse vulnerabilities that plagued ECDSA. The substrate's mint nonces are 16-byte values, with collision probability on the order of 2⁻⁶⁴ per same-cargo-same-issuer mint pair — adequate for any plausible mint volume.

Randomness beacons (used for cluster-split partition functions, §11.3.2): the substrate's design (v0.4 specification work) draws beacon values from the contributions of all cluster members at the SplitFrame, requiring an adversary to control a supermajority of cluster members to bias the beacon. This is design-only in v0.3.

**Residual risk.** Three residual risks. First, embedded systems with weak entropy sources (early-boot states, virtualized environments without paravirt entropy) can produce predictable keypairs; this is a long-known issue across cryptographic systems and the substrate inherits it. Second, the v0.4 randomness-beacon design is unimplemented and untested; the design's correctness depends on supermajority-honesty assumptions that may turn out to have edge cases. Third, deterministic ed25519 nonces, while secure under standard assumptions, fail catastrophically under fault-injection attacks where an adversary can cause the same private-key-and-message pair to produce two different signatures with different nonces. Fault-injection is a hardware-level concern that the substrate cannot defend against at the protocol layer.

**Operational response.** Embedded-system entropy issues are mitigated by operational discipline: substrate nodes should not run on systems with weak entropy at keypair-generation time, and key-generation tooling should verify entropy quality before producing keys. The v0.4 randomness-beacon design will be specified, implemented, and tested with adversarial scenarios before being relied on for production cluster splitting. Fault-injection on signing devices is the user's operational concern; high-value users should use hardware tokens with fault-injection resistance.

### 19.7 Timing side channels

**Attack.** An adversary with timing access to a node's signing or verification operations measures the time taken and infers private-key material. Classical examples: ECDSA implementations whose signing time correlates with the leading bits of the nonce, allowing recovery of the private key after enough signatures are observed. Modern variants: cache-timing attacks, branch-prediction attacks, hyperthreading-shared-state attacks.

**Defense.** Ed25519's design eliminates many timing channels that ECDSA and RSA implementations had to defend against. The signing algorithm has no secret-dependent branches, no secret-dependent table lookups, and no secret-dependent loop counts. Reference implementations (curve25519-dalek and its derivatives) are constant-time across all standard inputs. The substrate's reference implementation inherits this property.

Verification, which does not involve the private key, is less timing-sensitive but the implementation still avoids secret-dependent timing in the rare cases where it could matter (signature-malleability rejection paths, for example).

**Residual risk.** Two residual risks. First, the constant-time guarantee depends on the compiler not emitting secret-dependent branches or memory accesses; aggressive optimization passes can occasionally introduce timing channels that the source code does not have. The substrate's reference implementation pins compiler versions and includes timing-validation tests in the conformance suite to detect this. Second, side-channel attacks beyond timing — power analysis on embedded devices, electromagnetic-emission analysis on cryptographic accelerators — can compromise keys regardless of constant-time software. These are hardware-level concerns the substrate cannot defend against.

**Operational response.** Timing-channel discoveries in ed25519 implementations are tracked via the cryptographic community's standard channels (CVE database, the ed25519 maintainers' security advisories, the relevant Rust ecosystem advisories). The substrate's implementation upgrades when timing-channel patches are released. Hardware-level side-channel concerns are the user's operational responsibility; high-value users should use hardware tokens designed against side-channel attacks (Yubikey 5, Solokey, Trezor with safe-firmware).

### 19.8 The cryptographic-primitive migration path

If any of the substrate's cryptographic primitives is broken — by classical cryptanalysis, by quantum adversary, or by implementation flaw rendering the primitive unsafe even when correctly implemented — the substrate must migrate to successor primitives. This subsection specifies the migration path. The path is design-only in v0.3; v0.4 will implement the migration protocol's lockstep components.

**Stage 1: announcement and assessment.** The substrate's authors and the broader cryptographic community announce the threat. The substrate's authors assess: does the threat affect ed25519, blake3, both, or other primitives the substrate depends on? Is the threat publicly known and reproducible, or is it a credible report from a trusted source? What is the migration urgency — months, years, or immediate?

**Stage 2: successor selection.** The substrate's authors propose successor primitives chosen from the existing cryptographic standardization landscape. For ed25519 replacement: ML-DSA (Dilithium-derived NIST FIPS 204 standard, 2024) or FALCON for size-constrained deployments. For blake3 replacement: SHA-3 if the threat is specific to blake3's compression function, or a future post-quantum hash like SPHINCS+'s underlying primitives. The successor choice is open for community comment for a configurable period (target: 90 days for non-emergency, shorter for emergency).

**Stage 3: dual-mode operation.** The substrate's protocol gains a primitive-version field that distinguishes legacy bytes (ed25519/blake3) from new bytes (successor primitives). Both versions are valid simultaneously during the migration period. Existing bytes retain their original identities and histories; new bytes use the successor primitives. Cluster lockstep handles both versions in the same transition logic, with version-appropriate verification per transition.

**Stage 4: migration window.** Users are encouraged to transfer their legacy bytes to new keypairs under the successor primitives, with issuer support where available. Issuers may offer migration services (re-issuing existing bytes under successor primitives in exchange for the originals). The migration window is a configurable period (target: 12-24 months for non-emergency, shorter for emergency).

**Stage 5: legacy retirement.** After the migration window, the substrate's protocol stops accepting transitions signed under the legacy primitives. Bytes still under legacy primitives remain in cluster state but are immobilized: they exist, they verify, but they cannot be transferred under the legacy keys. Users who failed to migrate during the window have lost the ability to transfer their bytes, and recovery requires issuer cooperation or layer-2 dispute resolution.

**Stage 6: legacy archive.** A frozen copy of the cluster state at retirement is preserved for forensic and audit purposes. Anyone with the cluster's BFT-signed state attestations from before retirement can verify the legacy bytes' histories using the legacy primitives. The archive does not actively process new transitions; it is read-only.

The migration's correctness depends on (a) the successor primitives being secure under the threat that broke the legacy primitives, (b) the dual-mode operation handling both versions correctly without introducing new vulnerabilities, (c) the migration window being long enough for users and issuers to coordinate, and (d) the legacy retirement being executed simultaneously across the substrate's clusters to prevent split-brain operation. Each is a real engineering challenge; v0.4 specifications will address each.

**Residual risk.** A migration to successor primitives is a substrate-wide coordinated event. If it is executed under emergency conditions (legacy primitive broken with active exploitation), the migration window shortens and users may lose bytes they could not migrate in time. If it is executed under non-emergency conditions, the migration is more orderly but less urgent. The substrate's design assumes the cryptographic community provides advance warning of impending breaks (decade-scale for quantum, year-scale for classical cryptanalytic advances), which has been the historical pattern. A short-warning break (a polynomial-time discrete-log algorithm announced without warning) compresses the migration window and increases byte-loss risk.

**Operational response.** Substrate authors maintain active monitoring of cryptographic-community channels and commit to initiating the migration protocol within 30 days of any credible threat to a load-bearing primitive becoming public. Implementation vendors maintain successor-primitive support in their codebases, ready to enable on protocol-version change. Issuers commit to offering migration services for their cargo types. Users who hold significant byte value should diversify across keypairs and consider layer-2 services with built-in migration support.

### 19.9 Composition with other categories

The cryptographic attacks engaged in §19 compose with other categories' defenses in three ways.

**Composition one: cryptographic verification underlies every other defense.** The BFT supermajority commit (§13) relies on ed25519 signatures and blake3 hashes; if either primitive is broken, BFT fails. The dissent log (§14) relies on the same primitives; if either is broken, dissent attribution becomes untrustworthy. Content-addressed history (§10) relies on hash collision resistance; if blake3 is broken, the entire history-verification claim collapses. Cryptographic security is therefore the foundation; every other defense is conditional on it.

**Composition two: cryptographic attacks are typically protocol-class-one (cryptographic) but enable adversary-class-two (protocol-level) attacks.** A signature-forgery break enables the adversary to mount protocol-level attacks against any cluster — submitting forged transitions, producing forged state hashes, impersonating any user or issuer. Cryptographic attacks are therefore force-multipliers across §20 (lockstep protocol) and §21 (cluster topology) attacks.

**Composition three: cryptographic migration is a cross-cutting operational concern.** The migration path specified in §19.8 affects every other layer of the substrate — cluster topology (existing clusters must coordinate the migration), state persistence (checkpoints must support both primitive versions during migration), transports (no direct effect, since the transport layer is primitive-agnostic), and issuer registries (issuers must support both versions during migration). The migration is operationally complex precisely because cryptographic primitives are foundational, and §19.8's specification is the load-bearing operational document for the migration's success.

The next section (§20) walks lockstep protocol attacks. Where §19 engaged threats to the cryptographic primitives the substrate's lockstep relies on, §20 engages threats to the lockstep protocol itself — determinism breaks, ordering attacks, timing manipulation, and the broader class of attacks that target the substrate's consensus mechanism rather than its cryptographic foundation.
## §20. Lockstep protocol attacks

The substrate's lockstep deterministic simulation (§9) is the substrate's consensus mechanism. Every honest node executes the same deterministic state transition over the same canonically-ordered inputs, producing byte-identical state across the cluster, with cryptographic supermajority commit (§13) detecting any divergence. The lockstep protocol's correctness rests on two properties: every honest node executes the same operations in the same order, and the operations are themselves deterministic. Attacks that violate either property — by introducing nondeterminism, by manipulating ordering, by injecting timing or clock effects, by manipulating message delivery — threaten the substrate's consensus.

This section walks eight attack classes against the four-element rubric (§18.3). The attacks are §20.1 floating-point determinism break, §20.2 input-ordering determinism break, §20.3 timestamp manipulation, §20.4 clock skew, §20.5 network-layer reordering, §20.6 message duplication, §20.7 message dropping, §20.8 partition healing exploits. §20.9 closes by specifying the substrate's protocol-level invariants — the structural properties that, if maintained, are sufficient for lockstep correctness regardless of which specific implementation choices a conforming implementation makes.

By the close of §20, the reader should accept that the substrate's lockstep protocol is robust against the realistic attack surface a determined adversary at the protocol layer can present, that the residual risks are honestly named, and that the protocol's invariants are auditable rather than depending on the substrate's authors' good faith.

### 20.1 Floating-point determinism break

**Attack.** An adversary submits inputs whose deterministic transition involves floating-point arithmetic. Different implementations, different CPUs, or different compiler optimizations produce subtly different results — IEEE 754 operations vary in associativity, in handling of denormals, in fused-multiply-add precision, in compiler reorderings of expressions like `a + b + c`. The cluster nodes diverge: each computes a slightly different post-frame state hash. Supermajority commit fails. The cluster halts with `CLUSTER SPLIT` (§13.3 outcome four), or the divergent minority halts with `MINORITY DIVERGENCE` (outcome three). The adversary has caused a denial-of-service via legitimate-looking inputs.

**Defense.** The substrate's state-transition function forbids floating-point arithmetic entirely. All numeric values in the substrate's state — cargo amounts, joule costs, frame numbers, timestamps as discrete units — are represented as fixed-precision integers (i64 or u64). The reference implementation uses `Fixed64` for cargo amounts, with a documented scaling factor of 6 decimal places (so $1.50 USD-byte amount is stored as `1_500_000`). All arithmetic on cargo values uses integer operations with overflow checks; the operations are byte-deterministic across CPUs and compilers.

The substrate's conformance specification mandates integer-only arithmetic in the state-transition function. Implementations that introduce floating-point operations into transition logic — even via library calls that internally use floating-point — fail conformance vectors that include adversarial floating-point-edge-case inputs.

**Residual risk.** Two residual risks. First, the substrate's higher-level layer-2 services (price-discovery oracles, exchange-rate calculators, statistical-aggregation tools) may use floating-point internally; the substrate's protocol is unaffected, but the layer-2 services may produce results that diverge across implementations and that should not be trusted as substrate-level facts. Second, an implementation bug that accidentally introduces floating-point operations (a developer using `f64` instead of `i64` in a hot path) could pass cursory review but would be caught by the conformance suite's adversarial vectors. The conformance suite is the load-bearing defense.

**Operational response.** A floating-point-determinism-break attack against a conforming implementation cluster fails — every node computes the same integer result. If a non-conforming implementation is in the cluster, its hash diverges from the supermajority and the dissent log (§14) accumulates evidence; the non-conforming implementation is identified and excluded via cluster expulsion (planned v0.4). Operators monitor implementation diversity and flag any implementation that fails conformance vectors.

### 20.2 Input-ordering determinism break

**Attack.** An adversary exploits the cluster's input-ordering algorithm. The substrate's protocol orders the union of all peer inputs by canonical hash sort (§9.4 step 4): each input is serialized, blake3-hashed, and sorted by hash. If two implementations sort differently — different tiebreaking on equal-hash inputs (which should never occur for distinct inputs but could under edge cases), different byte-ordering interpretation, different hash representation — the cluster nodes process inputs in different orders, producing divergent state.

A more subtle variant: the canonical-serialization function is not byte-deterministic across implementations. Two conforming implementations agree on what the data structure is but encode it slightly differently — different field orderings, different optional-field representations, different integer-encoding rules. The hash inputs differ, the hashes differ, the sort orders differ.

**Defense.** The substrate's canonical serialization is specified to byte-level precision in the conformance specification. Bincode (the reference implementation's serialization format) is deterministic for the substrate's data structures: every input produces exactly one byte sequence, with field ordering, integer encoding, and optional handling all specified. Conformance vectors include adversarial inputs designed to surface serialization-level differences — empty collections, maximum-value integers, edge-case Unicode strings.

The hash sort itself is mechanically simple: sort by lexicographic byte order on the 32-byte blake3 output. There is no tiebreaking ambiguity because blake3's collision resistance makes equal-hash inputs from distinct preimages essentially impossible (probability ~2⁻¹²⁸ per pair). The conformance specification gives the sort algorithm in pseudocode; conforming implementations must produce identical orderings on the same input set.

**Residual risk.** Same residual risk as §19.2 (hash collision): if blake3 collisions become efficient, the canonical hash sort becomes manipulable, but the substrate's failure mode in that case is the cryptographic-migration scenario (§19.8), not a lockstep failure. Implementation-level serialization bugs are caught by conformance vectors; an implementation that passes the conformance suite but has a corner case the suite doesn't cover would produce divergent state hashes and be detected through dissent log accumulation.

**Operational response.** Conforming implementations agree on input ordering. A non-conforming implementation that orders inputs differently produces divergent state hashes and is excluded via dissent log + cluster expulsion. The substrate's operational discipline includes: every implementation MUST pass the conformance suite before joining production clusters; conformance vectors are versioned with the protocol; protocol upgrades require updated conformance vectors that all participating implementations must pass.

### 20.3 Timestamp manipulation

**Attack.** An adversary submits inputs containing fabricated timestamps — claiming a transition happened at a specific wall-clock time the adversary chooses, or claiming the cluster's current frame corresponds to a wall-clock time the adversary biases. If the substrate's transition logic depends on wall-clock timestamps for any decision (expiration of time-bound cargo, time-locked transfers, rate limiting), the adversary manipulates the decision by fabricating timestamps.

**Defense.** The substrate's lockstep protocol does not use wall-clock time anywhere in the state-transition function. The only time-like value the substrate's state contains is the frame number, which is deterministic by construction (incremented by one per committed frame, never set to a wall-clock-derived value). Frame numbers are monotonic, identical across all honest nodes, and forgeable only to the extent that a Byzantine majority could rewrite the cluster's state — which is a §21 cluster-topology attack, not a §20 timing attack.

Time-bound cargo (cargo with expiration semantics) is implemented at the layer above the substrate. The cargo specification can include a "valid until frame N" field; transitions involving the cargo after frame N are still cryptographically valid at the substrate level but are rejected by the cargo's application logic. The substrate stays out of wall-clock-time concerns; layer-2 services handle time-sensitive cargo by interpreting frame numbers and consulting external time-attestation mechanisms.

**Residual risk.** Three residual risks. First, layer-2 services that bridge frame numbers to wall-clock time (frame-N happened at approximately time T) are themselves a trust point; an adversary who controls a time-attestation service can mislead applications about when frame-N occurred. Second, applications that need wall-clock-precision timing — high-frequency-trading-equivalent latency claims, regulatory timestamping requirements — are not well-served by the substrate's frame-number-only design and must compose with external time sources. Third, some legitimate use cases (transaction "happened before noon UTC on a specific date") require wall-clock anchoring that the substrate provides only indirectly.

**Operational response.** Wall-clock manipulation does not affect substrate-level consensus. Applications that need wall-clock-anchored decisions use external time-attestation services (RFC 3161 timestamping authorities, NIST signed-time services, or substrate-level layer-2 services that publish frame-to-wall-clock attestations periodically). The substrate's operational guidance is: do not depend on wall-clock time within the substrate's transition function; if your application needs wall-clock time, layer it on top.

### 20.4 Clock skew

**Attack.** Different cluster nodes have skewed wall clocks — not because of attack, but because clock synchronization is hard. A node whose clock is 10 minutes ahead of its peers makes decisions about message timing, frame budgets, and timeout values that differ from its peers. Over time, this can produce divergent behavior even when the protocol logic itself is deterministic.

A more aggressive variant: an adversary deliberately runs nodes with manipulated clocks, hoping to exploit timing-dependent code paths in the substrate's protocol or transports.

**Defense.** The substrate's lockstep protocol does not depend on clock synchronization across nodes for correctness. The protocol's progress is driven by message exchange, not wall-clock time. A node's frame counter advances when its cluster commits a frame, regardless of how long that took in wall-clock time.

Two places where clock-like values appear in implementation: timeout values for missing-peer detection (§11.3.6, default tens of seconds) and checkpoint cadence (§16.4, default every 10,000 frames). Neither value affects the substrate's state-transition function or the cryptographic agreement protocol; they are operational tunings within each node's local discretion. A node with a skewed clock might detect a peer as missing slightly earlier or later than other nodes would, but the cluster's BFT supermajority handles this — the slow-detecting node's vote on missing-peer status is just one of n votes.

**Residual risk.** Two residual risks. First, severely skewed clocks (hours or days off) could cause a node to mistakenly mark all peers as missing simultaneously or to fail to detect a genuine missing peer for an extended time. This is an operational issue, not a protocol-level vulnerability: cluster operators monitor clock drift and correct it. Second, an adversary deliberately running with manipulated clocks could potentially exploit subtle timing-window edge cases in transport layers (TCP keep-alive intervals, QUIC connection-migration timing); the substrate's protocol layer is unaffected, but operational monitoring should detect persistent clock-skew anomalies.

**Operational response.** Cluster nodes run NTP or equivalent clock-synchronization services as a matter of operational hygiene. The substrate's operational documentation specifies that clock skew greater than a configurable threshold (suggested: 60 seconds) should trigger an operator alert. An adversary deliberately running with skewed clocks is detectable by anomaly monitoring and is handled via cluster expulsion if the adversary is otherwise meeting their lockstep obligations, or via missing-peer protocol if they are not.

### 20.5 Network-layer reordering

**Attack.** An adversary at the network layer (a man-in-the-middle, a malicious ISP, a state-level network operator) reorders messages between nodes, hoping to cause inputs to be processed in a different order than the protocol's canonical hash sort would dictate. If successful, the adversary forces nodes into divergent state.

**Defense.** The substrate's canonical hash sort (§9.4 step 4) defeats network-layer reordering by construction. Each node receives the union of all peer inputs for the frame, sorts them by canonical hash, and applies them in sorted order. The order in which the inputs *arrived* is irrelevant; the order in which they are *processed* is the canonical-hash-sorted order. As long as every honest node receives the same union of inputs, every honest node processes them identically.

The "as long as" condition is enforced by the protocol's input-exchange phase (§9.4 step 2-3): every node broadcasts its inputs to every peer; every node waits to receive inputs from every peer; the union is complete before processing begins. Phase buffering (§12) handles the case where messages from frame N+1 arrive before frame N's input phase completes.

**Residual risk.** Network-layer reordering attacks are structurally defeated by the canonical hash sort. The residual risk is implementation-level: an implementation that processes inputs in arrival order rather than canonical-hash-sorted order is non-conforming and produces divergent state, but the conformance vectors include adversarial inputs designed to surface this. A more sophisticated network-layer attack might selectively *drop* messages rather than reorder them; this is engaged in §20.7.

**Operational response.** Network-layer reordering against conforming implementations is benign — the canonical sort defeats it. Non-conforming implementations are detected via dissent log and excluded.

### 20.6 Message duplication

**Attack.** An adversary at the network layer duplicates messages — re-sending the same `InputBatch` or `StateHash` message multiple times. If the receiver's protocol logic does not deduplicate, the duplicate may be processed as two distinct inputs, doubling the apparent set of pending operations or interfering with the supermajority commit's tally.

**Defense.** The substrate's protocol deduplicates at multiple layers. At the input layer: each input has a canonical hash (used for the canonical sort), and an input that has already been processed for the current frame is silently dropped on duplicate receipt. Identical inputs from different peers are deduplicated by canonical hash. At the state-hash layer: each peer's hash for a given frame is recorded once; subsequent receipts of the same `StateHash` message from the same peer are silently ignored. Duplicate `StateHash` messages from a single peer claiming different hashes for the same frame are a Byzantine-behavior signal and are recorded in the dissent log.

The reference implementation enforces these deduplications via the `Node::recv_filtered` logic (which already handles phase buffering, §12) and via per-frame hash-set tracking of received messages.

**Residual risk.** Implementation-level: an implementation that fails to deduplicate produces incorrect state and is detected via supermajority commit divergence. The conformance vectors include adversarial duplicate-message scenarios.

**Operational response.** Deduplication is structural; no operational response is required for conforming implementations. Non-conforming implementations are excluded via dissent log.

### 20.7 Message dropping

**Attack.** An adversary at the network layer drops messages — selectively, deliberately, to prevent specific inputs from reaching specific peers. If a single peer fails to receive a message that other peers received, that peer's union of inputs differs from the others', producing divergent state.

A more strategic variant: an adversary drops messages from specific submitters, preventing those submitters' transactions from being processed. This is an availability attack against specific users rather than a consensus attack against the cluster.

**Defense.** The substrate's protocol handles missing messages at the supermajority commit layer (§13). If a node fails to receive a peer's input batch, that node's union of inputs is incomplete; the node's frame state will diverge from the supermajority. The supermajority commit detects the divergence; the dropping node halts with `MINORITY DIVERGENCE` and operator intervention restores connectivity.

For the strategic variant (dropping specific submitters' transactions), the substrate's input-distribution mechanism (§9.4 step 2: every node broadcasts to every peer) provides redundancy: a transaction submitted to any cluster node is broadcast to all peers, and an adversary would need to drop messages between every cluster node simultaneously to prevent the transaction from being processed. This is a state-level network attack that the substrate cannot fully defend against (an adversary with control of the global internet routing for the cluster's IP space can do this), but it is an extraordinarily expensive attack.

**Residual risk.** Three residual risks. First, an adversary with control of a single peer's network connection can drop messages to that peer, causing it to halt — which is denial-of-service against that peer but not consensus corruption against the cluster. Second, an adversary controlling the network between *all* cluster peers can prevent the cluster from making progress entirely; this is a cluster-level availability attack handled by geographic distribution of cluster nodes (§13.5). Third, an adversary controlling a specific user's network access can prevent that user's submissions from reaching any cluster node; the user's recourse is to use a different network path (different ISP, different geographic location, Tor or other anonymization).

**Operational response.** Persistent message-dropping against a peer is detected by the peer's repeated `MINORITY DIVERGENCE` halts and by missing-peer protocol triggers. Cluster operators investigate and either restore connectivity, switch to alternate transport (Tor, satellite, etc.), or accept the loss of the affected peer. The substrate continues operating without the affected peer, with the cluster's effective n decreased by one.

### 20.8 Partition healing exploits

**Attack.** A cluster has been partitioned: some nodes are in partition A, others in partition B, neither sub-partition has supermajority, both halt with `CLUSTER SPLIT`. The partition heals — connectivity is restored. An adversary attempts to exploit the healing to inject inputs that would not have been valid had the partition not occurred, or to cause the cluster to commit conflicting state from the two partitions.

**Defense.** The substrate's correct behavior on partition is to halt with `CLUSTER SPLIT` and resume from the last committed frame when the partition heals. Both partitions, while halted, were unable to commit further frames; there is no "partition A's committed frame" versus "partition B's committed frame" to reconcile. The healing is straightforward: reconnect transports, re-enter normal lockstep at the last committed frame, process pending inputs through the normal canonical-hash-sort and supermajority-commit pipeline.

The substrate's design specifically rejects "make progress in either partition during the partition" because that would require reconciling potentially-conflicting commits when the partition heals. The conservative choice is correct: lose availability during the partition, retain consistency.

**Residual risk.** Two residual risks. First, an adversary who fabricates a partition-and-heal scenario (deliberately disconnecting nodes, then reconnecting them) can use the disconnection window to submit inputs that would have been rejected in normal operation — but the substrate's verification on healing detects this because the inputs' validity depends on the cluster's state, which the partition did not advance. Second, the partition-and-heal protocol depends on the substrate's persistence layer (§16) being robust enough that nodes can resume from their last committed frame; persistence corruption during the partition window is a §23 (state attacks) concern.

**Operational response.** Partition healing is normal cluster operation; no special protocol is required beyond reconnection and resumption of lockstep. Operators monitor for unusually frequent partition-and-heal cycles, which may indicate an adversarial actor or an unstable network configuration that needs investigation.

### 20.9 Lockstep protocol invariants

The substrate's lockstep protocol is correct iff a small set of structural invariants hold. This subsection specifies the invariants. A conforming implementation must maintain all of them; an implementation that violates any is non-conforming and is detected via the conformance suite or via cluster-level dissent log accumulation.

**Invariant one: deterministic transition.** The state-transition function is a pure function of (current state, ordered input set). No I/O, no system calls returning time-varying values, no thread-local state, no compiler-dependent floating-point operations. Same inputs in same order on same starting state produce byte-identical resulting state.

**Invariant two: canonical input ordering.** Every honest node processes the same union of inputs in the same order, determined by canonical hash sort.

**Invariant three: monotonic frame progression.** Frame numbers advance by exactly one per committed frame. There is no skipping forward, no resetting backward, no parallel frame numbers.

**Invariant four: supermajority commit binding.** A frame is committed iff at least ⌊2n/3⌋+1 nodes report identical state hashes. No frame is committed without supermajority; no frame is committed with conflicting supermajority.

**Invariant five: cryptographic verification before processing.** Every input is verified cryptographically (signature against canonical preimage) before being included in the deterministic transition. Inputs that fail verification are silently dropped, deterministically.

**Invariant six: phase buffering.** Receive-side message buffering accommodates one frame of bidirectional asynchrony between any two nodes. Messages from "the future" (next-frame messages while still processing current-frame) are buffered; messages from "the past" (already-committed-frame messages) are discarded.

**Invariant seven: dissent log determinism.** Every honest node observing the same supermajority tally writes the same dissent log entry. Dissent attribution is identical across honest nodes for the same observed event.

These seven invariants are sufficient for lockstep correctness. An implementation that maintains all seven is correct regardless of which specific data structures, programming language, or transport layer it uses. The conformance specification operationalizes the invariants through test vectors that exercise each.

The next section (§21) walks cluster topology attacks. Where §20 engaged threats to the lockstep protocol within a single cluster, §21 engages threats to the cluster topology itself — Sybil attacks against admission, cluster-splitting at adversarial boundaries, cross-cluster transfer races, cluster orphaning, and cluster-level Byzantine collusion. The composition is that a §20 attack must succeed within a single cluster to corrupt that cluster's state; a §21 attack succeeds at the cluster-membership or cross-cluster layer to corrupt the federation's overall integrity.
## §21. Cluster topology attacks

The substrate's cluster topology (§11) is the substrate's scaling mechanism. Many clusters of bounded size, each performing lockstep consensus over its own bytes, with cross-cluster transfer protocols moving bytes between clusters as ownership crosses cluster boundaries. The topology is the architectural decomposition that lets the substrate scale across federation rather than through consensus growth, and it is the architectural layer where several attack classes operate.

This section walks five attack classes against the four-element rubric (§18.3). The attacks are §21.1 admission Sybil attacks, §21.2 cluster splitting at adversarial boundaries, §21.3 cross-cluster transfer race conditions, §21.4 cluster orphaning by selective gossip, §21.5 cluster-level Byzantine collusion. §21.6 closes by acknowledging that several defenses in this category are v0.4 specification work and naming the substrate's commitment to engaging them honestly in the meantime.

By the close of §21, the reader should accept that the substrate's cluster topology is robust against the realistic attack surface a sophisticated adversary at the topology layer can present, that the v0.4 gaps are honestly named rather than hidden, and that the substrate's federated structure is defensible against attacks that target its decomposition rather than its individual clusters.

### 21.1 Admission Sybil attacks

**Attack.** An adversary attempts to acquire enough cluster member slots to exceed the BFT supermajority bound (§13). With ⌊n/3⌋+1 nodes under the adversary's control, the adversary can prevent commits (denial-of-service); with ⌊2n/3⌋+1 nodes, the adversary can commit forged state. The attack succeeds if the substrate's admission gates can be cleared by the adversary at lower cost than the cluster's economic value warrants.

The attack has two profiles. Profile one: the adversary pretends to be many distinct legitimate operators, each clearing the admission gates independently. Profile two: the adversary corrupts existing legitimate operators (bribery, coercion, infiltration) and brings their nodes under adversarial control without the operators' awareness.

**Defense.** The substrate's admission protocol (§11.2) imposes three gates: cryptographic identity, proof-of-resource shadow period (default 30 days), and existing-member sponsorship (at least two existing cluster members vouching for the candidate). Each gate raises the adversary's cost.

The cryptographic-identity gate produces a permanent, content-addressed admission record bound to a specific ed25519 public key. There is no admission recovery for a lost private key; an adversary attempting to spawn many Sybils must generate, manage, and protect a large number of distinct private keys, each of which becomes a separate operational liability.

The shadow-period gate forces the adversary to run production-equivalent infrastructure for 30 days before the Sybil's vote counts. For a cluster of value V, an adversary attempting to acquire ⌊n/3⌋+1 Sybil slots must run that many shadow nodes for 30 days each, with the candidate's hashes monitored against the cluster's supermajority hash on every frame. Infrastructure cost is approximately ⌊n/3⌋+1 × $1000-3000/month per node (conservative cloud-hosting estimate); adversary scaling becomes economically painful at cluster sizes large enough to be valuable.

The sponsorship gate requires the adversary to either (a) recruit two existing legitimate members per Sybil attempt, paying or coercing them at the per-sponsorship cost; or (b) bring the Sybil's sponsors under adversarial control, doubling the corruption requirement. Sponsorship has reputational stakes for the sponsor: a sponsor whose sponsored candidate later misbehaves accumulates dissent-log weight, risking their own admission status. Sponsors who repeatedly vouch for adversarial candidates are themselves identifiable and excludable.

**Residual risk.** Three residual risks. First, a sufficiently-resourced adversary (state-level, large enterprise) can clear the admission gates by sustained operational effort. The defenses raise costs; they do not eliminate the threat. The substrate's architectural assumption (§18.2) is that the cost is high enough that the adversary's value capture is bounded. Second, the v0.3 implementation does not yet enforce the full admission protocol — it admits any peer that can connect, with operator vetting outside the protocol. The v1.0 substrate must implement the gates before production deployment is responsible. Third, the sponsorship gate is socially-contestable: an adversary can bribe sponsors, infiltrate sponsor pools, or run social-engineering campaigns to recruit unwitting sponsors.

**Operational response.** The cluster's dissent log accumulates evidence on candidates whose post-admission behavior diverges from the supermajority. Persistent misbehavers are expelled (planned v0.4) and their sponsors' reputations decay. The cluster's operational tooling monitors admission patterns for anomalies — unusually rapid admission rates, geographic clustering of new admissions, reused infrastructure across nominally-distinct candidates. Operators investigate flagged patterns and can pause admissions if a Sybil campaign is detected.

### 21.2 Cluster splitting at adversarial boundaries

**Attack.** A cluster reaches the splitting threshold (§11.3.2). The adversary attempts to manipulate the split such that all the cluster's adversarial nodes end up in one of the two resulting clusters, while the other resulting cluster has only honest nodes. If successful, the adversary gains a cluster where they hold the BFT supermajority and can corrupt state, while the honest cluster operates normally but loses oversight of the bytes that partitioned to the adversarial cluster.

The attack has two variants. Variant one: the adversary biases the cluster-splitting protocol's randomness beacon (§11.3.2 step 1), causing the byte and member partition functions to produce favorable outcomes. Variant two: the adversary times the split to coincide with a moment when honest members are unavailable (network outage, scheduled maintenance), shifting the post-split membership balance.

**Defense.** The substrate's cluster-splitting protocol (specification work for v0.4) is designed against both variants. The randomness beacon is constructed from contributions of *all* cluster members at the SplitFrame, with each member committing their contribution before any contribution is revealed (commit-reveal protocol). An adversary controlling fewer than the BFT supermajority cannot bias the beacon; an adversary at the BFT supermajority can corrupt many things, and the split's randomness is just one of them.

The member-assignment function (§11.3.2 step 3) is constrained to produce two new clusters each meeting the n≥4 BFT threshold and having approximately n/2 members. The function's output depends on the randomness beacon and the deterministic ordering of the cluster's pre-split membership; an adversary cannot directly choose which members go where.

The split's timing is set by cluster-size threshold rather than by adversarial choice. A cluster reaches the splitting threshold when its membership exceeds the operator-tunable splitting size (default: 32 members); the split happens at the next available SplitFrame. An adversary can attempt to time their attacks against scheduled maintenance windows, but the cluster's normal operation continues during such windows (BFT supermajority handles ⌊(n-1)/3⌋ unavailable members), and the SplitFrame happens whenever the threshold is reached, not at adversary-chosen times.

**Residual risk.** Two residual risks. First, the cluster-splitting protocol is design-only in v0.3. The randomness beacon, the member-assignment function, the partition function — all are specified at the prose level but not yet implemented. v0.4 will surface implementation details that this prose cannot anticipate, including subtle attack vectors against the specific commit-reveal mechanism the implementation uses. Second, an adversary controlling a BFT supermajority of the cluster can corrupt the split's randomness arbitrarily, since the supermajority's contributions dominate the beacon. This is the same fundamental BFT bound that applies everywhere; cluster splitting is not a special case.

**Operational response.** The first time the substrate's cluster splitting is exercised in production, operators monitor the split outcomes for suspicious patterns. A split that produces unusually skewed membership distributions, or that partitions bytes in patterns favoring specific adversaries, is investigated and may be reversed (via cluster merging, also v0.4 work) if anomalies are detected. The cluster's post-split state and the SplitFrame's contents are archived for forensic analysis.

### 21.3 Cross-cluster transfer race conditions

**Attack.** A byte is in the process of cross-cluster transfer from cluster A to cluster B (§11.3.3). The adversary attempts to exploit race conditions in the transfer protocol — submitting a transfer of the same byte to cluster A while the export attestation is being signed, attempting to introduce the byte to a third cluster C before B's import completes, or causing cluster B to import a byte that cluster A has not yet retired from its own state.

The attack succeeds if the substrate's cross-cluster protocol allows the byte to exist in two clusters simultaneously, or to be transferred under an outdated state.

**Defense.** The substrate's cross-cluster transfer protocol uses a five-step procedure (§11.3.3): (1) ownership transfer commits in cluster A with cross-cluster flag; (2) cluster A produces export attestation signed by BFT supermajority; (3) cluster B verifies and imports; (4) cluster A retires the byte; (5) external references resolve to cluster B.

The protocol's correctness depends on three orderings. First, cluster A's lockstep commits the cross-cluster transition before it produces the export attestation; the byte is no longer transferable within cluster A by the moment the attestation is signed. Second, cluster B's import is a single committed frame in cluster B's lockstep, with the import succeeding or failing atomically. Third, cluster A's retirement of the byte happens after cluster B's import, with the gossip overlay propagating the new ownership to any external party who queries.

A byte cannot exist in two clusters simultaneously because cluster A's lockstep commits the cross-cluster transfer (which includes retiring the byte from cluster A) before any other cluster can process an import attestation referencing the same byte. Cluster B verifies cluster A's BFT-supermajority signature on the export attestation; the signature is produced after the cross-cluster commit, so the byte is already retired from cluster A by the time cluster B can import.

**Residual risk.** Three residual risks. First, the cross-cluster transfer protocol is design-only in v0.3. Implementation will surface subtle race conditions — particularly around partial failures (cluster A commits the transfer, cluster B's import fails, the byte is in limbo). Second, an adversary controlling the gossip overlay between clusters could potentially delay propagation of the cluster-A-retirement message, allowing the byte's previous owner (in cluster A) to attempt re-spending in cluster A's view of the world; the substrate's defense is that cluster A's own lockstep already retired the byte, so the re-spending attempt fails at cluster A's verification step regardless of what cluster B believes. Third, cross-cluster transfers introduce a dependency on the export-attestation signature scheme; if cluster A's BFT supermajority is compromised, cluster A can sign export attestations for bytes that don't exist or that have already been transferred. This is engaged in §21.5.

**Operational response.** Cross-cluster transfer failures are detected by either cluster's lockstep failing to commit the corresponding frame. Failed transfers are retryable: the source cluster's state is unchanged (the cross-cluster commit was rolled back), and the user can re-submit the transfer. Anomalies in cross-cluster patterns — clusters attempting to transfer the same byte through multiple paths, clusters whose transfer-failure rate is unusually high — are flagged by operational monitoring for investigation.

### 21.4 Cluster orphaning by selective gossip

**Attack.** A cluster's existence depends on the substrate's gossip overlay propagating its state attestations, admission records, and cross-cluster transfer announcements to peer clusters. An adversary controlling enough of the gossip overlay can selectively suppress a target cluster's gossip, isolating it from the broader substrate. The target cluster continues operating internally but is unreachable for cross-cluster transfers, unable to admit new members from outside its current peering, and effectively orphaned.

A more subtle variant: the adversary suppresses *some* of the target cluster's gossip — specific announcements, specific transfers — while letting other gossip pass. The target cluster is partially isolated, with external observers seeing an inconsistent picture.

**Defense.** The substrate's gossip overlay (§11.4) is intentionally simple and topologically heterogeneous. Every node maintains a small number of peer connections; gossip propagates through the overlay via deduplication-by-content-addressing. An adversary attempting to suppress a target cluster's gossip must control all of the target cluster's peer connections; the cluster's nodes can refresh their peer connections to bypass adversarial peers, and the gossip overlay's heterogeneity (every node chooses its own peers) makes it costly for any adversary to control the connections of a specific cluster.

For the partial-suppression variant, the substrate's content-addressed gossip provides a defense: any party who has received some of the cluster's gossip (via any path in the overlay) holds the content-addressed identifier and can request the rest from any other peer in the overlay. Selective suppression requires the adversary to control all paths through which a specific message could propagate, not just some of them; for a sufficiently dense overlay, this is operationally infeasible.

**Residual risk.** Three residual risks. First, the gossip overlay's specification is brief (§11.4) and operational. v0.4 work should specify peer-selection algorithms, gossip propagation rules, NAT-traversal mechanisms, and bootstrap protocols precisely; in the absence of detailed specification, implementations may diverge in ways that produce orphaning vulnerabilities. Second, network-layer state-level attacks (BGP hijacking, ISP-level routing manipulation) can suppress entire geographic regions of the gossip overlay; this is engaged in §27 (physical attacks). Third, an adversary deploying a large number of well-connected gossip nodes can dominate the overlay's peering selections and selectively withhold messages; the defenses are admission-style gates on gossip-overlay participation (planned v0.4) and operational monitoring for gossip-pattern anomalies.

**Operational response.** A cluster that detects orphaning (it cannot reach known peer clusters, its gossip is not propagating, its cross-cluster transfers are failing) refreshes its peer connections, attempts to bootstrap from known reliable peers, and may request operator intervention if the orphaning persists. Substrate-level operational tooling monitors gossip propagation rates and flags clusters whose visibility from external observers has dropped unexpectedly.

### 21.5 Cluster-level Byzantine collusion

**Attack.** An adversary controls the BFT supermajority of an entire cluster — through Sybil attacks (§21.1), through corrupting existing operators, through deploying the cluster as their own infrastructure from the start. The cluster's lockstep continues operating, but the supermajority's commits no longer reflect honest consensus; the cluster signs forged state, fabricated export attestations, and false admission records.

The attack profile is qualitatively different from §13 (BFT) attacks: BFT defends against *up to* ⌊(n-1)/3⌋ Byzantine nodes per frame. Cluster-level Byzantine collusion *exceeds* this bound by definition, making BFT supermajority commit a tool of the adversary rather than a defense against them.

**Defense.** The substrate's defense against cluster-level Byzantine collusion operates at the *federation* layer rather than the *cluster* layer. Three mechanisms compose.

**Mechanism one: content-addressed history independent verification.** A cluster B importing a byte from cluster A (§11.3.3) verifies the byte's full chain end-to-end (§10.2). A malicious cluster A that signs an export attestation for a byte with a forged history fails verification at cluster B's import step; the byte's chain doesn't verify against cluster A's claim, and the import is rejected. Cluster A's BFT supermajority is irrelevant to the chain verification — the chain's correctness derives from the byte's own cryptographic provenance, not from the cluster's testimony.

**Mechanism two: cross-cluster attestation diversity.** Bytes that are valuable enough to attract adversarial attention typically transit multiple clusters during their lifetime. Each cluster that has handled a byte produces attestations visible to the substrate's gossip overlay. A malicious cluster A claiming to have handled a byte that other clusters' historical records contradict is detectable by querying the gossip overlay for the byte's history of cluster touches. Adversarial clusters that fabricate handling history for bytes they never actually managed are surfaced by the discrepancy.

**Mechanism three: cluster reputation accumulation.** A cluster operating honestly over long periods accumulates positive reputation (clean dissent log, successful cross-cluster transfers, no anomalies in admission patterns). A cluster newly admitted to the federation, or a cluster with anomalies in its history, is treated with more caution by other clusters. A cluster determined to be malicious can be expelled from the federation by quorum of honest clusters (the expulsion protocol's design is v0.4 work and is taken up in §22 and §25).

**Residual risk.** Four residual risks. First, cluster-level Byzantine handling is design-only in v0.3. The federation-layer defenses are specified at the prose level but not yet implemented; v0.4 must implement them before substrate operates with multiple clusters in production. Second, content-addressed history verification (mechanism one) requires the verifier to obtain the byte's full chain; an adversary who controls the chain's distribution can attempt to provide a fake chain to verifiers, but blake3's collision resistance defeats this — the fake chain's hashes don't match the real chain's hashes, and the verification fails. Third, the cluster-expulsion protocol depends on a quorum of honest clusters being identifiable. If the federation is dominated by adversarial clusters (the substrate-level analog of cluster-internal Byzantine majority), no honest expulsion quorum exists. The substrate's strategic case (§28) is that the federation maintains adequate honest constituency over the timeline relevant to substrate adoption. Fourth, an adversarial cluster colluding with all the other clusters that have handled a particular byte (a coordinated lie across the byte's entire transit history) can produce a consistent fake history; the substrate's defense is that such coordination is operationally hard at scale and would itself produce anomalies in the gossip overlay.

**Operational response.** Cluster-level Byzantine collusion detected by federation-level mechanisms triggers cluster expulsion (planned v0.4). Bytes resident in the expelled cluster are treated as orphaned: their history remains valid but their current state is unverifiable, requiring intervention by an honest cluster willing to import them with extra verification (auditor-grade chain examination, cross-referenced with all surviving handling-history attestations from other clusters). Recovery is partial — bytes whose handling history was entirely within the expelled cluster, with no cross-cluster transfers, may be unrecoverable. The substrate's operational guidance is that high-value bytes should diversify across multiple cluster transits to minimize this risk.

### 21.6 The v0.4 specification gap

The substrate's cluster topology defenses are partially design-only in v0.3. This subsection names the gap honestly so that the threat model is not read as a claim of completeness when it is not.

Five defenses are design-only:

- **Cluster splitting (§11.3.2 / §21.2)**: the SplitFrame protocol, the randomness beacon, the member-assignment function, the partition function. v0.3 does not implement any of these. v0.4 priority high.
- **Cross-cluster transfer (§11.3.3 / §21.3)**: the export-and-import protocol with BFT-supermajority signatures and gossip propagation. v0.3 does not implement. v0.4 priority high.
- **Cluster-level Byzantine handling (§11.3.4 / §21.5)**: the federation-layer defenses against malicious clusters. v0.3 implements intra-cluster BFT only. v0.4 priority high.
- **Gossip overlay specification (§11.4 / §21.4)**: peer-selection algorithms, propagation rules, bootstrap protocols. v0.3 specifies the overlay at the prose level. v0.4 priority high.
- **Cluster expulsion protocol (§14.3 / §21.5)**: the federation-quorum mechanism for removing malicious clusters. v0.3 specifies dissent-log accumulation; expulsion based on it is v0.4 work.

The substrate ships v1.0 with these gaps explicitly named. v1.0 substrate operation is therefore appropriate for single-cluster or small-federation deployments where the v0.4 mechanisms are not yet load-bearing. Multi-cluster production deployment requires v0.4. The treatise commits to specifying and implementing all five v0.4 items before the substrate's adoption crosses thresholds where multi-cluster operation becomes necessary.

The honest acknowledgment of the gap is part of the threat model's discipline. A treatise that claimed v1.0 substrate is fully cluster-topology-secure would be misleading; the treatise's claim is that v1.0 substrate has well-defended single-cluster operation with cluster-topology defenses specified-but-not-yet-implemented for federation-scale deployment. The distinction matters for any operator considering substrate deployment at present-day adoption levels versus federated-substrate adoption levels.

### 21.7 Composition with other categories

The cluster topology attacks engaged in §21 compose with other categories' defenses in three ways.

**Composition one: cluster topology defenses depend on cryptographic primitives (§19) and lockstep protocol invariants (§20).** Admission-record signatures use ed25519. Cluster-state hashes use blake3. Cross-cluster export attestations use BFT-supermajority signatures over canonically-serialized state. If §19 or §20 defenses fail, §21 defenses fail with them.

**Composition two: cluster topology defenses are the substrate's federation-layer immune system.** §19 defends individual cryptographic primitives. §20 defends individual cluster lockstep. §21 defends the federation of clusters as a whole — admission gates that limit Sybil entry, cross-cluster verification that limits malicious-cluster influence, expulsion mechanisms that remove identified bad actors. The federation-layer defenses are what make the substrate's "federate, don't centralize" architectural commitment defensible against sophisticated adversaries.

**Composition three: cluster topology gaps in v0.3 are the substrate's most pressing v0.4 work.** §19 and §20 defenses are largely implemented in the v0.3 reference. §21 defenses are largely design-only. Adopting the substrate beyond single-cluster, small-federation deployments depends on closing these gaps. The treatise's discipline is to name the gaps; the substrate's authors' discipline is to close them.

The next section (§22) walks issuer attacks. Where §21 engaged threats to the cluster topology — the federation layer — §22 engages threats to the issuer registry: compromised issuer keys, social engineering of issuer governance, regulatory capture, issuer collusion, and run-on-the-bank dynamics. The composition is that §21 defenses prevent malicious clusters; §22 defenses prevent malicious or captured issuers within otherwise-honest clusters.
## §22. Issuer attacks

The substrate's issuer registry (§15.1) is the architectural layer where authorized entities mint cargo-bearing bytes. A USD-byte issuer is a stablecoin provider; a joule-byte issuer is a registered solar cooperative; a kcal-byte issuer is a food cooperative or agricultural producer. The issuer registry is publicly visible, governance-mutable, and content-addressed; every byte's origin attestation is signed by an issuer whose authorization is verifiable by any party.

This section walks five attack classes against the four-element rubric (§18.3). The attacks are §22.1 compromised issuer key, §22.2 social engineering of issuer governance, §22.3 regulatory capture of issuer set, §22.4 issuer collusion, §22.5 run-on-the-bank dynamics. §22.6 closes by acknowledging that issuer-layer threats are where the institutional middle re-enters the substrate's stack as a layer-2 service, and where adversaries who cannot attack the substrate's protocol directly may attack through the issuers it depends on.

By the close of §22, the reader should understand that issuer attacks are categorically different from protocol attacks — they target the trusted entities the substrate explicitly retains for cargo-bearing bytes, and the substrate's defenses operate by limiting issuer power and ensuring issuer plurality, rather than by eliminating issuer trust entirely.

### 22.1 Compromised issuer key

**Attack.** An adversary obtains an issuer's ed25519 private key — through theft, malware, supply-chain attack, insider threat, or coercion. With the key, the adversary mints bytes claiming to be issued by the legitimate issuer: USD-bytes that aren't backed by dollar reserves, joule-bytes that don't correspond to actual energy production, kcal-bytes that no actual food was grown for. The forged bytes flow into circulation, get transferred to legitimate counterparties, and accumulate cryptographic provenance that masks their fraudulent origin.

The attack is particularly damaging because the substrate's chain verification (§10.2) does not detect forged-but-cryptographically-valid mints. The forgery is at the issuer's authorization layer, not at the substrate's cryptographic layer; the chain verifies, the signatures verify, the issuer registry confirms the issuer pubkey is authorized — but the *underlying claim* (that backing reserves exist for the USD-bytes, that energy was actually produced for the joule-bytes) is false.

**Defense.** The substrate's defense against compromised issuer keys is *containment plus rotation*. The substrate cannot prevent issuer-key compromise any more than it can prevent user-key compromise (§19.4); it can only limit the damage and provide a path to recovery.

Three layers of containment apply. First, **issuer key rotation** (planned v0.4): an issuer detecting compromise can rotate to a new keypair via a governance-mutable update to the registry. The rotation is a signed attestation from the *old* key authorizing the *new* key, with a timestamped frame number that scopes the compromise window. Bytes minted under the old key after the rotation timestamp are detectable as suspicious. Bytes minted before the rotation but after the actual compromise are harder — the substrate cannot retroactively determine when the compromise actually occurred — but the issuer's own off-substrate records and reserve attestations help establish the boundary.

Second, **issuer reserve attestations** (v0.4 specification work, may be implemented as layer-2): the substrate's protocol does not currently require issuers to attest periodically to their reserves, but the issuer registry's content-addressed structure makes such attestations natural. An issuer that publishes monthly reserve attestations (signed with the issuer's key, content-addressed in the substrate's gossip overlay) creates a cumulative record. A forged-mint attack inflates the issuer's apparent issuance beyond the reserve attestations; the discrepancy is detectable by anyone auditing the public attestations.

Third, **layer-2 issuer remediation services**: external auditors, regulatory bodies, and dispute-resolution services can examine an issuer's claims against external evidence (banking records, energy-grid reports, agricultural production records). When forgery is identified, the affected bytes can be invalidated through issuer cooperation or layer-2 dispute resolution. This is not a substrate-level guarantee but an operational reality: real issuers operate within real legal and regulatory frameworks that provide accountability the substrate's protocol does not.

**Residual risk.** Three residual risks. First, the v0.4 issuer-key-rotation protocol is unimplemented; v0.3 fixes the issuer set at genesis with no rotation mechanism. An issuer-key compromise in v0.3 has no protocol-level recovery and requires a substrate-wide governance event to update the registry. Second, the time between actual compromise and detection can be substantial; an adversary with a stolen issuer key can mint a large volume of forged bytes before the issuer notices, with the bytes acquiring cryptographic provenance that makes them indistinguishable from legitimate bytes at the chain-verification layer. Third, layer-2 remediation depends on external accountability mechanisms that may themselves be captured or compromised; if regulators are corrupt or auditors are bribed, the remediation fails.

**Operational response.** An issuer detecting compromise rotates keys (post-v0.4) and publishes a frame-stamped advisory through the gossip overlay. Counterparties who hold bytes minted under the compromised key during the suspect window can examine the issuer's reserve attestations to assess legitimacy, request issuer-level remediation if available, or pursue layer-2 dispute resolution. Bytes whose legitimacy cannot be established are treated as having impaired value at the application layer, with the chain remaining verifiable but the underlying claim discounted by counterparties. The substrate's role is to make the cryptographic provenance auditable; remedy depends on layer-2 mechanisms.

### 22.2 Social engineering of issuer governance

**Attack.** An adversary attacks the issuer-set governance flow (planned v0.4) through social engineering rather than through cryptographic or protocol-level means. The adversary submits proposals to add their own front company as an issuer, recruits enough existing issuers to vote for the proposal (through bribery, influence, or genuine persuasion), and gains issuance authority without actually backing the issued cargo with real reserves or production.

A more subtle variant: the adversary attacks individual existing issuers' decision-making rather than seeking new admission — convincing a USD-byte issuer to relax their reserve requirements, or convincing a joule-byte issuer to issue bytes against future production rather than already-delivered production. The issuer remains nominally the same; the cargo's quality silently degrades.

**Defense.** The substrate's defenses against governance social engineering operate at the *transparency* and *plurality* layers rather than at the technical layer.

The issuer registry is publicly visible (§15.1). Every issuer's pubkey is in the registry, every governance event that changes the registry is committed to the cluster's lockstep, every change produces a content-addressed record visible to any party. An adversary attempting to add themselves as an issuer cannot do so privately; the addition is auditable.

Issuer plurality is structural. The substrate is multi-issuer per cargo type; users can choose which issuer's bytes to accept and transact with. An issuer whose governance has been corrupted (relaxed reserves, accepted forged production claims) loses user trust as the corruption becomes visible — through reserve attestation discrepancies, through external auditor reports, through user-side risk assessment. The corrupted issuer's bytes trade at a discount at the application layer; eventually the issuer loses market share to honest competitors. The substrate doesn't prevent the corruption; it makes the corruption visible and provides users with alternatives.

The governance flow itself (v0.4 design) requires supermajority approval from existing issuers of the affected cargo type — not from a single administrator. An adversary seeking to add themselves as an issuer must convince a supermajority of existing issuers, each of whom has their own reputational stake in the cargo type's integrity. Supermajority capture is harder than single-administrator capture, though not impossible at sufficient resources.

**Residual risk.** Three residual risks. First, the issuer-governance flow is design-only; v0.4 specification will surface the actual mechanics, including exact supermajority thresholds and challenge periods. Second, governance attacks operate on long timescales (weeks to months for a proposal cycle) where adversaries can exert sustained pressure on individual existing issuers; the substrate has no protocol-level defense against patient corruption, only the visibility-and-plurality structural defense. Third, the "users choose which issuer's bytes to accept" defense depends on users having useful information about issuer quality; users without access to reserve attestations, audit reports, or comparative analytics are operating with information asymmetry that adversaries can exploit.

**Operational response.** Anomalous governance proposals (unusually rapid admission requests, requests from front companies with no production history, requests targeting cargo types with high concentration risk) are flagged by issuer-governance monitoring. The substrate's gossip overlay propagates governance events to all clusters and external observers; anomalies are identifiable and can drive community response. Issuer-quality reporting services (layer-2) consolidate reserve attestations, audit findings, and operational track records into comparative information that users can consult. The substrate provides the infrastructure for transparency; layer-2 services and user vigilance provide the actual quality assessment.

### 22.3 Regulatory capture of issuer set

**Attack.** A state or coalition of states uses regulatory authority to constrain the substrate's issuer set. Regulators can impose capital requirements that only large institutions can meet, demand reporting and disclosure that only regulated entities can provide, license-gate the right to issue cargo of certain types, and outright prohibit issuance of cargo types they wish to control (digital currencies competing with state-issued ones, energy markets the state wishes to monopolize, food production outside state-approved channels).

The attack succeeds if it reduces the substrate's issuer plurality to one or zero per cargo type — recreating the institutional middle's monopoly structure within the substrate's nominal multi-issuer architecture.

**Defense.** The substrate's structural defenses against regulatory capture are partial. The substrate cannot prevent states from regulating; it can only ensure that regulatory pressure on one jurisdiction's issuers does not eliminate issuance globally.

**Defense one: jurisdictional plurality.** The substrate's issuer set spans multiple jurisdictions. A USD-byte issuer in the United States is regulated by U.S. authorities; a USD-byte issuer in Switzerland is regulated by Swiss authorities; a USD-byte issuer in Singapore is regulated by Singapore. Regulatory pressure in any one jurisdiction does not eliminate issuance globally; users in regulated jurisdictions can transact with issuers in less-regulated jurisdictions, with the cross-border friction being legal and operational rather than substrate-level.

**Defense two: the substrate's cargo-class neutrality.** The substrate is cargo-class-agnostic. A regulator banning USD-byte issuance does not affect joule-byte, kcal-byte, or compute-hour-byte issuance. Users whose regulatory environment makes specific cargo types unavailable can shift to functionally-similar cargo types (joule-bytes denominated in energy units rather than dollar-equivalents; community-currency-bytes for local exchange).

**Defense three: the substrate's protocol-level absence of issuer-friendly features.** The substrate has no built-in mechanism for issuer-level lockup of bytes, freeze of user accounts, mandatory KYC integration, or any of the regulatory-compliance features that traditional banking infrastructure embeds. An issuer wanting to add such features can do so at the application layer (a custodial wallet that voluntarily implements KYC and freeze), but the substrate's protocol doesn't make such features universal. Regulators demanding universal compliance must do so through the application layer or through the issuer's voluntary cooperation; they cannot mandate it at the substrate's protocol layer.

**Defense four: layer-2 anonymizing intermediaries.** Privacy-focused layer-2 services (mixing services, zero-knowledge wrappers, confidential transactions) can provide users in regulated jurisdictions with access to less-regulated issuers' bytes without exposing the cross-border flow to regulatory observation. The substrate's protocol-level transparency (every transition visible to chain verification) does not prevent layer-2 obfuscation; users who want privacy can compose it on top of the substrate, at their own discretion.

**Residual risk.** Three residual risks, deeply interconnected. First, jurisdictional plurality fails if regulators coordinate globally — international agreements like the FATF travel rule already constrain stablecoin operations across jurisdictions, and a coordinated multi-state ban on substrate participation could substantially shrink the available issuer set. Second, layer-2 privacy services are themselves regulated (Tornado Cash sanctions, the EU MiCA framework's restrictions on privacy coins); using them may itself become illegal in regulated jurisdictions, putting users at legal risk regardless of the substrate's protocol-level neutrality. Third, the substrate's strategic case (§28) rests on the substrate acquiring independent constituency before global regulatory coordination matures; if regulatory coordination wins the race, the substrate's freedom claims are constrained.

**Operational response.** Issuers facing regulatory capture in their home jurisdictions can either comply (becoming a more regulated, more compliant issuer with reduced freedom) or relocate (moving operations to more permissive jurisdictions). The substrate's federation supports both responses without protocol-level changes; the issuer's clusters continue operating, the issuer's bytes remain valid, the issuer's regulatory profile changes. Users in regulatory environments where their preferred issuers have become unavailable can shift to alternatives or to layer-2 anonymizing intermediaries, with the legal risks named above.

### 22.4 Issuer collusion

**Attack.** Multiple issuers of a cargo type collude to manipulate market conditions, coordinate price fixing, or jointly attack a competing issuer. The substrate's multi-issuer architecture is undermined by coordination among the supposedly-competing issuers.

Examples: USD-byte issuers colluding to charge identical fees, eliminating price competition. Joule-byte issuers in a region coordinating to suppress production reporting, inflating the apparent value of issued bytes. A coalition of established issuers refusing to support governance admission of new issuers, freezing the issuer set at advantageous incumbent levels.

**Defense.** The substrate's defenses against issuer collusion are *transparency-based* and *exit-based* rather than coordination-prevention-based.

**Transparency defense.** Every issuer's actions are visible. Mint volumes, reserve attestations (when published), governance votes (in v0.4), and pricing structures are all observable. Collusion that produces visible patterns — identical fees across nominally-competing issuers, synchronized issuance pauses, simultaneous governance votes — is detectable by external observers, antitrust regulators, and competing actors. The substrate makes collusion visible; it does not prevent collusion from occurring.

**Exit defense.** Users dissatisfied with the cargo type's issuer landscape can exit. They can hold less of the cargo type, switch to functionally-similar cargo types under different issuers, or compose layer-2 alternatives that bypass colluding issuers entirely. Exit options constrain issuer collusion economically: collusion that is too aggressive drives users to alternatives, eroding the colluding issuers' shared advantage.

**Substrate-level absence of issuer-friendly features.** Just as with regulatory capture, the substrate's protocol-level neutrality limits the leverage colluding issuers have. They cannot lock users into their cargo type; they cannot prevent users from transacting with bytes from competing issuers; they cannot impose substrate-wide rules that benefit only colluders.

**Residual risk.** Three residual risks. First, transparency requires observers — auditors, journalists, antitrust regulators with substrate-monitoring capability. The substrate makes information available; users still have to attend to it. Second, exit defense depends on alternatives existing; in cargo types where regulatory or operational barriers limit issuer entry, exit options may be inadequate. Third, the substrate's neutrality cuts both ways: it does not stop colluding issuers from coordinating off-substrate (private agreements, market-making coordination, joint lobbying for regulatory protection). The substrate's defenses are protocol-internal; off-substrate coordination is a layer-2 and policy-layer concern.

**Operational response.** Antitrust enforcement against colluding issuers operates through normal regulatory channels (FTC, DOJ Antitrust Division, EU Competition authority, equivalent bodies globally). The substrate's transparency provides evidence; regulators provide enforcement. User-level response is exit and switching, supported by layer-2 services that aggregate issuer-quality information and facilitate cargo-type transitions.

### 22.5 Run-on-the-bank dynamics

**Attack.** A USD-byte issuer's reserve adequacy comes into question — through a reserve attestation that fails to verify, an external audit that finds discrepancies, a regulatory action that signals trouble, or a market-wide flight from stablecoins. Users rush to redeem their USD-bytes for actual dollars before the issuer's reserves are exhausted. The redemption demand exceeds the issuer's liquid reserves; the issuer suspends redemptions; the byte's market price collapses; users holding the byte at the moment of suspension face significant loss.

The dynamic is not adversarial in the traditional sense — there is no single attacker — but it is a structural failure mode that an adversary can trigger, accelerate, or exploit. An adversary holding a short position on a specific issuer's bytes can publicize information designed to trigger a run; an adversary controlling competitor issuers can coordinate FUD campaigns; an adversary with regulatory leverage can time enforcement actions to maximize disruption.

**Defense.** The substrate's defenses against run dynamics are *informational* and *plural* rather than mechanical.

**Informational defense.** Issuer reserve attestations (v0.4 specification work) provide ongoing evidence of reserve adequacy. An issuer publishing daily reserve snapshots makes its reserves auditable continuously, not just at scheduled audit dates. Users can assess reserve adequacy in real time; runs become information-driven rather than panic-driven, and an issuer with verifiably-strong reserves can resist runs that would topple a weakly-attested issuer.

The substrate does not currently mandate reserve attestations, but the issuer registry's content-addressed structure makes them natural to add at the layer-2 level. Issuer-quality reporting services consolidate attestations and audit findings into comparative information that users can act on before runs become critical.

**Plurality defense.** Run dynamics affect specific issuers, not the cargo type as a whole. Users running from a failing USD-byte issuer can redirect their redemption demand to other USD-byte issuers, as long as the alternatives are not also stressed. The substrate's multi-issuer architecture limits contagion: a single issuer's failure does not necessarily cascade to other issuers of the same cargo type, particularly if the failing issuer's distress is idiosyncratic (specific reserve issue, specific regulatory action) rather than systemic (general loss of confidence in the cargo type).

**Cargo-type-level diversification.** Users concerned about run risk in any single cargo type can hold multiple cargo types, balancing across issuers, jurisdictions, and asset classes. The substrate's cargo-neutral architecture supports this naturally; users build their own portfolios across the substrate's available issuance.

**Residual risk.** Three residual risks. First, run dynamics can be triggered by genuine issuer failures (insolvency, reserve theft, operational collapse) that the substrate cannot prevent. Some issuers will fail; users holding those issuers' bytes will lose value. The substrate's claim is that the *substrate* doesn't fail — chain verification continues, the cluster keeps committing frames, other issuers keep operating — but specific issuers' failures are not protected against. Second, systemic crises (general loss of confidence in stablecoins, broader financial-system stress) can affect multiple issuers simultaneously, making the plurality defense weaker. The substrate has no protocol-level response to systemic stress; it inherits the broader financial system's vulnerabilities to the extent that its cargo types depend on the broader financial system. Third, the substrate's transparency (real-time visibility of issuance volumes, on-chain verification of transitions) can itself accelerate runs — making bad news visible faster than traditional banking's information opacity does. This is a structural cost of the substrate's transparency and one the treatise should be honest about.

**Operational response.** Issuer-level response to runs is the issuer's responsibility — managing liquidity, communicating reserve adequacy, coordinating with regulators and market makers. The substrate's role is to maintain protocol-level operation regardless of any specific issuer's health. Users facing run risk on bytes they hold can attempt redemption while it remains possible, transfer to other issuers' bytes, or convert to other cargo types. Users acting before the run becomes critical have better outcomes than users acting at the run's peak; the substrate's transparency at least makes the timing visible.

### 22.6 The institutional middle re-enters via issuance

A meta-observation worth naming explicitly. Issuer attacks are categorically different from substrate-protocol attacks. The substrate is honest in §6.4 and §15 that it retains issuer trust as a *structural feature* — cargo-bearing bytes (USD, joule, kcal, compute-hour) require external attestation of the cargo's existence. The substrate provides cryptographic provenance for the *byte* but cannot provide it for the *underlying claim* the byte represents. The substrate eliminates the institutional middle's role in matching, clearing, and trust signaling for transfers, but does not eliminate the institutional middle's role in *vouching for the cargo* at the issuance moment.

This is the substrate's deepest structural compromise. The institutional middle re-enters the substrate's stack at the issuer layer, smaller and more constrained than its pre-substrate role, but real. A USD-byte issuer is a stablecoin provider — typically a regulated financial institution with banking relationships, reserve management, audit obligations. A joule-byte issuer is a registered solar cooperative with grid-interconnection attestation. A kcal-byte issuer is an agricultural cooperative with production records. Each is a smaller, more transparent institution than the institutional middle's pre-substrate dominance, but each is still an institution with the operational and trust requirements that institutions impose.

The substrate's freedom claim is *partial freedom* rather than *complete freedom*. §6.1 named four freedoms; §22 makes explicit that the freedoms are bounded by issuer trust. Where issuers are diverse, transparent, and competitive, the substrate's freedom claim is robust. Where issuers are captured, colluding, or single-points-of-failure, the substrate's freedom claim weakens at exactly that cargo type.

The substrate's ongoing work — both in protocol design and in community-building — is to maintain the conditions under which issuer plurality is sustainable. Adversaries who cannot attack the substrate's protocol may attack through the issuer layer, and the substrate's defenses at that layer are structural (transparency, plurality, exit) rather than cryptographic. This is the most important honest disclosure §22 makes.

### 22.7 Composition with other categories

Issuer attacks compose with other categories' defenses in three ways.

**Composition one: cryptographic primitives (§19) and protocol invariants (§20) are *necessary but not sufficient* for issuer-layer security.** A perfectly-implemented substrate protocol with a compromised issuer key produces forged-but-cryptographically-valid bytes. Issuer-layer defenses (reserve attestations, key rotation, governance plurality) operate above the protocol layer.

**Composition two: cluster topology defenses (§21) protect issuer-registry integrity at the cluster level.** A malicious cluster (§21.5) could refuse to honor a legitimate issuer's mints, or could falsely claim authorization for an unauthorized issuer; cluster-topology defenses (federation-layer verification, cluster expulsion) prevent cluster-level corruption from compromising the issuer registry.

**Composition three: issuer attacks are the bridge between protocol-level and economic/social attacks (§24-§25).** Many issuer attacks — collusion, run dynamics, regulatory capture — operate through economic and social mechanisms rather than through protocol exploitation. §22's treatment is the protocol-adjacent face of issues that §24 (economic) and §25 (social) develop further. Readers concerned about the substrate's institutional-middle exposure should read §22, §24, and §25 together.

The next section (§23) walks state attacks — corruption of the substrate's persisted state through memory error, adversarial replay, state-sync poisoning, and checkpoint tampering. Where §22 engaged threats to the issuer layer that the substrate retains, §23 engages threats to the substrate's own state-management infrastructure: the persistence layer (§16), the recovery procedures, and the data integrity guarantees the substrate's clusters depend on for continuous operation.
## §23. State attacks

The substrate's state is the live, in-memory representation of the cluster's bytes, issuer registry, and frame number, persisted to disk via the checkpoint+log mechanism (§16). State integrity is foundational: every transition the substrate validates depends on the current state being correct, every BFT supermajority commit binds the post-frame state hash, every recovery procedure relies on the persisted state being authentic. An attack that corrupts state — silently or detectably, on disk or in memory, during normal operation or during recovery — threatens the substrate's continuous-operation claim.

This section walks four attack classes against the four-element rubric (§18.3). The attacks are §23.1 state corruption via memory error, §23.2 state fork via adversarial replay, §23.3 state-sync poisoning, §23.4 checkpoint tampering. §23.5 closes by specifying the substrate's state-integrity invariants — the structural properties that, if maintained, are sufficient for state correctness across normal operation and recovery scenarios.

By the close of §23, the reader should accept that the substrate's state-management layer is robust against the realistic attack surface that targets stored and in-flight state, that the persistence layer's intentional simplicity (§16's "intentionally unclever" framing) is itself a defense, and that recovery procedures are auditable rather than depending on operator trust.

### 23.1 State corruption via memory error

**Attack.** A node's in-memory state corrupts during normal operation. The corruption may be benign (single-bit flip from cosmic ray, ECC-uncorrected hardware error) or adversarial (memory-tampering rootkit, hypervisor-level attack on virtualized substrate nodes, deliberate fault injection on physical hardware). The corrupted state diverges from the cluster supermajority on the next frame's commit. If the corruption is silent and the node fails to detect it, the node continues operating with corrupted state, producing divergent state hashes and accumulating dissent log entries from peers.

The attack profile is: the node itself is honest in intent, but its memory has corrupted; or the node's hardware has been compromised, but the node's software is unaware.

**Defense.** The substrate's primary defense against memory-error state corruption is *the lockstep protocol itself*. Every committed frame produces a state hash (§9.4 step 6). Honest peers compare their hashes; the supermajority commit (§13) detects divergence within milliseconds of the corruption affecting the state-transition output. The corrupted node halts with `MINORITY DIVERGENCE` (§13.3 outcome three) or, if the corruption is widespread, the cluster halts with `CLUSTER SPLIT`. The supermajority's hash agreement is the substrate's continuous-validity check on every node's state; corruption that affects state-relevant memory is detected on the next frame.

Secondary defenses operate at the hardware and OS layers. ECC RAM corrects most single-bit errors before they reach software. Server-class CPUs include MCE (Machine Check Exception) handlers that detect uncorrectable errors and halt the affected process. The substrate's reference implementation does not require ECC, but production deployments are advised to use it. Operating-system-level kernel-page-table-isolation, ASLR, and other hardening measures reduce the attack surface for memory-tampering rootkits.

For deliberate fault injection on physical hardware (Rowhammer attacks, deliberate undervolting, cold-boot attacks on encryption keys), the substrate has no protocol-layer defense — these are hardware-level attacks that operating systems and hardware vendors must address. The substrate's protocol-layer claim is that *whatever* the cause of the memory error, *the corruption is detected* by the supermajority commit before it can be acted on.

**Residual risk.** Three residual risks. First, memory corruption that affects code paths rather than state data (a corrupted instruction in the verification routine, a corrupted pointer in the state-transition logic) can cause the node to compute the wrong state without producing a recognizable hash divergence — the wrong state's hash is also wrong, and the node's behavior becomes unpredictable rather than detectably divergent. This is a hardware-level concern; the substrate's protocol cannot defend against arbitrary code corruption. Second, a Byzantine majority of nodes simultaneously experiencing the same memory corruption (coordinated cosmic-ray storm, coordinated hardware attack across a cluster) would produce supermajority-corrupted state. The probability is operationally negligible for non-coordinated errors but is the structural failure mode for coordinated hardware attacks. Third, brief memory-error windows where corruption occurs and is corrected (silent corruption transiently affecting transition output, then resolving) may produce dissent log entries that operators investigate but cannot reproduce.

**Operational response.** A node halting with `MINORITY DIVERGENCE` triggers operator investigation. The node's hardware is examined (memory tests, ECC error logs, MCE history); if hardware error is found, the hardware is replaced and the node rejoins via the persistence-and-replay procedure (§16.2). If no hardware error is found, the node's process is restarted from the checkpoint and replay; if the corruption recurs, the node's software is examined for protocol-conformance bugs. Persistent unexplained divergence triggers cluster-level expulsion (planned v0.4) until the cause is identified.

### 23.2 State fork via adversarial replay

**Attack.** An adversary attempts to cause two parts of the cluster to commit different frames at the same frame number — a state fork. The classic Byzantine general's problem in concrete form: if the cluster's lockstep loses synchronization, with some nodes processing one set of inputs and other nodes processing another, the cluster may end up in two distinct committed states for the same frame number.

The attack profile: an adversary controlling a subset of cluster nodes (under the BFT bound) coordinates with adversarial network conditions to feed different inputs to different honest nodes for the same frame. The cluster's BFT supermajority commit is supposed to prevent this — both partitions of nodes would fail to reach supermajority — but the adversary attempts to engineer conditions where supermajority is reached *separately* in two partitions, producing two valid-looking state branches.

**Defense.** The substrate's defense against adversarial state forks is *the BFT supermajority bound combined with the input-broadcast invariant*.

The BFT supermajority bound (§13) requires ⌊2n/3⌋+1 nodes to commit a frame. For two distinct state branches to both achieve supermajority, the adversary would need to control more than ⌊(n-1)/3⌋ nodes — exceeding the BFT bound. Below the bound, the adversary cannot achieve supermajority for an alternate state branch; the honest supermajority's hash dominates the commit.

The input-broadcast invariant (§9.4 steps 2-3) ensures every honest node receives the union of all peer inputs for the frame. An adversary attempting to feed different inputs to different nodes would need to suppress the input-broadcast messages selectively — preventing some honest nodes from seeing some inputs while letting other honest nodes see them. This is the network-layer attack already engaged in §20.7 (message dropping); the defenses there apply: the affected honest nodes detect the divergence on the next supermajority commit and halt with `MINORITY DIVERGENCE`, preventing the fork from reaching commit.

The substrate's protocol therefore makes adversarial state forks structurally infeasible *below the BFT bound*. Above the bound, the adversary can corrupt state arbitrarily; this is the §21.5 cluster-level Byzantine collusion case, with federation-layer defenses applying.

**Residual risk.** Three residual risks. First, the input-broadcast invariant requires every honest node to send to every peer; an implementation that fails this invariant (a node that selectively skips peers in its input broadcast) creates the conditions for adversarial fork attacks. Conformance vectors include adversarial broadcast-skipping scenarios. Second, in clusters at exactly n=4 (the BFT-meaningful minimum), the bound tolerates f=1 Byzantine node and supermajority is 3; an adversary controlling 1 node plus adversarial network conditions affecting 1 honest node can produce 2-vs-2 hash splits that prevent commit (similar to the n=3 BFT degeneracy in §13.2 but at n=4). Cluster admission policies (§11.3.1) treat clusters at exactly n=4 as marginal and seek to grow them. Third, partition healing (§20.8) is where state-fork concerns are most acute; the substrate's correct behavior is to not commit during partition (preserving consistency over availability), but an implementation that commits during partition can produce true forks that must be reconciled.

**Operational response.** A cluster-level state fork attempt produces detectable evidence: dissent log entries on every honest node showing peers reporting divergent hashes for the same frame, supermajority commit failures, and the cluster halting with `CLUSTER SPLIT`. Operators examine the dissent log to identify the adversarial nodes and the network conditions that enabled the attack, restore connectivity, and either expel the identified adversaries or pause cluster operation until the conditions are remediated.

### 23.3 State-sync poisoning

**Attack.** A node recovering from extended unavailability (crash, network partition, planned maintenance) requests state-sync from peers to catch up to the cluster's current frame. An adversary poisons the state-sync response — providing a forged state, a state from a different cluster, or a state with adversarial modifications. If the recovering node accepts the poisoned state, it rejoins the cluster with corrupt state, producing dissent on every subsequent frame.

The attack is particularly relevant for nodes that have been unavailable long enough that their local checkpoint+log is too stale for replay. v0.3 does not implement state-sync — recovering nodes must be brought back via persistence-and-replay only. v0.4 adds state-sync from honest peers; §23.3 engages the attack class that v0.4 must defend against.

**Defense.** The substrate's defense against state-sync poisoning operates through *cryptographic anchoring* of received state to the cluster's known-good attestations.

The recovering node has access to the cluster's BFT-supermajority signed state-hash attestations from before its unavailability — either through the gossip overlay's published checkpoints, through its own pre-unavailability persistence, or through cluster-level beacons that publish state hashes periodically. The recovering node knows the *content-addressed hash* of the legitimate state at any frame within the attestation history.

When the node requests state-sync, it requests state at a specific frame. Multiple peers respond with their copies of the state at that frame. The recovering node verifies each response's content-addressed hash against the cluster's BFT-signed attestation for that frame; only state matching the attested hash is accepted. A peer providing a poisoned state produces a hash mismatch and is rejected; an honest peer providing the correct state matches the attestation and is accepted.

The verification is therefore *cryptographic*, not *trust-based*. The recovering node does not need to trust the peers individually; it trusts the cluster's BFT-supermajority signature on the historical attestation, which is verifiable against the cluster's known pubkeys. Multiple peers responding with the same content-addressed state hash that matches the attestation is conclusive evidence of correctness.

**Residual risk.** Three residual risks. First, the recovering node must obtain a trustworthy cluster-state attestation for some frame in the recent past. If the node has been completely offline (no pre-unavailability persistence, no access to gossip overlay during unavailability), bootstrap is harder — it must be admitted as a new node (§11.2 admission gates) rather than as a recovering existing node. Second, the cluster's BFT-supermajority signature on state attestations requires ⌊2n/3⌋+1 honest signatures; if cluster-level Byzantine collusion has occurred (§21.5), the historical attestations themselves may be forged, and state-sync verification produces false confidence. The federation-layer defenses (§21.5) apply. Third, v0.4 implementation will surface details about the state-sync protocol itself (chunking, retries, simultaneous-peer-request strategies) that this prose cannot anticipate; the protocol's correctness depends on the implementation getting these right.

**Operational response.** State-sync requests that fail verification are retried against different peers; persistent verification failures across multiple peers indicate either adversarial coordination (the recovering node should escalate to operator investigation) or stale attestations (the recovering node should obtain fresher attestations from the gossip overlay before retrying). State-sync that succeeds with a verified state is followed by normal lockstep rejoin; the recovering node enters lockstep at the synced frame and proceeds.

### 23.4 Checkpoint tampering

**Attack.** An adversary with disk access modifies a node's `checkpoint.bin` file. When the node starts up (or recovers from a crash) and loads the checkpoint, it uses the modified state as its starting point. The modifications might be subtle (a single byte's owner changed, an issuer's pubkey replaced) or wholesale (a fabricated state from a different cluster substituted entirely).

The attack profile is: the node's hardware and operating system are intact, but the persistence files have been tampered with by an attacker who gained file-system access — through stolen disk images, shared-storage access misconfigurations, or insider threats on the node's host system.

**Defense.** The substrate's defense against checkpoint tampering composes two mechanisms: *immediate detection via supermajority commit* and *cryptographic integrity verification before load* (planned v0.4).

The immediate-detection defense is structural and works in v0.3 today. A node loading a tampered checkpoint enters lockstep with corrupt state. On the next frame's supermajority commit, the node's state hash diverges from the supermajority. The node halts with `MINORITY DIVERGENCE`. The tampering is detected within milliseconds of the node attempting to participate in cluster operation. The node cannot commit corrupt state to the cluster because BFT supermajority requires honest peers' agreement, which the tampered state will not produce.

The cryptographic-integrity defense (v0.4 work) adds proactive verification before the corrupted state ever enters lockstep. The proposed mechanism: at checkpoint write time, the node signs the checkpoint with its own ed25519 key, producing a `checkpoint.sig` file alongside `checkpoint.bin`. At checkpoint load time, the node verifies the signature before deserializing. A tampered checkpoint fails signature verification and is rejected; the node either restores from a backup checkpoint or halts and requires operator intervention.

The cluster's BFT-signed state attestations from the gossip overlay (§21.4) provide an additional offline verification path. A node concerned about checkpoint integrity can compare its checkpoint's content-addressed hash against the cluster's published attestations; mismatches indicate tampering.

**Residual risk.** Three residual risks. First, v0.3 does not sign checkpoints; the immediate-detection defense via supermajority commit is the only defense, and it operates after the tampered state has been loaded. A node that loads tampered state and immediately participates in lockstep will be detected, but the tampered state is briefly in memory before detection. Second, persistence-files-on-shared-storage configurations (NFS-mounted persistence, shared-disk virtualization) are particularly vulnerable to file-system-level tampering and should be avoided in production. Third, encryption-at-rest is not currently part of the substrate's persistence specification (§16.5); production deployments using OS-level full-disk encryption have additional defenses but the substrate doesn't mandate them.

**Operational response.** Checkpoint tampering detected by `MINORITY DIVERGENCE` halt triggers operator investigation. The node's persistence files are examined for evidence of tampering (unexpected modification times, mismatches against backup copies, signature failures if v0.4 signing is in place). The node's host system is examined for compromise. Recovery is via restoring known-good persistence (from backup or from peer state-sync) and rejoining the cluster after the node's host is verified clean.

### 23.5 State-integrity invariants

The substrate's state-management layer is correct iff a small set of invariants hold across normal operation and recovery scenarios. This subsection specifies the invariants. Conforming implementations maintain all of them; implementations violating any are detected via conformance vectors or via cluster-level dissent log accumulation.

**Invariant one: state is content-addressed.** Every state has a unique blake3 hash, computed over the state's canonical serialization. Two nodes with the same state produce the same hash; two nodes with different states (even by a single bit) produce different hashes. The hash is the substrate's primary state-integrity check.

**Invariant two: state advances only via committed frames.** A node's state advances when its cluster commits a frame; never otherwise. There is no manual state mutation, no out-of-band state injection, no state modification outside the lockstep. A state at frame N+1 is the deterministic transition of the state at frame N applied to frame N+1's committed inputs.

**Invariant three: persistence is content-verifiable.** A node can verify its persisted state's authenticity against external attestations — its own signature (v0.4), the cluster's BFT-supermajority signature, or the gossip overlay's published checkpoints. Persistence cannot be silently modified without detection.

**Invariant four: recovery is bounded by known-good attestations.** A recovering node anchors its state to a frame for which it has a verifiable attestation. State-sync that cannot be anchored to a known-good attestation is rejected; the recovering node treats unanchored state as untrusted.

**Invariant five: divergence halts the diverging node.** A node whose state diverges from the supermajority halts. It does not continue operating with corrupt state; it does not attempt to "fix" itself in place; it does not propagate corrupt state to peers. The halt is permanent until operator intervention or v0.4 state-sync recovery.

**Invariant six: dissent-log determinism (per §20.9 invariant seven).** Honest nodes observing the same supermajority tally produce identical dissent log entries. Dissent observations are reproducible across honest nodes, providing a consistent basis for misbehavior identification.

**Invariant seven: state hashes are forward-deterministic.** Given the state at frame N and the canonical-ordered inputs of frame N+1, the state hash at frame N+1 is uniquely determined. Two nodes computing the post-frame state hash from identical inputs and identical starting state produce identical hashes; this is the foundation that the BFT supermajority commit binds to.

These seven invariants compose with the §20.9 lockstep protocol invariants to specify the substrate's state-management correctness. An implementation that maintains all seven §23.5 invariants and all seven §20.9 invariants is correct regardless of which specific data structures, programming language, or operating system it uses. The conformance specification operationalizes the invariants through test vectors that exercise each.

### 23.6 Composition with other categories

State attacks engaged in §23 compose with other categories' defenses in three ways.

**Composition one: state integrity rests on cryptographic primitives (§19) and lockstep protocol invariants (§20).** The content-addressed state hash uses blake3; the BFT-signed state attestation uses ed25519; the deterministic transition that advances state requires the canonical input ordering and floating-point-free arithmetic invariants of §20.9. State integrity is conditional on both lower layers' correctness.

**Composition two: state-sync poisoning bridges to cluster topology (§21).** A recovering node requesting state-sync depends on the gossip overlay's correct propagation of cluster-state attestations; orphaning attacks (§21.4) on the gossip overlay can suppress the attestations the recovering node needs. The composition of §21 and §23 defenses is what makes recovery robust against both per-cluster and federation-level adversaries.

**Composition three: state attacks are typically detected, not prevented.** Unlike cryptographic attacks (§19) which the primitive's security prevents directly, state attacks largely succeed at the moment of corruption — what the substrate provides is *immediate detection* via supermajority commit, not prevention. The defense-in-depth strategy is: detect rapidly, halt the affected node, isolate the corruption, recover via verifiable mechanisms. Recovery, not prevention, is the substrate's primary state-integrity guarantee, and the treatise is honest about this distinction.

The next section (§24) walks economic attacks. Where §23 engaged threats to the substrate's data-integrity infrastructure, §24 engages threats to the substrate's economic-mechanism layer: joule-cost spoofing, economic griefing, fee manipulation, and MEV-equivalent extraction. The composition is that §23 defenses ensure the substrate computes the right state; §24 defenses ensure that the economic incentives operating on the substrate don't produce systematically harmful behavior even when state is correct.
## §24. Economic attacks

The substrate has no native token. There is no substrate-level coin to mint, stake, hold, or speculate on. There is no fee market — transitions cost nothing at the protocol layer. There is no leader auction, no validator set with inflationary rewards, no MEV-extractable transaction ordering. The substrate's design intentionally excludes the economic mechanisms that produce the most-studied attack surface of blockchain systems. This is itself a defense: many economic attacks that plague proof-of-work and proof-of-stake networks have no analog in the substrate because the targets simply do not exist.

But the substrate is not economically inert. Cluster operators bear costs (compute, storage, network, key management, operational labor) and may charge fees at the application layer for their services. Issuers operate businesses that issue cargo-bearing bytes, with their own economic models. Users transact with each other, exchanging cargo of various kinds, with prices and counterparty incentives operating around the protocol. Adversaries can attack these economic mechanisms even when the substrate's protocol layer is incorruptible.

This section walks four attack classes against the four-element rubric (§18.3). The attacks are §24.1 joule-cost spoofing, §24.2 economic griefing, §24.3 fee manipulation, §24.4 MEV-equivalent extraction. §24.5 closes by specifying what the substrate's economic-mechanism layer does *not* attempt to do — the architectural choices that make the substrate economically simpler than its blockchain alternatives, and the costs and benefits of that simplicity.

By the close of §24, the reader should understand that the substrate's economic-attack surface is small but non-zero, that the absences are structural defenses rather than oversights, and that the substrate's economic-mechanism layer composes with the issuer layer (§22) and the social layer (§25) to handle the attacks that protocol-level absence does not eliminate.

### 24.1 Joule-cost spoofing

**Attack.** The substrate's smart byte schema (§8.6) includes a two-part joule cost: an estimated component computed deterministically by the substrate, and an attested component reported by cluster operators based on actual energy measurements (RAPL counters, smart-meter telemetry). An adversary attempts to manipulate the joule cost — inflating it for transitions where the adversary benefits from higher reported costs (justifying higher application-layer fees the cluster operator collects), or deflating it where lower costs benefit the adversary (subsidizing competitors out of the market through artificially-cheap claimed operation).

The attack profile: a cluster operator reports false energy-attestation data, with cryptographic signatures that verify but values that don't correspond to actual measurements. Or: a substrate-using application aggregates joule-cost data across many transitions for compliance reporting (carbon accounting, energy efficiency claims), and an adversary manipulates the aggregate by spoofing the attestation values on transitions they control.

**Defense.** The substrate's defense against joule-cost spoofing is *bifurcated reporting plus external verification*.

The two-part joule cost separates *deterministic estimation* (which all honest nodes compute identically and which is therefore non-spoofable at the protocol layer) from *attested measurement* (which is operator-reported and is therefore spoofable but separately auditable). Applications that need joule-cost data for high-stakes purposes (carbon accounting, regulatory compliance) can use the deterministic estimate as a lower bound and treat the attested measurement as an operator claim subject to verification.

The deterministic estimate is computed by counting protocol-level operations (signature verifications, hash computations, byte-level transitions) and multiplying by published per-operation energy costs. The estimate is *conservative*: it captures the energy the substrate's transition function necessarily consumes, but does not include the energy spent on transport (which varies by network), persistence (which varies by storage), or operational overhead (which varies by deployment). An adversary cannot manipulate the deterministic estimate because every honest node computes the same value.

The attested measurement is *contestable*. A cluster operator's energy attestation is signed by the operator and committed to the cluster's lockstep, but its accuracy is the operator's claim. External verification mechanisms — third-party auditors examining the operator's energy infrastructure, comparing reported attestations against utility-bill data, checking RAPL counter consistency across the operator's hardware — can validate or contest the attestations. The substrate provides the cryptographic substrate for the attestation; external verification provides the truth.

For the aggregation-spoofing variant, the substrate's chain verification (§10) is the structural defense. Aggregate joule-cost claims that span many bytes can be audited by examining each byte's chain individually. An adversary inflating aggregate costs by spoofing per-transition attestations leaves a per-transition trail that auditors can examine.

**Residual risk.** Three residual risks. First, the deterministic estimate's published per-operation energy costs are themselves an attestation that operators rely on; if the substrate's authors publish incorrect per-operation costs, the deterministic estimate is wrong substrate-wide. The treatise's discipline is to publish the per-operation costs with sourced derivations and to update them as hardware evolves; v0.4 specification work. Second, attested measurements are inherently operator-trusted. Applications that demand higher confidence than operator attestation provides must compose layer-2 verification (third-party audit, regulator-issued certifications) on top of the substrate. The substrate cannot eliminate the trust requirement; it can only make the attestation auditable. Third, joule-cost data composes with carbon-accounting frameworks and energy-efficiency standards that themselves have specifications, units, and methodologies; mismatches between the substrate's joule-cost reporting and these external standards may produce data that is internally consistent but externally unusable.

**Operational response.** Joule-cost discrepancies between the deterministic estimate and the attested measurement, or between attested measurements and external evidence, are flagged for operator investigation. Operators with persistently-anomalous attestations are subject to dissent-log accumulation (§14) and potential cluster expulsion (planned v0.4). Applications using joule-cost data for high-stakes purposes (compliance, regulatory reporting) should require third-party audit of attestation accuracy as part of their risk management.

### 24.2 Economic griefing

**Attack.** An adversary submits transitions that are valid at the protocol layer but economically wasteful — transitions designed to consume cluster resources without producing useful work, to drive up operational costs for cluster operators and users, or to degrade application-layer performance through volume-based denial-of-service.

Examples: an adversary submits millions of zero-value transfers (sending one penny of USD-byte to themselves repeatedly), inflating cluster transaction volume without producing economic activity. An adversary submits maximum-size mints up to the issuer's authorization limits, padding the cluster's state with worthless byte allocations. An adversary submits high-frequency transition patterns designed to maximize cluster CPU and disk I/O without producing user-visible value.

**Defense.** The substrate's defenses against economic griefing operate at the *cluster-operator layer* (rate limiting, abuse detection) rather than at the protocol layer.

The substrate's protocol does not distinguish "useful" transitions from "useless" transitions; every cryptographically-valid transition is processed identically. This is intentional: protocol-level filtering of transitions based on economic value would require the substrate to make value judgments about user behavior, which is a layer-2 concern, not a substrate concern.

Cluster operators can implement application-layer rate limiting: limiting the rate of transitions per submitter pubkey, per source IP, per cluster connection, per cargo type. The substrate's transport layer (§17) does not natively support rate limiting, but operators can add it via reverse-proxy infrastructure, application-firewall rules, or custom transport implementations. Rate-limited submitters who exceed their limits are throttled or rejected at the operator's discretion.

Anomaly detection at the operator layer can identify griefing patterns: an unusual concentration of zero-value transitions from a small set of pubkeys, sustained high-frequency activity from a single submitter, mint patterns that exceed reasonable issuer activity. Identified griefers can be subject to operator-level access controls.

For volume-based economic attacks (the adversary's transitions consume disproportionate cluster resources), the substrate's natural economic feedback loop applies: cluster operators charge for their services, and operators experiencing higher griefing volumes either raise their fees, refuse griefing submitters, or accept the operational cost. Honest users gravitate to operators with lower-fee, lower-griefing environments; griefers are economically isolated.

**Residual risk.** Three residual risks. First, the substrate's protocol-level neutrality means any defense against griefing operates above the protocol layer. An adversary determined to grief can find operators willing to accept their volume (perhaps by paying premium application-layer fees) and continue griefing despite other operators' restrictions. Second, the line between "griefing" and "legitimate high-frequency use" is application-defined, not protocol-defined; an operator's anti-griefing rules can be miscalibrated, blocking legitimate users along with griefers. Third, distributed griefing campaigns (many adversarial pubkeys each submitting modest volume, collectively producing griefing-scale traffic) are harder to detect and isolate than concentrated single-source griefing.

**Operational response.** Cluster operators monitor traffic patterns and adjust rate limits, fees, and access controls in response to observed griefing. The substrate's gossip overlay can carry operator-level reputation about persistent griefers, allowing other operators to apply similar restrictions. Application-layer anti-abuse services (CAPTCHAs, proof-of-work challenges for submission, KYC for high-volume users at compliant operators) provide additional layers of defense.

### 24.3 Fee manipulation

**Attack.** Cluster operators charge application-layer fees for substrate access. An adversary attempts to manipulate the fee market — coordinating with other operators to fix prices above competitive levels, predatory pricing to drive competitors out of the market and then raising prices once concentrated, or fee-discrimination that steers high-value users to higher-fee tiers without their awareness.

The attack profile: adversaries operate cluster nodes (or related infrastructure: gateway services, wallet integrations) and exploit the substrate's open-architecture status to extract economic rent through fee manipulation, recreating the institutional middle's rent layer at the cluster-operator tier.

**Defense.** The substrate's defenses against fee manipulation are *transparency and competition* rather than protocol-layer control.

The substrate's protocol does not specify or constrain fees. Cluster operators are free to charge whatever they want for their services; users are free to choose which operators to use. The substrate's pricing market is therefore competitive at the operator layer, not regulated at the protocol layer.

Transparency of fees: operators publish their fee schedules; users can compare operators before choosing where to submit transitions; price differences across operators drive competition. The substrate's protocol-level interoperability (any cluster's bytes can be transferred to any other cluster, subject to cross-cluster transfer protocols when v0.4 ships) means user switching costs are low, increasing competitive pressure on operators.

Substrate-level interoperability: a user dissatisfied with one operator's fees can connect to a different operator with lower fees, with no substrate-level lock-in. The substrate's architecture explicitly avoids the network-effect lock-in that traditional financial intermediaries enjoy — there is no proprietary protocol, no licensed integration, no exclusive access right that prevents users from switching.

For the cartel-and-coordination variant, the substrate's transparency helps: visible fee schedules make coordinated price-fixing easier to detect than opaque industry pricing does. Antitrust enforcement (where it exists, and where regulators care) can investigate detected coordination. The substrate provides the data; regulators provide enforcement.

**Residual risk.** Three residual risks. First, the substrate-level interoperability defense is partial in v0.3: cross-cluster transfer is design-only (§11.3.3, §21.3), so user switching between clusters has friction until v0.4. Second, network-effect dynamics may concentrate cluster-operator market share over time even with substrate-level interoperability — the largest operators benefit from scale economies, customer-acquisition advantages, and integration network effects, leading to natural oligopoly. Third, fee discrimination based on user attributes (large users get lower rates, small users subsidize them; users in less-regulated jurisdictions get different prices than users in heavily-regulated jurisdictions) may emerge naturally and is hard to prevent without protocol-level intervention the substrate explicitly avoids.

**Operational response.** Users monitor fee competition and switch operators when better options emerge. Substrate-monitoring services can publish comparative fee data, helping users make informed choices. Antitrust regulators can investigate suspected price-fixing using publicly-available fee data. The substrate's role is to enable competition, not to prevent specific operators from charging high fees if they can find willing buyers.

### 24.4 MEV-equivalent extraction

**Attack.** Maximum Extractable Value (MEV) attacks in blockchain systems exploit the ability to reorder, insert, or censor transactions to extract value — front-running, back-running, sandwich attacks, censorship-for-pay. The attacks depend on the network having a transaction-ordering decision point (the block producer's choice of ordering) where an adversary can pay to influence the ordering.

The substrate has no equivalent decision point at the protocol layer. The substrate's input ordering is canonical hash-sort (§9.4 step 4), which is deterministic and unmanipulable; no node chooses ordering, no auction determines ordering, no fee market produces priority ordering. The substrate's protocol-level MEV surface is empty.

**Attack adapted to substrate.** An adversary attacks at the *application layer* — the wallets, market-making services, and exchange-equivalent applications that operate on top of the substrate. Application-layer adversaries can front-run users' transitions if they observe the user's intent before submission and can submit competing transitions faster. Cluster operators with privileged visibility into pending submissions before broadcast can attempt to capture MEV-equivalent value at the operator layer.

The attack profile: not protocol-level MEV (which is structurally absent), but application-layer MEV operating through observation and submission timing.

**Defense.** The substrate's defenses against application-layer MEV operate through *protocol-level neutrality* and *layer-2 privacy mechanisms*.

The substrate's protocol-level neutrality means no operator has guaranteed first-look at user submissions. A user submitting a transition to multiple operators simultaneously (gossip-broadcast at the application layer) prevents any single operator from front-running the user — the user's transition reaches all operators effectively at once, and the canonical hash-sort produces the same ordering at every cluster regardless of which operator received it first.

Layer-2 privacy mechanisms (encrypted submission pools, threshold-encrypted commit-reveal flows, zero-knowledge transition proofs) can hide users' intentions from operators until the transitions are committed, eliminating the observation window that application-layer MEV depends on. Several blockchain ecosystems have explored these mechanisms (Flashbots SUAVE, encrypted mempools); the substrate's architecture supports composing them as layer-2 services without protocol changes.

For the operator-level MEV variant (cluster operators with privileged visibility into pending submissions extracting value before broadcast), the substrate's economic-feedback defense applies: users will not use operators with documented MEV-extraction practices. The substrate's transparency makes the practices documentable; user choice handles the rest.

**Residual risk.** Three residual risks. First, layer-2 privacy mechanisms are themselves complex and may have their own attack surfaces; threshold-encrypted commit-reveal protocols have known vulnerabilities (selective abort attacks, free-riding on threshold-decryption participants), and substrate-level deployment of such mechanisms must engage these. Second, application-layer MEV requires application-layer observability of user intentions — wallet operators, exchange platforms, market-making services all have this observability and can extract MEV-equivalent value even with substrate-level neutrality. Third, the substrate's deterministic ordering eliminates protocol-level MEV but does not eliminate the *information asymmetries* between users and operators that economic-attack literature has shown produce predictable patterns of operator-favored extraction.

**Operational response.** Users seeking MEV resistance use layer-2 privacy mechanisms (when available) or submit through anonymized channels (Tor, mix-network) that prevent operators from associating submissions with user identity. Substrate-monitoring services can audit operator behavior for MEV-extraction patterns and publish operator reputation data. Application-layer wallets and integrators can implement MEV-resistant submission strategies (private relayer networks, just-in-time submission to minimize observation windows) on behalf of their users.

### 24.5 What the substrate's economic-mechanism layer does not attempt

The discipline of naming what the substrate is *not* doing economically continues. Several architectural choices are made deliberately to avoid problems that other distributed systems have grappled with at length.

**The substrate has no native token.** No substrate coin exists for users to hold, stake, or speculate on. The cargo-bearing bytes (USD-bytes, joule-bytes, etc.) are the only economic assets in the substrate; they reference external value (dollars, energy, calories) rather than substrate-internal value. The absence eliminates token-related attack surface entirely (no governance-token capture, no validator-stake centralization, no liquidity-pool manipulation), but it also means the substrate cannot self-fund through token issuance — operational sustainability depends on application-layer fees and external funding (issuer fees, operator service charges, donations).

**The substrate has no fee market at the protocol layer.** Transitions cost nothing to submit at the protocol level. This eliminates fee-market attack surface (priority-auction manipulation, fee-spike crisis dynamics, transaction censorship for fee-payment refusal), but it also means that *operators* must choose their fee mechanisms entirely outside the protocol. The protocol provides no built-in fee-collection mechanism, no enforcement of operator pricing, no protocol-level reward for operators' work.

**The substrate has no leader election.** No protocol-level role exists for "the leader of frame N." The lockstep protocol's deterministic input ordering and BFT supermajority commit do not require any single node to be in charge. This eliminates leader-election attack surface (leader bribery, leader-selection manipulation, leader DoS), but it also means the protocol does not benefit from leader-based optimizations (single-leader proposal phases, leader-driven transaction ordering).

**The substrate has no economic incentive layer for operators.** The protocol does not pay operators for their work. Operators must extract value through application-layer fees, by their own design. This eliminates the protocol-incentive attack surface (selfish mining, validator-reward manipulation, MEV-with-protocol-incentive), but it also means operator economics must be solved at the application layer, not within the substrate.

These four absences are the substrate's deliberate architectural simplicity. They eliminate large categories of attack surface that have consumed decades of distributed-systems research. They also mean the substrate's economic mechanisms are *minimal* — operators and applications must build their own economic structures on top, with the substrate providing only the underlying transaction layer. The treatise's claim is that this division of labor is correct: the substrate provides cryptographically-grounded byte-denominated commerce, and economic mechanisms layer on top, not within.

### 24.6 Composition with other categories

Economic attacks compose with other categories' defenses in three ways.

**Composition one: economic attacks frequently bridge from issuer attacks (§22).** Run dynamics, regulatory capture, fee manipulation — all involve economic mechanisms operating through the issuer or operator layer. The substrate's defenses at §22 (transparency, plurality, exit) are the same defenses that handle most §24 attacks; the categorization separates them analytically but the defenses are integrated.

**Composition two: economic attacks compose with social attacks (§25).** Coordinated griefing campaigns, fee-cartel formation, MEV-extraction normalization — these operate at the social layer (community coordination, narrative shaping, contributor influence) as much as at the economic layer. Readers concerned about the substrate's economic-attack surface should read §24 and §25 together.

**Composition three: the substrate's economic absences are the substrate's biggest economic defense.** No token / no fees / no leaders / no protocol-incentive layer — the four absences in §24.5 eliminate categorical attack surface. The treatise's discipline is that the absences are intentional and load-bearing, not oversights to be corrected. Engineers reading §24 should understand that the substrate's economic simplicity is itself a defense, and that the costs of the simplicity (no protocol-level operator funding, no built-in fee collection) are the costs the substrate has chosen to bear.

The next section (§25) walks social attacks. Where §24 engaged attacks operating through economic incentives, §25 engages attacks operating through social, organizational, and reputational mechanisms — contributor takeover, foundation capture, hostile fork-and-rebrand, name-squatting, search-result poisoning. The composition is that §24 defenses are largely architectural (the substrate's protocol-level economic absences); §25 defenses are largely organizational (the substrate's contributor practices, fork-detection, naming-and-discovery hygiene), and the social attacks are the ones the substrate's authors have the least direct control over.
## §25. Social attacks on the substrate itself

The substrate is a protocol, a reference implementation, a treatise, and a community of authors, contributors, operators, and users. The first three are technical artifacts that can be specified, audited, and verified. The fourth is a social structure that cannot be specified or audited in the same way. Adversaries who cannot break the cryptographic primitives, exploit the protocol invariants, or capture the issuers may instead attack the substrate's social and organizational structures — taking over contributor pools, capturing whatever foundation-equivalent stewardship exists, forking the substrate hostilely under deceptive branding, squatting the substrate's names and domains, poisoning search results so users find imitations rather than the real thing.

Social attacks are the most under-specified attack class in most distributed-systems threat models because they are organizational rather than technical. The substrate's threat model engages them anyway, because adversaries with enough resources to attack the substrate at scale will deploy organizational attacks alongside technical ones, and a treatise that ignored the social layer would be incomplete.

This section walks five attack classes against the four-element rubric (§18.3). The attacks are §25.1 contributor takeover, §25.2 foundation capture, §25.3 hostile fork-and-rebrand, §25.4 name-squatting, §25.5 search-result poisoning. §25.6 closes by acknowledging the limits of the substrate's authors' control over the social layer and naming the substrate's structural choices that limit the leverage social attackers can apply.

By the close of §25, the reader should accept that the substrate's social-attack defenses are organizational and procedural rather than cryptographic, that several of these defenses are genuinely partial, and that the substrate's structural choices (open-source licensing, no token, no foundation as a captureable entity) are the load-bearing defenses against the largest class of social attacks.

### 25.1 Contributor takeover

**Attack.** An adversary infiltrates the substrate's contributor pool — the developers, reviewers, and maintainers with commit access to the reference implementation. With enough contributor positions, the adversary can introduce deliberate vulnerabilities into the codebase, weaken existing defenses through subtle modifications, or block defensive pull requests through review-process manipulation. The infiltration may be patient (a single adversary establishing a multi-year track record of legitimate contributions before the malicious commit) or aggressive (a coordinated team of adversaries flooding the contributor pool simultaneously).

The attack profile is well-documented in adjacent open-source ecosystems: the XZ Utils backdoor (CVE-2024-3094, March 2024) was a textbook contributor takeover, with a single adversary spending three years establishing maintainer trust before introducing a backdoor that nearly reached production Debian and Red Hat distributions. Multiple Linux kernel contribution attempts have been detected and rejected through review-process vigilance. The pattern is real, ongoing, and well-resourced.

**Defense.** The substrate's defenses against contributor takeover operate through *multi-maintainer review*, *reproducible builds*, and *implementation diversity*.

Multi-maintainer review: every change to the reference implementation requires review and signoff from at least two independent maintainers, with explicit cryptographic signatures (signed commits, signed tags) bound to the maintainer's known identity. Single-maintainer commits are blocked by repository-level branch protection. The XZ Utils backdoor succeeded in part because the original maintainer's solo workflow had no second-reviewer requirement; the substrate's reference implementation's workflow does.

Reproducible builds: the reference implementation's release artifacts are built from source by multiple independent build systems, producing byte-identical outputs. A maintainer attempting to slip a backdoor into a released binary that doesn't match the source code is detected by reproducible-build verification. The Tor Project, Bitcoin Core, and several Linux distributions have established reproducible-build infrastructure; the substrate adopts the same practices.

Implementation diversity: the substrate's protocol is specified at the conformance-vector level (§20.9, §23.5 invariants) such that multiple implementations in different languages can be developed and tested against the same specification. A backdoor in the Rust reference implementation does not propagate to a Python implementation or a Go implementation; users running a non-Rust implementation are immune to Rust-specific backdoors. The substrate's authors actively encourage alternative implementations and provide the conformance vectors that make them verifiable.

The substrate's repository hosting (GitHub at v1.0, with mirrors on alternative platforms) is itself a single-point-of-failure that must be hardened. The reference implementation's release process includes signing every release tag with maintainer GPG keys; any release artifact whose signature does not verify is rejected. Mirror repositories on Codeberg, Sourcehut, and self-hosted Git servers provide redundancy if the primary platform is compromised.

**Residual risk.** Three residual risks. First, multi-maintainer review depends on maintainers having genuinely independent judgment; an adversary who can influence multiple maintainers simultaneously (through bribery, social engineering, or coordinated infiltration) can defeat the requirement. Second, reproducible builds verify that release artifacts match source code, but they do not verify that the source code itself is benign — a subtle backdoor introduced through legitimate-looking PRs that pass review will be in both the source and the reproduced binary. Third, implementation diversity is currently aspirational rather than actual; v0.3 has only the Rust reference implementation, and second-implementation work is community-dependent. The substrate's claim is conditional on the second-implementation work happening; if it doesn't, the substrate has only one implementation and its security is monoculture-bounded.

**Operational response.** Contributor takeover detected after the fact (post-commit anomaly review, security audit findings, community-reported suspicions) triggers commit-history forensic analysis, code review of recent changes by the suspect maintainer, and possible reversion of affected commits. The repository's branch-protection rules can be tightened to require additional reviewers for commits from probationary contributors. Legal action against confirmed adversaries is jurisdiction-dependent and slow; the substrate's primary response is technical (revert, audit, patch) rather than legal.

### 25.2 Foundation capture

**Attack.** Open-source projects often have foundation-equivalent organizational entities — non-profits that hold trademarks, manage domain registrations, organize conferences, distribute grants, and represent the project in legal and policy contexts. Adversaries attempt to capture these entities by getting their representatives onto governing boards, redirecting grant flows to favored contributors, manipulating trademark policy to constrain alternative implementations, or using legal authority to suppress critics.

The attack profile: an adversary establishes legitimate-looking participation in the foundation, builds reputation over months or years, and uses positional authority to shape the substrate's direction in ways that benefit the adversary. The adversary may be a state actor, a corporate competitor, an institutional incumbent threatened by the substrate, or a wealthy individual with personal motives.

**Defense.** The substrate's defense against foundation capture is *not having a foundation to capture*.

The substrate v1.0 has no foundation, no non-profit entity, no centralized governance organization. The reference implementation is hosted at a public Git repository (with mirrors). The treatise is available under open-content licensing. The substrate's name is not trademarked at the protocol level. There is no entity that can be captured because there is no entity at all.

This is not an oversight. The substrate's authors have considered foundation creation and rejected it for v1.0. The reasoning: a foundation creates a single point of failure for capture attacks. Bitcoin's lack of a controlling foundation is widely credited as a structural defense against capture; Ethereum's foundation has been the target of repeated influence campaigns. The substrate adopts the Bitcoin pattern: protocol coordination through informal community processes, decision-making through implementation reality (whatever the reference and conforming implementations actually do is what the substrate is), and governance through fork dynamics (if the community disagrees with the reference implementation's direction, anyone can fork).

The cost of having no foundation is real: no centralized funding for development, no legal entity to defend trademarks or copyrights, no formal mechanism for resolving disputes between contributors. The substrate accepts these costs because the alternative — a foundation that can be captured — produces worse failure modes.

For functions a foundation would normally perform (grants for development, trademark defense, legal representation), the substrate relies on *distributed organic mechanisms*: individual donations to specific contributors or working groups, community-led trademark vigilance, contributor self-organization for legal questions. These mechanisms are messier and less efficient than foundation-mediated alternatives, but they are also harder for any single adversary to capture.

**Residual risk.** Three residual risks. First, the absence of a foundation means the substrate cannot easily defend trademark or copyright claims against bad-faith actors. An adversary who registers "smart byte substrate" as a trademark in their jurisdiction can attempt legal action against the actual substrate's authors and operators. The defense is preemptive trademark filing by community members in major jurisdictions and the documentation of prior art (this treatise itself, with its publication date, serves as prior art). Second, organic distributed funding may produce uneven contributor support — popular contributors get well-funded, less-visible contributors get neglected — leading to development priorities that don't reflect the substrate's actual needs. Third, the substrate's no-foundation choice depends on the community being capable of self-organization; if the community fragments or fails to coordinate, the absence of formal coordination structure is a liability.

**Operational response.** When trademark or naming disputes arise, the community responds through public documentation of the substrate's history, prior art, and existing usage patterns. When funding gaps appear, individual contributors and donors fill them through direct support. When legal questions arise, contributors consult their own legal counsel; the substrate's authors do not provide centralized legal guidance because there is no centralized authority to provide it.

### 25.3 Hostile fork-and-rebrand

**Attack.** An adversary forks the substrate's reference implementation, modifies it to serve adversarial purposes (introducing backdoors, removing privacy features, adding mandatory KYC, redirecting issuer-registry control to adversarial entities), and rebrands the result to compete with the legitimate substrate. The hostile fork claims compatibility with or improvement over the original, attempts to capture market share through marketing or regulatory advantage, and may eventually attempt to displace the legitimate substrate as "the" smart byte substrate.

The attack profile is well-known in cryptocurrency: numerous Bitcoin forks have attempted to position themselves as the "real" Bitcoin (Bitcoin Cash, Bitcoin SV, etc.), often with substantial marketing budgets and confused user populations. The substrate, being open-source, can be forked freely; the question is whether the legitimate substrate can be distinguished from hostile forks.

**Defense.** The substrate's defenses against hostile fork-and-rebrand operate through *conformance verification* and *protocol-level interoperability boundaries*.

Conformance verification: any implementation claiming to be the substrate must pass the substrate's conformance test vectors (§20.9, §23.5 invariants). Implementations that fail conformance are not the substrate, regardless of their branding. Hostile forks that introduce protocol-incompatible modifications fail conformance and are detectable as non-substrate. Hostile forks that modify only the application layer (wallets, integrations, operational tools) but maintain protocol conformance are technically still substrate implementations, but their non-protocol modifications can be identified and disclosed by community review.

Protocol-level interoperability boundaries: the substrate's bytes are content-addressed and chain-verified. A hostile fork operating its own clusters cannot transfer its bytes into legitimate substrate clusters (cross-cluster transfer protocols verify that the source cluster is part of the legitimate substrate's federation, identified through the gossip overlay's reputation history). The hostile fork's bytes remain confined to the hostile fork's clusters; users who want to interact with the legitimate substrate must use the legitimate implementation.

Reputation continuity: the legitimate substrate's reference implementation has a continuous commit history, a public maintainer set, conference appearances and academic citations, and an established treatise (this document). A hostile fork attempting to displace the legitimate substrate must establish equivalent reputation — which is expensive and slow — or rely on user confusion. Community education and documentation (clear "the legitimate substrate is the one at this URL with this maintainer set") helps users distinguish.

**Residual risk.** Three residual risks. First, conformance verification is only as good as the conformance vectors; an adversary who exploits conformance-vector gaps (test scenarios the vectors don't cover) can produce a hostile fork that passes conformance while still being adversarial. The substrate's authors must maintain the conformance vectors as a security-critical artifact. Second, regulatory or business pressure can produce situations where users *prefer* a hostile fork because it complies with regulations the legitimate substrate refuses to comply with — recreating the institutional middle's compliance environment within the substrate's nominal architecture. Third, marketing and user-acquisition campaigns operate at scales that small contributor communities cannot match; a well-funded hostile fork can capture significant user attention before the community's response materializes.

**Operational response.** Hostile forks identified by the community are documented publicly (a "known forks" page maintained by the substrate's contributors, listing each fork's deviations from conformance and the operational risks of using it). Conformance vectors are updated to detect specific hostile-fork modifications when they are identified. The legitimate substrate's authors make no claim to legal authority over forks; the substrate is open-source and forks are permitted by license. The defense is informational, not legal.

### 25.4 Name-squatting

**Attack.** An adversary registers domain names, social-media handles, package-registry namespaces, and other naming resources associated with the substrate, with the goal of either monetizing the squatting (forcing the substrate's authors to buy back the names at high prices) or impersonating the substrate to mislead users. Squatted resources may serve malicious content (phishing pages, malware downloads, fake documentation that omits security features).

**Defense.** The substrate's defenses against name-squatting are *preemptive registration*, *cryptographic identity*, and *community vigilance*.

Preemptive registration: substrate-related domain names (smartbyte.substrate, smart-byte-substrate.org, similar variants), package-registry namespaces (npm "smart-byte-substrate", crates.io "smart-byte-substrate", PyPI "smart-byte-substrate"), and social-media handles (Twitter/X, Mastodon, Bluesky, GitHub organization names) should be registered by the substrate's contributors before public launch. The cost is modest (a few hundred dollars per year for domains, free for most package registries) and the defensive value is significant.

Cryptographic identity: the substrate's authoritative communication channels — release announcements, security advisories, maintainer signatures — use cryptographic signing. A user verifying a security advisory's signature against published maintainer pubkeys can confirm authenticity regardless of which domain or platform delivered the message. Squatted domains delivering unsigned or invalidly-signed content are identifiable.

Community vigilance: substrate contributors and users monitor naming resources for suspicious registrations and report findings to community channels. Common naming-attack patterns (typosquatting, homograph attacks using Unicode lookalikes, sub-domain mimicry) are documented for user awareness.

**Residual risk.** Three residual risks. First, preemptive registration has practical limits — the substrate cannot register every plausible domain, every package-name variant, every possible social-media handle in every jurisdiction. Some squatting will occur. Second, cryptographic identity defenses depend on users actually verifying signatures, which most users do not do. Tool-level integration (signed package managers that verify automatically, signed-release verification in deployment tooling) reduces the user burden but is not universal. Third, social-media platforms have inconsistent name-recovery policies; a squatted handle on one platform may be unrecoverable while another platform might honor a substrate-related claim.

**Operational response.** Identified squatting attempts are documented publicly. Cryptographic verification is standardized in the substrate's release tooling so that users can detect impersonation attempts automatically. Community communication channels are documented (with cryptographic verification) so users have a clear "this is the legitimate substrate's official channel" reference.

### 25.5 Search-result poisoning

**Attack.** An adversary manipulates search-engine results so that users searching for "smart byte substrate" or similar queries find adversarial content — hostile forks (§25.3), squatted domains (§25.4), misleading documentation, or outright disinformation about the substrate. Search-result manipulation can be SEO-based (creating large volumes of substrate-mentioning content that links to adversarial destinations), advertising-based (paying for top-of-results ad placement on substrate-related queries), or platform-based (exploiting search-engine policies that penalize the legitimate substrate while elevating alternatives).

The attack is particularly effective during the substrate's early adoption period, when authoritative resources are still establishing themselves and adversaries can preempt the legitimate substrate's search ranking.

**Defense.** The substrate's defenses against search-result poisoning operate through *authoritative link infrastructure*, *direct-discovery channels*, and *community SEO*.

Authoritative link infrastructure: the substrate's reference implementation, treatise, and authoritative documentation all live at well-known canonical URLs that other authoritative sources (conference papers, GitHub README links, related-project documentation) link to consistently. Inbound links from authoritative sources improve search ranking organically; the substrate's authors cultivate these links through normal academic and open-source-community participation.

Direct-discovery channels: users seeking the substrate are encouraged to find it through trusted sources (academic papers, well-known security mailing lists, established open-source aggregators) rather than through search-engine queries. The substrate's release announcements include canonical URLs that users should bookmark; subsequent updates use the same canonical URLs rather than introducing new ones.

Community SEO: the substrate's contributors maintain documentation, blog posts, and community forum content that rank organically for substrate-related queries. Cross-linking between contributor sites builds the link graph that search engines use to identify authoritative content. The substrate's authors do not engage in paid SEO or link-buying schemes (which are themselves potentially compromising) but they also do not abstain from organic SEO best practices.

**Residual risk.** Three residual risks. First, search-engine algorithms are opaque and can change without warning; the substrate's organic ranking depends on the engines' continued willingness to surface authoritative content over manipulated content. Second, paid advertising can outrank organic results, particularly for high-value queries; an adversary willing to spend on ads can ensure their content appears before the legitimate substrate's content. Third, search-engine providers are themselves entities that can be pressured (by states, by large advertisers, by their own policies) to demote the substrate's content; if Google decides to remove the substrate from search results, the substrate's discovery via Google fails entirely. This is a §27 (physical attacks) concern as well as a §25 concern.

**Operational response.** Substrate users who detect search-result poisoning report it through community channels. Documentation is updated to provide direct links and to warn about the specific impersonation patterns observed. Long-term, the substrate's reputation builds through organic citation (by legitimate publications, conferences, and adjacent open-source projects) that is harder to displace through paid manipulation.

### 25.6 The limits of the substrate's authors' control

A meta-observation worth naming explicitly. Social attacks on the substrate operate at the layer where the substrate's authors have the least direct control. Cryptographic primitives (§19) are mathematically constrained. Protocol invariants (§20) are auditable. Cluster topology (§21) is operationally bounded. Issuer behavior (§22) operates in legal and regulatory frameworks. State integrity (§23) is technically verifiable. Economic mechanisms (§24) operate in market conditions.

Social structures are different. They depend on community formation, individual participation, organizational coordination, and reputational dynamics — none of which can be specified in conformance vectors or enforced by protocol logic. The substrate's defenses at the social layer are organizational practices (multi-maintainer review, signed releases, conformance vectors), structural choices (no foundation, open licensing, no token), and community vigilance — all of which are necessary but none of which is sufficient on its own.

The substrate's structural choices that limit social-attack leverage:

**No token.** The substrate has no native asset to manipulate, capture, or use as a leverage point. Adversaries cannot acquire substrate-tokens to gain governance power because there are no substrate-tokens.

**No foundation.** The substrate has no centralized organizational entity to capture, infiltrate, or sue. Adversaries seeking to apply organizational pressure must do so against decentralized contributors, which is harder.

**Open licensing.** The substrate is dual-licensed under Apache-2.0 and MIT. Adversaries cannot leverage license restrictions against legitimate users; users cannot leverage license restrictions against adversaries either, but the symmetry favors free use over capture.

**Conformance verification.** The substrate's identity is the conformance vectors. Implementations that pass conformance are the substrate; implementations that fail are not. Adversaries cannot rebrand non-substrate implementations as the substrate without passing the same vectors that the legitimate implementation passes.

**Cryptographic continuity.** The substrate's authoritative communications use cryptographic signing. Adversaries cannot impersonate the substrate's authors without compromising their keys, and the multi-maintainer review structure makes single-key compromise insufficient for substrate-wide impersonation.

These five structural choices compose into a substrate that is harder to socially attack than alternative architectures with tokens, foundations, restrictive licenses, or centralized authority structures. The choices are not perfect defenses, but they raise the cost of social attacks substantially and limit the leverage adversaries can apply.

The honest disclosure: social attacks are the threat class the substrate's authors are most worried about over the long term. Cryptographic primitives are conservative for decades. Protocol invariants are auditable indefinitely. Social structures are fragile, depend on continued community engagement, and can be eroded slowly enough that defenders may not notice until significant damage is done. The substrate's structural choices help, but the substrate's social health requires ongoing community work that the substrate's authors cannot fully control.

### 25.7 Composition with other categories

Social attacks compose with other categories' defenses in three ways.

**Composition one: social attacks frequently bridge from issuer attacks (§22) and economic attacks (§24).** Foundation capture, contributor takeover, and search-result poisoning often operate alongside regulatory capture (§22.3), fee manipulation (§24.3), or governance social engineering (§22.2). Adversaries with resources for one category typically deploy across multiple categories simultaneously. The defenses must be similarly integrated.

**Composition two: social attacks compose with legal attacks (§26) and physical attacks (§27).** A state-level adversary attacking the substrate may use social attacks (foundation capture, contributor pressure) alongside legal attacks (operator obligation, securities classification) and physical attacks (operator coercion, infrastructure seizure). The substrate's defenses across §25, §26, §27 are interdependent.

**Composition three: social-layer defenses are organizational, not technical.** Unlike the cryptographic and protocol defenses of §19-§23, social-layer defenses depend on community practices, organizational hygiene, and reputational dynamics. The substrate's authors maintain the technical defenses; the substrate's community maintains the social defenses. The treatise's discipline is to name this division of labor honestly: the substrate is more than a protocol, and its security depends on more than protocol correctness.

The next section (§26) walks legal attacks. Where §25 engaged threats operating through social and organizational mechanisms, §26 engages threats operating through legal and regulatory mechanisms — securities classification, transaction taxation, operator obligations, contract-law claims, and intellectual-property attacks. The composition is that §25 defenses depend on community-level coordination; §26 defenses depend on jurisdictional plurality and protocol-level absence of regulatable features. Together, §25 and §26 cover the non-technical attack surface that adversaries use when they cannot break the substrate technically.
## §26. Legal attacks

The substrate operates in legal environments. Cluster operators are organized under specific jurisdictions' laws. Issuers are typically regulated entities (stablecoin providers under banking law, energy producers under utility regulation). Users transact across borders subject to taxation, anti-money-laundering, and securities regulation. The substrate's protocol-level neutrality cannot insulate the substrate's participants from the legal frameworks they operate within; legal attacks are real, jurisdictionally varied, and increasingly sophisticated.

This section walks five attack classes against the four-element rubric (§18.3). The attacks are §26.1 securities classification, §26.2 transaction taxation, §26.3 operator obligation, §26.4 contract-law claims, §26.5 intellectual-property attacks. §26.6 closes by acknowledging the substrate's structural choices that limit legal-attack leverage and naming the jurisdictional plurality the substrate depends on.

The treatise does not provide legal advice. The substrate's authors are not lawyers; the engagements below describe attack patterns and structural defenses, not legal opinions about specific jurisdictions or specific operators. Substrate adopters in any jurisdiction must consult their own counsel for compliance with applicable laws.

By the close of §26, the reader should accept that the substrate's legal-attack surface is real and partially defensible, that the substrate's "protocol not service" framing is load-bearing for limiting legal exposure, and that several of the substrate's most consequential defenses (jurisdictional plurality, multi-issuer architecture, layer-2 separation) operate at the legal layer as well as the technical layer.

### 26.1 Securities classification

**Attack.** A regulator classifies the substrate's bytes — or specific cargo classes within them — as securities under their jurisdiction's securities law. With securities classification, the substrate's bytes become subject to registration requirements, disclosure obligations, anti-fraud provisions, and intermediary-licensing rules. Issuers face securities-registration obligations they cannot meet without becoming regulated broker-dealers; cluster operators face exchange-registration obligations; users face investor-accreditation requirements.

The U.S. SEC has applied the Howey test (SEC v. W.J. Howey Co., 328 U.S. 293, 1946) to crypto-asset offerings since the 2017 DAO Report and has pursued enforcement against numerous projects on securities grounds. The EU's Markets in Crypto-Assets Regulation (MiCA, in force since 2024) provides a more structured framework but imposes significant licensing requirements on most crypto-asset service providers. Other jurisdictions (Japan, Singapore, UAE) have variously stricter or more permissive frameworks.

The attack profile: a regulator reaches the substrate's authors, issuers, or operators with enforcement actions claiming securities violations, with the goal of either forcing compliance (registration, licensing, restricted access) or shutting down substrate operations within the regulator's jurisdiction.

**Defense.** The substrate's structural defenses against securities classification operate through *cargo-class neutrality* and *non-investment-product framing*.

The substrate's bytes carry cargo. The cargo is what determines regulatory status. A USD-byte represents a claim on dollar reserves held by an issuer; whether this constitutes a security depends on the issuer's structure (a regulated stablecoin provider's USD-bytes face different regulatory treatment than an unregulated startup's USD-bytes). A joule-byte represents a claim on energy production; whether this is a security depends on whether the joule-byte's holder expects investment returns from the issuer's efforts (the Howey test's "expectation of profits derived from the efforts of others" prong) or simply represents a unit of energy purchase. A kcal-byte representing already-produced food is not a security under any reasonable reading; it's a food purchase.

The substrate's protocol layer does not produce securities. The protocol layer produces *bytes* — cryptographically-provenanced units of arbitrary cargo. Whether any specific cargo class is a security is an issuer-and-cargo-class question, not a substrate-layer question. The substrate's authors do not market, sell, or distribute investment products; they ship a protocol and a reference implementation under open-source licensing.

For cargo classes that *are* securities under applicable law (some kinds of governance tokens, some kinds of fractional asset claims), the appropriate response is for issuers to register with relevant regulators, comply with disclosure requirements, and limit distribution to qualified parties. The substrate's protocol does not prevent compliance; it provides the cryptographic transaction layer underneath whatever compliance regime the issuer adopts.

**Residual risk.** Three residual risks. First, regulatory definitions evolve. A regulator with sufficient creativity can argue that almost any cargo class is a security if it benefits from any "common enterprise" or "expectation of profits"; the substrate's cargo-class diversity does not by itself prevent expansive regulatory readings. Second, the substrate's authors and reference-implementation maintainers may be pursued under accomplice or aiding-and-abetting theories even if they do not directly issue or distribute regulated cargo; this has happened in adjacent crypto enforcement cases — Alexey Pertsev was convicted in Dutch court in May 2024 (sentenced to 64 months, appealing) on a theory that Tornado Cash itself executed money laundering, while Roman Storm was convicted in U.S. federal court in August 2025 on the unlicensed-money-transmission charge but received hung-jury outcomes on the more serious money laundering and sanctions charges. Third, unregistered offerings of substrate-issued cargo by issuers operating in regulated jurisdictions create securities violations regardless of the substrate's protocol-level neutrality; the issuers bear the legal exposure, but reputational damage to the substrate is real.

**Operational response.** Issuers facing securities classification typically respond by either registering and complying (becoming regulated entities with significant operational overhead) or restricting distribution to non-U.S./non-EU users (geographic exclusion through application-layer KYC and access controls). Substrate-level operators in regulated jurisdictions may face exchange-registration obligations if they facilitate trading; the substrate's protocol-level absence of trading mechanisms (no order books, no matching engines at the protocol layer) is helpful but not dispositive — application-layer trading services on top of the substrate may still trigger exchange registration. Users in regulated jurisdictions consult their own legal counsel about which substrate cargo classes they can hold or transact in compliantly.

### 26.2 Transaction taxation

**Attack.** Tax authorities classify substrate transitions as taxable events — every transfer of cargo-bearing bytes treated as a sale or exchange triggering capital-gains calculation, every cross-cluster transfer as a realization event, every micropayment as a separate taxable transaction. Compliance becomes operationally infeasible at substrate scale: a user making thousands of micropayments per year faces tax-reporting obligations that overwhelm the underlying transaction value.

The U.S. IRS treats cryptocurrency transactions as taxable events for federal income tax purposes (IRS Notice 2014-21, expanded by the 2024 Form 1099-DA reporting requirements). The U.K. HMRC has similar policies. Many jurisdictions are actively expanding their tax-reporting requirements for crypto-asset transactions. The reporting burden, even when each transaction's tax liability is small, can be prohibitive.

The attack profile is not adversarial in the conventional sense — tax authorities are not seeking to harm the substrate — but the cumulative effect of comprehensive transaction taxation can make substrate use operationally untenable for users in jurisdictions with aggressive enforcement.

**Defense.** The substrate's defenses against transaction-taxation overreach operate through *cargo-class differentiation* and *layer-2 reporting tools*.

Cargo-class differentiation: not every cargo class triggers the same tax treatment. USD-byte transfers between two users may be treated as currency transfers (potentially with no realized gain or loss if the USD-byte's value is constant) rather than as sales of property. Joule-byte transfers may be treated as energy purchases (deductible business expenses for businesses, not capital-gains events). Kcal-byte transfers may be treated as food purchases. The substrate's cargo-neutral architecture allows users to compose transactions that match the tax treatment they need; the substrate does not impose a single tax treatment across all cargo.

Layer-2 reporting tools: the substrate's content-addressed history (§10) provides complete, auditable records of every transaction a user has participated in. Tax-preparation tools operating on top of the substrate can produce comprehensive reports — categorizing transactions by cargo class, computing realized gains and losses where applicable, generating jurisdiction-specific tax forms. The substrate provides the data; layer-2 services provide the compliance interface.

For micropayment-scale transactions, several jurisdictions provide de minimis exemptions (the U.S. allows up to $200 in personal-use crypto transactions per transaction without reporting, though this varies). The substrate's transaction-volume capacity does not change the applicability of these exemptions; users transacting below the de minimis threshold remain unaffected.

**Residual risk.** Three residual risks. First, the U.S. 1099-DA reporting regime (effective 2025-2026) requires certain crypto-asset brokers to report user transactions to the IRS, with penalties for non-reporting. Substrate operators offering broker-like services in U.S. jurisdiction must comply or restrict access. Second, jurisdictions with more aggressive tax enforcement (some EU member states, India, China) treat all crypto-asset transactions with high scrutiny; users in these jurisdictions face high compliance costs. Third, the substrate's transparency (every transition visible on the chain) makes evasion harder than traditional cash transactions; users seeking transaction privacy must use layer-2 anonymizing tools, which themselves face increasing regulatory pressure.

**Operational response.** Users consult tax-preparation tools and tax professionals for compliance with their jurisdiction's reporting requirements. Layer-2 services may offer cargo-class-specific tax reporting (separate reports for stablecoin transfers, energy purchases, food purchases) that simplify compliance. Users in jurisdictions with high compliance burden may shift to cargo classes with lower tax friction (joule-bytes for energy purchases rather than USD-bytes for the equivalent dollar value).

### 26.3 Operator obligation

**Attack.** Regulators impose obligations on substrate cluster operators — anti-money-laundering reporting, know-your-customer requirements, sanctions compliance, transaction monitoring, suspicious-activity reporting. Operators face the choice of complying (becoming regulated financial institutions with significant overhead) or restricting their services to non-regulated jurisdictions or non-regulated user classes.

The FATF Travel Rule (Recommendation 16, expanded to crypto-assets in 2019) requires virtual-asset service providers to collect and transmit originator and beneficiary information for transactions above a threshold. The EU's Transfer of Funds Regulation (in force June 2023) imposes parallel requirements at lower thresholds. The U.S. Bank Secrecy Act and OFAC sanctions impose reporting and screening obligations on any operator deemed a "financial institution" or "money services business."

The attack profile: regulators classify substrate operators as virtual-asset service providers, money services businesses, or equivalent regulated entities, imposing operational costs that small operators cannot absorb and forcing consolidation around large, regulated, capture-friendly operators.

**Defense.** The substrate's defenses against operator-obligation overreach operate through *protocol-not-service framing* and *jurisdictional plurality*.

Protocol-not-service framing: the substrate is a protocol specification and a reference implementation, distributed under open-source licenses. The substrate's authors do not operate clusters, do not facilitate transactions, do not provide custody, do not execute trades. Cluster operators are independent entities; the substrate's authors do not control them, profit from them, or direct their compliance. This separation is structurally important: it limits the substrate's authors' regulatory exposure while allowing operators to make their own compliance decisions.

The protocol-not-service distinction has been litigated in adjacent crypto contexts with mixed but instructive results. Bitcoin's authors have largely escaped direct regulatory exposure because no single entity operates Bitcoin's network. Ethereum's foundation has had more regulatory exposure because of the foundation's coordinating role. The Tornado Cash precedent is particularly relevant and has evolved across jurisdictions: the U.S. Treasury sanctioned the Tornado Cash smart contracts in August 2022 (the first time OFAC sanctioned smart contract addresses directly); the U.S. Court of Appeals for the Fifth Circuit ruled on November 26, 2024 that immutable smart contracts do not qualify as "property" under federal law and that OFAC exceeded its authority; OFAC lifted the sanctions in March 2025; Pertsev was nonetheless convicted in Dutch court in May 2024 (appealing); Storm was convicted in U.S. federal court in August 2025 on unlicensed-money-transmission grounds but received hung-jury outcomes on the more serious charges, and the U.S. DOJ issued an "Ending Regulation by Prosecution" memo in April 2025 signaling reduced criminal-enforcement appetite for protocol developers. The substrate's authors aim for the Bitcoin pattern — code released under open license, no foundation, no centralized service offering — to maximize the protocol-not-service positioning, though the legal effectiveness of the positioning is jurisdiction-dependent and the precedent landscape continues to evolve.

Jurisdictional plurality: substrate operators distributed across multiple jurisdictions provide redundancy against single-jurisdiction enforcement. An operator in the U.S. complying with FATF Travel Rule requirements does not prevent an operator in Switzerland from operating with different compliance choices. Users seeking to avoid Travel Rule reporting can transact through operators in jurisdictions where the rule does not apply, with the legal risks of doing so depending on the user's own jurisdiction.

The substrate's protocol-level absence of operator-friendly compliance features (no built-in KYC integration, no native transaction monitoring, no protocol-mandated reporting) is honest about what the substrate does not provide. Operators wanting these features must implement them at the application layer, which both limits universality (compliance is operator-specific, not substrate-wide) and protects the substrate's protocol-level neutrality.

**Residual risk.** Three residual risks. First, the protocol-not-service distinction is legally tenuous in some jurisdictions and the precedent landscape is unsettled. The Pertsev conviction (Dutch court May 2024) shows that European jurisdictions may pursue protocol authors directly; the Storm verdict (August 2025) shows the U.S. theory has narrowed to the unlicensed-money-transmitter charge while excluding the broader money-laundering and sanctions theories; the Fifth Circuit's November 2024 ruling and the OFAC delisting in March 2025 represent partial wins for the protocol-not-service framing. The substrate's authors' jurisdictional choices and operational practices affect their direct exposure, and the legal landscape is changing fast enough that v1.0-era positioning may not match v2.0-era enforcement. Second, jurisdictional-plurality defense fails if regulators coordinate globally. The FATF's mutual evaluation processes increasingly pressure jurisdictions to harmonize crypto regulations; a U.S./EU/Japan/UK alignment on substrate operator obligations could dramatically shrink the available operator set. Third, well-meaning compliance choices by individual operators (offering reporting tools, implementing KYC, adopting Travel Rule wrappers) can normalize compliance expectations and pressure non-compliant operators by competitive comparison rather than by regulatory mandate.

**Operational response.** Operators in regulated jurisdictions typically register as appropriate (money services businesses, virtual-asset service providers, or equivalent), implement required compliance measures, and absorb the operational costs. Operators preferring to avoid regulation operate in less-regulated jurisdictions, restricting their user base to those willing to use offshore operators. Users navigate the operator landscape based on their own compliance needs and risk tolerances. The substrate's role is to make multiple operator choices available; the substrate does not prescribe specific compliance regimes.

### 26.4 Contract-law claims

**Attack.** Adversaries pursue contract-law claims against substrate operators, issuers, or even authors, arguing that substrate participation creates implicit contracts that have been breached. Examples: a user whose bytes are lost due to a software bug sues the reference implementation's authors for breach of implied warranty. An issuer whose business is harmed by substrate-level changes sues the authors for tortious interference. A regulator argues that the substrate's documentation creates promises that constitute consumer contracts subject to consumer-protection law.

The attack profile: contract-law claims convert technical and architectural choices into legal liabilities, with damages potentially exceeding any rational scaling of the substrate's authors' actual involvement. Open-source software has historically benefited from license disclaimers (the "AS IS" clause in MIT/Apache licenses) but these protections vary across jurisdictions and may not survive aggressive contract-law theories.

**Defense.** The substrate's defenses against contract-law claims operate through *open-source license disclaimers*, *no-promises framing*, and *contributor-individual liability containment*.

Open-source license disclaimers: the substrate is dual-licensed under Apache-2.0 and MIT. Both licenses include broad disclaimers of warranty ("AS IS"), explicit limitations of liability, and disclaimers of fitness for any particular purpose. The treatise and the reference implementation both bear these disclaimers prominently. Users accepting the substrate accept the licenses; the disclaimers' enforceability varies by jurisdiction but provides substantial legal protection in most.

No-promises framing: the treatise is careful to describe what the substrate *does* and what it *does not provide*, with consistent acknowledgment of partial freedoms (§6.2), unimplemented v0.4 work (§11.5, §15.5, §16.5, §21.6, §23.4), and structural limits. The substrate does not promise the institutional middle's services; it does not guarantee specific outcomes; it does not warrant specific cargo classes for specific use cases. The treatise's discipline of explicit non-promises limits the surface area for "you promised X and didn't deliver" claims.

Contributor-individual liability containment: the substrate's contributor model is open and distributed. Individual contributors take responsibility for their own contributions; there is no centralized entity (no foundation, §25.2) that bears collective liability for the project. This limits the targets for contract-law claims to individual contributors, who can be defended on individual-licensee grounds rather than as collective project sponsors.

**Residual risk.** Three residual risks. First, license disclaimers are not universally enforceable. Some jurisdictions (notably Germany under § 309 BGB, and parts of Brazilian consumer law) limit the enforceability of broad warranty disclaimers; users in these jurisdictions may have residual contract claims that the licenses cannot disclaim. Second, contributor-individual liability containment depends on contributors actually being individuals; a contributor working through an LLC or corporate entity may inherit institutional liability that broader claims can reach. Third, the substrate's reference implementation, treatise, and documentation are *content* that may bear obligations beyond software licensing — content that could be argued to constitute professional advice (financial, technical, legal), with corresponding professional-liability exposure for the authors.

**Operational response.** Substrate authors maintain prominent disclaimer notices in the treatise, in the reference implementation, and in published documentation. Authors who wish to limit their personal exposure may organize their substrate-related work through limited-liability entities that bear the work's risks rather than the individual authors. Users with potential contract claims are encouraged to pursue them through individual operator relationships (where commercial agreements actually exist) rather than through the substrate's authors (who have no commercial relationship with users).

### 26.5 Intellectual-property attacks

**Attack.** Adversaries pursue intellectual-property claims to constrain the substrate's distribution, modification, or use. Patent claims: an adversary holds a patent that allegedly reads on the substrate's protocol or implementation, demanding licensing fees or claiming infringement damages. Trademark claims: an adversary registers "smart byte substrate" as a trademark in their jurisdiction and pursues legal action against the actual substrate's authors and operators. Copyright claims: an adversary argues that the substrate's reference implementation contains copyrighted material from another project without proper attribution, triggering DMCA takedowns or copyright-infringement claims.

The attack profile is well-known in adjacent open-source contexts: SCO's lawsuits against Linux from 2003 onward (eventually defeated but consuming significant defense resources), patent trolls' assertions against open-source projects (typically settling or being dismissed but creating sustained legal pressure), trademark disputes over project names. The substrate is potentially exposed to all of these.

**Defense.** The substrate's defenses against IP attacks operate through *prior-art establishment*, *patent-non-aggression* via the Apache license, and *cryptographic-namespace* approaches.

Prior-art establishment: this treatise itself, with its publication date and detailed technical specifications, serves as prior art for any future patent claims that might attempt to read on the substrate's mechanisms. The substrate's reference implementation, published openly with timestamped commits, similarly establishes prior art. Any patent claim against the substrate must contend with detailed prior-art documentation that predates most plausible patent priority dates.

Patent-non-aggression via Apache license: the Apache 2.0 license includes an explicit patent grant from contributors to users — Apache 2.0 contributors implicitly license any patents they hold that read on their contributions. This protects substrate users from being sued by substrate contributors over patent claims arising from substrate contributions. The license does not protect against third-party patent assertions, but it limits the patent-attack surface from within the substrate's own contributor community.

Cryptographic-namespace: the substrate uses content-addressing throughout (byte identities, history hashes, state hashes). Names that matter at the protocol level are cryptographic, not human-readable. An adversary pursuing trademark claims against "smart byte substrate" cannot reach the protocol's content-addressed identifiers; they can only target the human-readable name. The substrate is robust to renaming if necessary; the protocol's identity is in its conformance vectors and content-addressing, not in its trademark.

**Residual risk.** Three residual risks. First, patent litigation is expensive to defend even when meritless. An adversary willing to bring frivolous patent claims can drain the substrate's contributors' resources before being defeated, potentially achieving the adversary's goal of hampering substrate development. Second, trademark claims in specific jurisdictions can succeed even when the trademark is bad-faith; the substrate's contributors may need to navigate name changes in specific markets without prior coordination. Third, copyright claims based on alleged code-similarity to closed-source proprietary systems can be hard to defend even when no actual infringement occurred; the substrate's reference implementation must be audited for clean-room provenance before release.

**Operational response.** Substrate contributors maintain documentation of their work's clean-room provenance (no contributor uses proprietary code from previous employers, all contributions are written from public specifications and prior-art only). Patent claims against the substrate are documented publicly and defended through prior-art arguments; the substrate's authors do not settle frivolous patent claims and do not pay licensing fees for invalid patents. Trademark issues in specific jurisdictions are handled by community-led trademark filings and (where necessary) name variants for specific markets.

### 26.6 The structural limits of legal-attack defenses

The substrate's structural choices that limit legal-attack leverage:

**Protocol not service.** The substrate's authors do not operate clusters, do not facilitate transactions, do not provide custody. The protocol-not-service framing is the foundation of legal-attack defense across §26.1 (no securities offering), §26.3 (no operator obligation on authors), and §26.4 (no contractual relationship with users). The framing's legal effectiveness is jurisdiction-dependent but provides substantial protection in jurisdictions that recognize the distinction.

**Jurisdictional plurality.** Substrate operators, issuers, and users distributed across multiple jurisdictions provide redundancy against single-jurisdiction enforcement. The substrate inherits this defense from its federated architecture; cluster topology that spans jurisdictions naturally produces legal-attack-resistance through jurisdictional diversity.

**Open-source licensing.** Apache 2.0 and MIT licenses provide warranty disclaimers, patent grants, and broad permissions for use and modification. The licenses' protections are not absolute but provide substantial legal cover for users, contributors, and operators in most jurisdictions.

**No tradable substrate-internal asset.** The substrate has no native token (§24.5); there is no substrate-issued asset that can be classified as a security or subject to securities regulation. Cargo-bearing bytes inherit their legal classification from the cargo, not from the substrate; users seeking to limit securities exposure can choose cargo classes that don't trigger securities classification in their jurisdiction.

**Cryptographic-namespace identity.** The substrate's protocol-level identity is in its conformance vectors and content-addressing, not in human-readable trademarks. The substrate is robust to renaming if necessary; trademark attacks on specific names cannot reach the protocol itself.

These five structural choices compose into a substrate that has *limited* legal-attack exposure compared to alternative architectures with foundations, native tokens, or proprietary licensing. The defenses are partial and jurisdiction-dependent, but they raise the cost of legal attacks substantially and limit the leverage adversaries can apply.

The honest disclosure: legal attacks are jurisdictionally varied in ways that generic threat-model engagement cannot fully capture. The substrate's defenses are designed to be robust across jurisdictions, but specific jurisdictions can mount attacks that the substrate's general-purpose defenses do not anticipate. Substrate adopters must consult their own legal counsel in their own jurisdiction; the treatise provides architectural context but cannot provide jurisdiction-specific legal guidance.

### 26.7 Composition with other categories

Legal attacks compose with other categories' defenses in three ways.

**Composition one: legal attacks frequently follow social attacks (§25) or accompany physical attacks (§27).** A state-level adversary may pursue legal claims against substrate operators while simultaneously attempting contributor takeover (§25.1) and infrastructure seizure (§27). The defenses across §25, §26, §27 must be integrated; isolating any one category produces incomplete defense.

**Composition two: legal-attack defenses depend on structural protocol choices that enable cross-jurisdiction operation.** The substrate's protocol-level absence of operator-friendly compliance features (no built-in KYC, no native AML reporting, no protocol-mandated transaction monitoring) is what allows operators in less-regulated jurisdictions to operate without the compliance overhead that operators in heavily-regulated jurisdictions face. Without this protocol-level neutrality, the substrate would be uniformly subject to the most-aggressive jurisdiction's regulations.

**Composition three: legal-attack defenses are inherently partial and jurisdiction-dependent.** Unlike cryptographic defenses (§19) which are mathematically constrained, or protocol invariants (§20) which are auditable, legal defenses depend on specific legal regimes and their interpretation. The substrate's discipline is to name the structural choices that maximize legal robustness while acknowledging that specific jurisdictions can mount attacks that no general-purpose architectural defense can fully prevent.

The next section (§27) walks physical attacks. Where §26 engaged threats operating through legal and regulatory mechanisms, §27 engages threats operating through physical-coercive mechanisms — operator coercion, hardware seizure, network egress blocking, BGP hijacking. The composition is that §26 defenses operate within legal frameworks; §27 defenses operate when legal frameworks are bypassed entirely or used as cover for coercive action. Together, §26 and §27 cover the state-level attack surface that the substrate's most resourceful adversaries can deploy.
## §27. Physical attacks

The substrate operates on physical infrastructure: servers in datacenters, network connections through ISPs and IXPs, undersea cables, BGP-routed packets, electrical power. Adversaries with physical access to any of these can attack the substrate by mechanisms that have no protocol-layer defense — seizing servers, coercing operators, blocking network traffic, hijacking BGP routes. The substrate's defenses against physical attacks operate at the *operational* layer (geographic distribution, infrastructure plurality, backup recovery) rather than at the cryptographic or protocol layer.

This section walks four attack classes against the four-element rubric (§18.3). The attacks are §27.1 operator coercion, §27.2 hardware seizure, §27.3 network egress blocking, §27.4 BGP hijacking. §27.5 closes by acknowledging the partial nature of the substrate's physical-attack defenses and naming the operational practices that limit damage even when individual operators are compromised.

The honest disclosure that this section makes upfront: the substrate's defenses against physical attacks are weaker than its defenses in any other category engaged so far in Part III. Adversaries with state-level coercive power can substantially harm specific substrate operators, specific clusters, and specific user populations. The substrate's claim is not that physical attacks fail; it is that physical attacks against any single point in the substrate's federated infrastructure produce bounded damage that the rest of the federation continues operating around. This is *operational resilience*, not *cryptographic resistance*, and the difference matters.

By the close of §27, the reader should accept that the substrate's federated architecture is the load-bearing physical-attack defense, that geographic and jurisdictional plurality are necessary conditions for substrate freedom claims, and that physical attacks are where the substrate's defenses cross from technical mechanisms into operational practices that the substrate's authors have less direct control over than at the protocol layer.

### 27.1 Operator coercion

**Attack.** A state actor — law enforcement, intelligence services, or an authoritarian government — coerces a substrate cluster operator into modifying their operations to serve the state's purposes. The coercion may be lawful (court orders, regulatory directives, formal legal compulsion) or unlawful (extralegal pressure, threats, detention, asset seizure outside legal process). The coerced operator may be required to: provide real-time access to the cluster's transitions for surveillance, refuse service to specific users or pubkeys, falsify state attestations, or shut down operations entirely.

The attack profile spans a wide range. At the legal end: a U.S. cluster operator served with a National Security Letter requiring data disclosure. In the middle: a Chinese operator subject to the Personal Information Protection Law's data-localization requirements. At the extreme: an operator in an authoritarian regime physically detained until they provide cluster credentials, with no legal recourse and no public visibility.

**Defense.** The substrate's defenses against operator coercion operate through *operator plurality*, *protocol-level neutrality*, and *coercion-resistant operational practices*.

Operator plurality: the substrate's federated architecture means no single operator's compromise affects the substrate as a whole. A user whose preferred operator is coerced can switch to a different operator in a different jurisdiction. Cluster operations continue around the coerced operator; that operator's specific contributions to the cluster's lockstep can be replaced by other cluster members' lockstep activity. The substrate's operational tooling supports rapid operator switching and cluster-membership reconfiguration.

Protocol-level neutrality: the substrate's protocol provides no operator-controlled mechanisms for selective service refusal, surveillance integration, or transaction censorship. An operator coerced to refuse service to specific users can do so only at the application layer (their own connection-acceptance logic), not at the substrate's protocol layer. The user can connect to a different operator and have their transactions processed identically. The protocol's neutrality means that coerced operators cannot be effectively turned into substrate-wide enforcement mechanisms; their coercion affects only their direct users.

Coercion-resistant operational practices: substrate operators can implement *threshold-key-management* practices where multiple operators must collaborate to authorize sensitive operations. An operator under coercion who is asked to produce signing keys can honestly report that the keys are split across multiple operators in multiple jurisdictions, and that no single operator has the ability to comply with the coercion alone. This shifts the coercion to require multi-jurisdictional cooperation, which is dramatically harder to arrange than single-jurisdiction coercion.

Tor and equivalent transports (§17.4) provide an additional layer: substrate clusters operating over Tor can be reached by users without revealing the user's identity to the operator, limiting the user-identification value of any compelled-disclosure order against the operator. The operator's compelled disclosure reveals the existence of substrate traffic but not the identities of users behind it.

**Residual risk.** Three residual risks. First, operator plurality assumes alternative operators exist. In jurisdictions where regulators have driven all substrate operators offshore, users in that jurisdiction must use offshore operators with the legal risk that entails. The substrate's strategic case (§28) depends on offshore operators remaining available — i.e., on no global regulatory consensus shutting down substrate operations entirely. Second, protocol-level neutrality is meaningful only if users actually have operator alternatives accessible. A coerced ISP that blocks access to alternative operators (§27.3) eliminates the user's practical ability to switch even when alternatives technically exist. Third, threshold key management is operational practice, not protocol mandate. Operators who have not implemented threshold practices have single keys subject to single-coercion compromise; the substrate cannot enforce that operators implement these practices.

**Operational response.** A coerced operator may be unable to publicly disclose the coercion (gag orders, NSLs in the U.S., similar mechanisms elsewhere). The substrate's operational community develops *canary statements* — periodic public statements from operators affirming that they have not been coerced. The disappearance of an operator's canary is an indirect signal of coercion that other community members can observe. Coerced operators who are able to publicly disclose coercion may do so, allowing users to switch to alternatives. The substrate's gossip overlay can carry operator-status information so users can respond to coercion signals.

### 27.2 Hardware seizure

**Attack.** Law enforcement or intelligence services physically seize a substrate cluster operator's hardware — servers, persistent storage, hardware security modules, key-management appliances. With the hardware, the adversary obtains: the operator's signing keys (potentially), the cluster's persisted state at the moment of seizure, the operator's logs and operational records, and any user-identification data the operator's application layer collected.

The attack is straightforward to execute against operators in jurisdictions with cooperative law enforcement and inadequate legal protection for operators' infrastructure. Recent precedents include Tornado Cash-related arrests and prosecutions: Alexey Pertsev was detained in the Netherlands in August 2022 and convicted in May 2024 (sentenced to 64 months, currently appealing); Roman Storm was arrested in Washington State in August 2023 and convicted in U.S. federal court in August 2025 on the unlicensed-money-transmission charge with hung-jury outcomes on the more serious charges; Roman Semenov remains at large. Various crypto-exchange seizures and broader cybercrime hardware seizures targeting operators of any contested service round out the precedent landscape.

**Defense.** The substrate's defenses against hardware seizure operate through *operational hygiene practices* and *cryptographic key isolation*.

Operational hygiene: substrate operators are advised to maintain hardware in jurisdictions with stronger legal protections than their primary operational base (Switzerland, Liechtenstein, Singapore for many use cases), to use hardware security modules (HSMs) that resist key extraction even with physical access, to implement hard-disk encryption that requires authentication separate from the hardware itself, and to maintain operational practices (regular key rotation, distributed backups, encrypted logs) that limit the value of seized hardware.

Cryptographic key isolation: an operator's signing keys should be protected by HSMs or hardware tokens that prevent key extraction even with full physical access to the surrounding system. Yubikeys, Trezor devices, and dedicated HSMs (Thales, Utimaco, AWS CloudHSM) provide this protection at varying levels of assurance. An operator whose hardware is seized but whose keys are HSM-protected has lost their operational ability to participate in the cluster but has not surrendered the keys themselves.

Distributed backups: persisted state (§16) replicated across multiple operators in multiple jurisdictions means that hardware seizure at any single operator does not destroy the cluster's data. The substrate's content-addressed history (§10) is verifiable from any honest peer; an operator whose persistence is seized can rejoin the cluster from honest peers' state-sync (planned v0.4) once they recover operational capability.

Threshold-key practices (§27.1) further limit the value of hardware seizure: an operator whose key shares are distributed across multiple jurisdictions cannot sign anything from any single seized HSM. Hardware seizure becomes useless without simultaneous seizure across jurisdictions.

**Residual risk.** Three residual risks. First, HSM protection has limits. Sufficiently sophisticated state-level adversaries (NSA, GCHQ, PLA) may have key-extraction capabilities that commercial HSMs cannot resist; the substrate's operators should not assume HSM protection is absolute against state-level adversaries. Second, distributed-backup operational practices add operational complexity that small operators may not implement. The substrate's defenses depend on operators implementing the practices, not just having them available. Third, hardware seizure may include user-data seizure (application-layer logs, user pubkey-to-identity mappings) that compromises user privacy independent of substrate-protocol defenses.

**Operational response.** Operators whose hardware is seized announce the event publicly (where legally permitted), rotate their keys, and re-establish operations from preserved key shares and distributed backups. The cluster continues operating through other members; the seized operator's loss is bounded by the federation's plurality. Users whose data was on the seized operator's application layer may face privacy compromise; the substrate's operational guidance is that high-value users should diversify their operator relationships and use anonymizing intermediaries to limit single-operator exposure.

### 27.3 Network egress blocking

**Attack.** A state actor or ISP blocks network traffic to substrate cluster nodes from users in their jurisdiction. The blocking may target specific IP addresses (clusters' known addresses), specific protocols (the substrate's TCP framing), or specific traffic patterns (recognized substrate handshake signatures). Users in the blocked jurisdiction cannot reach substrate operators; their substrate use is suppressed without any direct attack on the substrate's protocol or operators.

The attack is well-precedented: China's Great Firewall, Iran's intermittent VPN blocks, Russia's blocks against specific cryptocurrency services. Network egress blocking is a standard tool for jurisdictions seeking to suppress specific online activities without legal action against the activities' providers.

**Defense.** The substrate's defenses against network egress blocking operate through *transport diversity*, *circumvention infrastructure*, and *protocol-flexibility*.

Transport diversity: the substrate's transport layer (§17) is intentionally pluggable. v0.3 supports TCP and in-process mpsc; v0.4 will add QUIC and WebSocket; v1.x targets Tor and other anonymizing transports. Users in jurisdictions blocking specific transports can fall back to alternative transports — TCP-blocked users can use QUIC, port-restricted users can use WebSocket on standard web ports, deeply-restricted users can use Tor. The substrate's protocol is unchanged across transports; only the wire format differs.

Circumvention infrastructure: substrate users can connect through circumvention tools (Tor, Snowflake, Lantern, Outline VPN, mainstream commercial VPNs). The substrate does not require these tools but is designed to work alongside them. Circumvention tools' own resilience to blocking is well-developed; the substrate inherits whatever circumvention robustness the chosen tool provides.

Protocol-flexibility: substrate handshakes and traffic patterns can be designed to resist deep-packet-inspection (DPI) recognition. Pluggable transport designs (Tor's obfs4, meek, Snowflake) demonstrate that protocol traffic can be made hard to distinguish from common web traffic, frustrating signature-based blocking. v1.x substrate work should include obfuscated transport options for high-censorship environments.

The gossip overlay (§11.4) provides additional resilience: a user who can reach any substrate node can verify byte history and submit transactions; the gossip overlay propagates the user's submissions to clusters that may be unreachable directly. Even partial connectivity can support substrate use.

**Residual risk.** Three residual risks. First, the substrate's pluggable-transport infrastructure depends on operators actually deploying alternative transports. If all substrate operators use only TCP, transport diversity is theoretical rather than practical. v0.4 work on QUIC, WebSocket, and Tor transports is required for transport diversity to be meaningful. Second, deep-packet-inspection capabilities continue to improve, with state-level DPI systems increasingly capable of detecting circumvention tools through statistical traffic analysis. The arms race between censorship and circumvention is ongoing; the substrate inherits the current state of the art but cannot guarantee future censorship resistance. Third, complete network isolation (a jurisdiction that blocks all internet access to non-state-approved infrastructure) defeats any substrate-level defense; users in such jurisdictions must use out-of-band channels (satellite internet, manual transfers across borders) that are themselves under attack.

**Operational response.** Substrate operators monitor for blocking patterns affecting their user base and deploy alternative transports to maintain reachability. Users in heavily-restricted jurisdictions develop practices for using circumvention tools effectively (regularly changing entry points, using multiple parallel circumvention paths, maintaining offline backups of substrate-relevant data). The substrate's community shares circumvention guidance through documentation and mutual support.

### 27.4 BGP hijacking

**Attack.** An adversary with access to BGP route announcements (a state-controlled telecom, a compromised ISP, an attacker with route-hijacking capability) announces routes that direct substrate-cluster traffic through adversarial infrastructure. The adversary intercepts substrate traffic, observes communication patterns, potentially modifies traffic in flight (though the substrate's cryptographic signatures detect modification), or simply blackholes traffic to prevent it from reaching its destination.

BGP hijacking has been used at scale: the 2008 YouTube hijack by Pakistan Telecom, multiple Chinese ISPs' BGP attacks, the 2018 Amazon Route 53 hijack to steal cryptocurrency. The attack is technically sophisticated but well-documented; state-level adversaries and well-resourced criminals can execute it.

**Defense.** The substrate's defenses against BGP hijacking operate through *cryptographic verification* (which already protects against in-flight tampering), *transport diversity* (which limits single-route dependence), and *operational monitoring*.

Cryptographic verification: substrate messages are cryptographically signed (§19). An adversary intercepting and modifying messages produces invalid signatures that honest nodes reject. BGP hijacking that aims to inject forged messages fails at the substrate's verification layer; the only effective BGP attack against the substrate is observation (revealing communication patterns) or denial-of-service (blackholing traffic). The substrate's transport-layer encryption (TLS over TCP, native TLS in QUIC) further limits observation value, encrypting message contents even if metadata (source/destination IPs, traffic timing) remains visible.

Transport diversity: a user reaching a substrate cluster through one transport can fall back to another if BGP hijacking affects the first. A cluster operating across multiple data centers in multiple ASNs is harder to hijack comprehensively than a single-data-center cluster. Operational practice should distribute cluster nodes across multiple network providers to limit single-provider hijacking exposure.

Operational monitoring: BGP route changes affecting substrate clusters can be detected by route-monitoring services (BGPmon, Cisco's BGP monitoring, RIPE's RIS service). Substrate operators monitor for unexpected route changes affecting their clusters' IP ranges and respond by switching to backup providers, alerting the community, or temporarily routing through alternative paths until the hijack is addressed.

RPKI (Resource Public Key Infrastructure, RFC 6480 and related specifications) provides cryptographic authorization for BGP route announcements; ASNs implementing RPKI can reject route announcements from unauthorized origins. Substrate operators should encourage their network providers to implement RPKI; this is an internet-wide hardening effort that the substrate benefits from but does not control.

**Residual risk.** Three residual risks. First, RPKI deployment is incomplete globally; many ASNs still accept unsigned route announcements, and BGP hijacking remains effective in regions with low RPKI coverage. The substrate inherits the broader internet's BGP-security state. Second, traffic-pattern observation (visible source/destination IPs, traffic timing) reveals operator and cluster identities even when message contents are encrypted. Adversaries with traffic-analysis capabilities can identify substrate users by their connection patterns to known substrate clusters. Tor and equivalent traffic-anonymization tools mitigate but do not eliminate this exposure. Third, BGP hijacking that simply denies service (blackholing) does not require message modification or observation; the substrate's response to denial-of-service is operational (switch transports, switch providers) rather than cryptographic.

**Operational response.** Substrate operators implement BGP route-monitoring and respond to detected hijacks by working with network providers to filter the bad routes and re-establish correct routing. Persistent BGP attacks against a specific operator may require switching infrastructure providers entirely. The substrate's community shares BGP-monitoring infrastructure and incident-response practices.

### 27.5 The partial nature of physical-attack defense

The substrate's defenses against physical attacks are *partial*. This is the section's most important honest disclosure, and it deserves explicit treatment rather than being scattered across the residual-risk subsections.

Physical attacks bypass the substrate's cryptographic and protocol-level defenses entirely. An adversary who can seize hardware does not need to break ed25519. An adversary who can coerce operators does not need to clear the BFT bound. An adversary who can hijack BGP routes does not need to manipulate the canonical hash sort. The substrate's response to physical attacks is operational resilience, not cryptographic resistance — limiting damage from any individual attack while continuing operations through the unaffected federation.

The substrate's structural choices that limit physical-attack leverage:

**Federated architecture.** No single point of physical compromise affects the substrate as a whole. An operator seized in one jurisdiction is one of many operators; the cluster continues operating through others. A network blocked in one jurisdiction is one of many networks; users connect through alternatives. This is the foundation of substrate physical-attack resilience.

**Geographic distribution.** Operators in multiple jurisdictions provide redundancy against single-jurisdiction enforcement. The substrate's strategic case depends on operators *actually* being distributed — if all operators end up in U.S. jurisdiction (by regulatory pressure, by market consolidation, by network effect), the geographic-distribution defense fails. The substrate's authors actively encourage operator distribution across jurisdictions and specifically across the major jurisdictional clusters (North America, EU, Asia-Pacific, jurisdictions with strong digital-rights protection like Switzerland and Iceland).

**Content-addressed recovery.** A cluster recovering from physical compromise of any subset of its members can rebuild from honest peers' content-addressed state attestations (§16, §23.3 — though state-sync from honest peers is v0.4 work). Hardware seizure does not destroy data because the data is verifiable from any honest peer.

**Protocol-level absence of single-point-of-failure features.** No leader, no foundation, no token, no centralized authority — the substrate's protocol-level absences (named in §24.5 and §25.6) limit the leverage physical attacks can apply. There is no leader to seize, no foundation to raid, no token to confiscate. Physical attacks must target distributed infrastructure to have substrate-wide effect, which is operationally much harder than targeting centralized infrastructure.

**Operational resilience practices.** Threshold key management, distributed backups, transport diversity, BGP monitoring — these operational practices are not protocol-mandated but are widely adopted by substrate operators. The substrate's documentation includes operational guidance for these practices; the substrate's community supports their adoption.

These five structural choices compose into a substrate that is *resilient* against physical attacks rather than *immune* to them. The treatise's discipline is to name the difference. A substrate operator can be coerced, seized, blocked, or hijacked — and the substrate continues operating while that operator recovers (or while users switch to other operators).

The honest disclosure: physical attacks against state-level adversaries are the threat class the substrate's authors expect to escalate fastest. As substrate adoption grows, state-level interest in the substrate grows, and physical-attack capabilities are deployed. The substrate's defenses are designed to make these attacks expensive and operationally bounded, not to make them impossible. Substrate adopters operating in adversarial jurisdictions must understand that they are operating in adversarial jurisdictions, with all the operational risk that entails.

### 27.6 Composition with other categories

Physical attacks compose with other categories' defenses in three ways.

**Composition one: physical attacks frequently accompany legal attacks (§26).** A state-level adversary using legal compulsion to obtain operator data may simultaneously deploy physical-attack capability if legal mechanisms are insufficient. The defenses across §26 and §27 are interdependent; isolated treatment of either category produces incomplete defense. The substrate's jurisdictional-plurality defense operates across both categories simultaneously.

**Composition two: physical attacks frequently complete state-level attacks (§28-class adversaries).** The state-level adversary class (§18.1 class four) uses legal pressure first, social attacks (§25) second, physical attacks third — escalating from less-coercive to more-coercive mechanisms as needed. A treatise that engaged each category in isolation would miss the integrated nature of state-level adversarial capability.

**Composition three: physical-attack defense is the substrate's most operational layer.** Unlike cryptographic defenses (§19) which are mathematically constrained, or protocol invariants (§20) which are auditable, physical-attack defenses depend on operator practices, infrastructure choices, and community vigilance. The substrate's authors maintain the protocol; the substrate's operators maintain the operational defense surface. The treatise's discipline is to name this division of responsibility honestly.

The next section (§28) walks AI-layer attacks. Where §27 engaged threats from state-level adversaries deploying physical-coercive capability, §28 engages threats from AI-mediated incumbents — the strategic adversary class that the treatise has named since §1 as the substrate's primary competition. §28 is the load-bearing strategic engagement that Part III has been building toward; it integrates the technical-threat-model discipline of §19-§27 with the strategic-positioning discipline of §1, §3.5, §6.4, §7, §22.6, and §25.6. By the close of §28, Part III is complete and the substrate's threat model is fully specified.
## §28. AI-layer attacks

The treatise has been honest from §1 onward that the substrate competes against an AI-mediated trajectory. AI companies — Anthropic most concretely, given the treatise's authorship context, but the pattern generalizes to OpenAI, Google DeepMind, and the broader AI-as-financial-infrastructure cohort — are racing to capture the institutional middle's transformation as it consolidates around AI-augmented services. The race is not between AI and the substrate; both use AI capabilities. The race is between AI deployed *as the new institutional middle* and AI deployed *as the substrate's tooling for substrate operations*. The two trajectories are mechanically distinct, lead to different power structures, and produce different futures. §28 engages the attack vectors AI-mediated incumbents can deploy against the substrate to win the first trajectory.

This section walks four attack classes against the four-element rubric (§18.3). The attacks are §28.1 AI-as-issuer capture (AI companies become the dominant cargo issuers, capturing the substrate's freedom-bounded layer), §28.2 AI-as-host capture (AI companies become the dominant cluster operators, controlling substrate access), §28.3 AI-as-validator capture (AI companies' models become the substrate's de-facto verification authority through user trust), §28.4 AI-as-narrative capture (AI-mediated information channels shape user understanding to favor incumbent products over substrate adoption). §28.5 closes by engaging the substrate's most strategically important question — whether the substrate's authors believe the substrate will ship and be adopted before the AI-mediated rent layer consolidates — and naming the conditions under which each trajectory wins.

§28 is the load-bearing strategic engagement that Part III has been building toward. The previous categories — cryptographic, lockstep protocol, cluster topology, issuer, state, economic, social, legal, physical — each engaged a class of adversary the substrate must survive. §28 engages the *integrated* adversary: AI-mediated incumbents who can deploy attacks across multiple categories simultaneously, with structural advantages no other adversary class possesses (AI compute capacity, information-channel control, regulatory access, vendor relationship density, marketing scale). The defenses against each AI-layer attack are weaker than the defenses against any single non-AI attack in its respective category, because AI-mediated incumbents combine multiple attack capabilities that the substrate's single-category defenses were not designed to handle simultaneously.

By the close of §28, the reader should accept that the substrate's strategic competition is real, that the substrate's defenses against AI-layer attacks are partial, and that the substrate's most important defense is *winning the timing race* — shipping, getting adopted, and acquiring independent constituency before the AI-mediated rent layer consolidates beyond the substrate's ability to displace it.

### 28.1 AI-as-issuer capture

**Attack.** AI companies become the dominant issuers of cargo-bearing bytes in the substrate, leveraging their AI-augmented financial infrastructure to issue USD-bytes, joule-bytes, compute-hour-bytes, and any other cargo class with compelling AI-mediated pricing, customer service, and integration. Once dominant, AI-company issuers can: charge spreads that recreate the institutional middle's rent extraction, condition issuance on AI-company-specific compliance regimes, refuse issuance to users or applications that compete with AI-company services, and use issuance authority as leverage to constrain the substrate's broader development.

The attack profile: AI companies enter the substrate's issuer landscape with structural advantages — superior pricing through AI-augmented operations, superior customer experience through AI-mediated interfaces, superior integration through AI-tooling that other issuers cannot match. The advantage compounds: better experience attracts more users; more users justifies more AI investment; more AI investment widens the experience gap. The substrate's multi-issuer architecture (§22) becomes nominal; in practice, one or two AI-company issuers per cargo class capture most of the volume.

The attack is not adversarial in the conventional sense — AI companies offering better service is not malice. The structural threat is that "better service" leverages AI-company structural advantages to reproduce the institutional middle's monopoly within the substrate's nominal multi-issuer framework, with AI companies becoming the new institutional middle.

**Defense.** The substrate's defenses against AI-as-issuer capture operate through *structural plurality requirements*, *protocol-level absence of issuer-friendly features*, and *competing issuer enablement*.

Structural plurality: the substrate's multi-issuer architecture (§15.1) is protocol-mandated rather than voluntary. Users can choose any issuer's bytes; cluster operators must accept transitions for all registered issuers; the substrate's protocol does not privilege any issuer over any other. AI-company issuers operating with structural advantages compete on those advantages, but they cannot use the substrate's protocol to lock users into their services. Users can switch issuers at any time, with bytes from one issuer functionally equivalent to bytes from another for cargo-class-equivalent purposes.

Protocol-level absence of issuer-friendly features: the substrate has no built-in mechanism for issuer-level user lockup, mandatory KYC integration, compliance-attestation requirements, or any of the features AI-company issuers might use to differentiate themselves from other issuers and attempt to lock users in. AI-company issuers can implement such features at the application layer, but users can route around them by using less-restricted issuers — and the substrate's protocol-level neutrality means routing-around is technically straightforward.

Competing issuer enablement: the substrate's reference implementation, conformance vectors, and treatise are open-source. Anyone can become an issuer for any cargo class; the substrate's authors actively encourage diverse issuance and provide tooling that lowers the operational cost of being an issuer. Cooperative issuers (community solar cooperatives for joule-bytes, agricultural cooperatives for kcal-bytes, credit unions for USD-bytes) can issue bytes alongside AI-company issuers, with users choosing based on values, pricing, or practical considerations.

The substrate's joule-cost transparency (§8.6, §24.1) provides additional defense: AI-company issuers' operations have substantial energy costs that are transparently reportable. Users comparing issuers' joule-cost-per-transition data can identify AI-company issuers as energy-intensive and choose lower-energy alternatives based on their preferences.

**Residual risk.** Three residual risks. First, structural plurality is meaningful only if alternative issuers actually exist and operate competitively. AI-company structural advantages may make non-AI issuers economically unsustainable, with cooperatives and credit unions exiting cargo classes where AI companies dominate. The substrate's protocol allows alternatives; it cannot guarantee alternatives' economic viability. Second, AI-company issuers operating across many cargo classes simultaneously can offer integrated services (a single AI company issuing USD-bytes, joule-bytes, and compute-hour-bytes) that single-cargo competitors cannot match operationally. Cross-cargo integration becomes a soft lock-in even without explicit lock-in mechanisms. Third, regulatory frameworks favoring large institutional issuers (capital requirements, licensing burdens) may exclude smaller competitors from issuance entirely, with regulation effectively privileging AI-company issuers against the cooperative alternatives the substrate would otherwise enable.

**Operational response.** Substrate community development efforts focus on supporting non-AI issuers — providing operational infrastructure, regulatory navigation, and user-acquisition support. Substrate-monitoring services publish issuer-quality and issuer-concentration data, allowing users to make informed choices about issuer diversity. Where regulatory frameworks favor AI-company issuers, substrate community advocacy engages with regulators to argue for proportionate requirements that smaller issuers can meet.

### 28.2 AI-as-host capture

**Attack.** AI companies become the dominant cluster operators in the substrate, leveraging their compute infrastructure, AI-augmented operational capabilities, and customer-acquisition channels to host substrate clusters at scale. Once dominant, AI-company hosts can: charge fees that recreate the institutional middle's rent extraction at the operator layer, condition cluster access on AI-company-specific terms, integrate AI-company services as default substrate access points, and use hosting authority to influence substrate development direction.

The attack profile parallels §28.1: AI companies enter cluster operation with structural advantages (superior infrastructure, superior reliability, superior integration with AI-mediated tooling). Users gravitate to AI-company-hosted clusters because they work better; smaller hosts cannot match the experience; the substrate's federated architecture becomes nominal; in practice, one or two AI-company hosts capture most of the substrate's cluster operations.

**Defense.** The substrate's defenses against AI-as-host capture operate through *protocol-level interoperability*, *operator plurality enablement*, and *user-side switching infrastructure*.

Protocol-level interoperability: the substrate's protocol (Parts II) makes any conforming cluster fully interoperable with any other conforming cluster. A user using an AI-company-hosted cluster can transfer bytes to a user on a smaller community cluster without protocol-level friction. Cross-cluster transfer protocols (§11.3.3, v0.4 work) make this operationally smooth. AI-company hosts cannot leverage their dominance to fragment the substrate; the protocol's interoperability is enforced cryptographically rather than through commercial agreements.

Operator plurality enablement: the substrate's reference implementation is open-source and well-documented. The operational requirements for running a cluster are modest (modest CPU, modest RAM, persistent storage, reliable network — see §11.1's empirical scaling table). The substrate's authors actively support smaller hosts through documentation, deployment tooling, and community infrastructure. Cooperative hosts (university clusters, community-organization clusters, individual-operator clusters) can compete with AI-company hosts on values and trust even when they cannot compete on operational scale.

User-side switching infrastructure: substrate-using applications (wallets, integration tools, bridge services) should support multi-host operation by default, distributing user submissions across multiple hosts simultaneously rather than concentrating on any single host. The substrate's gossip overlay (§11.4) provides the routing infrastructure; user-side tools should be designed to leverage it. A user submitting to multiple hosts simultaneously cannot be locked into any one host's terms.

**Residual risk.** Three residual risks. First, protocol-level interoperability is technical; operational interoperability requires user-side tooling that makes cross-host operation transparent. If user-side tooling is dominated by AI-company-built wallets and integrations, the technical interoperability is theoretical and AI-company hosts maintain practical lock-in. Second, AI companies' compute scale and operational capability may make their hosts' performance dramatically better than smaller hosts'. Users facing latency or reliability differences may not value substrate values enough to accept the operational degradation. Third, AI-company hosts may offer integration with AI-company services (financial AI agents, customer service agents) that smaller hosts cannot match. Bundled services become a soft lock-in even without explicit lock-in mechanisms.

**Operational response.** Substrate community efforts include supporting non-AI hosts (cooperative hosting, community infrastructure, user-friendly deployment tooling) and developing user-side tooling that defaults to multi-host operation. Substrate-monitoring services publish host-quality and host-concentration data. Where AI-company hosts attempt to leverage dominance for lock-in, the substrate's community develops alternative tooling that preserves user choice.

### 28.3 AI-as-validator capture

**Attack.** Users delegate verification of substrate transactions to AI assistants. An AI assistant becomes the user's interface to the substrate — interpreting transitions, validating cargo claims, identifying suspicious activity, recommending transactions. The user's actual verification capability degrades; they trust the AI's judgment because AI-mediated interfaces are more convenient than manual chain verification.

Once user verification is AI-mediated at scale, AI companies' models become the de-facto authority on substrate transaction legitimacy. AI companies can: bias their models' verification toward AI-company-approved issuers and hosts, flag user-favored alternatives as suspicious, refuse to recommend non-AI-company services, and use verification authority as leverage to shape substrate behavior.

The attack profile is subtle: the substrate's protocol-level verification (§10.2) remains correct; the user's chain verification produces the right answer; but the user delegates verification to an AI assistant whose judgment is influenced by the AI company's commercial interests. The substrate's cryptographic guarantees become irrelevant if users do not exercise them directly.

**Defense.** The substrate's defenses against AI-as-validator capture operate through *user-empowerment tooling*, *competing AI verification*, and *protocol-level verifiability transparency*.

User-empowerment tooling: substrate verification is computationally cheap (§10.2 walks the procedure in five steps; a typical byte's full chain verification takes milliseconds). Substrate-using applications should default to performing verification client-side rather than delegating to remote services. Users see verification results directly; they understand what verification means and what it doesn't mean. The substrate's community develops verification tooling that prioritizes user understanding over AI-mediated convenience.

Competing AI verification: open-source AI models (Llama, Mistral, others) can perform substrate verification independently of AI-company-controlled models. Substrate-using applications can offer verification through user-chosen AI assistants, with transparent reporting of which AI made each verification decision. Users concerned about AI bias can choose verification through AI models they trust or perform verification manually.

Protocol-level verifiability transparency: every substrate verification reduces to a deterministic computation over the byte's content-addressed chain. There is no judgment involved; the verification either succeeds or fails based on cryptographic correctness alone. AI assistants performing verification are not making judgments; they are running the verification procedure. The substrate's transparency means that AI-mediated verification is auditable: an AI claiming a transaction is valid can be checked against the underlying cryptographic verification, and disagreement is detectable.

**Residual risk.** Three residual risks. First, user-empowerment tooling depends on users actually using it. If AI-mediated interfaces are dramatically more convenient, users will use them and accept whatever verification their chosen AI provides. The substrate cannot force users to verify directly; it can only make direct verification possible. Second, competing AI verification depends on alternative AI models being competent for substrate-specific verification tasks. If AI companies invest heavily in substrate-verification capabilities and open-source alternatives lag, AI-company verification dominates by capability rather than by user choice. Third, AI-mediated decisions about non-protocol-level issues (which cargo to accept, which issuers to trust, which hosts to use) involve judgment that the substrate's transparency does not constrain. AI assistants advising users on these decisions can shape user behavior in ways that protocol-level verification correctness does not address.

**Operational response.** Substrate community efforts include developing verification tooling that prioritizes user understanding, supporting open-source AI verification capabilities, and educating users about the difference between protocol-level verification (cryptographic, judgment-free) and judgment-laden decisions (cargo selection, issuer choice, host choice). Substrate-using applications transparently report what verification was performed and by which model.

### 28.4 AI-as-narrative capture

**Attack.** AI-mediated information channels shape user understanding of the substrate. Search results, AI-assistant responses to substrate-related questions, AI-summarized news about the substrate's adoption — all are influenced by the AI providers' editorial choices. AI providers can: emphasize substrate alternatives in their responses, frame substrate adoption as risky or fringe, prioritize AI-company-friendly substrate variants, and shape long-term user perception in ways that cumulatively favor incumbent products over substrate adoption.

The attack is not necessarily deliberate; AI companies' models reflect their training data, their RLHF preferences, and their commercial context. An AI assistant trained primarily on content reflecting the institutional middle's perspective will naturally produce responses framed by that perspective, even without explicit anti-substrate intent. The cumulative effect over millions of user interactions is substantial narrative shaping.

The attack profile: a user asks an AI assistant about smart byte substrate adoption. The assistant's response reflects its training: substrate adoption is "complex" and "controversial"; AI-company alternatives are "established" and "trusted"; risks are emphasized; benefits are downplayed. The user concludes that substrate adoption is not worth the effort. Multiplied across millions of users, this is decisive market influence with no overt manipulation.

**Defense.** The substrate's defenses against AI-as-narrative capture operate through *clear authoritative documentation*, *open-source AI alternatives*, and *substrate-quality evidence accumulation*.

Clear authoritative documentation: this treatise itself is the substrate's primary defense against narrative capture. AI assistants trained on the treatise will encounter the substrate's actual claims, defenses, and tradeoffs in the substrate's own voice. The treatise's discipline of explicit acknowledgment (partial freedoms, v0.4 work, structural costs) makes it harder for AI assistants to characterize the substrate as overpromising; the substrate's own honesty about its limits is a defense against caricatures of those limits.

Open-source AI alternatives: AI assistants based on open-source models (Llama, Mistral, Qwen, others) can be trained or fine-tuned on substrate-favorable data without the commercial constraints AI-company models face. Substrate-using applications can offer AI assistance through user-chosen models; users concerned about narrative bias can use models they trust.

Substrate-quality evidence accumulation: as the substrate is adopted, real-world evidence accumulates — successful issuers, healthy clusters, satisfied users, audited operations. The evidence is publicly verifiable through the substrate's transparency; AI assistants summarizing the evidence cannot easily distort it without producing summaries that contradict the underlying data. Substrate's transparency creates an information environment that resists narrative capture: claims about substrate behavior can be checked against substrate state directly.

**Residual risk.** Three residual risks. First, clear documentation depends on AI training data reaching the documentation. If AI providers selectively exclude substrate documentation from their training corpora (or deprioritize it in fine-tuning), the substrate's documentation does not influence AI-mediated narratives. The substrate cannot force AI providers to include its documentation. Second, open-source AI alternatives depend on the broader open-source AI ecosystem maintaining capability competitive with AI-company models. If AI-company models substantially outperform open-source alternatives, users gravitate to AI-company models for capability reasons, exposing themselves to whatever narrative bias those models contain. Third, narrative capture operates over long time scales — months and years rather than minutes. By the time substrate adopters notice that AI-mediated narratives are systematically biased against the substrate, significant adoption damage may have already occurred.

**Operational response.** Substrate community efforts include maintaining authoritative documentation that is unambiguously the substrate's own voice, supporting open-source AI ecosystems, and educating users about the difference between AI-mediated information and substrate-direct information. Substrate-using applications offer direct access to substrate state and documentation, allowing users to bypass AI-mediated framing when they choose.

### 28.5 The strategic timing question

Part III has engaged the substrate's threat model across ten attack categories. Cryptographic, lockstep protocol, cluster topology, issuer, state, economic, social, legal, physical, AI-layer. Each category has been engaged against the four-element rubric (§18.3); each has named defenses, residual risks, and operational responses; each has been honest about the partial nature of those defenses.

The substrate's most strategically important question — engaged here at the close of Part III rather than scattered across earlier sections — is whether the substrate's defenses, taken together, are *sufficient given the timing*. The substrate's defenses against any single attack class are reasonably robust. The substrate's defenses against the *integrated state-level + AI-mediated* adversary that combines attacks across multiple categories simultaneously are weaker. The substrate's defenses against an integrated adversary deploying their attacks *before the substrate has acquired independent constituency* are weakest of all.

The treatise's strategic claim, named honestly: the substrate must ship and acquire adoption before the AI-mediated rent layer consolidates beyond the substrate's ability to displace it. This is the timing race. The race is winnable but not won. The race's outcome depends on conditions the substrate's authors only partially control.

The pace of consolidation is rapid. By 2026, AI-agent financial infrastructure is moving from pilots into production: stablecoin transaction volume reached approximately $33 trillion in 2025 (up roughly 72% year over year), with stablecoin supply surpassing $300 billion and projected to reach approximately $420 billion in 2026 with agentic payments named as a primary growth driver; Coinbase's x402 protocol (open-sourced 2025) enables instant programmable payments over HTTP for AI agents; the ERC-8004 standard for verifiable on-chain AI agent identity deployed on BNB Chain in February 2026; market analysts (MarketsandMarkets) project the AI-agents market growing from approximately $7.84 billion in 2025 to approximately $52.62 billion by 2030 at 46.3% CAGR. The infrastructure for AI-mediated financial transactions is being built now, on the institutional middle's terms, with stablecoins as the cargo and AI companies as the issuance and routing layer. The substrate's window for offering an alternative is bounded by how fast that infrastructure consolidates — measured in months and quarters, not years and decades.

**Conditions under which the substrate wins:**

- The substrate ships v1.0 with a working reference implementation and publishes the treatise (this document) before AI-company financial-services products reach broad adoption.
- Multiple competing substrate implementations emerge in the year following v1.0, demonstrating implementation diversity and preventing single-implementation monoculture.
- Multiple jurisdictions develop favorable regulatory frameworks for the substrate's protocol-not-service framing, creating jurisdictions where substrate operation is unambiguously legal.
- Cooperative issuers (credit unions for USD-bytes, community solar cooperatives for joule-bytes, agricultural cooperatives for kcal-bytes) launch substrate-issuance offerings that compete with AI-company issuers on values and trust.
- User-side tooling (wallets, integrations, browsers with substrate support) reaches usability parity with AI-company alternatives.
- Substrate adoption acquires enough scale that the substrate has its own constituency — users, operators, issuers, developers — independent of any single jurisdiction's regulatory permission or any single AI company's tolerance.

**Conditions under which the substrate loses:**

- AI companies achieve regulatory and market dominance in financial AI services before the substrate ships, with AI-mediated financial agents becoming the default rather than substrate-mediated direct transactions.
- Regulatory frameworks consolidate globally to require AI-mediated compliance for any financial transaction above trivial thresholds, effectively forbidding substrate operation outside AI-company-mediated channels.
- The substrate's reference implementation has a critical security failure that damages reputation before alternative implementations emerge.
- The substrate's community fragments before achieving independent constituency, with multiple substrate variants competing for the same niche and none achieving critical mass.
- AI-mediated narratives shape user understanding so thoroughly that substrate adoption never reaches the threshold where independent constituency is possible.
- Physical and legal attacks on substrate operators succeed in jurisdictionally consolidating substrate operation into AI-company-friendly hands before independent infrastructure is established.

The substrate's authors' honest assessment, named explicitly: the conditions under which the substrate wins are achievable but require substantial work that has not yet been done. The conditions under which the substrate loses are paths the substrate is currently on if no countervailing work is done. Neither outcome is determined; both are achievable.

### 28.6 The substrate's most important defense

The substrate's most important defense, across all categories engaged in Part III, is *winning the timing race*. Cryptographic primitives are conservative for decades. Protocol invariants are auditable indefinitely. Cluster topology defenses are sufficient for sophisticated single-category adversaries. Issuer-layer defenses limit institutional-middle re-entry. Economic, social, legal, physical defenses are layered and partial. AI-layer defenses are weakest. But the substrate's *strategic survival* does not depend on any single category's defenses; it depends on the substrate acquiring independent constituency before the AI-mediated rent layer consolidates.

Independent constituency means: enough users to make substrate adoption matter politically; enough issuers to make multi-issuer architecture practically meaningful; enough operators to make federation distribution real; enough developers to maintain the substrate's reference implementation and conformance vectors; enough public visibility to make narrative capture costly; enough regulatory engagement to establish substrate-favorable frameworks in major jurisdictions. Independent constituency is what protects the substrate from being absorbed, captured, or marginalized by AI-mediated incumbents.

Building independent constituency is work the substrate's authors do partially and the substrate's community does mostly. The treatise commits the substrate's authors to: maintaining the reference implementation, maintaining the conformance vectors, publishing the treatise and its updates, supporting community development efforts, and engaging publicly with substrate adopters and critics. The community's commitment is to: developing alternative implementations, operating independent clusters, launching cooperative issuance, building user-side tooling, advocating with regulators, and educating users.

The honest disclosure that closes Part III: the substrate's threat model has been engaged comprehensively, but the substrate's strategic survival is not primarily a threat-model question. It is an adoption-and-timing question, and the answer is to be determined by work done after the treatise's publication. The treatise specifies what the substrate is and what it must survive; the work of making the substrate actually win is ongoing.

### 28.7 Composition with all other categories: Part III closes

The four AI-layer attacks engaged in §28 compose with all other Part III categories simultaneously. AI-as-issuer capture (§28.1) is an extreme of issuer attacks (§22) operating with structural advantages. AI-as-host capture (§28.2) is an extreme of cluster topology attacks (§21) deployed by adversaries with operational scale. AI-as-validator capture (§28.3) is a social attack (§25) operating through delegated verification rather than direct compromise. AI-as-narrative capture (§28.4) is a social attack (§25) operating through information-channel control rather than identity capture. The cryptographic, protocol, state, economic, legal, and physical categories all provide layered defenses that AI-mediated incumbents must overcome, but the integration of those defenses across categories is what determines whether AI-layer attacks succeed.

Part III is now complete. Eleven sections. Ten attack categories engaged with the four-element rubric. Specific defenses named, specific residual risks acknowledged, specific operational responses specified. The substrate's threat model is the most comprehensive treatment of distributed-systems threat models that the treatise's authors have produced; it is also necessarily incomplete because real adversaries discover attacks the treatise does not anticipate.

Part IV walks the workarounds — the alternative architectures critics propose instead of the substrate. Each is treated seriously; each is shown to fail at scale or against the adversaries Part III engaged. Part IV's discipline is to engage the workarounds as they are actually proposed rather than as straw versions of those proposals. The result is the substrate's case as the *correct* architecture rather than just *one* architecture among many — the case that completes Part I's establishment of the substrate's necessity with the demonstration that no proposed alternative survives the engagement Part III specified.

By the close of Part IV, the substrate's case as both *necessary* (Part I) and *correct* (Parts II-III + Part IV's failure of alternatives) will be established. Parts V-VII engage the retrofits, distribution implications, and closing argument that complete the treatise.