What happens inside a swap when the network suddenly gets a spike of transactions

07 September 2026

When a sudden spike in network transactions hits, the swap you submitted stops advancing until fee pressure and block space resolve. The exchange's automated process cannot cut in line; it can only wait for its place in the mempool or validator queue like every other pending transaction.

Here is the mechanism. You submit a swap instruction. That instruction becomes part of a pending pool of unconfirmed transactions - the mempool on Ethereum-like chains, or the transaction queue on Solana. A spike means many more users are sending transactions at once. Validators or block producers select which transactions to include in the next block. Their selection criteria are almost always fee-based: higher fees get picked first. Your swap's fee was set when you approved the quote, typically minutes before the spike. That fee is now too low relative to the new, higher fees that spike participants are paying.

The exchange's system monitors the mempool or queue. It sees your transaction is not being included block after block. Some exchanges have a mechanism to "bump" the fee - resubmit the same transaction with a higher gas price or priority fee. But this requires the exchange's infrastructure to detect the spike, decide the bump is worth the cost, and push the replacement transaction before the original expires. If the exchange does not bump, or bumps to a fee that is still too low, your swap stalls.

On Ethereum and its compatible chains, spikes cause the mempool to swell. Transactions with low gas prices can remain pending for hours or even days until the mempool clears. The exchange may have set your transaction's gas price at a level that was reasonable under normal conditions. A sudden spike to the 90th or 99th percentile of gas prices leaves it stranded. The exchange cannot simply cancel and re-price without your permission on a swap that has already been dispatched to the network. Some exchanges include a "cancellation window" before the transaction broadcasts, but once it is in the mempool, cancellation also requires a replacement transaction - which itself must pay a competitive fee.

On Solana, the mechanism differs but the outcome is similar. Solana's leader schedule means only one validator produces blocks in a given slot. A spike in transactions forces that leader to select from a queue. Transactions with higher priority fees jump ahead. Your swap's fixed priority fee, set before the spike, becomes non-competitive. Solana transactions that are not included in a slot are simply dropped - they do not linger in a mempool. The exchange must detect the drop and re-submit with a higher fee. If it does not retry aggressively, the swap waits.

The spike also affects the exchange's liquidity sourcing. If the swap involves a decentralized exchange that itself is congested, the quote your exchange received might no longer reflect actual trading conditions. The exchange may hold your transaction while it re-evaluates the route, adding further delay.

If your swap is caught in this situation, the hub page Why your swap is stuck and what to do walks through the practical steps: checking the mempool status, contacting exchange support, and understanding when to wait versus when to cancel. The spike will eventually subside, block space will open, and lower-fee transactions will clear. But that can take minutes, hours, or, in extreme congestion events, days. The only variable the exchange controls - fee pricing - was set before the spike, and that is why the swap is now waiting.

Back to dead tokens