Blockchain Congestion: How Queues Build and Fees Rise

You send a transaction, the next block arrives, and your payment is still waiting. There may be nothing wrong with it. More transactions may be competing for space than miners can fit into that block.

Transactions arrive throughout the day, while confirmations come in batches. Work left over from one block meets fresh arrivals before the next. A brief rush can create a backlog that takes much longer to clear than it took to form.

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.

In a simplified queue where transactions stay available until mined, the balance is:

New backlog = previous backlog + new arrivals - work cleared.

The backlog cannot fall below zero, and all three quantities need to use the same unit, such as bytes or weight units. The queue grows when arrivals exceed the space actually cleared. If arrivals exactly match it, an existing backlog stays the same size.

Real mempools also remove transactions for reasons such as expiry, replacement, or memory limits. That can shrink a node's queue without confirming the removed payments.

Why congestion can outlast the rush

To work off a backlog through confirmations, blocks need room beyond what new traffic consumes. Suppose new arrivals use 80 percent of each block's capacity. The other 20 percent is available to reduce the backlog, so ten blocks' worth of waiting work would take 50 blocks to clear.

That estimate assumes unchanged traffic, equally sized blocks filled whenever work is available, and no transactions leaving the queue for other reasons. On a chain averaging ten minutes per block, 50 blocks would mean roughly eight hours and twenty minutes. An individual transaction's wait also depends on its fee priority.

Block timing adds uncertainty. Ten minutes is a target average, so some blocks arrive much sooner and others much later. During a long gap, transactions keep accumulating. Even a mostly quiet day can have a congested hour.

How fees affect the wait

A node's mempool holds the unconfirmed transactions it has accepted under its local rules. There is no single global queue: nodes can see different transactions and apply different policies.

Miners commonly prioritize by fee rate, accounting for transaction dependencies and resource limits. A higher fee rate can improve your transaction's chances, but paying more does not make the next block arrive sooner or guarantee inclusion. A large absolute fee can also be misleading if the transaction itself is large.

Fees depend on the competition for the next block. A backlog of low-fee transactions can remain while more urgent payments confirm at relatively modest rates. Heavy demand from higher-paying users can push rates up quickly. Queue size alone cannot tell you the fee needed for prompt confirmation.

What sets base-layer throughput

Three quantities give a rough capacity estimate: usable space in a block, the average footprint of a transaction, and the average block interval.

Usable blockspace / average transaction footprint / average block interval.

Use compatible units: block weight with transaction weight, or block bytes with transaction bytes. The estimate also assumes enough demand to fill the available space. Actual throughput depends on what miners include and how quickly nodes can relay and validate it.

One transactions-per-second figure rarely describes a chain well. A batch transaction can pay many recipients. A consolidation can consume many inputs while making just one output. Contract activity adds a different mix of scripts and signatures. The same block limit can therefore hold very different numbers of transactions or payments.

Raising the limit gives miners room to clear more work per block. Shortening the target interval offers more frequent opportunities. Both involve tradeoffs: larger mined blocks require more bandwidth, validation, and storage, while shorter intervals leave less time for each block to propagate before another is found.

Two approaches to Layer 1 scaling

BTC: weight and efficiency

Bitcoin limits each block to 4 million weight units. SegWit places unlocking data for SegWit inputs in a witness structure. Witness bytes count as one weight unit each; non-witness bytes count as four. That discount makes room for more transaction data than the earlier one-megabyte limit allowed, with the gain depending on the transaction mix.

Taproot can save space on some complex spends. With a suitable key-aggregation scheme, cooperating signers can authorize a key-path spend using one signature. A script-path spend reveals the selected script and its proof, keeping the other scripts hidden. The underlying Schnorr signature is 64 bytes; a Taproot transaction signature is 65 bytes when it includes an explicit non-default sighash byte.

BTC targets a ten-minute block average and retargets mining difficulty every 2,016 blocks. Its capacity approach combines a fixed weight ceiling with more efficient transaction formats. Sustained demand can still fill that capacity and increase competition on fees.

BCH: headroom and adaptation

Bitcoin Cash raised its block limit to 32 MB in 2018. The 2024 upgrade introduced ABLA, which adjusts the limit using mined block sizes. Its mainnet settings retain a 32 MB floor and allow gradual increases or decreases above that floor as usage changes.

ABLA responds to blocks that were mined, so a sudden mempool rush does not instantly raise the limit. The limit also sets a ceiling, not a requirement for miners to fill every block. Its capacity adjustment and the queue's recovery take time.

BCH also adopted Schnorr signatures in 2019: 64 bytes for the signature itself, plus a sighash byte for transaction signatures. ASERT adjusts the mining target each block to help keep the long-run interval near ten minutes as hash rate changes. It cannot eliminate the randomness of individual block times.

BCH's larger base-layer allowance provides more headroom for ordinary transactions, with higher potential demands on nodes as mined blocks grow. Comparing it with BTC requires accounting for transaction formats as well as the different capacity units.

Both Bitcoin Core and Bitcoin Cash Node support compact block relay. A node can reconstruct much of a new block from transactions it already has, using short identifiers supplied by a peer and requesting missing transactions. This can reduce bandwidth and propagation delay, though the node still needs to validate and process the full block.

What extra layers add

Payment channels, sidechains, and rollups can handle activity without putting every user action into a separate base-layer transaction. That can increase usable payment or application capacity. Each approach also has its own constraints: channels need liquidity and monitoring, while sidechains and rollups differ in their bridges, sequencing, proof systems, and settlement guarantees. Ethereum's scaling guide explains several of these distinctions.

Congestion is one possible failure mode, but software and infrastructure failures can also interrupt service. The incidents below illustrate different dependencies; they are not a ranking of overall reliability:

• Core Lightning, August 2026: A security advisory directed operators to version 26.06.7 and recommended the daemon's offline mode until they could upgrade. This was a software-security issue, rather than a blockspace shortage.
• smartBCH, 2022: The project's account of the CoinFLEX bridge crisis described backing funds under a custodian's control and a stalled exit path. Sidechain capacity could not resolve that custody problem.
• Arbitrum One, December 2023: A surge of inscriptions disrupted the sequencer and feed. The resulting backlog kept gas prices elevated during recovery.
• OP Mainnet, July 2026: An infrastructure fault left external nodes and RPC providers on a stale head for about 22 minutes, with throughput near zero for about 16 minutes. The postmortem reported no reorganization or finality violation.

Measure these systems' throughput alongside their confirmation and settlement conditions. An off-chain payment, a sequencer receipt, and a base-layer confirmation represent different stages of completion.

Try it in Blockspace Lab

Blockspace Lab lets you change arrivals, average transaction size, block capacity, and timing, then watch the backlog and fee-priority bands respond.

Start with steady traffic below capacity. Switch to a burstier pattern with a similar average rate and watch how much work remains after the peak. Then lower demand again. The time needed to drain the queue is often the most revealing part of the exercise.

The lab models how a BTC weight ceiling, BCH's adaptive limit, or custom settings affect the queue. It does not establish what a live network can safely support. That requires node benchmarks, propagation measurements, storage estimates, and real traffic data alongside the model.

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