FREE EXPERT TABLETOP · WORKS OFFLINE
Same signature or new authorization?
Six fictional incidents. Use the original signature, blockhash lifetime, execution result, and business receipt to decide whether to rebroadcast, keep waiting, or prepare a new action.
Practice only; no live transaction. This casebook makes no wallet prompt or RPC request, and it does not store answers.
A REPEATABLE RECOVERY PATH
Preserve identity, then follow evidence
01 · IDENTIFY Which exact message? Keep the cluster, signature, serialized bytes, and blockhash lifetime together.
02 · OBSERVE What actually happened? Distinguish wallet cancellation, delivery acknowledgement, status, execution error, and committed state.
03 · RECOVER Is this the same action? Rebroadcast identical bytes while valid. After expiry, reconcile history and business state before new signatures.
A timeout is not an execution result. A new signature may be a new business action, even when the screen says “retry.”
Transaction delivery, blockhash expiry, chain evidence, and business-level uniqueness are separate recovery checks.
FORMATIVE · UNSCORED · NOT SAVED
Work the incidents Choose the safest next action, then read the evidence boundary.
01 RPC TIMEOUT · STILL VALID
The RPC call times out after the wallet returns a signature. The current block height is below the stored last-valid height.
Signed message Fully signed and unchanged
Original signature Known and retained
Lifetime Current height 840100 · last valid 840140 What should delivery recovery do?
Build a fresh transaction for the same purchase and collect another signature immediately. Rebroadcast the identical signed bytes and keep polling the original signature through the required commitment. Mark the action failed because a transport timeout proves the RPC never processed it. Check my decision Choose an action before checking.
02 COMMITMENT · WAITING FOR FINALITY
A provider reports the withdrawal as confirmed. The application records completion only after finalized state.
Observed status Confirmed
Required evidence Finalized at the selected cluster
Business action One withdrawal, already submitted What should the learner-facing status say?
Finalized, because every confirmed transaction is already at the strongest commitment. Failed, then offer another withdrawal, because the finality threshold was not reached in one poll. Confirmed but pending finality; retain this signature and reconcile until the required commitment is observed. Check my decision Choose an action before checking.
03 EXPIRED MESSAGE · INCOMPLETE LOOKUP
The stored last-valid height has passed. One RPC returns null from its recent status cache and a confirmed getTransaction lookup returns null.
Original signature Still available
Status lookup Recent cache only; no history search
Application receipt Not yet reconciled What evidence should come before a new authorization?
Treat the null as proof of non-execution and immediately sign a replacement withdrawal. Search history with a compatible reader and reconcile the target account or receipt; keep the result unknown if evidence still conflicts. Replace the blockhash inside the old serialized message and keep its existing wallet signatures. Check my decision Choose an action before checking.
04 INSTRUCTION ERROR · FEE EVIDENCE
Finalized transaction metadata contains an InstructionError. The transfer state is unchanged, and the fee payer's balance fell by the network fee.
Execution result Finalized with an instruction error
Program accounts Instruction state rolled back
Fee payer Network fee may still be charged What is the accurate recovery report?
The entire transaction rolled back, including its network fee, so no balance changed. Resubmit the same failed signed message until its instructions succeed on a later execution. Report failed execution and the fee charge separately; inspect the business state before any new authorized attempt. Check my decision Choose an action before checking.
05 WALLET REJECTION · BEFORE SUBMISSION
The wallet rejects a signature request. The application confirms that its sendTransaction method was never called.
Wallet response User rejected before signing
Submission call Never made
Chain evidence No transaction signature was submitted by this client How should the application record this?
On-chain execution failure, including a network fee, because any closed wallet prompt reaches a validator. Local user cancellation before submission; preserve the course state and let the learner decide whether to start again. Finalized cancellation on Solana, because wallet rejection is stored as a transaction result. Check my decision Choose an action before checking.
06 TWO TABS · SAME BUSINESS INTENT
Two tabs sign a withdrawal for the same order using different recent blockhashes. Both transactions have different signatures.
Transaction identities Distinct messages and signatures
Application intent One order and one withdrawal
Weak guard A browser-only disabled button Which control prevents paying twice?
Rely on transaction-signature deduplication to recognize that both different signatures represent the same order. Disable the button in the first tab and assume no other device or server worker can submit the action. Enforce a durable order key or one-time receipt atomically at the business or program boundary. Check my decision Choose an action before checking.
PRIMARY REFERENCES
Check the recovery boundary
This tabletop does not send a transaction, confirm a signature, or decide whether any real payment is safe to repeat. Scenarios are fictional.
