Track a Cross-Chain Route After Replacing Its Source Transaction

After replacing a pending source transaction, track the route from the replacement’s hash and confirm its on-chain effects before treating the cross-chain swap as active. On Ethereum, a replacement is a newly signed transaction that uses the same sender and nonce; the transaction hash changes because the signed transaction changes. The original hash does not become an alias for the replacement, and a route tracker that still watches only the original can appear stuck.

First compare the transactions’ calldata and destination, not just their hashes. A fee bump can preserve the swap call, while a replacement can also change the call or cancel it with a different transaction. For readers comparing route construction and execution across chains, this guide to ParaSwap routes for cross-chain swaps covers the route-selection context; the tracking question starts with what the replacement actually executes.

What changes when a source transaction is replaced?

The sender’s nonce determines the transaction’s position in that account’s sequence; it does not preserve the transaction’s identity or intent. Ethereum nodes use local transaction-pool policies to decide whether to accept a same-nonce candidate, so a submitted replacement is not proof that every node discarded the original. Once one same-nonce transaction is included in the canonical chain, another transaction with that nonce cannot also execute on that chain.

That distinction matters for swaps. If the replacement retains the route’s calldata, contract target, token approvals and relevant parameters, it may still initiate the intended source leg once included. If it changes those fields, it may perform a different action or no route action at all. A same-nonce “cancel” transaction can consume the nonce without initiating the swap. The route is not continued merely because the wallet labels a transaction “replaced.”

Record the new hash, sender, nonce, chain and target. Then inspect the replacement transaction itself. A pending transaction has no receipt yet; after inclusion, its receipt reports whether execution succeeded or reverted. A successful receipt means the EVM call completed without reverting. It does not, by itself, establish that a separate destination-chain leg has settled.

How do you reconnect the route to the new hash?

Update the tracker to watch the replacement hash, then identify the source-side event or message that the route’s bridge or relayer uses to continue processing. Cross-chain systems do not share one universal route identifier. Depending on the implementation, correlation may rely on an event emitted by the source contract, a message identifier, or another route-specific record.

• Check that the replacement is on the intended source chain and from the expected sender.
• Compare its target and calldata with the original route transaction to confirm that the swap call remains intact.
• Read the receipt status and logs; look for the source contract’s expected execution or message event.
• Use the route’s own identifier or source event data to inspect destination processing, then verify the destination transaction and resulting asset balance.

A transaction explorer can establish inclusion, receipt status and emitted logs on one chain. A route interface may combine those facts with off-chain relayer or bridge status. If the interface still shows the old hash, its display may be stale; check the new hash and source events directly before concluding that the route failed. Conversely, a successful source receipt is not evidence that a relayer delivered the message or that the destination call succeeded.

What if the replacement succeeds but the route does not finish?

Separate source execution from destination settlement. If the source transaction reverted, its intended contract effects were rolled back, though gas was still spent; a destination leg should not be inferred from the attempted call. If it succeeded but no expected event appears, verify that the replacement called the route contract with the intended parameters. A successful transaction can execute a different call and still have a successful receipt.

If the expected source event exists, follow the route-specific message or status record. A destination transaction may be pending, delayed, failed or absent, depending on the bridge’s execution model. Those states require different remedies. Re-submitting the source swap because one screen remains pending can create a second route if the first source transaction already executed. Use the bridge or route’s documented recovery path when its own status indicates a destination-side failure.

Reorganizations add another edge case. An included source transaction can be removed from the canonical chain before finality, taking its logs with it; a tracker should treat confirmation depth or finality according to that chain and protocol’s rules. A status read during that interval is provisional. Do not equate an explorer’s momentary inclusion with irreversible route completion.

Which status should you trust?

Trust the chain’s canonical receipt and the route’s protocol-specific records, in that order of dependency. The source receipt establishes whether the replacement executed on the source chain. Its expected event or message record establishes whether the route was initiated. The destination receipt and resulting state establish whether the route completed there.

Keep both hashes in your notes, labeled original and replacement, but use the replacement hash for source-chain receipt checks. Retain the nonce and route identifier to connect the transaction to the route. If the replacement changed the call, assess it as a new action rather than assuming it inherits the original quote or route. The confirmed facts are the replacement’s inclusion, receipt status and on-chain events; any unobserved bridge processing or destination settlement remains unverified.