Cross-Chain Swap Routes Settle by Different Rules

Choose a cross-chain swap route by comparing how it settles, not just the quoted output: a canonical bridge waits for the source chain’s settlement rules, while liquidity routes can deliver destination funds before their reimbursement is final. A route may also combine a swap on the source chain, a transfer, and a destination swap. Those steps change which contracts execute and where a failure can leave funds. Before signing, check the destination token, minimum received, fees, and the settlement path behind the quote. For the wallet sequence and transaction steps, see quickswap cross-chain swap steps.

How does a canonical bridge settle a swap?

A canonical bridge settles through the contracts and verification rules that connect a specific parent chain to its rollup. On an Arbitrum withdrawal to Ethereum, for example, the L2 gateway burns the child-chain token and creates a message to the parent-chain gateway. The message becomes executable on Ethereum only after the rollup assertion is finalized under its challenge process; the user then executes the withdrawal through the Outbox.

This route’s security inherits from the rollup’s settlement mechanism and the bridge contracts. It does not rely on a third-party relayer promising to replace the asset from its own inventory. The trade-off is time: a canonical withdrawal can remain pending through the challenge period, and claiming it may require a separate transaction and Ethereum gas. Deposits in the other direction follow a different path, so do not assume the wait is symmetric.

Canonical routes are strongest when the destination asset is the canonical representation and the user values settlement through the chain’s own bridge. They are less convenient when the desired asset is a different token or when an application needs funds immediately. A displayed “swap” may require extra transactions around the bridge: an approval, a source-chain exchange, or a destination-chain exchange. The route description should identify those calls, not compress them into one label.

What changes in a burn-and-mint route?

A burn-and-mint route destroys tokens on the source chain and creates corresponding tokens on the destination after the transfer message is verified. Circle’s Cross-Chain Transfer Protocol (CCTP) uses this model for native USDC: the source TokenMessenger burns USDC and emits a message; an attestation service signs that message, and the destination TokenMessenger verifies it before minting USDC.

This avoids locking one token representation on one chain and issuing a wrapped representation on another. The asset remains USDC issued under Circle’s system on both sides. But the route depends on the issuer’s contracts and the attestation step. Until the required attestation is available and accepted on the destination, the mint cannot complete. A quote that advertises fast execution should not be read as a guarantee that every settlement step has already finalized.

Burn-and-mint routes are relevant only when the source and destination assets are supported by that mechanism. They do not automatically exchange USDC for ETH or another token. A router can add a swap before or after the transfer, but each added exchange introduces its own contract call, slippage, and execution risk. Compare the route’s final token amount with the amount after fees, rather than treating the bridge fee as the whole cost.

How does a relayer route deliver funds faster?

A relayer route delivers destination funds from liquidity that a relayer already controls, then settles the relayer’s claim against the user’s source deposit later. In Across’s intent flow, the user deposits through a SpokePool, a relayer fills the order on the destination SpokePool with its own capital, and protocol settlement later verifies the fill and repays the relayer. The destination delivery and the relayer’s reimbursement are separate events.

That separation is the source of the speed advantage and a key part of the trust model. The user receives destination funds without waiting for the full source-to-destination settlement process, while the protocol must still validate the deposit and fill. Liquidity, route limits, and execution availability affect which orders can be filled. A failed or delayed fill is not the same state as a completed destination transfer; check the order status and the transaction that actually delivered the destination asset.

Aggregators can compare these settlement families and compose multiple swaps, but their quote is a snapshot of route availability, price impact, gas, and fees. Inspect the route details before signing:

• Confirm the exact source and destination token contracts. A familiar ticker can refer to different token representations on different chains.
• Compare net output and minimum received after bridge fees, relayer fees, gas, and swap price impact.
• Identify whether settlement depends on a rollup challenge, a signed attestation, or a relayer fill followed by reimbursement.
• Check how the interface reports pending, failed, and completed steps, including any claim or retry transaction it may require.

For most users, the better route is the one whose final asset and settlement dependency match the task, at an acceptable net output. Choose the canonical bridge when its settlement path and wait are acceptable; choose an issuer burn-and-mint path when the required native asset is supported; choose a relayer route when faster delivery matters and its liquidity-based settlement model fits. If the quote does not expose which contracts execute or what event counts as completion, it does not provide enough information to compare routes safely.