Track replacement and cancellation of a pending swap

A pending swap's original hash may never receive a receipt if another transaction with the same account nonce replaces it. A tracker that watches only one hash can wait forever.

Track identity at two levels

Keep the original transaction hash as evidence, but also retain chain, sender and nonce when available. Those fields help identify a replacement occupying the same sequence position. The Ethereum transaction model supplies this context.

A replacement can preserve the swap calldata with different fee parameters, or change the destination and data entirely. Do not call every replacement a speed-up. A cancellation-style replacement usually represents a different transaction intended to consume the nonce before the original executes.

Confirm what actually executed

Once a replacement is included, inspect its contents and receipt. If it executes the intended swap, associate the new hash with the attempt. If it performs a different action, record the original swap as replaced rather than successful. The receipt status still determines whether the replacement itself succeeded.

Fee-bump thresholds and mempool acceptance rules differ by client and network policy. Do not hardcode a universal percentage and present it as a protocol rule. A replacement request is also not proof that the old transaction cannot win the race.

Keep the history legible

Show the original and replacement relationship, including a link to the executed transaction on the correct chain. Avoid deleting the first hash, because support investigations may start from it.

A useful fixture emits an original hash, then a different transaction at the same nonce, and finally a receipt only for the replacement. Verify that the interface stops waiting for the original and reports the replacement's actual meaning.