Why TPS Alone Fails as a Measure of Blockchain Scalability

Claims about peak transactions per second (TPS) have become a shorthand for blockchain performance, yet those headline numbers rarely map to operational capacity when networks are genuinely decentralized. Benchmarks run on isolated nodes or in tightly controlled testnets measure execution speed but omit relay, verification, latency and bandwidth effects that dominate real deployments. Historical examples show theory diverging from practice: ambitious whitepaper figures have collapsed under realistic network conditions, while engineering projects have proved very high TPS in lab settings without the same results on live mainnets. The practical bottleneck is linear: as throughput rises, every full node faces proportionally higher verification and synchronization work until hardware and bandwidth limits bite. A different design philosophy separates execution from finality by having provers generate compact validity evidence that ordinary nodes can cheaply check; recursive zero-knowledge proofs exemplify this approach by collapsing many verifications into one. That trade shifts the heavy lifting to specialized provers, introducing new operational costs and orchestration challenges and raising questions about where centralization might reappear. Some recent client-level tests have demonstrated million-TPS numbers, and some teams claim multi-million theoretical ceilings, but live transaction mixes and vote or consensus messages typically lower real user-focused throughput to far smaller values. Economic signals such as fees and observed demand often give a clearer picture of usable capacity than synthetic TPS peaks because they reflect how a network behaves under actual load. Retrofitting proof-based verification onto chains designed for sequential execution is nontrivial; it requires rethinking state models, tooling, and validator incentives, which explains why most large protocols remain on traditional paths. The net technical takeaway is simple: raw execution speed is necessary but not sufficient for scalable, decentralized ledgers; sustainability requires matching verification cost models to network topology and economic incentives. For builders and investors, the practical implication is to treat headline TPS as a partial data point, to evaluate proof and prover economics, and to test performance in distributed, adversarial conditions before drawing conclusions about scalability.