Check Both Chains Before Resending a Pending Bridge Transfer

2 chain records determine whether a bridge transfer is stuck: the source transaction and the destination execution. The first shows whether your deposit or swap remains on the canonical source chain; the second shows whether the bridge completed delivery. Checking both prevents you from treating a delayed transfer as a failed one and accidentally sending funds twice.

What does a reorg do to a pending bridge transfer?

A reorg replaces recent blocks with a different version of the chain, which can remove a transaction that appeared confirmed. If the source transaction disappears from the canonical chain, the bridge may no longer have a valid deposit or message to process.

But a source reorg does not automatically undo a transaction already executed on the destination chain. Bridge designs differ: some wait for stronger source-chain finality before acting, while others rely on relayers or validators to pass a message. Check the route’s mechanics; for a fuller look at comparing routes, see mayan bridge.

How can you tell whether the transfer is still progressing?

Start with the source transaction hash in a block explorer for the sending chain. Check whether it appears in the current canonical chain, whether it succeeded, and whether its block has reached the finality level required by the bridge.

Then check the bridge’s own status and the destination chain. Look for a destination transaction hash, and verify whether that transaction succeeded and delivered the expected asset to your address. A “pending” label alone does not tell you which stage is waiting.

• Source transaction is canonical and successful: the bridge may still be waiting for confirmations, a relayer, or destination execution.
• Source transaction is missing or reverted: the bridge may have lost the event it was tracking; confirm the result on the canonical chain before taking action.
• Destination transaction succeeded: check the destination wallet and token details; the asset may be represented by a chain-specific token.
• Source and destination records conflict: save both transaction hashes and contact the bridge’s official support channel.

Explorer data can lag or disagree briefly, especially during a reorg. If the transaction’s status is unclear, compare another reliable view of that chain before deciding it has disappeared.

When should you retry or contact support?

Retry only after confirming that the original source transaction is no longer canonical and that the bridge has not completed the destination transfer. If the source transaction was removed, check your wallet balance and transaction history: the source-chain state may have reverted, but the exact outcome depends on what else happened in the replacement chain.

Do not submit the same transfer again just because the bridge interface still says “pending.” A second transfer can create a separate deposit, with its own fees and destination delivery. If the source record is gone but the bridge still reports progress, or if the destination shows a completed transfer you cannot locate, give support the source hash, destination hash if available, route, and wallet address.

For most readers, the right move is to wait while the source transaction remains canonical and the bridge is progressing, then act only after both chain records and the bridge status agree that the first transfer failed.