A Cross-Chain Transfer Looks Stuck. Here’s How to Track It

Two transaction records show the two legs of a cross-chain transfer: one on the source chain and one on the destination. A confirmed source transaction means the first leg was recorded; it does not prove the destination asset has arrived. Check the destination leg before deciding that the transfer failed or sending it again.

Start with the transaction hash from the bridge interface or your wallet, and open it in the explorer for the source chain. The source receipt can show whether the transaction is pending, failed, or confirmed, and its event logs may identify the bridge message created for the transfer.

Why is my cross-chain transfer still pending?

A transfer can pause between source confirmation and destination execution because the route must pass a message or liquidity between chains. Depending on the route, a relayer or other service may need to observe the source event and submit the destination transaction; some routes also require a separate claim step.

Look up the route’s status in the bridge interface, then check the destination chain’s explorer using any destination transaction hash or message identifier shown there. Route designs differ: the mechanics described in this portal bridge overview are one example of why the transfer type matters. A source transaction can be confirmed even while the destination transaction has not yet been submitted.

What should I check on each chain?

Use the source transaction to establish what was requested, then look for evidence that the matching message was executed on the destination. Keep the chain names beside the hashes: a hash belongs to a particular chain, and searching for it in the wrong explorer can make a valid transfer look missing.

• Source status: Confirm that the transaction succeeded, rather than merely appearing in wallet history.
• Transfer details: Compare the sender, destination chain, token, amount, and recipient with the route you started.
• Message identity: Match the bridge message ID or event details across the interface and explorers, if the route exposes them.
• Destination status: Check whether the destination transaction is pending, successful, or failed, and whether the expected token arrived at the intended address.

For a token transfer, verify the token contract on the destination chain as well as its displayed name and symbol. Different tokens can use the same symbol, and a bridge may deliver a token representation specific to that route.

When should I retry or contact support?

Do not start a second transfer just because the first one is taking longer than expected. First check the route’s stated processing guidance and whether the original message is still pending, claimable, or already executed; a duplicate can send more funds without resolving the first transfer.

If the route shows a failed destination step or offers a recovery action, follow the bridge’s own instructions for that transfer. If it remains unresolved, provide support with the source chain and transaction hash, destination chain, recipient address, and message ID if available. Never share your recovery phrase or private key to get help.