Answers>Learn about scalability & performance>What causes blockchain congestion?
What causes blockchain congestion?
// Tags
blockchain congestionhigh gas fees
TL;DR: Blockchain congestion occurs when more transactions are submitted to the network than can fit in the next block. Every blockchain has a maximum amount of computation or data it can process per block, and when demand exceeds that limit, a backlog forms in the mempool (the waiting area for unconfirmed transactions). Congestion leads to higher transaction fees (as users compete for limited block space), longer confirmation times, and degraded user experience. The root causes include fixed block capacity, demand spikes from popular events, fee market dynamics, and the fundamental design tradeoffs that prioritize security and decentralization over raw throughput.
The Simple Explanation
A blockchain processes transactions in batches called blocks. Each block has a capacity limit. On Ethereum, this limit is expressed as a gas limit (currently around 30 million gas per block). On Bitcoin, it is a weight limit (4 million weight units per block). On Solana, it is a combination of compute units and account locks per slot. Regardless of the specific mechanism, every chain has a ceiling on how much work it can do per block.
When the number of transactions being submitted to the network is lower than the block capacity, everything runs smoothly. Transactions are included in the next block, fees are low, and confirmation is fast. When the number of transactions exceeds the block capacity, a queue forms. This queue is the mempool, a holding area maintained by each node where valid but unconfirmed transactions wait for inclusion in a future block.
The mempool is not first-come, first-served. It is a fee-based priority queue. Block producers (miners or validators) select the transactions that pay the highest fees because that maximizes their revenue. When the mempool is full, users who want their transactions confirmed quickly must outbid everyone else by offering a higher fee. This bidding war is what causes gas prices to spike during congestion. Users who are unwilling or unable to pay the elevated fees have their transactions stuck in the mempool for minutes, hours, or sometimes days.
Demand Spikes
The most visible cause of congestion is a sudden surge in demand for block space. These spikes are often triggered by specific events. A popular NFT mint can generate tens of thousands of transactions within minutes as collectors rush to secure limited-edition tokens. A DeFi protocol launch or airdrop claim attracts a flood of users interacting with new smart contracts simultaneously. A major market crash triggers a wave of liquidations, position closures, and panic selling as DeFi participants scramble to adjust their positions.
On Ethereum, some of the worst congestion events in the network's history were caused by specific applications. The CryptoKitties craze in December 2017 clogged the network for days. Yuga Labs' Otherside NFT mint in May 2022 caused gas prices to exceed 8,000 gwei, with some users paying thousands of dollars in fees for transactions that ultimately failed. Airdrop claims for tokens like Uniswap's UNI and Arbitrum's ARB created sustained congestion lasting hours as millions of eligible wallets rushed to claim.
Meme token trading creates recurring congestion on chains like Solana and Base, where a viral token launch can generate millions of swap transactions within hours. Unlike planned events (where users at least know congestion is coming), meme token surges are unpredictable and can overwhelm network capacity with little warning.
Fixed Block Capacity and Production Rate
The deeper cause of congestion is that block capacity and production rate are fixed by the protocol's design, while demand is variable and sometimes explosive. Ethereum produces a block every 12 seconds with a gas limit of roughly 30 million gas. A simple ETH transfer costs 21,000 gas. A Uniswap swap costs 150,000-300,000 gas. A complex DeFi interaction might cost 500,000 gas or more. Under ideal conditions, Ethereum can process roughly 15-30 transactions per second depending on the complexity of those transactions. When thousands of users are simultaneously trying to mint an NFT, swap a token, or claim an airdrop, 15-30 TPS is nowhere near enough. Bitcoin faces the same fundamental constraint with even tighter limits. Blocks are produced every 10 minutes (compared to Ethereum's 12 seconds), and each block can hold approximately 2,000-3,000 transactions. This gives Bitcoin a throughput of roughly 5-7 TPS. During periods of high demand, Bitcoin's mempool can accumulate hundreds of thousands of unconfirmed transactions, with low-fee transactions waiting days for confirmation.
These capacity limits are not arbitrary. They exist to maintain decentralization. If blocks were larger or produced faster, fewer nodes could keep up with the data processing requirements, which would centralize the network around operators with expensive hardware. The tradeoff between throughput and decentralization is at the heart of blockchain design and is often called the blockchain trilemma (the difficulty of simultaneously achieving scalability, security, and decentralization).
MEV and Priority Gas Auctions
Maximal Extractable Value (MEV) contributes to congestion in a less obvious but significant way. MEV refers to the profit that block producers and searchers can extract by reordering, inserting, or censoring transactions within a block. When a profitable MEV opportunity appears (such as an arbitrage between two DEXes), multiple searchers compete to capture it by submitting transactions with progressively higher fees. This priority gas auction consumes block space and drives up fees for everyone, even users whose transactions have nothing to do with the MEV opportunity.
Sandwich attacks are a specific MEV pattern that directly impacts regular users. A searcher detects a large swap transaction in the mempool, places a buy order before it (front-running) and a sell order after it (back-running), profiting from the price impact the victim's transaction creates. These front-run and back-run transactions consume additional block space and increase congestion beyond what organic user demand would produce.
Layer 2 Solutions and Congestion Relief
Layer 2 networks (like Arbitrum, Base, Optimism, and zkSync) were designed in part to relieve congestion on Ethereum L1. By processing transactions on a separate chain and posting compressed summaries back to Ethereum, L2s dramatically increase the total throughput available to users. A transaction that costs $5 in gas on Ethereum L1 during congestion might cost $0.01 on an L2. However, L2s can also experience their own congestion during extreme demand spikes, and they inherit some limitations from the L1 they settle to.
Solana takes a different approach to congestion management with its local fee markets. Instead of a single global fee market where all transactions compete for the same block space, Solana attempts to isolate congestion to specific "hot" accounts. Transactions interacting with a congested contract (like a popular DEX pool) pay elevated fees, while transactions interacting with unrelated contracts are unaffected. This design reduces the collateral damage of congestion spikes, though it does not eliminate them entirely.
How long does blockchain congestion last?
The duration of congestion depends on what caused it. A scheduled event like a high-profile NFT mint or an airdrop claim usually produces a sharp spike that clears within minutes to a few hours once the rush of claimants subsides. Sustained congestion is different: when a chain is persistently running near capacity (for example, during a prolonged bull market or a viral meme token cycle), elevated fees and slow confirmations can last days. Bitcoin congestion tends to clear more slowly than Ethereum because its 10 minute block time means the mempool drains in larger, less frequent steps. The practical signal that congestion is easing is a falling mempool size combined with declining priority fees.
Congestion is also closely related to why blockchains slow down in general, and it is distinct from a complete outage. If a network stops producing blocks entirely, that is a chain halt, not congestion.
How do block limits differ across blockchains?
Because every chain caps how much work fits in a block, the headroom before congestion sets in varies widely. The table below summarizes the approximate capacity constraints that determine how quickly each network backs up under load.
Blockchain
Block time
Capacity metric
Approx. throughput
Bitcoin
~10 minutes
4M weight units
5 to 7 TPS
Ethereum L1
~12 seconds
~30M gas per block
15 to 30 TPS
Solana
~400 ms slot
Compute units and account locks
Thousands of TPS
Arbitrum / Base (L2)
Sub-second
L2 gas, settled to L1
Hundreds to thousands of TPS
Higher throughput chains and Layer 2 networks absorb demand spikes better, but no design is immune. For a deeper look at the relationship between speed and capacity, see throughput vs latency and what a Layer 2 blockchain is.
What is the difference between congestion and a chain halt?
Congestion and a chain halt both look like "the network is broken" to an end user, but they are fundamentally different conditions with different causes and fixes. Congestion means the chain is still producing blocks; it is just full and expensive. A chain halt means block production has stopped entirely.
Aspect
Congestion
Chain halt
Block production
Continues normally
Stopped
Transactions
Confirm slowly, high fees
Do not confirm at all
Root cause
Demand exceeds block capacity
Consensus failure or client bug
Typical resolution
Demand subsides, fees fall
Validators coordinate a restart
In short, congestion is a pricing and capacity problem, while a chain halt is an availability problem. MEV activity such as priority gas auctions can intensify congestion, so understanding what MEV is helps explain why fees climb faster than raw user demand alone would predict.
How can developers reduce the impact of congestion?
Applications cannot eliminate congestion, but they can stay reliable through it. Use dynamic fee estimation rather than hardcoded gas prices, implement retry logic with proper nonce management, and queue non-urgent transactions for off-peak windows. On the data side, prefer push-based delivery over tight polling loops so your ingestion keeps pace as blocks grow. Understanding how RPC requests work, choosing streaming over polling, and accounting for provider RPC rate limiting all reduce the chance that congestion turns into dropped data or failed user transactions.
Frequently Asked Questions
Why do gas fees spike during congestion?
Block space is limited, and the mempool is a fee-based priority queue. When more transactions compete than a block can hold, users bid higher fees to get included first. That bidding war pushes the prevailing gas price up until demand falls back below block capacity.
Does congestion mean the blockchain is down?
No. During congestion the chain keeps producing blocks and confirming transactions; they are just slower and more expensive. A network that stops producing blocks is experiencing a chain halt, which is a separate problem.
Can Layer 2 networks get congested too?
Yes. Layer 2s offer far more throughput than Ethereum L1, so they tolerate larger spikes, but extreme demand can still fill their capacity and raise fees. They also inherit some constraints from the Layer 1 they settle to.
How can I tell if congestion is clearing?
Watch the mempool size and priority fees. A shrinking backlog of unconfirmed transactions combined with falling priority fees is the clearest sign that demand has dropped back below block capacity.
Why don't blockchains just make blocks bigger?
Larger or faster blocks raise the hardware cost of running a node, which pushes out smaller operators and centralizes the network. Capacity limits are a deliberate tradeoff that protects decentralization, a tension often called the blockchain trilemma.
How Congestion Impacts Developers Building on Quicknode
For developers, congestion affects both transaction submission and data ingestion. On the submission side, transactions with insufficient gas fees get stuck in the mempool or are dropped entirely. Applications need robust fee estimation, retry logic, and nonce management to handle congested conditions gracefully. Quicknode's Core API provides reliable transaction submission with consistent performance even during peak congestion, and enhanced API methods help applications estimate appropriate gas prices based on current network conditions.
On the data ingestion side, congestion means more transactions per block, larger blocks, more events to process, and higher data volumes. Polling-based architectures struggle during congestion because the volume of data per block increases while the polling interval remains fixed, creating a processing backlog. Quicknode Streams handles congestion gracefully because its push-based architecture scales with block size. Whether a block contains 100 transactions or 1,000 transactions, Streams delivers the complete data to your destination with the same guaranteed delivery and ordering. Configurable batching and compression help manage the increased data volume during sustained congestion periods.
