Keep a local ledger of swap attempts and outcomes

A local swap ledger connects user intent to external evidence. It helps the application recover from reloads and timeouts without assuming that a missing screen state means no transaction happened.

Store the minimum useful record

Give each attempt a stable identifier before asynchronous work starts. Record chain, account, provider version, intended asset amounts, creation time and current stage. Add approval hashes, swap hashes or order identifiers as they become known.

Keep sensitive authorization material out of ordinary browser history storage. A digest or provider order identifier is often enough for reconciliation; a reusable signature needs a separately justified handling policy.

Separate attempts from transactions

One attempt may include an approval transaction and a swap transaction. A replacement transaction can introduce another hash for the same nonce. Conversely, a newly authorized trade is a different attempt even if its token pair matches the previous one.

Record these relationships rather than overwriting one generic hash field. That makes history explainable when the approval succeeds but the swap is cancelled or reverts.

Reconcile with evidence

The Ethereum JSON-RPC documentation describes receipt lookup and transaction information used to observe execution. A missing receipt is not itself a final failure state; the transaction may be pending, unknown to that node or affected by replacement.

On restart, query unresolved references and update observations under their original chain and account. Do not resend merely because the last local stage says “submitting.” Preserve uncertainty until the available evidence resolves it.

Keep display totals derived

Calculate history summaries from reconciled records. Avoid maintaining a separate “successful swaps” counter that increments every time a polling response says success.

Test a reload after receiving a hash but before saving the next UI state, duplicate receipt observations and an approval-only attempt. These cases reveal whether the ledger models real operation boundaries or merely mirrors screen transitions.