What does "blockhash not found" mean on Solana, and how do you avoid it?

16 October 2026

A "blockhash not found" error means the transaction you submitted references a recent blockhash that the network no longer recognizes as valid. On Solana, every transaction must include a blockhash from a recent block (typically the last 150 blocks, about 60-90 seconds of chain time). If that blockhash has expired or was never part of the chain, the transaction is rejected. To avoid it, ensure your transaction uses a fresh blockhash and submits before it expires.

Why blockhashes matter on Solana

Solana uses blockhashes to prevent replay attacks and to give each transaction a short, unique lifetime. When you construct a transaction, you fetch the latest blockhash from an RPC node (usually via getLatestBlockhash). That hash is valid only for a limited window - roughly 150 blocks. After that, the network discards it. If your transaction lands after that window, you get "blockhash not found."

This is not a bug. It is a deliberate design choice. Unlike Ethereum, where transactions can sit in a mempool indefinitely, Solana expects transactions to be processed quickly or not at all. The Gulf Stream protocol (covered elsewhere on this site) forwards transactions directly to validators without a mempool, so there is no queue to hold stale transactions.

Common causes

• Slow transaction construction. You fetch a blockhash, then spend time building or signing the transaction. By the time you submit, the hash has expired.
• Network congestion. High traffic can delay submission past the expiry window.
• RPC node lag. The node you queried might return a blockhash that is already near expiration, especially if it is behind the cluster.
• Retry logic without refresh. Automated scripts that resubmit the same transaction without fetching a new blockhash will eventually hit this error.

How to avoid it: a step-by-step approach

1. Fetch the blockhash as late as possible

Do not fetch the blockhash minutes before you intend to submit. Fetch it immediately before signing and sending. In code:

# Pseudocode for a Solana SDK
latest_blockhash = client.get_latest_blockhash()
transaction = Transaction(recent_blockhash=latest_blockhash, ...)
client.send_transaction(transaction)

If your workflow has any delay between fetching and sending, move the fetch closer to the send.

2. Set a reasonable expiry or retry with a fresh blockhash

Many Solana SDKs let you specify a last_valid_block_height or use the blockhash directly. If your transaction might not confirm on the first try, do not simply resend the same bytes. Instead, fetch a new blockhash and rebuild the transaction.

For simple retries, a loop like this works:

1. Fetch latest blockhash.
2. Build and sign transaction.
3. Send transaction.
4. If error is "blockhash not found", go back to step 1.
5. If error is something else, handle accordingly.

3. Use durable nonces for transactions that must outlive a single blockhash window

If your use case requires a transaction to remain valid for hours or days - for example, a scheduled payment or a multi-step swap - use a durable nonce. This is covered in detail in the "Solana durable nonces" article on this site. Briefly, a durable nonce account stores a counter that you increment manually. The transaction uses that nonce instead of a blockhash, and it stays valid until you explicitly advance the nonce.

4. Choose a responsive RPC node

Some public RPC endpoints return stale blockhashes, especially under load. If you run your own node, ensure it is well-connected and synced. If you use a third-party provider, check their reliability metrics. The getLatestBlockhash response includes a slot field; you can verify that slot is within the last few blocks.

5. Monitor your transaction submission timing

If you are sending transactions programmatically, log the time between fetching the blockhash and receiving the confirmation. A gap of more than 30 seconds is risky. If you see that consistently, either your network round-trip is slow or your RPC is behind.

What to do when you see the error

• Retry with a fresh blockhash. Do not modify the transaction other than the blockhash and signature.
• Check the RPC node's status. If the node returns blockhashes from old slots, switch to a different endpoint.
• If retries fail repeatedly, inspect the transaction for other issues - insufficient funds, invalid account data, or a program error might be the real cause. The "blockhash not found" message sometimes masks a deeper problem if your RPC node is misconfigured.

A note on versioned transactions

Versioned transactions (introduced in Solana 1.10) use the same blockhash mechanism. The advice above applies equally to legacy and versioned transactions. Address lookup tables do not affect blockhash expiry.

Summary

"Blockhash not found" means your transaction's time window closed. The fix is straightforward: fetch a fresh blockhash just before sending, and retry with a new one if needed. For transactions that must live longer, use durable nonces. The error is not a sign of network failure - it is Solana enforcing its design for fast, deterministic transaction processing.

Back to solana