What to Do When a Bridge Transfer Is Delayed

If a bridge transfer stalls, first check whether the source-chain transaction is still pending or has finalized; those are different failures with different next steps. Find the transaction hash in the wallet or bridge interface and open it in the source chain’s explorer. A submitted transaction is not proof that the bridge has received a deposit: the source chain must include it, and the bridge may wait for additional confirmations before acting. Avoid starting a second transfer until you know which stage is stuck.

How can you tell where the transfer is delayed?

A pending or failed source transaction has not produced a usable deposit event for the bridge. Check its status, nonce where relevant, and fee details in the explorer; on some chains, a low-fee transaction can remain queued while later transactions proceed. If the transaction is confirmed, compare its block and status with the bridge’s own transfer page, since that page may update only after its monitoring or confirmation threshold is met. For the separate question of how acrossbridge uses liquidity pools, see the explanation of how liquidity can speed destination delivery after a source deposit is recognized.

What should you do while the source transaction is pending?

Use the wallet’s supported replacement or cancellation flow only if the chain and wallet allow it, and verify the replacement’s effect before signing. On account-based chains that use sequential nonces, a replacement may compete with the original transaction; it does not reverse a transfer that has already been included. Check the bridge’s status page or support instructions before changing fees or resubmitting, because the safe action depends on the source chain and bridge route.

What if the source transaction is confirmed but the bridge has not paid out?

Keep the source transaction hash and destination address, then follow the bridge’s official status or recovery process. A bridge may still be waiting for its confirmation threshold, a relayer or validator action, destination-chain execution, or available liquidity; these are separate stages, and a pool-based fast route cannot bypass source-chain inclusion or finality. Before using any recovery page, check that it belongs to the bridge and never share a seed phrase or private key.

• Source transaction pending: check inclusion and fee status.
• Source transaction failed: inspect the failure reason before trying again.
• Source transaction confirmed: check the bridge’s required confirmations and transfer status.
• Bridge shows an error: use its documented recovery route with the transaction hash.

Watch the source explorer’s confirmation count against the bridge’s stated threshold; that is the next signal that tells you whether to keep waiting or pursue the bridge’s recovery steps.