Five rules that minimise bridge risk in practice.
Rule 1: Use the strongest available trust model
For every (source, destination, asset) tuple:
- If both chains are Cosmos: IBC, always.
- If it's Polkadot ↔ Ethereum: Snowbridge, always.
- If it's USDC anywhere Circle supports: CCTP, almost always.
- Otherwise: pick the largest validator set (Axelar > LayerZero).
- Never use a bridge that's been hacked in the last 12 months.
The wallet's picker enforces the first four; the user enforces #5 by reading the bridge's history before clicking.
Rule 2: Bridge in small increments
If you need to move €10,000:
- Bad: one €10,000 bridge transaction.
- Better: five €2,000 bridge transactions, spaced 30+ minutes apart.
Reasons:
- Concentrated risk: if the bridge fails on transaction #1 of #5, you lose 20% not 100%.
- Anonymity-set hygiene: large single bridge transactions are distinctive and chain-analysable.
- Liquidity-network bridges (Connext, Hop) have per-tx pool limits.
The wallet's bridge UI suggests splitting amounts above €5000.
Rule 3: Use canonical IBC channels
If you bridge ATOM from Cosmos Hub to Osmosis via IBC, use channel-141 (the canonical one). Using a non-canonical channel produces a different IBC denom that Osmosis AMM pools don't recognise. The wallet always defaults to canonical channels; never override unless you have a specific reason.
Similar idea on EVM bridges: use the canonical wrapped token for each chain (canonical USDC, canonical WETH). The wallet's UI marks these explicitly.
Rule 4: Verify the destination chain address
Bridges are unforgiving about destination address. Sending to a Solana address from an Ethereum-side bridge with a typo isn't recoverable.
Three discipline points:
- Copy-paste from the destination chain's wallet UI, not from memory or notes.
- Verify the last 6 characters before signing.
- Test with €1 first if it's a new (source, destination, asset) combination you've never used.
Rule 5: Confirm before assuming
Bridge transactions appear "complete" in the source chain UI long before the destination side credits you. If your XRPL bridge to Ethereum shows "confirmed", the EVM-side tokens might take another 5-15 minutes.
The wallet's bridge dashboard shows both sides — source and destination — with a state machine. Wait for "complete on both sides" before assuming the bridge is done.
If it's been >2 hours and only one side shows confirmed, file a support ticket. Don't bridge a second time — you'll just lose more.
What the cert tree forces
The wallet's gating tree requires:
- bridges.101 (this course) for any bridge operation
- crosschain.301 (Bridge Lord) for bridge operations above €500/day
- crosschain.401 (Bridge Master) for bridge operations above €2000/day
Without these certs you're capped at €500/day across all bridges. With crosschain.401, you're capped at €2000/day. Above that requires the Maestro tier.
These caps aren't arbitrary. They're a forcing function: "if you're moving more than €5000 across chains, you've actively learned how each layer works, and the operations log proves it."
End of course
You now understand:
- What a bridge is (lock + prove + mint)
- The trust-model spectrum (light-client → centralised → federated → optimistic → liquidity-network → atomic swap)
- The six bridges the wallet integrates and what each is for
- The history of bridge hacks ($2.5B lost in 5 years)
- The five safe-bridging rules
This unlocks bridges.201 (DEX aggregation across chains) and crosschain.301 + 401 (the Bridge Lord / Master cert path). The cert tree is gated to prevent users from bridging large amounts without progressively deeper understanding.
The exam is 28 of 35 questions; pass at 78%. Good luck.