Most pending Solana swaps either land once the network includes them or become safe to replace after their recent blockhash expires; the right action depends on the signature status and last valid block height, not the spinner. A timeout in an app or wallet is not proof that the transaction failed. Check the signature first, then choose the recovery path that matches what the chain reports.
1. Is the transaction still pending?
A pending swap has no confirmed outcome yet, so wait and track its signature while its blockhash remains valid. Solana reports commitment levels as processed, confirmed, and finalized: processed means a node saw it in a block, confirmed means the cluster has voted on that block, and finalized is the strongest settlement signal. For a swap you need to act on, confirmed is a useful checkpoint; finalized gives greater certainty.
Look up the signature in a Solana explorer or through an RPC status query. If it is processed, allow time for it to advance; if it is confirmed with no error, the swap executed even if the app has not refreshed its display. A null status can mean the transaction has not landed, or that the RPC’s recent status cache no longer holds it, so query transaction history before concluding it was dropped.
This path is best when the signature is recent and its validity window has not elapsed. It does not fit a transaction that reports an execution error or whose blockhash is already expired; those need diagnosis or a fresh transaction, not more waiting.
2. Has the blockhash expired?
An expired blockhash means the signed transaction can no longer be newly processed, so you can prepare a replacement after checking its signature history. Ordinary Solana transactions use a recent blockhash that is valid for roughly 150 slots—typically about 60–90 seconds, since slot duration varies. The reliable cutoff is the transaction’s lastValidBlockHeight, not a stopwatch.
For example, suppose you submit a swap, see no result, and the explorer still has no status. If the current block height is below the saved last valid block height, keep checking: the original may still land. Once the height has passed that limit, check history again; if the signature never landed, request a fresh quote and sign a new transaction. A retry built with the old blockhash will fail with an age or blockhash error.
This check is best when submission stalled or the wallet timed out. It does not fit a signature already confirmed on-chain: sending a new swap in that case could trade twice. Solana’s Transaction Confirmation & Expiration documentation describes the recent-blockhash window and why a lagging RPC can return a nearly expired hash.
3. Did execution fail on-chain?
An on-chain failure means the transaction was included but an instruction returned an error, so inspect the error and program logs before retrying. Solana transactions are atomic: a failed swap does not leave a partial token exchange, though the network fee is still charged. The Solana fee documentation gives a base fee of 5,000 lamports per signature, with an optional priority fee that depends on the transaction’s requested compute-unit limit and price.
For a swap, common causes include the pool moving beyond the transaction’s minimum-output threshold, insufficient SOL for the fee or account rent, and a compute-budget or program error. A slippage or minimum-output failure points to a stale quote or a price move; changing the priority fee alone will not fix it. Refresh the quote and reassess the slippage tolerance. If logs show a compute limit failure, repeated retries with the same transaction parameters are unlikely to help.
This path is best when the signature has an explicit error, because the error narrows the fix. It does not fit a missing signature status: absence from one RPC response is not an execution error. Byreal is a Solana DEX incubated by Bybit, and the same on-chain checks apply when you swap there; separate network execution costs from pool price impact when estimating a retry, with Byreal DEX fees as the relevant service-cost reference.
4. Should you submit a replacement swap?
Submit a replacement only after the original is confirmed failed or its validity window has expired and its signature is absent from transaction history. Before signing again, get a fresh quote, verify the minimum output against your slippage tolerance, and make sure the wallet has SOL for network fees. The tolerance is a bound on acceptable execution, not a promise that the pool will deliver that price.
When network congestion is the likely cause, a higher priority fee can improve scheduling odds, but it cannot rescue an expired blockhash or overcome a swap’s minimum-output check. Solana’s fee formula prices the requested compute units, so an unnecessarily high compute limit can raise the priority fee without guaranteeing inclusion. If the transaction is still valid and status is unresolved, wait; if it is definitively expired, rebuild it; if it failed, correct the reported cause before resubmitting.
Decision rule: replace only a transaction that has failed or expired without landing; otherwise, keep tracking its original signature.