Solana blockhash expiry and durable nonces

A recent blockhash gives an ordinary message a bounded lifetime

A builder normally requests a recent blockhash before constructing a transaction. The hash becomes part of the signed message and ties it to a validity condition the network can recognise.

The getLatestBlockhash response also provides lastValidBlockHeight. Keep that value with the signed attempt. The transaction signature identifies the attempt, while the saved height supports the application's lifetime strategy.

Use block height for that comparison. Slot is a scheduling identifier, and elapsed wall-clock time is another measure again. A fixed seconds-based timer cannot replace the protocol's returned lifetime information through changing network conditions.

The builder, wallet and submission service should agree on the message they handle. If a service silently replaces the blockhash after the user's signature, that signature no longer approves the modified bytes.

Work through a height-based observation

Choose a teaching response with last-valid block height 10,150. At observed height 10,100, the lifetime check alone has not expired. The request still needs to satisfy all other conditions, and successful inclusion is not established by remaining lifetime.

At a relevant observed block height greater than 10,150, that old recent-blockhash condition cannot support new inclusion. The application should still ask whether the original signature executed before that point.

Suppose the send response was lost at height 10,120 but the transfer actually executed at 10,121. Checking height later at 10,151 does not undo the payment or make a replacement safe. Signature and state reconciliation answer the outcome question.

These numbers explain the comparison; they are not a current network snapshot or a universal lifetime interval. Use the actual returned value for each constructed attempt.

An unknown blockhash can indicate different endpoint views

A builder can read a blockhash from one endpoint and send to another with a different state view. A node performing preflight may not recognise the value yet or under the chosen commitment. That can produce a blockhash error without the simple explanation that the user waited too long.

Keep the endpoint context and commitment used during construction. Use compatible read and submission conditions, and account for provider freshness. A min-context capability, where supported by the method, can help prevent relying on a view older than a required observation; it is not a way to manufacture missing history.

Wallet approval also takes time. A hardware signing flow or a request awaiting several people can consume the usable window. If the message must be refreshed, obtain all required signatures for the refreshed message.

Diagnose the error with these facts rather than a generic increase-fee response. Scheduling priority cannot make an unrecognised or expired validity condition correct.

Recent blockhash and durable nonce validity

Observe execution and lifetime together

Persist the intent, signature, blockhash, last-valid height and source context before or alongside broadcast. Poll or subscribe to the signature under a deliberate request budget.

If an execution result appears, classify success or failure independently from commitment. For a payment, also validate the actual recipient and amount. If no result appears, inspect the lookup's cluster, conditions and history coverage.

A null response at one source does not settle the outcome. The status cache and a historical transaction service cover different data. Keep an explicit unresolved state when evidence is insufficient.

Once the attempt's lifetime has passed, stop trying to obtain new inclusion with those old bytes, but preserve the record for reconciliation. A newly constructed and signed transaction is another identity and can repeat a business action.

A durable nonce uses a stored validity value

A durable nonce account provides a value that can be used in a transaction's validity field under the nonce mechanism. The transaction includes the required nonce-advance instruction and authorisation. Its usable lifetime follows account state rather than the ordinary recent-blockhash height window.

This can suit an offline or multi-party signing workflow. Participants sign the same final message, and the sender later checks that the nonce account still has the expected usable state.

Advancing the nonce consumes that value for the relevant request path. Competing requests using the same nonce need their own coordination; the account is not an unlimited collection of independent lifetimes.

Runtime failure handling is important. A valid durable-nonce transaction can advance the nonce and retain the network fee even when later application execution fails. Refetch the nonce state before constructing another attempt rather than assuming the failed action leaves the old value reusable.

Choose a replacement using the business result

For an ordinary payment, first establish whether the earlier attempt already satisfied the invoice or recipient requirement. Link all attempts to that intent. A new signature cannot tell your application on its own that the original was unpaid.

For a program designed around an intent-specific state, verify that the program enforces the invariant correctly. A memo, reference or PDA address alone does not prevent duplicate execution without the necessary checks.

Keep successful, failed and unresolved attempts in the final record. The retry guide explains application state and transport choices, and payment idempotency connects them to one-time fulfilment.

Common questions