Transactions arrive continuously, while confirmation space appears in blocks. Congestion begins when more blockspace is requested between blocks than the next block can provide.
Any transaction left behind carries into the next round, where it meets new arrivals. One full block may create a small delay. Several full blocks turn that delay into a backlog, and the backlog can survive long after the original rush has passed.
How a traffic spike becomes a backlog
Sample traffic shown against a fixed capacity line
Room available
Blocks keep up and the queue clears.
Traffic spike
New work piles up while demand stays high.
Fee bidding
Higher fees move a transaction closer to the front.
How the Queue Grows
Suppose 1.4 blocks' worth of transactions arrive before the next block. That block clears one block's worth and leaves 0.4 waiting. If the same thing happens again, the waiting total reaches 0.8 blocks. Repeated overload turns a short wait into a long queue.
The running balance is simple:
New backlog = previous backlog + new arrivals - work cleared.
The queue grows whenever arrivals consume the whole block. Once traffic falls below capacity, only the unused part of each new block can clear older work.
Why Congestion Can Outlast the Rush
Only spare capacity clears a backlog. If current traffic uses 80 percent of each block, the remaining 20 percent can work through older transactions. A backlog equal to ten full blocks would take about 50 blocks to clear at that rate. The traffic spike may be over while users are still waiting.
Block timing can stretch the delay further. A proof-of-work interval is an average, so some blocks arrive early and others arrive late. A late block gives transactions more time to accumulate. Bursty demand can produce an hour of congestion within a mostly quiet day.
Fees Follow the Backlog
A node's mempool holds unconfirmed transactions it has accepted under local policy. Mempools can differ between nodes, and miners commonly select by fee rate while also accounting for transaction dependencies, packages, resource limits, and their own policies. A higher fee rate can improve a transaction's selection priority, but there is no single global queue. Block rules and block timing set the pace of confirmation, while fee pressure usually eases after higher-paying demand and the backlog fall.
What Sets Layer 1 Throughput
Four parameters set practical throughput: usable space in each block, the average footprint of a transaction, the average block interval, and the speed at which nodes can relay and validate a new block.
A rough throughput estimate is:
Usable blockspace / average transaction footprint / average block interval.
One transactions-per-second figure rarely describes a chain well. A batch payment can create many outputs. A consolidation may use many inputs. Contract activity can add scripts, signatures, or state changes. The same block limit can hold very different transaction counts.
Raising the limit gives the queue more room. Shortening the interval creates clearing opportunities more often. Larger blocks increase bandwidth, validation, and storage loads. Shorter intervals leave less time for a block to reach the network.
Two Approaches to Layer 1 Scaling
BTC: weight and efficiency
Bitcoin limits each block to 4 million weight units. SegWit moved signatures and scripts into a separate witness structure, then counted each witness byte at one quarter of the weight of other transaction data. SegWit transactions can therefore fit more useful data under the same weight ceiling. The exact gain depends on the mix of transactions in the block.
Taproot and Schnorr signatures save space on some complex spends. A cooperative multisignature spend can use one key-path signature, while a script-path spend reveals only the branch it used. Schnorr signatures have a fixed 64-byte format and can be batch verified.
BTC targets a ten-minute block average and retargets mining difficulty every 2,016 blocks. Its approach keeps a predictable upper bound on per-block work and looks for efficiency inside it. A sustained rush can still fill that bound and start a fee-driven queue.
BCH: headroom and adaptation
Bitcoin Cash raised its block limit to 32 MB in 2018. In 2024, ABLA made the limit adaptive. It updates after each block using an exponentially weighted history of mined block sizes. The 32 MB limit is its floor, and sustained use can move the limit upward at a controlled rate.
BCH added Schnorr signatures in 2019, reducing a typical signature from 71 or 72 bytes to a fixed 64 bytes. ASERT adjusts the mining target each block to keep the long-run block interval near ten minutes when hash rate changes.
BCH provides more immediate Layer 1 headroom and lets sustained demand influence future capacity. Node operators face higher possible bandwidth, validation, and storage loads as mined blocks grow.
Both Bitcoin Core and Bitcoin Cash Node use compact block relay. Peers send short transaction identifiers and reconstruct a block from transactions already in their mempools. They request only what is missing, saving relay bandwidth and often reducing propagation time.
What Extra Layers Add
Payment channels, sidechains, and rollups can move activity away from a base-layer queue. Channels add liquidity and monitoring requirements. Sidechains and rollups may rely on bridges, sequencers, or extra proof systems. The failures vary:
- Core Lightning, 2026: Version 26.06.7 fixed confirmed vulnerabilities; earlier releases became unsupported, with offline mode advised until operators could upgrade.
- smartBCH, 2022: The CoinFLEX bridge became stuck, leaving its BCH backing under a custodian's control and sidechain exits uncertain.
- Arbitrum One, 2023: A surge of inscriptions stalled the sequencer and feed, followed by a backlog and high gas prices during recovery.
- OP Mainnet, 2026: External nodes and RPC providers served a stale head for about 22 minutes, pushing throughput close to zero for part of the incident.
Their throughput belongs to a different operating and trust boundary from the base chain, so it should be measured separately.
In Blockspace Lab
Blockspace Lab models arrivals, transaction size, block capacity, block timing, backlog, and fee priority. Try a smooth traffic pattern and a bursty one with a similar average rate to see how much work carries forward.
The lab can show how a 4 million weight-unit ceiling, a 32 MB floor, or another limit changes a queue. It cannot decide whether a limit is safe for a live network. That requires node benchmarks, propagation data, storage costs, and real traffic measurements.
Sources
- Blockspace Lab: interactive congestion simulator
- BTC protocol: SegWit, compact block relay, Schnorr signatures, and Taproot
- BCH protocol: 32 MB block limit, ABLA, Schnorr signatures, and ASERT