Where Cross-Chain Swaps Spend Their Time

A cross-chain swap takes time because it must move value and coordinate a trade across two networks that do not update together. Before, many users treated the wait as one bridge transfer; now intent based routes can deliver destination funds before the bridge’s back-end settlement finishes. That can feel faster, but it changes what “complete” means: funds may be available while the intermediary that advanced them is still waiting to be repaid.

Most routes divide the work into stages: the source transaction is submitted, the source chain reaches the confirmation level the route requires, a bridge or relayer verifies the transfer, and a transaction executes on the destination. If the destination token differs from the source token, a swap may add another execution step. The interface may show one progress bar, but the underlying work can involve several chains, contracts and off-chain services.

That distinction helps explain why a confirmed source transaction does not prove the destination swap has finished. For a wider comparison of route types and their trade-offs, see this guide to Paraswap bridge and cross-chain swap choices. The useful question while waiting is which stage remains open, not simply how long the spinner has been visible.

What happens after I submit a cross-chain swap?

First, the source-chain transaction must be included in a block and meet the route’s confirmation requirements. Those requirements reflect a trade-off: waiting for stronger finality reduces exposure to a source-chain reorganisation, while accepting fewer confirmations can let later stages begin sooner. Chainlink’s CCIP documentation, for example, describes a default path that waits for full source-chain finality before verification; its confirmation settings can affect latency, subject to the lane and token pool’s minimums.

Next, the route must establish that the source event is valid and arrange delivery. In a message-based bridge, off-chain verifiers may attest to the event before a destination executor submits a transaction. In an intent-based route, a relayer may instead use its own destination-chain tokens to fulfill the user’s requested outcome, then claim repayment later. Across’s documentation describes this as initiation, fill and settlement: the user’s deposit is recorded, a relayer fills on the destination, and protocol accounting repays that relayer afterwards.

The destination transaction still needs block space and enough gas to run. If it also calls a token swap, that call must succeed under the quote’s execution conditions. Congestion, a route-specific confirmation delay, low available liquidity, a paused lane, or a failed destination call can therefore leave a transfer waiting at different points. These are distinct causes, even when a wallet uses the same “pending” label for all of them.

Why can one route finish before another?

A liquidity-backed route can make the destination leg appear fast because a relayer advances tokens it already holds there. The user pays for that service through the quoted exchange rate or fees; the relayer bears capital and execution costs while waiting for settlement. In Across’s documented model, settlement happens in batches after fills, so the repayment timeline is separate from the user’s destination delivery.

A route that waits for a bridge message to be verified and executed may avoid that particular advance of destination liquidity, but its timing depends more directly on source finality, verification and destination execution. A canonical bridge may also prioritise its own security model over fast availability. Neither design is universally quicker: the chains involved, token pair, route configuration, liquidity and network conditions all matter.

Using a bridge and then swapping on the destination chain is another option. It makes the stages easier to distinguish, but can require a separate transaction and expose the user to a second quote, gas cost or execution failure. A cross-chain swap bundles the requested outcome into a route, which is more convenient, but adds dependencies between the bridge, liquidity provider or relayer, and destination swap.

• Check the source transaction. Confirm it is included and successful on the source chain, rather than relying on a wallet’s submitted status.
• Find the route’s message or deposit status. If the source transaction is confirmed but the cross-chain record is not yet indexed or verified, destination execution may not have started.
• Check destination execution separately. A filled or delivered status is stronger evidence of arrival than source confirmation; if there is a destination transaction hash, inspect whether it succeeded.
• Compare the quote before retrying. A second submission can create another transfer. Check the original route’s status and any stated expiry or refund process first.

What should I compare before choosing a route?

Compare the expected output, fee, confirmation policy and failure handling together. A route with a shorter quoted time may rely on a relayer and destination liquidity; a route with a longer wait may offer a different verification or finality path. The quote is an estimate for a particular route and moment, not a guarantee that every stage will complete at the same pace.

For most routine transfers, the better choice is usually the route that clearly shows the destination amount, has sufficient liquidity for the amount being sent, and gives you a trackable status and understandable recovery path. A small fee difference is less useful if the destination leg is opaque or a failed execution leaves you unsure what happens next. For a large or time-sensitive transfer, compare the route’s finality assumptions and destination execution requirements as closely as its speed.

While the transfer is pending, follow the source confirmation, bridge or deposit status, and destination execution as separate signals. The next useful change is not another minute on the timer: it is evidence that the route has moved from source confirmation to verification, from verification to fill, or from fill to successful destination execution.