A Cross-Chain Transfer Is Stuck. Which Step Failed?

A delayed cross-chain transfer usually means one step has not finished: the source transaction, the bridge’s routing or settlement, or the destination transaction. Find the last confirmed step before you retry, because sending again too soon can create a second transfer without fixing the first.

A typical transfer begins when you approve a token and submit a transaction on the source chain. The chain includes it in a block; the bridge or its service then detects it and waits for whatever confirmation conditions its route requires. Next, a relayer or other settlement mechanism handles the cross-chain instruction. On the destination chain, the transfer may use available liquidity or trigger a swap before a transaction delivers the output to your wallet. The exact route varies: bridges can use different combinations of validators, relayers, liquidity pools and contracts. For a fuller walkthrough, see this step-by-step explanation of a Bungee bridge transfer.

Where can a cross-chain transfer get stuck?

It can pause wherever one component is waiting for another. Start with the source transaction hash in the source chain’s block explorer. If the transaction is pending, it has not yet completed on that chain. If it failed or was dropped, the bridge may never have received a usable transfer instruction. If it succeeded, check whether the bridge interface has detected it and whether the route has moved to settlement.

A visible source transaction does not prove that the destination delivery is complete. The bridge may still be waiting for confirmations, a relayer may not have submitted the next transaction, or the route may lack the required liquidity. Even after destination submission, that chain’s transaction can fail—for example, if its execution conditions are not met. Each stage has its own status and, when submitted on-chain, its own transaction record.

How do you find the last completed step?

Compare the transfer’s status with the records on both chains. Use the transaction hash and the same wallet address shown in the transfer details. Then check these points in order:

• Source: Did the transaction succeed, and does it show the token leaving your wallet?
• Bridge status: Does the route show that it detected the source transaction and advanced past confirmation?
• Destination: Is there a destination transaction hash, and did that transaction succeed?

If the source succeeded but there is no destination hash, the unresolved work is likely between those records. If there is a destination hash, inspect its status and the receiving address. A confirmed destination transaction that sent funds to a different address is not the same problem as a pending bridge step.

Should you retry a delayed transfer?

Retry only after you know what happened to the first transfer. A pending source transaction may need time or a wallet-supported replacement; a successful source transaction may already be in the bridge’s queue. Starting another transfer can commit more funds while the first continues. Check the route’s own status and support guidance, and provide the source hash if you need help.

Treat the bridge’s status as a map of the process, not as proof that every chain has finished. The key question is simple: what is the last successful record, and what transaction or service step comes next? That answer tells you whether to wait, investigate destination execution, or contact the route operator.