Why is my Solana transaction not confirming? "Blockhash not found" and "block height exceeded" explained
A Solana transaction that never confirms has almost always either expired before it reached a leader or was dropped at ingress. It is rarely stuck waiting somewhere. Solana has no mempool, so a transaction that does not land within the lifetime of its recent blockhash, about 150 slots or roughly 60 to 90 seconds, is simply gone, and the client surfaces this as "Blockhash not found" or "block height exceeded".
Common causes
- The recent blockhash was already old when you signed, because the RPC node you queried was itself behind the chain tip and handed you a stale one.
- The transaction was submitted during congestion with a compute unit price too low to be prioritised, and was dropped before the leader rather than queued.
- The send path lost the transaction at QUIC ingress, where stake-weighted quality of service can shed traffic from unstaked or low-stake origins under load.
- Preflight simulation passed against a lagging node but the live cluster state had already moved on.
System-level mechanism
The recent blockhash is both a time-to-live and a replay guard. Its validity is bounded by last_valid_block_height, and once the chain passes that height the transaction can no longer be included, full stop. Because forwarding to the expected leader happens through Gulf Stream rather than a shared mempool, there is no pool to inspect and no requeue. The two failure modes that matter are therefore expiry (the blockhash aged out before landing) and ingress drop (the transaction never reached a leader that built a block). Distinguishing them is the whole diagnostic, and it points at the health of the specific RPC node in your send path, not at the cluster.
What this indicates
Persistent non-confirmation from a single endpoint usually indicates that endpoint is lagging the tip and issuing near-expired blockhashes, or that your priority fee and send strategy are not surviving congestion. It is an ingress-path and RPC-health problem before it is a chain problem.
Related issues
Inconsistent blockhash or slot across RPC endpoints; RPC requests timing out under load; read availability holding while writes fail during partial degradation.
Deep references
- Expensive work before authentication covers the request-cost asymmetry that makes RPC nodes lag the tip under load in the first place.
- We're securing validators at the wrong layer places ingress drop in the wider class of transport and RPC layer failures.
- NR-2026-001, Agave RPC architectural findings covers how RPC node behaviour under load shapes exactly this ingress path.