Why the protocol is the only legitimate substrate. Why layer-2 is structurally counterfeit. Why custodial digits are not the asset. The mathematical and structural reasoning, with worked analogies, presented as a standalone reference for projects building on Bitcoin's original design.
The protocol is the only legitimate substrate. Properties enforced by the protocol — backing, exchange, ownership, qualification, counting, presentation — are properties that can be verified by anyone running the protocol. Properties asserted off-chain are claims, not realities. The chain is the verification layer; everything else is unverified assertion.
Every layer-2 mechanism introduces a trusted intermediary that defines whether the layer-2-to-layer-1 equivalence holds. The intermediary can modify the relationship, suspend it, or fail. A 1:1 relationship between an off-chain claim and an on-chain reality is achievable only through a trusted bridge, and a trusted bridge is by definition not trustless. This is structurally identical to how the gold-standard paper note was layer-2 on top of gold: a piece of paper, no matter how well-printed, is not gold. The promise of redemption is what made paper "equal" gold. The promise was modifiable, was modified, and the equivalence was abolished. The paper became fiat; the gold went elsewhere. The same mathematical pattern operates in every layer-2 system in cryptocurrency, regardless of the intentions of those building it.
The Bitcoin Cash network does not passively ignore off-chain activity. It actively verifies every transaction submitted to it against protocol rules. Transactions trying to spend something the protocol doesn't recognize as a legitimate asset are rejected, not ignored. This is the same property as a bank inspecting a bill before accepting it — counterfeit bills are not "invisible," they are refused. Off-chain claims of value that try to enter on-chain state are similarly refused at the validation layer.
Money in a custodial account is digits in a ledger maintained by the custodian. If the custodian has no reserves, the digits represent nothing. The user has only a claim against the custodian, not the asset itself. The protocol does not know about the custodian's ledger; the protocol only knows about its own state. From the protocol's perspective, the user owns whatever they hold on-chain at addresses they control, and nothing else. Custodial digits are off-chain assertions that the protocol does not recognize.
The technical record is documented in Bitcoin's whitepaper and Satoshi's contemporaneous writings (see Vol. 13). The whitepaper specifies on-chain scaling. Satoshi's positions on large blocks and against centralizing modifications are explicit in the primary sources. The appearance of contestation in the current ecosystem is the result of informational-environment capture (see Vol. 14), not actual ambiguity in the technical record. The structural arguments developed in this document are internally consistent and stand on their own merit regardless of whether the contestation in the surrounding environment is acknowledged or settled.
For any project building on the original design: load-bearing properties should be defined and enforced by the protocol, not by intermediaries, off-chain claims, or trust assumptions. Backing, exchange, voting, allocation, ownership — each becomes a structural reality when relocated to protocol enforcement, and remains an unverified assertion when it lives in any layer above the protocol. The choice between these two states is the choice between cryptographic verifiability and trust-based assertion.
A digital asset has properties to the extent that the protocol it lives on enforces those properties. A backing claim is real to the extent that the protocol enforces backing. A voting right is real to the extent that the protocol verifies eligibility. An ownership claim is real to the extent that the protocol recognizes the owner's address as controlling the asset.
Properties asserted outside the protocol — in custodial ledgers, exchange databases, layer-2 channel states, wrapped representations on other chains, off-chain governance announcements — are claims about reality, not reality itself. They become reality only if and when they produce verifiable consequences within the protocol. Until they do, they exist in a separate informational space that the protocol does not recognize.
This is not a metaphysical claim or an ideological position. It is a structural description of how the protocol operates. Bitcoin Cash, like any protocol-defined system, has internal state (the chain) and verification rules (the consensus protocol). The internal state is what the protocol enforces; the verification rules are how the protocol decides what enters the state. Everything outside this is, from the protocol's perspective, not yet real.
The on-chain-only design philosophy takes this structural property seriously and builds within it consistently. Projects following this philosophy locate their load-bearing properties on the protocol, not in any layer above it. The cost of doing so is that operations must conform to the protocol's constraints; the benefit is that the operations inherit the protocol's verifiability and immutability.
The clearest historical parallel for the layer-2-to-layer-1 relationship is the paper note's relationship to gold under the gold standard. The parallel is exact, not metaphorical. The structural mechanics are the same.
Phase 1 — The original arrangement. Gold is the monetary substance. It is heavy, scarce, expensive to verify, and inconvenient for everyday transactions. The paper note is introduced as a convenience — a claim on gold redeemable at the issuing bank. The note's value derives entirely from the redeemability. The note is, mathematically, layer-2 on top of gold.
Phase 2 — The normalization. Over time, the paper note circulates in place of gold. Most transactions happen in notes. The notes are treated as money. The gold sits in the bank, held by the issuer, used only for rare large settlements between institutions. The "convenience" layer becomes the dominant layer.
Phase 3 — The capture. The issuer accumulates gold reserves. The relationship between notes outstanding and gold reserves becomes opaque. The note holders cannot, in practice, all redeem at once — there is not enough gold to honor universal redemption. The issuer maintains the redeemability claim as long as the system is operating under normal conditions; the claim becomes contingent under stress.
Phase 4 — The recognition. Eventually, the issuer formally suspends redemption. The notes are now fiat — not backed by gold, not redeemable for gold, but still circulating as money because the population has adapted to using them and because the issuer enforces their use through legal-tender laws. The gold has been quietly transferred from the population's holdings to the issuer's holdings. The layer-2 became the dominant layer; the underlying layer-1 was demonetized.
The paper note was counterfeit from the launch. A piece of paper, no matter how well-printed, is not gold. The two have different physical properties, different supply dynamics, different verification procedures. The paper's claim to equal gold rested entirely on the issuer's promise. The promise is the bridge. The bridge is fragile by design — it can be modified, contingent on conditions, or suspended outright.
The same structural logic applies to every layer-2 mechanism in cryptocurrency. A wrapped token on another chain is not the base asset. A Lightning channel balance is not Bitcoin. A custodial deposit at an exchange is not the asset the depositor believes they own. The equivalence in each case rests on the intermediary's promise — the channel partner's honesty, the bridge operator's solvency, the custodian's reserves, the sidechain validators' alignment. Each promise is the bridge. Each bridge is fragile by design.
This is not a claim about the intentions of layer-2 developers. Most layer-2 systems are built by people with honest motivations who do not understand themselves to be reproducing the gold-standard pattern. The pattern operates regardless of intent. The mathematics of layer-2-to-layer-1 relationships are what they are — a 1:1 relationship between an off-chain claim and an on-chain reality is achievable only through a trusted bridge, and a trusted bridge is, by definition, not trustless.
The layer-2 promoter who responds "but our bridge is secure" misses the point. The question is not whether a particular bridge is secure today. The question is whether the structural relationship — claim depends on bridge depends on intermediary — is the same as the gold-standard pattern that has been demonstrated to fail in every historical case. The answer is yes, structurally. The specific bridge may be more or less secure than historical analogs, but the structural vulnerability is the same.
To understand what the Bitcoin Cash network does with off-chain claims, the cleanest analogy is a bank inspecting currency. The analogy is exact in structure.
A customer walks into a bank with a stack of bills, claiming the stack is $10,000. The bank does not simply accept the customer's claim and credit their account with $10,000. The bank inspects the bills. The bills pass through verification procedures — visual inspection, ultraviolet light, magnetic ink detection, watermark verification, possibly more sophisticated authentication. Real bills pass verification and are accepted. Counterfeit bills fail verification and are rejected.
If the customer's stack contains $6,000 in real bills and $4,000 in counterfeit, the bank credits the customer's account with $6,000. The other $4,000 is not "ignored" or "invisible to the bank." It is detected and refused. The counterfeit bills do not enter the bank's ledger because the bank actively prevents them from doing so.
The customer's verbal claim — "I have $10,000 here" — does not determine the outcome. The bank's verification procedure determines the outcome. The bank does not credit accounts based on customer assertions; it credits based on verified instruments.
Bitcoin Cash operates on the same principle, scaled to a different medium. A user submits a transaction. The transaction asserts ownership of certain inputs and proposes their consumption. The protocol does not accept the transaction based on the user's assertion. The protocol validates the transaction against consensus rules. The protocol checks whether the asserted inputs exist in the UTXO set, whether the signatures match the addresses controlling those inputs, whether the script conditions are satisfied, whether no double-spending is attempted.
If the transaction passes validation, the protocol accepts it and updates chain state accordingly. If the transaction fails validation, the protocol rejects it. The user's intent does not override validation. The chain does not record transactions based on what the user wanted to happen; it records based on what the protocol verified.
The parallels:
| Bank | Bitcoin Cash Protocol |
|---|---|
| Customer brings claim. "I have $10,000 in this stack." | User submits transaction. "I assert these inputs are mine and propose this output." |
| Bank inspects with verification procedures. UV light, watermarks, ink authentication. | Protocol validates against consensus rules. UTXO check, signature check, script execution, double-spend check. |
| Real bills accepted. Entered into the bank's ledger. | Valid inputs accepted. Transaction confirmed; chain state updated. |
| Counterfeit bills refused. Do not enter the ledger. | Invalid inputs cause rejection. Transaction refused; chain state unchanged. |
| Customer's verbal claim doesn't override inspection. | User's intent doesn't override validation. |
| Counterfeit doesn't enter the bank's ledger. It exists outside the bank's recognition. | Invalid transaction doesn't enter the chain. It exists outside the protocol's recognition. |
The bank does not say "the customer believes the bills are real, so we'll record them conditionally." It rejects them. Bitcoin Cash does not say "the user has off-chain claims to this asset, so we'll process the transaction conditionally." It rejects it.
The protocol's verification is the legitimacy mechanism. What passes verification becomes part of the chain. What fails verification does not exist from the chain's perspective. This is not passive non-acknowledgment — it is active inspection and active rejection, the same as any verification system that takes its job seriously.
The active-verification property forecloses entire categories of attempts to translate off-chain reality into on-chain state. Each category fails for the same structural reason: the protocol does not accept claims that don't pass its verification.
Wrapped representations on other chains. An asset wrapped on Ethereum or any other chain is not the underlying asset. The wrapper is a token issued by some custodian or contract on the other chain. If the custodian or contract claims to back the wrapped token 1:1 with the underlying asset, that claim depends on the custodian's solvency, the bridge's integrity, the other chain's security model. From the Bitcoin Cash protocol's perspective, the wrapped representation is not the underlying asset — it is a separate token on a separate chain with separate properties. Attempts to use the wrapped token as if it were the underlying asset on Bitcoin Cash fail because the Bitcoin Cash protocol does not know about the wrapper and does not check the other chain.
Custodial holdings. A user with a balance at a centralized exchange does not hold the underlying asset. They hold a claim against the exchange. The exchange holds (or in failed cases, fails to hold) the actual asset. If the user tries to use their exchange balance as if they directly held the on-chain asset, the protocol rejects the attempt — the user's address does not control the on-chain asset. The exchange's address does. Only the exchange can produce transactions involving the asset; the user must withdraw the asset to their own address first, at which point the exchange must perform the on-chain transfer for the asset to become the user's in the protocol's recognition.
Lightning Network channel balances. A balance in a Lightning channel is not Bitcoin. It is a position in a channel between two parties, anchored to Bitcoin only at channel open and close. During the channel's life, the balance is determined by the channel's internal state, which is enforced by the channel partners' cooperation. If a channel partner becomes uncooperative, the channel must be closed through the dispute mechanism, which may produce a different on-chain settlement than the user expected. The channel balance is a claim within the channel's trust model, not an on-chain reality.
Sidechain holdings. Assets held on a sidechain anchored to Bitcoin Cash are not Bitcoin Cash assets. They are tokens or balances on the sidechain, enforced by the sidechain's consensus (which is typically weaker than Bitcoin Cash's and may have entirely different security properties). The "anchor" to Bitcoin Cash is a mechanism by which the sidechain operators commit to maintaining the sidechain's relationship to Bitcoin Cash — a commitment that depends on the sidechain operators' integrity and continued operation.
Off-chain governance representations. A platform that issues governance tokens claiming to represent voting weight in a Bitcoin Cash protocol is, from the protocol's perspective, just issuing tokens. The voting weight claim is an off-chain assertion. If the Bitcoin Cash protocol or any application on it implements voting that depends on actual on-chain assets, the off-chain governance tokens are irrelevant — the on-chain voting reads on-chain state, not off-chain governance ledgers.
The pattern is consistent across categories. The protocol verifies what it sees on-chain. It does not check external chains, custodial databases, sidechain consensus, or off-chain claims. Everything outside the protocol exists in a separate informational space that the protocol does not recognize, and attempts to translate from that space to on-chain state fail at the validation layer.
Proponents of layer-2 systems sometimes argue that their specific construction achieves 1:1 equivalence with the base layer through technical sophistication — careful cryptographic design, multi-signature controls, optimistic challenge periods, fraud proofs, zero-knowledge validation, federation models, threshold cryptography. The argument is that with sufficient engineering, the bridge can be made strong enough that the layer-2 representation is effectively equivalent to the base layer.
The structural response: no partial-trust mechanism is fully trustless. Every bridge introduces failure modes that don't exist at the base layer. The failure modes can be reduced in probability through engineering, but they cannot be eliminated. The base layer has no such failure modes because it has no bridge.
Specific failure modes that bridges introduce:
— Channel partner abandonment (Lightning Network) — channel must be closed through dispute mechanism, potentially with different terms than the user expected
— Sidechain validator collusion — sidechain validators can finalize states that don't correspond to the sidechain's stated rules; the anchor to the base chain is enforced by the validators themselves
— Rollup operator censorship — operators can refuse to include transactions, delay them, or prioritize their own
— Custodial counterparty insolvency — the custodian's balance sheet may not actually back the wrapped representations they issue
— Bridge contract bugs — bridge contracts have been the source of multiple billion-dollar exploits in crypto's history; the bridge code is itself code that can be broken
— Regulatory or legal pressure on intermediaries — channel partners, custodians, bridge operators, rollup sequencers can be ordered by regulators to freeze, seize, or modify positions
— Cryptographic assumption failures — some layer-2 systems depend on cryptographic assumptions (e.g., specific elliptic curves, specific hash functions) that may be invalidated by future cryptanalysis or quantum computing
Each of these failure modes has occurred or could occur. None of them apply to the base layer because the base layer is the verification system rather than depending on a separate one. A transaction confirmed on Bitcoin Cash is verified by Bitcoin Cash consensus; there is no operator with discretion over it, no intermediary whose solvency it depends on, no bridge whose security it inherits.
The proponent of a strong bridge responds: "But our specific bridge minimizes all of these failure modes." This may be true. The structural point is independent: a layer-2 system can never reach zero on these failure modes. The base layer reaches zero by construction.
Furthermore, the structural argument doesn't depend on judging any specific layer-2 system harshly. A well-engineered layer-2 system might be more reliable than a poorly-engineered one. But "more reliable than another layer-2" is not equivalent to "equivalent to the base layer." The structural relationship — layer-2 representation depends on bridge depends on intermediary — is invariant across all layer-2 systems regardless of engineering quality.
The base layer has no bridge because it is the verification system itself. The base layer is what bridges connect to. The bridge is by definition external to the base layer; the base layer is by definition not the bridge. Any system that introduces a bridge to the base layer introduces a structural component that the base layer does not have.
Custodians introduce a class of failure that the protocol does not have. The custodian's solvency, regulatory compliance, operational integrity, and willingness to honor withdrawals are all separate concerns from the protocol's properties. A custodian can be perfectly trustworthy today and fail tomorrow due to regulatory action, internal fraud, technical failure, or external attack. The protocol cannot be made worse by the custodian's failure because the protocol does not depend on the custodian.
If you hold an asset on-chain at an address you control, the only entity that can affect your holding is you (with your private key). If you hold an asset at a custodian, the custodian's choices and circumstances can affect your holding. These are categorically different security models. The first is what the protocol provides; the second is something a layer above the protocol provides at the cost of reintroducing trust.
They are claims against the custodian. The custodian has issued a record on their internal ledger saying you have X amount. If the custodian honors withdrawals when you request them, your claim is converted into the actual asset and you receive it on-chain. If the custodian cannot or will not honor withdrawals, your claim is just an entry in a ledger you don't control, with whatever recourse the legal system provides.
The most concrete way to see this: if the custodian has no reserves — if they have promised more assets than they actually hold — then your "balance" is digits in a database, backed by nothing. The protocol does not know about your balance and cannot help you recover it. Your only recourse is against the custodian directly.
This is not a theoretical concern. Multiple major exchanges have failed with billions of dollars of user balances unrecoverable. The users' digits in the exchanges' databases were not the assets. The actual assets either didn't exist, were stolen, or were used for other purposes. The users were creditors of insolvent companies, not holders of the assets they thought they had.
Direct on-chain ownership requires the user to manage their own private keys, understand transaction construction, pay protocol fees for each operation, and accept full responsibility for their assets. This is more demanding than using a custodian.
The protocol is not designed to be maximally convenient. It is designed to be maximally verifiable. The convenience of custodial relationships is purchased with trust in the custodian. The verifiability of direct ownership is purchased with operational complexity for the user. These are trade-offs, not strict improvements in either direction.
The on-chain-only design philosophy accepts the operational complexity as the cost of cryptographic ownership. Users who want convenience over verifiability can use custodians, but they should do so understanding what they are giving up — and they should not expect protocol-level guarantees from custodial relationships.
The structural argument is not that direct ownership is universally better than custodial relationships for every user. It is that protocol-level properties only attach to direct ownership. If you want the protocol's verification, integrity, and immutability guarantees, you must hold the asset directly. If you accept custodial convenience, you accept trust in the custodian as part of the deal.
This is the question that drove the layer-2 push in BTC and is one of the central disagreements documented in Vol. 13. The on-chain scaling position — held by Satoshi in the original whitepaper and by Bitcoin Cash since the 2017 fork — is that the base layer scales through increasing block sizes and other on-chain efficiency improvements. The layer-2 scaling position is that the base layer should stay constrained and transactions should move off-chain.
The on-chain-only philosophy goes with the on-chain scaling position. The reasoning: layer-2 scaling reintroduces the intermediary that the base layer eliminated. It is "scaling" only in the sense that it allows more transactions to be processed by intermediaries — not more transactions to be processed by the protocol. Calling intermediary processing "Bitcoin scaling" obscures what is actually happening: a different system using Bitcoin as a settlement layer is processing transactions, and those transactions are being labeled as if they were Bitcoin transactions.
The on-chain scaling answer to congestion is to increase the protocol's capacity, not to move transactions outside the protocol. Block size, transaction efficiency, validation parallelization, hardware improvements — all are on-chain levers. Layer-2 is not a scaling solution; it is a different network that uses Bitcoin as anchoring.
No. Layer-2 systems are real engineering accomplishments. Lightning Network is a working system. Sidechains are working systems. Rollups are working systems. The people building them are doing serious technical work.
The structural claim is not "layer-2 systems don't work" or "their developers are bad people." The structural claim is "layer-2 systems are not the protocol they anchor to; they are separate systems with separate trust models that use the protocol as an anchor."
This distinction matters because it affects what users should expect. A user transacting on Lightning has the security model of Lightning, not the security model of Bitcoin. A user holding wrapped BTC on Ethereum has the security model of the wrapper plus Ethereum, not the security model of Bitcoin. Conflating these gives users a false sense of inheriting the base layer's properties when they have actually accepted a different set of properties.
Honest layer-2 development would acknowledge this clearly: "This system uses Bitcoin as an anchor, but it is a separate system with its own trust model and its own failure modes." Some layer-2 developers do communicate this way. Others conflate their system with the base layer in marketing, which is the part of the layer-2 landscape that the on-chain-only critique most directly addresses.
The philosophical argument has practical consequences. Projects that take the on-chain-only philosophy seriously build differently than projects that don't, and the resulting systems have structurally different properties.
Backing becomes real. If a backed asset's backing is enforced by the protocol — the redemption rate, the redemption mechanism, the supply ceiling, all encoded in immutable contracts — then "backing" is not a marketing claim but a structural property. A holder can verify the backing without trusting the issuer. The issuer cannot quietly degrade the backing because the backing is not in the issuer's control.
Exchange becomes deterministic. If asset exchange is conducted through a protocol-enforced mechanism (a mathematical exchange standard with fixed rates), then the exchange has no counterparty risk, no market manipulation surface, no slippage, no liquidity dependencies. Every actor faces the same exchange terms. The exchange mechanism is the same for retail and institutional, for early and late participants, for small and large transactions.
Voting becomes verifiable. If voting is conducted on-chain, with qualification, counting, and presentation all handled by the protocol, then voting outcomes are verifiable by anyone. No election official has discretion over the count. No media outlet has authority to declare the result. The protocol's state is the result; the result is whatever the protocol's state shows.
Allocation becomes auditable. If revenue allocation flows directly through on-chain transactions, then every disbursement is visible the moment it happens. No quarterly report stands between the commitment and its execution. Anyone watching the chain can verify what is allocated to whom.
Ownership becomes literal. If you hold an asset at an address you control, you own it. The protocol enforces your ownership. No third party can seize it, freeze it, or modify it. The cost is the responsibility of managing your own keys; the benefit is that no one else's choices or circumstances can affect your holdings.
Each of these properties is unavailable in systems that relocate the relevant function to intermediaries. Custodial backing depends on the custodian. Counterparty exchange depends on the counterparties. Trusted-intermediary voting depends on the intermediaries. Quarterly-reported allocation depends on the reporter. Custodial ownership depends on the custodian.
The on-chain-only philosophy is the discipline of refusing these dependencies. Projects that follow it pay the cost of operating within protocol constraints; they receive the benefit of properties that intermediary-based systems cannot provide regardless of engineering quality.
The on-chain-only design philosophy, in its fullest form:
1. The protocol is the legitimacy layer. Properties are real to the extent they are protocol-enforced.
2. Layer-2 systems are structurally counterfeit. They use intermediaries to assert equivalences that the protocol does not verify.
3. The protocol's verification is active. Transactions that fail validation are rejected, not ignored. Off-chain claims that try to enter on-chain state are refused at the validation layer.
4. Custodial holdings are not the asset. They are claims against the custodian. The protocol does not know about them.
5. The base layer has no bridge. Any system that introduces a bridge introduces failure modes the base layer doesn't have.
6. The structural pattern of layer-2-as-counterfeit is identical to the historical gold-standard pattern. Both produce the same trajectory — convenience layer becomes dominant, underlying asset is accumulated by the issuer, redemption is eventually suspended, the original layer is demonetized.
7. The contestation around these points in the broader Bitcoin ecosystem is the result of informational-environment capture (see Vol. 14), not actual ambiguity in the technical record (see Vol. 13).
8. Projects taking this philosophy seriously build with load-bearing properties relocated to protocol enforcement. The cost is operational complexity within protocol constraints. The benefit is verifiability, immutability, and the elimination of intermediary failure modes.
This is the reference. Project documents can cite it instead of re-litigating the underlying arguments. When a question arises — why on-chain only, why not layer-2, why not custodial, why not synthetic — the answer lives here, in the structural form that applies regardless of which specific project is asking.