Blockchain is often seen as infrastructure that runs around the clock, doesn't depend on banks, and can accept transactions from anywhere in the world. But even decentralized networks have their limits.
When too many users join, a blockchain begins to resemble a city highway during rush hour. Cars keep arriving, free space on the road shrinks, traffic slows, and eventually the flow stops.
Something similar happens on a blockchain: more transactions are submitted than the network can process. A queue forms, fees rise, and some operations may wait hours for confirmation.
What happens when a Blockchain is congested
Every public blockchain has limited throughput. Over a given period, the network can process only a limited number of operations. If more requests arrive, the extra transactions don't disappear—they wait their turn.
In Bitcoin, unconfirmed operations enter the mempool. Other networks may the different mechanics, but the principle remains the same: the blockchain must decide which transactions to process now and which to leave for later.
As long as the load remains moderate, users barely notice anything. But if network activity rises sharply, the first signs of blockchain congestion begin to appear:
transactions take longer to confirm;
transaction costs increase;
applications begin to operate more slowly;
low-fee transactions may remain stuck in the queue for a long time.
Although these problems are most commonly associated with Bitcoin and Ethereum, even modern high-performance networks are not immune.
Why blockchains become congested
The main reason for blockchain congestion is simple: at some point, demand for using the network exceeds its capacity.
This doesn't necessarily require millions of people to decide to transfer cryptocurrency at the same time. Sometimes a single popular application, the launch of a new token, or an army of automated bots is enough.
Everyone wants to make a transaction at the same time
The most obvious scenario is a sudden surge in user activity.
The history of the crypto market has seen plenty of such cases. On Ethereum, the hype surrounding ICOs, NFTs, and the first blockchain games repeatedly created serious pressure on the network.
One of the best-known examples is CryptoKitties. In 2017, the game featuring virtual cats became so popular that it accounted for a noticeable share of Ethereum activity and became a clear demonstration of the limitations of the infrastructure at the time.
Later, similar situations arose for other reasons: the popularity of DeFi, new token launches, NFT mints, Ordinals on Bitcoin, and memecoin trading.
For a blockchain, it makes practically no difference why demand has increased. If there are too many transactions, the network has to queue them.
There is not enough space in a block
A blockchain does not have unlimited space. Every new block can contain only a limited amount of data. As a result, hundreds or thousands of transactions compete for inclusion in the next block.
In Bitcoin, a new block is created on average about once every ten minutes. During that time, the network may receive a huge number of new operations. If more than can fit into the block, the remainder enters the mempool and waits for the next block.
This is one of the reasons why, during periods of especially high load, some Bitcoin transactions take significantly longer than usual to confirm.
Network speed has a limit
Blockchain performance is often described using TPS — transactions per second. Bitcoin has a relatively low TPS. More modern networks can process far more operations.
But a high TPS does not make a blockchain immune to congestion. If a network can process several thousand transactions per second, it simply means it takes a larger flow of operations to overload it.
It is similar to widening a highway: it helps reduce traffic jams—until there are once again too many cars.
Not all transactions are equal
Transferring coins from one wallet to another is a relatively simple operation. But modern blockchains have long been used for much more than transfers.
Buying a token on a decentralized exchange may involve several smart contracts at once. Adding liquidity, issuing a loan, liquidating a position, or performing a complex swap through several pools requires significantly more computation.
This means two transactions may look identical to the user—they click the “Confirm” button—while placing completely different loads on the network. So it's not just the number of operations that matters, but their complexity.
Bots can create load faster than humans
Automated systems are a separate problem. A trading bot doesn't get tired, doesn't sleep, and doesn't spend several seconds thinking before pressing a button. It can submit enormous numbers of transactions almost continuously.
The problem becomes particularly noticeable during launches of new tokens and NFTs, when programs begin competing en masse for the opportunity to execute an operation before everyone else.
In 2022, this kind of automated traffic contributed a major Solana outage. The network faced millions of requests per second and eventually stopped producing new blocks for roughly seven hours.
This case clearly demonstrates that high stated performance does not necessarily mean absolute resilience under extreme loads.
Why fees increase during congestion
When there is not enough space for everyone, a priority market emerges. In Bitcoin, the user effectively offers miners a price for including their operation in a block. If the queue is small, a relatively low fee is enough. But when the mempool is full, the situation changes.
Imagine ten thousand transactions in the queue, while the next block can accommodate only some of them. It is more profitable for a miner to select the operations offering higher fees first.
Users begin raising their bids. Fees increase. And low-fee transactions gradually move farther and farther back in the queue.
A similar logic applies in other blockchains, although the specific mechanisms used to determine fees may differ.
That is why, during periods of intense activity, the cost of a transaction can sometimes change literally within a few minutes.
Can a transaction get stuck forever?
More likely — for a very long time. If a user sends a transaction with a fee well below the market rate, the network may keep prioritizing other operations. This is especially noticeable in Bitcoin.
An unconfirmed transaction remains in the mempool until it is included in a block. During high network load, the waiting time may stretch to several hours or even longer.
In some cases, the user can increase the fee and thereby raise the priority of the operation.
If this is not done, the transaction will either eventually be included in a block after network congestion decreases or, over time, some nodes will stop storing it and remove it from the mempool.
What blockchain congestion means for an ordinary user
The most unpleasant consequence of blockchain congestion is unpredictability.
A user may be accustomed to a transfer taking a few minutes and costing, say, one dollar. But during a surge in activity, the same transfer may suddenly cost much more or take much longer.
For an ordinary transfer, this is inconvenient but not always critical. In DeFi, the consequences can be more serious.
Imagine a trader who wants to swap a token quickly during a sharp market move. While the transaction is waiting for confirmation, the price changes. As a result, the operation may be executed at a less favorable rate or fail altogether.
Therefore, network congestion affects not only blockchain speed, but also the operation of the entire ecosystem of applications built on top of it.
Can congestion stop a blockchain?
Ordinary blockchain congestion does not, by itself, mean the network will stop.
Bitcoin, for example, can keep producing blocks even when an enormous queue of transactions builds up. Users wait longer and pay more.
However, in more complex blockchains, an extreme flow of operations can sometimes cause problems at the validator and software level.
That is why it is important to distinguish between two scenarios. In the first, the blockchain continues working but becomes expensive and slow. In the second, the load triggers a technical failure, and the network temporarily stops functioning normally.
How developers deal with blockchain congestion
Developers have been trying to solve the scalability problem almost since the first public blockchains appeared. There is still no perfect approach. Almost every solution involves a trade-off between speed, cost, security, and decentralization.
The idea is fairly simple. Why record every small user operation directly on the main blockchain if many transactions can be processed separately and only the aggregated result submitted to the base network?
Ethereum Layer 2 networks, including Arbitrum, Optimism, and Base, operate according to this principle. The main Ethereum network receives fewer individual transactions, which reduces the load on it. For users, this usually means cheaper and faster operations.
Distribute the load
Another approach is sharding. Imagine a huge supermarket with only one checkout. Even if the cashier works very quickly, sooner or later a queue will form. The obvious solution is to open additional checkouts.
Sharding uses roughly the same idea: the network distributes work across several segments that can process data in parallel. In theory, this can significantly increase performance.
In practice, things are more complicated: secure interaction between shards must be organized while preserving a unified system state. That is why sharding is considered a powerful but technically complex way to scale a blockchain.
Bundle transactions into batches
Another method is batching. Instead of sending one hundred separate transactions to the base blockchain, they can be combined, and the result can be recorded as one larger operation.
As a result, the cost of publishing data is distributed among many users, while the main blockchain receives significantly fewer operations.
It is similar to public transport: instead of a hundred cars on the road, several buses carry dozens of passengers at once.
Increase the block size
The most obvious solution is to add more space. If each block can contain more transactions, the network can process a larger flow of operations.
This approach is used, for example, by Bitcoin Cash, where the permitted block size is significantly larger than in Bitcoin.
But blocks cannot be increased indefinitely. The larger they become, the more data nodes have to transmit and store. This raises hardware and internet connection requirements.
If running a full node becomes too expensive, the number of independent network participants may decrease. Therefore, increasing the block size is inevitably connected with the issue of decentralization.
Create blocks faster
The second option is not to increase the size of the “carriage,” but to send new ones more frequently.
Bitcoin creates a block approximately once every ten minutes. Litecoin does so approximately once every 2.5 minutes. Modern networks can create new blocks even faster. This lets the transaction queue clear more quickly.
But there are limitations here as well. The more frequently blocks appear, the faster information must spread among thousands of nodes. If the network cannot synchronize quickly enough, the risk of conflicts and other technical problems increases.
Therefore, reducing block time requires serious optimization of the entire infrastructure.
Why you cannot simply make a “very fast blockchain”
At first glance, the solution seems obvious: huge blocks, new ones every few milliseconds — problem solved.
But a blockchain is different from an ordinary centralized database. All network participants must receive data, verify it, and reach agreement on the state of the system.
The more transactions that pass through the network, the more powerful validator servers must be, the faster their connections must become, and the more storage they require.
If the requirements become too high, only large companies and professional data centers will be able to maintain nodes.
The network will become faster, but at the same time it may become more centralized. This is why developers are constantly looking for a balance between three characteristics:
speed, security, and decentralization.
This problem is often called the blockchain trilemma.
Will blockchain congestion disappear in the future?
Most likely, not completely. Even if network performance increases tenfold, demand may grow along with it.
The history of the internet demonstrates a similar pattern: the more infrastructure bandwidth increases, the more applications begin using it. The same thing happens with blockchains.
Cheaper transactions make new applications possible. New applications attract users. Users generate even more transactions — and network load increases again.
That is why developers are gradually moving away from the idea of a single “perfect” blockchain that should process everything on its own.
Instead, a multi-layer architecture is emerging: the base blockchain handles security and final settlement, while a significant share of operations moves to faster, additional networks.
Instead of a conclusion
Blockchain congestion is not an error and does not necessarily mean that the network is poorly designed.
Most often, it is simply a conflict between a limited resource and excessively high demand.
Therefore, the main challenge for developers is not to eliminate blockchain congestion once and for all, but to make it less noticeable to users.
Fast networks, Layer 2 solutions, rollups, sharding, batching, and new consensus mechanisms are all different attempts to solve the same problem:
How to let millions of people use a blockchain simultaneously without anyone noticing how complex the infrastructure under the hood really is.