How to Diagnose a Stalled Cross-Chain Transfer

When a cross-chain transfer stalls, identify the last completed step before retrying or seeking recovery. A bridge transfer is a sequence: a source-chain transaction emits an event or changes asset custody, bridge components observe and verify that change, then a destination-chain transaction releases or creates the corresponding asset. A successful source transaction confirms only the first part. It does not prove that the destination action has happened.

Start with the transaction hash and the exact source and destination networks. Check the source transaction in that chain’s explorer, then check the bridge’s own status interface for the same transfer. The interface may show a message identifier or a destination transaction hash that lets you trace the next stage. For a comparison of how relay bridges move assets, see the guide to relay bridge designs; the model affects which component must act next.

How do I find where the transfer stopped?

Trace the transfer from the source transaction forward, and treat each status as evidence about one specific stage. If the source transaction reverted, the bridge cannot process an event that was never emitted. The asset transfer itself did not complete, though the failed transaction may still have consumed network gas.

If the source transaction succeeded, inspect its event logs or token movements. Confirm that the transaction used the intended bridge contract, asset, amount, and destination address. A successful transaction to a different contract or a different destination address is not a pending transfer for the route you intended.

Next, determine whether the bridge has observed and accepted the source event. Bridges do this differently: a relayer may submit a message, a set of validators may attest to it, or a proof may need to become available. The source chain’s confirmation and finality rules also matter. Until the bridge’s required threshold is met, a transfer can remain pending even though an explorer labels the source transaction successful. There is no universal wait time; use the route’s stated requirements rather than assuming that one confirmation count applies to every chain.

If the bridge reports that the message is ready but no destination transaction exists, the delay is likely in submission or destination execution. If a destination transaction exists, inspect its receipt. A reverted receipt means execution was attempted but did not complete. A successful receipt should show the release, mint, or other destination-side action. The exact event and asset model depend on the bridge.

What should I do when the destination step is pending or failed?

Use the bridge’s documented status or recovery path for the state shown. A pending message may need more source finality or a relayer action; a failed destination call may require a retry or claim transaction. These are different conditions. A retry intended for a failed destination call will not resolve a message that has not yet passed source verification.

Before taking action, check the route’s instructions against the transaction data and message identifier. In particular, establish whether the recovery action reuses the original verified message or creates a new source transfer. Do not submit a second deposit just because the first one is delayed: some systems can process both transfers, leaving you with duplicate transfers rather than a repair.

• For a source transaction that reverted, confirm the asset remains in the source wallet before initiating a new transfer.
• For a message awaiting finality or verification, wait for the stated route condition or use the bridge’s official status interface.
• For a destination transaction that reverted, follow the bridge’s documented retry or claim procedure and check which account must pay destination gas.
• For a successful destination receipt with no visible balance, verify the destination network, receiving address, and token contract in a chain explorer.

Recovery may require a separate destination transaction and enough native gas on that chain. Some bridges expose a retry or claim action; others handle submission automatically or define a different recovery procedure. Read the action’s parameters before signing. A wallet prompt should match the expected network, contract, and message. Never share a seed phrase or private key to get a transfer unstuck.

When is a transfer complete, and when should I escalate?

Consider a transfer complete when the destination chain records the expected asset action for the intended address. A bridge dashboard saying “complete” is useful, but the destination transaction receipt is the direct evidence of execution. If that receipt succeeded and the asset is absent from the wallet display, check the address and token contract on the destination chain before treating the transfer as lost.

Escalate when the bridge’s documented processing condition has been met but its interface shows no corresponding next-stage transaction, or when the available recovery action fails. Provide the source transaction hash, route, message identifier if available, and destination transaction hash if one exists. These identifiers let the operator locate the exact state transition without asking you to repeat the transfer.

The practical rule is simple: diagnose by the last confirmed state, then act on that state alone. A source-chain success, a verified bridge message, and a destination-chain success are separate facts. Keeping them separate avoids duplicate deposits and points recovery at the component that actually stopped.