How does an exchange handle a SOL swap when the Solana network is congested

05 September 2026

When the Solana network is congested, the exchanger does not process your SOL swap instantly. Instead, it holds your transaction in a queue, retries submission at intervals, and only marks the swap complete after the network confirms the transaction on-chain.

The core problem is that Solana's validator set can only process a finite number of transactions per second. During congestion - often caused by memecoin launches, NFT mints, or spam attacks - the network's fee market becomes erratic. Regular transactions may fail to be included in a block for minutes or hours. The exchanger cannot control this; it depends on Solana's consensus layer.

Here is what happens step by step when you initiate a SOL swap during congestion:

1. Transaction submission. The exchanger constructs a Solana transaction (typically a simple SOL transfer to its own hot wallet or a token swap via a Solana-based automated market maker). It signs the transaction with its fee payer and broadcasts it to the Solana RPC endpoint it uses.

2. Initial failure. The RPC node returns an error such as "blockhash not found" or "transaction was not confirmed in 60 seconds." This is common during congestion. The blockhash used to sign the transaction expires after roughly 80 seconds. If the network is too slow to include the transaction in a block, the signature becomes invalid.

3. Retry loop. The exchanger does not give up. It generates a new blockhash, re-signs the transaction, and re-broadcasts it. This retry loop continues for a configurable period - often several minutes. Some exchangers increase the priority fee on each retry to improve the chance of inclusion. The exact retry logic varies by implementation, but the principle is the same: keep trying until the network accepts the transaction or a timeout is reached.

4. User experience. During this period, the exchanger's interface typically shows the swap as "pending" or "processing." You cannot cancel the swap; the exchanger has already reserved the incoming SOL (or the asset you are swapping out of) and will not release it until the transaction either confirms or the timeout expires.

5. Timeout and failure. If the retry loop exhausts its attempts (for example, after 10 minutes of failed broadcasts), the exchanger marks the swap as failed. It then returns the original asset to your wallet or to an internal balance you can withdraw. The exchanger absorbs the network fees spent on the failed attempts. You lose only time.

6. Partial confirmation risk. A rare edge case: the transaction appears to fail from the exchanger's perspective (no confirmation after timeout), but later the network includes it. This can happen if a validator picks up a retry broadcast that was delayed. The exchanger typically has logic to detect this by monitoring the Solana ledger for transactions signed with its keys. If it finds a late confirmation, it reconciles the swap retroactively - usually by crediting the destination asset to your account. This is why you should not re-initiate a swap immediately after a timeout; the exchanger may still settle it.

The key takeaway is that the exchanger is a middleman, not a speed guarantee. During Solana congestion, the bottleneck is the network itself. The exchanger can only retry, adjust fees, and wait.

For a broader understanding of how this fits into the overall process, see the hub page "Swapping Solana tokens without a DEX". It explains why using an exchanger differs from trading on a Solana-native decentralized exchange, and why the retry logic described here is one of the trade-offs.

Back to crypto atms