When you cross chains, someone has to verify that the source-side lock happened before the destination-side mint. That "someone" is the bridge's validator set. Different bridges have different sets.
Mapping the players
| Bridge | Validator set | Trust ≈ |
|---|---|---|
| IBC | Both chains' own validators (light-client) | Both chains being safe |
| Snowbridge | Polkadot validators (BEEFY commitments) | Polkadot itself |
| CCTP | Circle (a single regulated issuer) | Circle |
| Ripple native | Ripple Labs (single issuer) | Ripple |
| Axelar | ~70 BFT validators | Two-thirds of those validators |
| Wormhole | 19 guardians | 13-of-19 multisig |
| LayerZero | App-configurable DVN multisig (commonly 5-of-7) | The DVN set |
The trust assumption you take varies hugely. Light-client bridges (IBC, Snowbridge) inherit the source chain's full security; federated bridges add a separate trust assumption on a smaller validator set; centralised bridges put it all on one entity.
Compare the assumptions
For IBC moving ATOM from Hub to Osmosis:
"I trust Cosmos Hub validators (~180) and Osmosis validators (~150) to not collude with each other to fake my packet."
For Snowbridge moving DOT to Ethereum:
"I trust Polkadot validators (~600) to not sign a fraudulent BEEFY commitment."
For Wormhole moving SOL to Ethereum:
"I trust 13 of the 19 specific Wormhole guardian validators to not collude to fake my message."
For LayerZero moving anything:
"I trust 5 of the 7 specific DVN validators the app configured to not collude or get phished simultaneously."
These are dramatically different statements. Federated bridges with 19+ validators look diverse, but operational security usually concentrates around a few hosting providers, a few cloud regions, a few key-management systems. Ronin's 5-of-9 became 5-of-1 in effect once Sky Mavis outsourced one of them.
What "diverse" actually means for a federation
A genuinely diverse federation:
- Validators in different jurisdictions (US, EU, Asia, NZ — to avoid single-state seizure)
- Different hardware (HSMs from different vendors, MPC vs HSM mix)
- Different operators (no two validators at the same company)
- Different software stacks (different Linux distros, different validator binaries)
Most federations don't have this. Wormhole has the most diverse guardian set in production today; Axelar is second. LayerZero's per-app DVN configurations vary wildly — a careful app uses diverse DVNs; a lazy app stacks them all on AWS.
Why this matters for you
If you have €10000 to move from Cosmos to Ethereum, your options are:
- Cosmos Hub → Axelar (Cosmos↔ETH) → Ethereum: trust 70 Axelar validators
- Cosmos Hub → IBC → Osmosis → Osmosis IBC bridge to Ethereum: 2 IBC light-client jumps
- Wait for direct IBC-Polkadot-Snowbridge multi-hop: not yet shipped
For €100 you might just pick whichever is fastest. For €10000 you do the trust-assumption math.
What the wallet shows
The bridge picker UI shows each candidate's:
- Security tier label (e.g. "BEEFY light-client", "19-guardian federation")
- Fee + latency
- Per-validator-set incident history (e.g. "Wormhole: 1 critical Feb 2022 (patched + backfilled)")
You see the trade-offs before you click. The wallet's job is presenting them honestly; the choice is yours.
A heuristic
For amounts below €500: pick by fee + speed. For amounts above €500: pick by trust model; fee + speed are tiebreakers. For amounts above €5000: also factor in the bridge's incident history within the last 24 months.
The wallet's progressive cert gating (crosschain.101 → 301 → 401) is meant to force this discipline at the policy layer.
Next: gas tokens — "I have funds" doesn't mean "I can send".