This article is part 4 of the Bitcoin Cash: Built for the Future series, exploring BCH's technical design and long-term positioning.
Every blockchain faces the same question: how do you process more transactions without sacrificing decentralization and security? This tension, often called the blockchain trilemma, has no single correct answer. Bitcoin Cash emphasizes on-chain scaling while remaining open to Layer 2 solutions where they make sense. This article looks at how that works and where the tradeoffs lie.
The Scale of the Problem
Traditional payment networks operate at enormous throughput: Visa peaks at ~65,000 TPS, Mastercard averages ~5,000, PayPal ~1,000. No blockchain base layer comes close today. Getting there requires balancing scalability with decentralization and security, and every project navigates that differently.
How BCH Scales On-Chain
Adaptive Block Size (ABLA)
Since May 2024, BCH uses the Adaptive Blocksize Limit Algorithm (ABLA), which automatically adjusts the block size limit based on actual usage. Unlike BTC's fixed ~1–4 MB limit, ABLA responds to demand without requiring manual coordination.
Key properties:
- 32 MB floor: the limit never drops below this, preserving standby capacity
- Demand-driven growth: as blocks fill, the limit rises smoothly with built-in rate caps
- Elastic buffer: absorbs sudden demand surges, then gradually decays back
- Spam resistance: growing the limit requires sustained demand from >50% of hashrate
- Controlled rate: maximum growth of ~2× per year even under extreme sustained load
If adoption grows, capacity grows with it automatically, without requiring governance debates or upgrade coordination.
Theoretical Throughput at Various Block Sizes:
| Block Size | Avg Tx Size | Txs per Block | TPS (10-min blocks) |
|---|---|---|---|
| 32 MB (floor) | 250 bytes | 128,000 | ~213 |
| 32 MB (floor) | 400 bytes | 80,000 | ~133 |
| 32 MB (floor) | 500 bytes | 64,000 | ~107 |
| 64 MB | 250 bytes | 256,000 | ~427 |
| 64 MB | 400 bytes | 160,000 | ~267 |
| 128 MB | 250 bytes | 512,000 | ~853 |
| 128 MB | 400 bytes | 320,000 | ~533 |
| 256 MB | 250 bytes | 1,024,000 | ~1,707 |
| 256 MB | 400 bytes | 640,000 | ~1,067 |
A simple payment runs ~225–250 bytes; complex transactions are larger. At the 32 MB floor, baseline capacity is roughly 100–200+ TPS, with ABLA raising that ceiling as demand grows. This is still far from Visa-level throughput, but the limit is not fixed.
UTXO Parallel Validation
As covered in our UTXO advantages article, UTXOs are independent objects that can be validated simultaneously across CPU cores. Throughput scales naturally with hardware, without requiring protocol changes. Account-based systems like Ethereum must serialize state updates more carefully, which is one reason L2 rollups became central to Ethereum's scaling roadmap.
Supporting Optimizations
Several other improvements work alongside ABLA and UTXO parallelism:
- Schnorr signatures and optimized opcodes speed up per-transaction validation
- Graphene and compact blocks reduce block propagation bandwidth to a fraction of raw block size
- CTOR (canonical transaction ordering) enables more efficient propagation and parallel validation
- High-performance UTXO storage, pruning, and parallel IBD reduce node hardware requirements
Together, these help ensure that larger blocks don't proportionally increase network overhead.
How Other Chains Compare
BTC keeps L1 conservative (~7 TPS) and routes payments through Lightning. This preserves low node requirements but adds UX complexity. Ethereum uses an L2 rollup-centric approach that provides high throughput at the cost of fragmented liquidity and bridging friction. Solana maximizes L1 throughput with aggressive hardware requirements, achieving thousands of TPS but with centralization and stability tradeoffs. Cardano uses eUTXO with formal methods and modest base-layer throughput.
BCH scales L1 through larger blocks and UTXO parallelism. Simple payments stay fast and cheap on-chain, though current capacity remains well below traditional payment networks. Each approach reflects different priorities, and no single strategy has proven definitively superior.
Common Concerns
"Large blocks centralize the network." This is a legitimate concern. However, ABLA's growth rate (~2×/year max) is designed to stay within long-term hardware improvement trends, and at the current 32 MB floor, requirements remain manageable on consumer hardware.
"UTXO set growth." UTXO set size scales with active addresses and outputs, not directly with transaction volume. Efficient databases, pruning, and dust prevention policies help keep this in check.
"Can't scale without L2." On-chain scaling handles current usage and can accommodate significant growth. For Visa-level throughput, some combination of L1 and L2 will likely be needed for any blockchain. BCH's approach is to scale L1 while remaining open to L2 where it adds value.
Conclusion
BCH's scaling approach is to grow base-layer capacity through ABLA, parallel validation, and network optimizations, while keeping the door open for L2 solutions where they're useful.
This provides real benefits today: automatic capacity growth, low fees, and straightforward on-chain transactions. It also has real limitations. Even with ABLA, reaching traditional payment network scale will require continued infrastructure improvements and likely complementary L2 solutions for some use cases.
On-chain scaling is one viable strategy among several. BCH's implementation shows it can deliver tangible benefits in simplicity, fees, and user experience, while other chains demonstrate that alternative approaches have their own strengths.
