When a Cross-Chain Transfer Stalls, Check Both Chains

A cross-chain transfer can look stuck because the source chain accepted it while the destination chain has not finished its part. That matters because sending the same transfer again may create a second transaction, not speed up the first. A bridge moves assets or messages between separate blockchains, which do not share one transaction record.

Ethereum.org’s bridge guide describes several designs, including locking tokens on one chain and issuing corresponding tokens on another. Each route has its own steps and timing. For a fuller explanation of how to compare routes, see this mantle bridge guide.

Why is a cross-chain transfer still pending?

It may be waiting for the source transaction to be included in a block, for enough confirmations, or for the bridge to pass a message to the destination. A confirmation is a later block that adds confidence the earlier transaction will stay in the chain. Some routes also wait for finality, the point when a transaction is treated as settled under that network’s rules.

Other routes use a liquidity provider: a service that pays out tokens on the destination chain before the source-side transfer is fully settled. That can make a transfer faster, but it changes which step the user must track. A slow transfer is not automatically a failed one; the bridge’s own status page or instructions should say what step is pending.

How can you tell where the transfer stopped?

Start with the transaction hash, the unique identifier shown by the wallet or bridge. Open it on the source chain’s block explorer, a site that displays public transaction records. Check whether it succeeded, failed, or is still waiting. Then look for the bridge’s transfer record or message status and, if available, the destination transaction hash.

• If the source transaction is pending, check the wallet’s fee settings and the source network’s current conditions.
• If it failed on the source chain, the explorer should show a failed status; check the wallet or bridge instructions before trying again.
• If the source succeeded but the destination is pending, follow the bridge’s stated wait or claim steps.
• If the destination transaction failed, keep both hashes and contact the bridge’s official support channel for route-specific steps.

Should you retry or claim the transfer?

Do not repeat a transfer just because the destination balance has not changed. First confirm that the original source transaction succeeded and check whether the route requires a manual claim. A claim is a separate action that completes delivery after earlier checks or waiting periods. Some bridges handle delivery automatically; others require the user to submit that final step.

Also confirm the destination network and token. A bridge may deliver a token representation, rather than the same asset contract used on the source chain. The ticker alone may not identify which token arrived.

The practical rule is to follow the transfer’s recorded state, not the wallet’s balance screen alone. If the source transaction succeeded and the bridge shows a pending destination step, wait or use the documented claim process. Retry only when the bridge’s instructions or support confirms the original transfer cannot complete.