Let confirmed swap records survive a chain reorganization

A recent receipt can disappear or move if the chain reorganizes. Keep enough block context to revise a transaction's status without losing its history.

Store the inclusion evidence

Alongside the transaction hash, record the receipt's block number and block hash. Confirmation policy should be chain-specific and explicit. A fixed number of blocks is an application policy, not a universal finality guarantee.

EIP-1898 describes block-hash selectors and canonicality checks for state queries. Where supported, using a specific block identity can help keep related reads coherent. Confirm actual support in the selected RPC.

Reconcile a changed receipt

If the original block is no longer canonical, move the trade back to a provisional state and query the transaction again. It may be re-included, remain pending or be replaced. Do not immediately create a new swap, reverse every accounting entry or claim the tokens are permanently lost.

Store outcome revisions as events rather than overwriting the only record. A history such as included, reorg detected, re-included explains what occurred and supports idempotent reconciliation.

Downstream consumers need a policy

If another system acts on swap completion, tell it whether the event is provisional or meets the application's finality threshold. A webhook consumer that treats the first success event as irreversible can make decisions the tracker later cannot undo.

A deterministic test can return a successful receipt under block hash A, then no receipt, then the same transaction under block hash B. Verify that the user sees a pending reconciliation interval and only one ultimate fill. Include a replacement transaction scenario to ensure nonce evidence does not get mistaken for re-inclusion of the original call.