Cross-Chain Swap Timing Depends on Finality and Execution

Wait until the destination-chain transaction has executed and reached the finality threshold used by the route; a source-chain confirmation alone does not complete a cross-chain swap. The elapsed time depends on two networks and the bridge’s verification and execution path, so there is no single wait that applies to every route. A wallet may show “confirmed” while the bridge is still checking the source event or waiting to submit the destination transaction.

“Swap” can describe either an atomic exchange between parties or a route that bridges an asset and swaps it on the destination chain. In a bridge route, one transaction can trigger several later steps. For a step-by-step account of how a relay bridge moves assets, see the linked guide. The timing question is best answered by identifying which step the transaction has reached.

What determines how long a cross-chain swap takes?

The route’s total time is the combined wait for source-chain inclusion, bridge verification, destination execution and, where needed, destination-chain finality. Those stages depend on different mechanisms. The source chain’s consensus determines when its transaction is considered sufficiently settled; the bridge’s contracts and verification design determine when source activity can authorize a destination action; and the destination chain must include that action in a block.

“Confirmed” and “finalized” are not interchangeable. A transaction can appear in a block before the chain’s consensus rules give it stronger finality. For example, Ethereum proof of stake uses Casper FFG: validators vote on checkpoint pairs, and a supermajority link justifies and finalizes checkpoints. A bridge that waits for stronger source-chain finality can take longer than one that accepts a shallower confirmation threshold, but it reduces exposure to a source-chain reorganization.

Bridge architecture also matters. A lock-and-mint route records assets in a source-chain contract, verifies the event, then authorizes a destination contract to mint or release a representation. A burn-and-mint route burns on the source before minting on the destination. A liquidity route may instead have a relayer or solver deliver destination assets from inventory, with protocol settlement occurring separately. That can make the user-facing transfer faster, but it does not mean every underlying settlement step is already final.

Delays can therefore arise at different points: a congested source chain may delay inclusion; a bridge may be waiting for confirmations or a proof; a relayer may not yet have submitted the destination transaction; or destination congestion and insufficient execution gas may prevent completion. A route estimate is a forecast for those steps, not a consensus guarantee.

Which transaction status should I wait for?

Wait for a successful destination-chain transaction, then allow that chain’s own finality rule to apply before treating the received asset as settled. Track the source and destination transactions separately: the source hash proves what was submitted on the source chain, while the destination hash shows whether the receiving contract actually executed.

• Source pending: The source transaction has not yet been included. Check its status and fee conditions on the source chain before doing anything else.
• Source confirmed, bridge pending: The event is on-chain, but the bridge has not yet completed its verification or relay step. Check the route’s status page for the specific stage it reports.
• Destination transaction pending: The bridge has submitted a destination transaction, but the destination chain has not included it yet.
• Destination transaction failed: The transaction was included but execution reverted or otherwise failed. Check the route’s instructions for whether a retry or claim is supported.

Do not infer success from a wallet balance display alone if the route reports a pending or failed step. Token indexing can lag, and a wallet may not display a token automatically even after the destination transaction succeeds. Verify the destination transaction’s receipt and the relevant contract event or resulting balance using the destination chain’s explorer.

When should I act on a swap that is still pending?

Act when the route’s documented completion window has passed or a specific step is marked failed; until then, diagnose the current step rather than submitting a duplicate transfer. A second source transaction can create a second bridge request, which may move the same intended amount again if both requests later complete.

Start with the source transaction receipt. If it failed, the bridge should not be expected to execute the corresponding destination action. If it succeeded, compare the source event with the route’s status: the bridge may still be waiting for its confirmation threshold, generating or checking a proof, or waiting for a relayer. If a destination transaction hash exists, inspect its receipt. A failed destination execution is different from a relay delay and may require a protocol-supported retry or claim.

Use the route’s stated recovery process and keep the source hash, destination hash, and request identifier together. Never share a seed phrase or sign an unrelated transaction to “release” a pending transfer. The practical rule is simple: a source confirmation starts the cross-chain process; a successful destination execution completes the user-facing transfer, and destination finality determines how settled that result is.