Why does my Solana transaction expire before it confirms?

21 September 2026

A Solana transaction expires because it includes a blockhash that becomes invalid once the block it references is more than 151 blocks old, which at typical network speed means about 60 seconds. If the transaction hasn't been included in a confirmed block by then, the network rejects it and you must submit a new one.

The blockhash clock

Every Solana transaction must carry a recent blockhash from the network. This blockhash ties the transaction to a specific point in the chain. When you fetch a blockhash from a validator or RPC provider, you get one from the most recent block. That blockhash is valid only for the next 151 blocks. After that, the network treats the transaction as expired and will not process it.

The 151-block window is fixed by the protocol. It is not configurable per transaction. If your transaction reaches a leader after that window closes, the leader discards it.

Why your transaction misses the window

Several common scenarios cause a transaction to arrive too late:

• Congestion on the network. When many users send transactions, leaders may prioritize others over yours. If your transaction sits in the forwarding queue (Gulf Stream handles this differently than a traditional mempool, but the result is similar: your transaction waits) and the 151-block window passes, it expires.

• Slow RPC responses. If your wallet or application fetches a blockhash and then takes more than a few seconds to sign and submit the transaction, the blockhash may already be several blocks old when it finally reaches a leader. The expiry window runs from the block the hash came from, not from when you received it.

• Failed simulation or pre-flight checks. Many wallets simulate the transaction before sending. If that simulation takes time, or if you manually review and delay signing, the blockhash you originally fetched may expire before the actual submission.

• Priority fee too low. Transactions with a low priority fee per compute unit are often skipped by leaders in favor of higher-paying ones. A skipped transaction that still has a valid blockhash will eventually be processed if the leader includes it, but if it keeps getting skipped for 151 blocks, it expires.

What you can do

1. Fetch a fresh blockhash close to submission

Minimize the gap between fetching the blockhash and sending the transaction. If your code or wallet allows, fetch the blockhash immediately before signing, not minutes earlier. Some wallets do this automatically; others cache blockhashes and reuse them, which increases expiry risk.

2. Increase the priority fee

A higher priority fee makes leaders more likely to include your transaction in the next block. Check the current priority fee recommendation from your RPC provider or a fee estimator site. The exact amount needed varies with network load. There is no fixed "good" number; look at the recent block data to decide.

3. Use a durable nonce

If your transaction genuinely needs to survive longer than one minute - for example, you are signing offline or waiting for user action - replace the blockhash with a durable nonce. A durable nonce is a stored value on chain that stays valid until you explicitly advance it. The procedure:

1. Create a durable nonce account (costs about 0.001 SOL in rent).
2. Include the nonce's value in your transaction instead of a recent blockhash.
3. The transaction remains valid until someone uses the nonce in a successful transaction (which you control) or the nonce account is closed.

This is covered in more detail on the durable nonces page already on this site.

4. Check RPC performance

If you run your own RPC node or use a third-party provider, ensure you are getting blockhashes from a well-connected node. A node that is lagging behind the cluster will give you an outdated blockhash, which may expire even before you submit. Use the getRecentPerformanceSamples endpoint to see if your node's view of the cluster is current.

5. Retry with a new blockhash

When a transaction expires, the correct response is to fetch a new blockhash, re-sign with the same instructions, and submit again. Most modern wallets and dApps do this automatically. If yours does not, you may need to manually retry.

When expiry is not the real problem

Sometimes a transaction appears to expire but the underlying issue is something else. For example:

• The transaction is already processed. Check the signature on a block explorer. If the transaction succeeded or failed in an earlier block, the "expired" message from your wallet may be misleading.

• The blockhash was never valid. If you used an incorrect or corrupted blockhash, the network rejects the transaction immediately, not after 151 blocks. This usually produces a different error, such as "blockhash not found."

• Account data changed. If an account your transaction depends on was modified between fetching the blockhash and submitting, the simulation may fail even though the blockhash is still valid. The error message may mention "account not found" or "insufficient funds" rather than expiry.

Expiry due to blockhash age is a straightforward protocol mechanic. If your transactions consistently expire, the most likely fixes are faster submission, higher fees, or a nonce.

Back to solana