A Solana transfer can outlive the blockhash used to build it while you check an address or wait for a wallet to submit it. For an ordinary recent-blockhash transaction, that expiry closes the opportunity to execute the old signed instruction. The useful question is whether that window has actually closed before you approve a replacement.
| What you need to know |
|---|
| An ordinary Solana transaction carries a recent blockhash with a limited validity window. |
| A successful submission response is not confirmation that the transfer was processed. |
| Changing the blockhash and signing again can allow two transactions to execute if the original remains valid. |
| A blockhash-not-found error can also result from a lagging RPC node or a temporary fork. |
The blockhash ties the signed message to recent chain history. Solana’s confirmation and expiration documentation describes a typical usable window of roughly 60 to 90 seconds. That estimate is not a countdown you can apply to every wallet screen: the time already spent obtaining the hash and collecting signatures matters, and block production varies.
For developers, the more useful boundary is the lastValidBlockHeight returned with getLatestBlockhash. The documentation says to poll getBlockHeight at the confirmed commitment level until the returned height is greater than that stored boundary. A clock-based timeout alone does not establish that the original transaction can no longer land.
One signed instruction, two ways to retry
Resending the same signed transaction gives the network another opportunity to receive that instruction within its validity window. Replacing the blockhash and signing again creates another transaction. Solana’s retry guidance warns that both can be accepted if the original hash is still valid. For a transfer, that can mean sending the intended payment twice.
The same guide distinguishes submission from execution: sendTransaction returning an ID tells you the RPC node received the transaction, not that the cluster processed or finalized it. That signature is the reference for checking status. Before approving a replacement transfer, check what happened to the original; neither a missing confirmation nor a successful submission response settles the payment’s outcome.
A blockhash-not-found message needs a separate diagnosis. One RPC node can supply a fresh hash while a lagging node used for submission or simulation does not yet recognize it. A hash from a temporary minority fork can also disappear from the chain the wider network follows. These are documented reasons for the error, so the message alone is insufficient evidence of expiry.
Keep the original signature available while resolving the status. If the transfer is already confirmed, another payment would be a new action. If it remains unprocessed and its validity boundary has passed, the old instruction cannot newly execute and a replacement can use a fresh hash. This guide covers ordinary recent-blockhash transactions; Solana’s durable-nonce mechanism uses a different validity rule and requires its own confirmation handling.
