The Toll Road You Were Promised Would Be Free: How Refusing to Scale Rebuilds the Banks
Or: The Lightning Network is a hub-and-spoke payment processor wearing a hoodie.
The previous essay argued that general-purpose economic networks converge on one dominant standard, that multiple blockchains recreate the intermediaries they claim to eliminate, and that if one chain can do everything more cheaply, fragmentation is an artificial tax. This essay asks the prior question: what makes a blockchain capable of absorbing all that activity in the first place?
The answer is scaling. And the refusal to scale is the original sin from which every subsequent intermediary descends.
I. The Design Specification
The Bitcoin white paper is eight pages long. Its objective is stated in the abstract: a peer-to-peer electronic cash system allowing payments to be sent directly from one party to another without going through a financial institution (Nakamoto, 2008). The word “directly” is doing the work. The system was designed to eliminate intermediaries from electronic value transfer. Not to reduce them. Not to replace them with different intermediaries wearing different labels. To eliminate them.
This objective imposes a design constraint: the base layer must be capable of handling the transaction volume that economic activity demands. If the base layer cannot handle the volume, then either activity is excluded or it is moved somewhere else. “Somewhere else” is, by definition, not the peer-to-peer layer. It is an additional system, with its own trust assumptions, its own operators, its own failure modes, and—inevitably—its own fees.
That “somewhere else” is an intermediary. Call it a layer, a channel, a sidechain, a rollup, or a bridge. The economic function is identical: a third party stands between sender and receiver and extracts rent for the service of settlement.
II. The Artificial Scarcity of Block Space
Bitcoin Core’s block size was limited to one megabyte. This was a temporary anti-spam measure in the early protocol, not a permanent architectural commitment. The consequence, once transaction volume grew, was predictable and predicted: a fee market emerged in which users competed for scarce block space by bidding up transaction fees. At peak congestion, median fees exceeded $30. During the 2017 and 2021 fee spikes, small-value transactions became economically irrational to settle on-chain.
This is not a side effect. It is the direct, foreseeable, and entirely avoidable result of refusing to increase the capacity of the base layer. Block space scarcity is a policy choice, not a physical constraint. The protocol could have accommodated larger blocks. The decision not to do so was ideological—rooted in a particular vision of decentralisation that equated full-node operation by individual hobbyists with security, and that treated any increase in storage or bandwidth requirements as unacceptable centralisation pressure.
The economic consequence of that decision was to transform Bitcoin from a peer-to-peer cash system into a settlement layer—a system where only high-value transactions justify the fee, and everything else must be handled somewhere other than the chain Nakamoto described.
Budish (2025), in a treatment published in the Quarterly Journal of Economics, showed that the flow cost of maintaining Nakamoto-style trust scales linearly with the value secured. His three-equation framework demonstrates that the ongoing cost of blockchain security must be large relative to the one-off benefit of attacking the system, and that this cost scales with the economic stakes. The implication is that a blockchain whose fee revenue cannot support its security budget is structurally dependent on block subsidies, speculation, or external enforcement—none of which are peer-to-peer properties. A chain that scales transaction volume, by contrast, can generate the fee revenue to sustain security from economic activity alone, without requiring artificial scarcity or subsidy dependence.
III. Off-Chain Is Not On-Chain
This point should not require elaboration, but evidently it does.
When a transaction occurs on-chain, it is validated by the consensus mechanism, recorded in the distributed ledger, and immutably settled. The sender and receiver are the only necessary parties. There is no intermediary. This is the design specification. This is what “peer-to-peer” means.
When a transaction occurs off-chain—through a payment channel, a sidechain, a rollup, or any other layered construction—it is not validated by the main chain’s consensus mechanism at the time of execution. It is settled later, in aggregate, if at all. Between execution and settlement, the transaction exists in a different trust environment with different assumptions, different operators, and different risks.
The distinction is not terminological. It is structural. An off-chain transaction is a promise that may eventually be settled on-chain. An on-chain transaction is a fact that has already been settled. The entire history of financial crises is the history of promises failing to become facts.
IV. The Lightning Network: Empirical Centralisation
The Lightning Network is the flagship off-chain scaling solution for Bitcoin Core. It operates through bilateral payment channels, funded by on-chain transactions, through which parties can exchange value without broadcasting each transfer to the blockchain. Multi-hop routing allows payments between parties who do not share a direct channel, by routing through intermediary nodes.
In theory, this is a decentralised mesh. In practice, it is a hub-and-spoke payment network.
Lin et al. (2020), publishing in the New Journal of Physics, analysed the structure of the Lightning Network over eighteen months from its 2018 launch. Their findings were unambiguous: the BLN exhibits a highly centralised structure, with a small core of well-connected hub nodes surrounded by a large periphery of weakly connected participants. The average Gini coefficient of node strengths across the network’s history was approximately 0.88, meaning that 10% of nodes held 80% of the bitcoins at stake, and 50% of nodes held 99%. The network structure was, in the authors’ terms, increasingly compatible with a core-periphery topology.
Martinazzi and Flori (2020), in PLOS ONE, confirmed these findings independently. Their topological analysis found that the Lightning Network represents a centralised configuration with few highly active nodes playing as hubs. The removal of these central nodes was shown to produce a substantial drop in network efficiency, while the network showed robustness only against random (non-targeted) disruptions. Improvements in network efficiency during their sample period were attributable to increased channel capacity, not to better structural allocation.
Zabka et al. (2022), presenting at Financial Cryptography, conducted a betweenness-centrality analysis and found that a small number of nodes attracted a significant fraction of all routed transactions. Their subsequent journal-length treatment in Telecommunications Policy (Zabka et al., 2024) documented that the Gini index for Lightning Network inequality had risen by over 15% across their measurement period, with the network becoming progressively more concentrated over time.
These are not polemical claims. They are peer-reviewed empirical measurements of network topology. And they describe a structure that is functionally equivalent to a traditional payment network: a small number of large, well-capitalised routing nodes through which the majority of transactions flow, each extracting a routing fee for the service.
In economic terms, the Lightning hub is a payment processor. It is a financial intermediary. It stands between sender and receiver, holds capital in escrow, routes payments for a fee, and can fail, be attacked, or refuse service. The fact that it uses cryptographic channels rather than correspondent banking does not change its economic function.
V. Sidechains: Federated Trust by Another Name
Sidechains are independent blockchains pegged to a parent chain, allowing assets to move between them. In the Bitcoin ecosystem, the most prominent implementation is Blockstream’s Liquid Network, a federated sidechain in which a fixed set of functionaries—known entities, not anonymous miners—validate transactions and manage the two-way peg.
A federated sidechain is, in structural terms, a consortium of trusted intermediaries managing a shared ledger. The trust model is explicitly non-Nakamoto: users must trust that a threshold majority of federation members will behave honestly, will not collude, will not be compromised, and will not censor transactions. The federation is the sidechain’s equivalent of a board of directors.
This is not a criticism of the engineering. Liquid works for its intended purpose. The criticism is of the claim that this architecture preserves the peer-to-peer, trustless properties of the Bitcoin white paper. It does not. It replaces Nakamoto consensus with a known set of signatories. That is a different trust model. The user is trusting a federation, not a protocol.
The same analysis applies to every proposed sidechain construction. Drivechains, merge-mined sidechains, and validity-proof chains each introduce their own trust assumptions distinct from the base layer. Some rely on miner honesty under incentive structures that have not been tested at scale. Others depend on cryptographic proofs whose verification costs create their own bottlenecks. The common thread is that none of them provide the same security guarantee as native on-chain settlement under full proof-of-work consensus. Every sidechain is a trust downgrade dressed as a feature upgrade.
The irony is thick enough to cut: the organisations building these sidechains and layers are, in many cases, the same organisations that argued against increasing the block size. They opposed the simple solution—make the chain bigger—and then built complex, fragile, intermediated alternatives whose entire commercial justification depends on the base layer remaining small. The fox did not merely enter the henhouse; it bricked up the door and sold the hens a ladder.
The pattern is consistent across every off-chain and side-chain construction: the trust model degrades as activity moves away from the base layer. On-chain, the security model is Nakamoto consensus backed by proof-of-work. On the Lightning Network, the security model requires channel monitoring, penalty transactions, and routing through intermediary nodes whose reliability and honesty cannot be protocol-enforced. On a federated sidechain, the security model requires trusting a defined set of functionaries. On a bridge, the security model is—as the previous essay documented—catastrophically fragile.
Each step away from the base layer is a step toward intermediation. The question is whether those steps are necessary.
VI. The Scaling Alternative
They are not necessary if the base layer can scale.
The economic logic is direct. If the blockchain can process the required transaction volume natively—on-chain, validated by consensus, settled immediately—then there is no need for payment channels, no need for federated sidechains, no need for bridges, no need for rollups, and no need for the additional trust assumptions, costs, and failure modes that each of these entails.
BSV’s architectural choice was to remove the block size limit and allow the chain to scale with demand. This is a factual design decision. Whether it succeeds in practice is an empirical question about throughput, latency, reliability, cost, and sustained performance under load. But the design objective is unambiguous: keep everything on one chain, settle everything on-chain, and let the chain grow to meet demand.
This approach preserves the properties that the white paper specified. Every transaction is validated by consensus. Every transaction is recorded in the public ledger. Every settlement is final at the time of inclusion. No payment processor sits between sender and receiver. No federation manages a separate trust domain. No bridge carries assets between incompatible environments.
The standard network-economics arguments from the previous essay apply with even greater force here. Katz and Shapiro (1985) showed that in markets where compatibility generates value, larger networks produce stronger adoption externalities. Economides (1996) demonstrated that compatibility converts potential complementarity into actual value. If all transactions settle on one chain, the network effect is maximal. If transactions are dispersed across channels, sidechains, and layers, the network is fragmented and the conversion costs identified in the previous essay reappear.
Scaling the base layer is not merely a technical preference. It is the only architecture that preserves the system’s original design specification while simultaneously capturing the network-economic advantages of a unified ledger.
VII. The Incentive Structure of Not Scaling
If the case for on-chain scaling is this straightforward, one must ask why the dominant BTC implementation chose not to scale. The technical arguments about node requirements are real but overstated—storage and bandwidth costs have fallen by orders of magnitude since 2009, and the hardware requirements for validating larger blocks are well within the reach of commercially available infrastructure. The honest answer is that the refusal to scale serves a different constituency.
When block space is artificially scarce, fee revenue per transaction rises. When base-layer capacity is constrained, the demand for off-chain solutions creates new markets for the firms and developers building those solutions. Lightning Network operators, sidechain federations, bridge developers, and Layer-2 platforms are businesses. They have investors, employees, revenue models, and equity. They exist because the base layer is constrained. If the base layer could handle the volume, their products would be unnecessary.
This is not a conspiracy theory. It is a standard observation from industrial organisation. When a platform constrains capacity, the constraint creates demand for complementary services. The providers of those services have a rational interest in maintaining the constraint. Katz and Shapiro (1994) described exactly this dynamic in their treatment of systems competition: in systems markets, the compatibility decisions made by platform owners determine which complementors prosper, and complementors whose business depends on fragmentation will resist unification.
The multi-layer BTC architecture is not an emergent solution to a hard problem. It is an artificial ecosystem created by an artificial constraint, populated by firms whose revenue depends on that constraint persisting. The intermediaries that Bitcoin was designed to eliminate have been reintroduced as Layer-2 service providers, and they have a structural incentive to ensure that the base layer never makes them redundant.
VIII. What Scaling Actually Means
Scaling is not merely about block size. It is about the capacity of the entire system—validation, propagation, indexing, storage, and query—to handle the volume that economic activity requires without degrading the security, finality, or auditability of the ledger.
This means that miners must be able to validate large blocks within consensus time. It means that transaction propagation must be efficient enough to prevent orphan-rate increases. It means that storage must be economically feasible over time. It means that the indexing and querying infrastructure must keep pace with the data. And it means that the economic model must sustain itself: that fee revenue from a high volume of low-fee transactions can replace block subsidies as they decline.
These are engineering problems, not impossibilities. They are solved, or solvable, by the same combination of hardware improvement, software optimisation, and infrastructure investment that has governed every other scaling problem in the history of computing. The Internet did not refuse to scale when packet volumes exceeded early router capacity. It scaled the infrastructure. The same logic applies.
Budish’s (2025) analysis in the QJE is instructive here from a different angle. His demonstration that the cost of Nakamoto trust scales linearly with the value secured implies that a blockchain must generate sufficient ongoing revenue to fund its security. A chain that processes millions of low-fee transactions generates that revenue through volume. A chain that processes thousands of high-fee transactions generates it through scarcity pricing—but scarcity pricing excludes the majority of potential economic activity and drives it into off-chain environments where the Nakamoto trust model does not apply. The scaling approach aligns the economic model with the security model. The non-scaling approach fractures them.
IX. The Architecture of Honesty
The honest formulation is this:
If you do not scale the base layer, you will need intermediaries. If you need intermediaries, you have rebuilt the financial system under new branding. If you have rebuilt the financial system under new branding, you have failed the design specification of the Bitcoin white paper.
The Lightning Network is empirically a centralised hub-and-spoke payment network (Lin et al., 2020; Martinazzi & Flori, 2020; Zabka et al., 2022, 2024). Federated sidechains are empirically consortium-managed trust systems. Bridges are empirically fragile, with over $2.8 billion in documented losses (Zhang et al., 2024; Rashid et al., 2025). Layer-2 platforms are empirically businesses that profit from base-layer constraints. None of these are peer-to-peer. None of these are trustless. None of these are what Nakamoto described.
A blockchain that scales its base layer does not need any of them. It processes transactions directly, settles them immediately, records them permanently, and charges a fee low enough that micropayments, data transactions, and high-frequency commercial activity are all economically viable. It captures the full network effect of a unified ledger. It does not fragment its security model across trust domains of varying quality. And it does not create business opportunities for intermediaries whose existence depends on the base layer’s failure to do its job.
This is not a sales pitch. It is a syllogism. The design specification requires peer-to-peer settlement. Peer-to-peer settlement requires on-chain capacity. On-chain capacity requires scaling. Scaling is therefore not optional. It is the necessary condition for fulfilling the system’s own stated purpose.
Everything else is a toll road wearing the costume of a public highway.
References
Budish, E. (2025). Trust at scale: The economic limits of cryptocurrencies and blockchains. The Quarterly Journal of Economics, 140(1), 1–62. https://doi.org/10.1093/qje/qjae033
Economides, N. (1996). The economics of networks. International Journal of Industrial Organization, 14(6), 673–699. https://doi.org/10.1016/0167-7187(96)01015-601015-6)
Katz, M. L., & Shapiro, C. (1985). Network externalities, competition, and compatibility. American Economic Review, 75(3), 424–440.
Katz, M. L., & Shapiro, C. (1994). Systems competition and network effects. Journal of Economic Perspectives, 8(2), 93–115. https://doi.org/10.1257/jep.8.2.93
Lin, J.-H., Primicerio, K., Squartini, T., Decker, C., & Tessone, C. J. (2020). Lightning network: A second path towards centralisation of the Bitcoin economy. New Journal of Physics, 22(8), 083022. https://doi.org/10.1088/1367-2630/aba062
Martinazzi, S., & Flori, A. (2020). The evolving topology of the Lightning Network: Centralization, efficiency, robustness, synchronization, and anonymity. PLOS ONE, 15(1), e0225966. https://doi.org/10.1371/journal.pone.0225966
Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf
Rashid, A., et al. (2025). SoK: Cross-chain bridging architectural design flaws and mitigations. Digital Communications and Networks. https://doi.org/10.1016/j.dcan.2025.100429
Zabka, P., Foerster, K. T., Decker, C., & Schmid, S. (2022). Short paper: A centrality analysis of the Lightning Network. In Financial Cryptography and Data Security (pp. 374–385). Springer. https://doi.org/10.1007/978-3-031-18283-9_18
Zabka, P., Foerster, K. T., Schmid, S., & Decker, C. (2024). A centrality analysis of the Lightning Network. Telecommunications Policy, 48(1), 102673. https://doi.org/10.1016/j.telpol.2023.102673
Zhang, M., Zhang, X., Zhang, Y., & Lin, Z. (2024). Security of cross-chain bridges: Attack surfaces, defenses, and open problems. In Proceedings of the 27th International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2024) (pp. 1–19). ACM. https://doi.org/10.1145/3678890.3678894