Bridging is the step where most self-custody losses happen. Not because bridges are exotic, but because the interface hides how many separate systems a single click actually touches, and because the failure modes are silent: the transaction succeeds, and the asset that arrives is not the one you expected.
This is the sequence we run before moving anything meaningful across chains. It takes about fifteen minutes the first time on a given route and under two minutes afterwards.
1. Decide whether you need to bridge at all
Bridging adds a trust assumption that trading does not. If the asset you want exists natively on the chain you already hold funds on, buying it there is strictly safer than bridging to it, even when the quoted cost is slightly worse.
The honest reasons to bridge are: the asset only lives on one chain, the liquidity you need only lives on one chain, or you are moving into or out of a position you already hold. Convenience is not one of them.
2. Identify what kind of bridge you are using
Three designs dominate, and they fail differently.
- Canonical bridges are operated by the chain itself. Your asset is locked on the origin chain and a native representation is minted on the destination. Risk concentrates in the chain team and its upgrade process.
- Lock-and-mint third-party bridges hold your deposit in a contract and mint a wrapped claim. If that contract is drained, the wrapped token is backed by nothing, and it usually keeps trading for a while anyway.
- Liquidity network bridges never mint. They pay you out of a pool on the destination chain. Nothing is wrapped, but the transfer fails or prices badly when the destination pool is thin.
You can usually tell which you have by reading what the destination token is called. If the receive side says anything other than the plain ticker, you are being minted a claim, not handed the asset.
3. Check which token address actually arrives
This is the check that saves people. Copy the contract address of the token you will receive and compare it against the address the destination chain’s main liquidity uses. Several chains have three or four competing versions of the same stablecoin, only one of which trades deeply.
Arriving with a wrapped version nobody quotes means you now have to bridge back to sell, paying twice and taking the same risk again. The interface will not warn you, because from its perspective the transfer worked.
4. Confirm you have gas on the destination chain
A bridge delivers the token you asked for. It does not necessarily deliver the native asset needed to pay for the next transaction. Landing a stablecoin on a chain where you hold zero gas leaves you holding an asset you cannot move.
Some bridges offer a small gas top-up in the same flow. Where that option exists, take it. Where it does not, send gas first as a separate, small transfer and confirm it landed before bridging the main amount.
5. Test the route with a small amount
Send an amount you would be relaxed about losing, and watch it all the way through: origin confirmation, relayer pickup, destination mint or payout. Then check the received token in a block explorer rather than trusting the wallet label.
The test costs two sets of fees. It is the cheapest insurance available on this step, and it also tells you the real end-to-end time, which is frequently different from the estimate shown.
6. Read the delay and finality windows
Optimistic designs include a challenge period, commonly measured in days for withdrawals back to the settlement layer. Fast withdrawals exist, but they are a separate service that fronts you liquidity for a fee, with its own counterparty.
Know which one you are using before you need the funds. A position that must be closed inside an hour cannot depend on a route with a multi-day exit.
7. Total the cost on both sides
The real cost is origin gas, plus the bridge or relayer fee, plus destination gas, plus any slippage on a liquidity network route. Compare the amount that lands in your wallet against the amount you sent. That difference is the only number that matters.
Aggregator interfaces will quote several routes for the same transfer. The cheapest is not automatically the right one, because a route can be cheap precisely because it passes through a bridge with weaker assumptions.
8. Keep the transaction hashes
Save the origin hash and, once it exists, the destination hash. Every bridge support process starts by asking for them, and a stalled transfer without a hash is close to unrecoverable.
If a transfer stalls, check the bridge’s own status page first, then whether the destination chain is producing blocks. Most stalls are relayer backlogs that clear on their own. Resubmitting the same transfer on a different route while the first is pending is how one stuck transfer becomes two.
What this sequence does not cover
None of it protects against a compromised front end. If the site serving the bridge interface is hijacked, the approval you sign can point anywhere, and every check above will still pass. Bookmark the interfaces you use, verify the contract addresses independently, and treat any link that reaches you through a message as untrusted.
It also says nothing about whether the destination venue is worth trading on once you arrive. That is a separate assessment, covered in our guide on how to choose a reliable DEX, and the routing side is in the DEX aggregator guide.
For projects that need users to reach a token on a specific chain without losing them at the bridging step, the acquisition and onboarding side is covered on our crypto traffic acquisition page.