Transaction modal and status UX
Shared receipt-based outcomes, duplicate protection, and resumable confirmation.
Approve, Mint, Burn, Cancel, and Claim use the shared tracked transaction flow.
Sequence
- Verify the initiating account and chain, switching network if required.
- Simulate the intended write.
- Ask the wallet to confirm and submit.
- Wait for the receipt and decode its actual outcome and amounts.
- Refresh RPC financial state and wait separately for indexer history.
Immediate burns, queued submissions, slippage refunds, cancellations, and claims must not share an invented success outcome.
Reloads and replacements
Submitted transaction hashes, account, chain/deployment, and intended action are journaled in browser storage. Reloading resumes confirmation; it does not resend the transaction. Unknown or timed-out confirmation remains retryable rather than being called successful.
Replacement and cancellation transactions need their own receipt outcome. The app checks persisted pending transactions and locks duplicate submissions in the current instance. Fresh simulation and contract checks remain authoritative for races across tabs.
Browser storage availability can limit confirmation recovery across reloads. An indexed-history delay is separate from an on-chain failure.
Last updated on