Why a Cross-Chain Transfer Is Stuck and When to Retry

A cross-chain transfer can be confirmed on its starting chain and still be unfinished on its destination chain. The source contract first locks or burns the tokens and emits a message. A validator set or other verification system checks that event, then a relayer carries its proof to the destination. There, a contract verifies the proof and releases or mints the corresponding assets. Each step has its own transaction and can have its own status.

This is asynchronous: the chains do not share one transaction that succeeds or fails all at once. Think of it like a parcel with separate acceptance, transit and delivery scans; a “sent” notice is not a delivery receipt. Some protocols call their messages omnichain because they coordinate actions across chains. For a fuller explanation of how an omnichain model coordinates those steps, see the linked explainer.

What does each transfer status mean?

A status describes one stage in the route, and its exact label depends on the bridge or app. “Submitted” usually means the source transaction was broadcast; “confirmed” or “finalized” means the source chain has accepted it to the protocol’s required level. Neither label alone proves that the destination contract has completed the transfer.

After source confirmation, the message may be waiting for verification, a signature or a relayer. A proof or attestation may then be ready to submit, while destination execution can still be pending. “Completed” should mean the destination action has succeeded, but check the destination transaction itself when funds have not appeared in your wallet.

How can I tell whether a retry is safe?

Match the transfer across chains before sending anything again. Start with the source transaction hash in the bridge’s tracker or the source chain explorer. Confirm that the transaction succeeded and look for a message, sequence number or transfer identifier. Use that identifier to find the destination-side status and, if available, its transaction hash.

• If the source transaction failed, no successful transfer message was emitted; retrying the source action may be necessary.
• If the source succeeded but verification or proof delivery is pending, wait or use the protocol’s supported message-recovery path.
• If the destination transaction failed, check whether the protocol exposes a retry or claim action for that existing message.
• If the destination transaction succeeded, do not resend; check the destination token and recipient address.

When should I avoid submitting the transfer again?

Do not start a second source transfer just because the tracker is slow or a destination balance has not updated. The first message may still be travelling, and a new source transaction can create a second transfer. A retry of destination execution is different: in some protocols it reuses the verified message, while others require a fresh claim or have no user retry button.

Before retrying, verify the status on the relevant chain, confirm the recipient and token, and read the action label in the bridge interface. If the source transaction succeeded and the destination action is still pending, wait for that message or use its explicit recovery option. Retry only the stage marked failed, using the original transfer record. That keeps a delay from turning into an unintended duplicate.