A bad bridge experience usually starts with a false assumption: “my coins are travelling.” They are not. A cross-chain transfer is a handoff between contracts, liquidity, and settlement rules. The safe path is to identify who controls the value before you sign, who pays you on arrival, and what happens if nobody does.
Your real choice is whether you need the original asset to travel or just the destination balance to arrive
A bridge moves value between networks. A cross-chain swap also changes the asset, such as ETH on one chain becoming USDC on another. The distinction matters: a bridge route can still use a swap under the hood, but the question to ask is whether the quoted output token and amount are acceptable before approving anything.
The catch is timing. Some designs wait for the source-chain transfer to finalize before release. Others pay you first from destination liquidity and settle the accounting later. Faster does not mean your deposited tokens are sitting in a destination wallet with your name on them.
| Route type | Who holds the input while in flight | Who supplies the destination asset | Best fit |
|---|---|---|---|
| Canonical bridge | A source-chain bridge contract | The bridge’s minting or release mechanism | When native-route provenance matters more than speed |
| Liquidity-pool bridge | A source contract or pool | A destination liquidity pool | When the route is simple and pool liquidity is sufficient |
| Intent-based route | An origin-chain escrow contract | A relayer using its own destination-chain capital | When a quoted outcome and quick delivery matter most |
An intent route changes the holder twice, which is why it can arrive before settlement
With an intent-based transfer, you first authorize a transaction and your input tokens enter the origin contract’s escrow. You no longer hold them in your wallet, but neither does the relayer. The escrow is the on-chain commitment that makes the order credible.
Next, a relayer decides to fill the order. It sends its own tokens on the destination chain to your stated recipient. At that point, you hold the received output in your destination wallet. The relayer, not you, is then waiting to be repaid through the protocol’s later settlement process.
For a route that delivers the quoted asset on the destination chain, use the across bridge. The important check is still the quote: confirm the input token, output token, recipient address, amount received, and displayed fee before signing. A familiar token symbol is not enough; verify the network and token contract in the wallet prompt.
If the fill does not happen, escrow is not the same thing as instant recovery
An unfilled order normally remains in the origin escrow until its deadline and refund path are processed. That is the moment burned users often miss: you may have a valid claim on the funds without having spendable funds yet. Do not send a second transfer merely because the first one is pending.
The safer route is the one whose failure mode you can afford to wait through
- Use a canonical route when you need the chain’s native bridge path and can wait for finality.
- Use a liquidity route when you understand the pool and the route does not introduce an unwanted wrapped asset.
- Use an intent route when you want destination delivery funded by a relayer and accept that source-side settlement continues afterward.
Before submitting, save the source transaction hash, check the destination recipient, and wait for the route’s status to become filled or refunded. Never treat an approval as a completed transfer.