Transaction
Exact signed message, signature, blockhash or durable nonce, and validator status.
EXPERT · SAFE, LOCAL-ONLY CASEBOOK
Nonce and Claim Replay Tabletop
A wallet label such as “failed” does not tell you which layer rejected a transaction, whether a nonce advanced, whether the fee was charged, or whether an application claim was consumed. Read the evidence before deciding what to retry.
Keep three records separate
Nonce account
Stored value before and after validation, plus whether the network fee persisted.
Business claim
Claim ID, consumed receipt, and protected program state.
A new blockhash creates a new signed transaction message. It does not make an already-used voucher new.
Choose the next safe action
Each fictional case is independent. Choose one response, then inspect the explanation. Your answers remain in this page and are never scored or saved.
Case 1 · The submission timed out
A wallet returned signed bytes and your client submitted them. The RPC connection timed out before returning a signature status. You still have the original transaction signature and message digest.
Case 2 · An unsent message expired
A multisigner workflow confirms the old recent blockhash expired before any submit attempt. No signature was sent to an RPC node and the application receipt is still absent.
Case 3 · A valid nonce reaches a program error
The stored nonce and required authority validate. The runtime begins the transaction, but the protected program instruction returns an error.
Case 4 · Nonce validation rejects the message
The transaction refers to an initialized nonce account, but its stored value no longer matches the signed message. The nonce authority did not authorize this value.
Case 5 · The same voucher has a fresh transaction
The first redemption created a new signed transaction and used voucher claim-7F3. A second transaction has a fresh blockhash and a valid issuer signature over the same voucher.
Build an incident evidence row
For a real system, record these separately and bind them to the exact network, commitment, provider, and observation time. This worksheet does not connect to a wallet, RPC, or program.
| Original signature | Processing stage | Nonce before / after | Fee evidence | Receipt / protected state | Next action |
|---|---|---|---|---|---|
| Exact submitted signature | Validation, execution, or unknown | Observed account values | Confirmed metadata or not yet known | Claim consumed? State changed? | Reconcile or rebuild and re-sign |
If submission status is unknown, query the original signature first. If a message changes, every required signer must sign the new bytes. If a business claim is retried, the program must still enforce one-time use.