Trace a Stalled Bridge Transfer from Source to Destination

To check a stalled bridge transfer, trace its source transaction to finality, then verify whether the bridge’s destination-side action was submitted and completed. A bridge moves value through a sequence of events across separate chains; a “pending” label in the interface can describe any gap in that sequence. Start with the transaction hash and the exact route, not the wallet’s balance display.

How do I tell whether the source transaction went through?

Open the source-chain explorer and search the transaction hash shown by the bridge or wallet. Check its execution status, block inclusion, sender, destination contract, token and amount. A transaction that is pending in the wallet has not been included yet; one that reverted was included but its state changes were rolled back. Neither has completed the bridge transfer.

If the source transaction succeeded, inspect its logs or events. For an EVM transaction, the receipt and emitted contract events can show whether the expected bridge contract accepted the deposit or message. A successful receipt alone does not prove the intended transfer happened: a transaction can call a different contract, transfer a different asset, or succeed without producing the bridge event the route expects. Match the event and parameters to the route details.

Then distinguish inclusion from the bridge’s required source-chain finality. A bridge may wait for a configured number of confirmations or another chain-specific finality condition before acting. During that interval, the source transaction can look successful while the destination action has not started. The route’s own status page or transfer history is useful for locating that handoff; a manta bridge walkthrough covers one route in more detail. Treat the interface as an index to evidence, and confirm important status against the relevant chain explorer.

Why can a confirmed transfer still be missing on the destination?

Because “confirmed on the source” and “executed on the destination” are separate states. A bridge must relay or prove information from one chain to the other, then cause the destination contract or account system to release, mint, or otherwise deliver the asset. The mechanism varies by route: a liquidity bridge may fill an order from destination liquidity, while a canonical layer-2 bridge may process a message through its own contracts.

Use the source event to identify the recipient address, destination chain, asset and amount. Search that address on the destination explorer, including the token’s contract or asset identifier rather than only its ticker. A token can be present under a different contract than the one your wallet displays, and the destination balance view may not include it automatically.

If there is a destination transaction hash, inspect its receipt. A successful destination transaction indicates that execution completed on-chain, though you should still verify the recipient and token transfer event. A reverted destination transaction is different from a transfer that was never submitted: the route may support a retry, or it may require a route-specific recovery step. Do not submit another transfer just because the balance has not changed; the first transfer may still be in flight.

What should I do when the bridge has not completed the handoff?

Use the evidence to identify the state and the next permitted action. Record the source hash, route, source and destination networks, token, recipient and any destination hash. Then check the bridge’s transfer history or official status information for the same record. A missing destination transaction points to an uncompleted handoff; a failed destination transaction points to execution trouble; a successful destination transaction with no visible balance points to an asset or wallet-display issue.

• Source pending: wait for inclusion or check whether the transaction was replaced, dropped or rejected by the source network.
• Source reverted: verify the receipt and error details; only retry after confirming the first attempt did not execute.
• Source final, no destination hash: check the bridge’s documented processing state and support channel for that exact transfer record.
• Destination failed or completed: follow the route’s retry or claim instructions if available, or add the correct asset to the wallet after verifying its contract address from a trusted source.

Some withdrawals from rollups have an explicit proof and finalization sequence. In those routes, a source-side withdrawal event can be valid while funds remain unavailable until the proof is accepted and a separate finalization transaction executes. The required wait and steps depend on the bridge’s design, so use its current route-specific instructions rather than assuming every transfer settles in the same way.

Take care with recovery. Never share a seed phrase or private key, and do not sign an unfamiliar “unlock” transaction sent by unsolicited support. If the route provides a retry or claim action, verify that it belongs to the bridge you used and that the transaction’s destination and calldata match the documented operation. The practical rule is simple: locate the last confirmed on-chain event, then act only on the next step that route specifies.