Trace Each Leg to Find Where a Cross-Chain Swap Stalled

To find where a cross-chain swap stalled, trace its source-chain transaction, bridge message and destination-chain transaction as separate events. A swap interface may present one progress bar, but the route can call a source-chain exchange, submit a message through a bridge or messaging protocol, and then execute another swap on the destination chain. The first confirmed event without its expected successor identifies the stage to investigate.

Start with the transaction hash shown in the swap interface and open it in the source chain’s block explorer. Check the receipt, not just the wallet’s pending indicator: a successful receipt means the transaction was included and did not revert at that point. Then look for the bridge or router event emitted by the transaction. If the interface exposes a message ID or route details, record those too. For a brief comparison of how a spot swap can involve a routed exchange call, see this ParaSwap guide to three spot-swap routes; route composition matters when separating an exchange leg from a bridge leg.

What should I check on the source chain?

Check whether the source transaction was included, whether it succeeded, and whether it emitted the event that starts the cross-chain leg. A pending transaction has not yet produced a confirmed on-chain result. A reverted transaction has failed on the source chain, so there may be no bridge message to track. A successful receipt alone is not proof that the full swap completed: it only confirms that the source-chain call executed without reverting.

Inspect the transaction’s logs or decoded call to identify the router or bridge contract involved. The swap may perform a token approval and then a separate swap transaction; an approval does not itself move tokens or start the route. If the successful transaction calls a router, look for its swap or bridge event and note the token amount, destination chain and recipient. Those fields help distinguish the intended route from another transaction sent by the same wallet.

How do I follow the bridge message?

Search the bridge or messaging protocol’s tracker with the source transaction hash, message ID or route ID it recognizes. Trackers may show separate milestones for source confirmation, message verification or attestation, and destination execution. Their status labels are protocol-specific. “Confirmed” can refer only to the source event; it does not necessarily mean the destination contract has run.

Match the tracker record to the source transaction before acting. Confirm the source and destination chains, sender or recipient, token and amount. Some systems assign a message identifier distinct from either chain’s transaction hash. The destination transaction, when one exists, has its own hash. Searching only the source hash on the destination explorer will usually not reveal that transaction.

The point where progress stops narrows the cause:

• No successful source receipt: investigate the wallet transaction, its nonce, fee settings or revert reason.
• Successful source receipt but no matching message: check that the transaction called the expected route and emitted the expected bridge event.
• Message recorded but not yet eligible for delivery: the protocol may still be waiting for source-chain finality or its own verification step.
• Destination transaction exists but failed: inspect its receipt and revert reason; the message arrived, but destination execution did not complete.

A tracker’s “pending” state is not, on its own, evidence of a lost transfer. Source-chain finality requirements and protocol processing take time, and the interval varies by route. Compare the displayed milestone with the previous one and check whether a destination transaction hash has appeared. If it has, the destination explorer is the right place to inspect execution.

What does a destination transaction tell me?

A successful destination receipt confirms that the destination call executed, but verify the result the swap promised. Check the recipient, output token and token-transfer logs; an execution can succeed while delivering an unexpected amount or asset if the route’s terms allow that outcome. If the destination receipt reverted, the route reached the destination but the final call failed. That is a different failure from a message still awaiting delivery.

Some routes contain more than one swap or contract call. A source-side swap can succeed before the bridge transfer begins, and a destination-side swap can fail after the bridge has delivered an intermediate token. In that case, the bridge may report completion even though the user did not receive the requested output asset. Identify which token was transferred across chains and which contract was meant to convert it afterward.

When should I retry or request recovery?

Retry only after establishing which stage failed and what the route’s recovery path supports. A fresh swap can spend the same balance again while the original message is still progressing. If the source transaction reverted, there is no successful source call to recover. If the tracker shows an approved or delivered message with a failed destination execution, the protocol or application may expose a retry, gas top-up or manual execution path; these are not interchangeable, and availability depends on the route.

Use the swap interface’s support channel or the protocol’s documented recovery flow with the source hash, message ID and any destination hash. Never send funds to an address offered in an unsolicited message. The practical rule is to identify the last confirmed event first: a chain receipt proves execution on that chain, while a bridge status describes only the protocol milestone named by that tracker.