Official MASTR logo MASTR
Menu

Solana: from quote to settlement

Solana transaction expiry: submitted is not confirmed

A recent blockhash limits validity; a timeout alone does not establish the final outcome.

Updated 30 September 2026 · MASTR Labs

Article text and technical graphics are in English. Navigation is available in seven languages.

Reference guides
  1. A short-lived transaction message
  2. Follow block height and signature status
  3. Why blind retries confuse the record
  4. Preserve the useful evidence
  5. Worked example
  6. Sources and originals

A short-lived transaction message

Ordinary Solana transactions carry a recent blockhash. Validators reject a transaction once that blockhash is outside the accepted processing window. This bounds how long the network must consider the same transaction for processing. Durable nonce transactions follow a different mechanism and should not be analysed as if they used the ordinary recent-blockhash lifecycle. 1

Follow block height and signature status

The getLatestBlockhash response includes lastValidBlockHeight. A confirmation flow can track the transaction’s signature and the relevant block-height condition, using a consistent commitment context. A fixed 60-second timer is a user-interface timeout, not consensus proof that a transaction can never land. RPC nodes can differ in freshness, and a response can be lost even when a transaction was processed. 2

Why blind retries confuse the record

Rebroadcasting the same signed transaction and constructing a new transaction are different actions. A fresh blockhash changes the message and requires a new signature. Before offering a new payment or trade, an interface needs to determine whether the earlier one settled or expired. Otherwise the user can mistake two distinct authorisations for a harmless network retry.

Preserve the useful evidence

A good support record includes the signature, the reported state, the observation time and the RPC commitment used. It never needs a seed phrase. Distinguish pending, failed on-chain, expired and unknown. An explorer not immediately showing a signature is an observation about that explorer at that moment, not proof of non-execution across the network.

Track the transaction, not only a timer
Educational diagram. Open the full-size graphic. Credits ↗ A client timeout is not proof that the transaction never executed.

Worked example

A wallet reports a request timeout, but the transaction’s signature later appears as confirmed. The timeout described a failed wait for a response. It did not reverse the transaction. Starting an equivalent newly signed trade before resolving that uncertainty could create a second trade.

Sources and originals

  1. Solana: confirmation and expiration
  2. Solana RPC: getLatestBlockhash

Continue reading

Solana: from quote to settlement →

MASTR

Support independent research

The investigations, original evidence and guides here are free to read. Voluntary donations help fund the research and keep MASTR’s tools available.

Open wallet