Blockchain scalability is the ability to process a larger useful workload without making validation, propagation, storage, or participation unacceptably fragile.
Transaction count per second is one measurement. It is not the whole system: transaction sizes vary, demand arrives in bursts, blocks are probabilistic, and a network that can produce a large block must still distribute and validate it.
A basic capacity model
For a rough steady-state estimate:
capacity ≈ block bytes ÷ average transaction bytes ÷ average block interval
Every term hides variability. A batched payout can represent many payments in one transaction. A token or contract transaction can be larger than a simple transfer. A ten-minute target does not produce a block exactly every ten minutes.
When incoming demand exceeds available blockspace for long enough, a backlog forms. Fee selection and miner policy then determine which transactions are included first.
Blockspace Lab lets you vary those factors without presenting the result as a forecast.
BCH's base-layer approach
Bitcoin Cash prioritizes more transaction capacity on the base layer. Its current consensus limit is controlled by the Adaptive Blocksize Limit Algorithm rather than a permanently fixed byte value.
ABLA responds to sustained block usage through bounded, gradual changes. It can raise the limit when blocks remain sufficiently full and reduce it under lower use, subject to its floor and adjustment rules.
ABLA does not measure hardware capacity directly. It is a demand-responsive consensus rule, so node software, operational benchmarks, and ecosystem planning still need to keep pace with the limit it permits.
What larger blocks cost
More on-chain throughput can increase:
- bandwidth required to receive and relay blocks;
- validation and database work during bursts;
- UTXO-set growth;
- historical storage and indexing costs;
- initial synchronization time;
- the advantage of well-connected mining infrastructure;
- the impact of implementation bugs or resource-exhaustion attacks.
Engineering techniques such as compact block relay, parallel script checks, pruning, efficient databases, and assume-valid or snapshot-style synchronization can reduce particular costs. They do not make the costs zero or remove the need for measurement.
Where the UTXO model helps
Transactions spending unrelated outputs have explicit, separate conflict sets. Nodes can parallelize some signature checks and transaction work, and applications can split independent positions across outputs.
That does not mean every workload scales linearly. A contract using one state UTXO serializes access to that state. Block acceptance still updates shared indexes and commitments. Hardware, software architecture, and workload shape determine the realized gain.
Fees under spare and scarce capacity
When available blockspace exceeds demand, users can often transact near the network's minimum accepted fee rate. If demand approaches or exceeds capacity, fee competition can emerge on BCH just as it can on other blockchains.
Larger or adaptive capacity changes how often scarcity occurs; it does not repeal scarcity. Miner minimums, wallet estimates, transaction size, and child or package policies also matter.
Layer 2 is a separate design axis
Payment channels, rollups, sidechains, federations, and other higher-layer systems can move repeated activity away from base-layer settlement. They introduce their own liquidity, data availability, proof, custody, routing, or bridge assumptions.
A chain can pursue both base-layer capacity and higher layers. The meaningful comparison is not "L1 versus L2" in the abstract, but which operations happen at each layer and what users must trust when moving between them.
Evidence to watch
A credible scaling claim should publish:
- sustained and burst validation benchmarks;
- block propagation measurements across realistic network conditions;
- node hardware and bandwidth requirements;
- UTXO-set and index growth;
- reorganization and mempool behavior under load;
- fee and inclusion outcomes for different transaction types;
- independent implementation agreement and test vectors.
BCH has a clear on-chain scaling policy and protocol machinery for adaptive capacity. Whether that approach supports much larger real demand depends on continuous implementation work, diverse node operation, and measured performance—not on a headline transaction rate.
For the relationship between demand, queues, and fees, read how blockchain congestion develops. The UTXO versus account-model guide separates state architecture from capacity claims.