Bridge Trust Models Compared: Light Client, Validator Set, Intent
Bridges have lost more value than any other category in crypto, and almost always at the same point: whoever attests that funds arrived on the other side.
Bridges have lost more value than any other category in crypto, and almost always at the same point: whoever attests that funds arrived on the other side.
A bridge must convince the destination chain that something happened on the source chain. Light-client bridges verify consensus proofs cryptographically and inherit the chains' own security. Validator-set bridges rely on an external group whose keys are the entire attack surface. Optimistic bridges assume validity unless challenged within a window. Intent-based bridges use a solver who fronts the funds and takes the settlement risk. The trust model determines what can fail and how much.
Chains cannot read each other. When you bridge, some mechanism has to tell chain B that a deposit landed on chain A, and everything about a bridge's risk profile is determined by what that mechanism is. Ronin lost roughly $624m because five of nine validator keys were compromised. Wormhole lost about $326m because a signature verification flaw let an attacker forge the attestation. Nomad lost about $190m because a routine upgrade made every message trivially valid. Three different bridges, one category of failure: the thing that says "yes, this happened" was wrong.
A group of nodes watches the source chain and signs an attestation. A threshold of signatures releases funds on the destination. This is the easiest model to build and the most common historically.
The security is exactly the security of those keys and no more, regardless of how secure the underlying chains are. A 5-of-9 multisig protecting a billion dollars is a five-key problem, and the incentive to obtain five keys scales with the balance. Ask two questions of any bridge in this category: how many signers, and are they independent organisations running independent infrastructure? A validator set operated by one team on one cloud provider has one point of failure with several names.
The destination chain runs a light client of the source chain, verifying its consensus directly, or receives a cryptographic proof — a zero-knowledge proof of state — that it can check. There is no external committee. If the source chain finalised the deposit, the destination can establish that fact for itself.
This is the strongest model available and the hardest to build: it requires implementing one chain's consensus rules inside another's execution environment, and keeping that implementation correct through every upgrade on both sides. Proving costs are real, so these bridges are typically slower or more expensive, and coverage across chains is narrower.
Residual risk sits in the implementation rather than in a trusted party — a bug in the verifier is still a total loss, but there is no key to steal.
Messages are assumed valid and executed after a challenge window during which any watcher can submit fraud proof. The trust assumption is that at least one honest watcher exists and is online.
The trade-off is latency: a genuine optimistic bridge cannot deliver instantly without someone fronting liquidity. In practice most consumer-facing optimistic bridges pair the slow verified path with fast liquidity providers who advance funds and take the settlement risk. Across is the clearest implementation of this pattern — users get a fast fill from a relayer, and the underlying settlement is verified more slowly with the relayer bearing the wait.
Nomad's failure is the cautionary case for this family: an initialisation error set the trusted root to zero, and because the design assumed messages were valid, every forged message passed until someone noticed.
You state an outcome — this much of this asset on that chain — and a competitive network of solvers bids to deliver it. A solver pays you on the destination immediately from its own inventory and later reclaims from the source.
Your counterparty risk during the transfer is close to zero, because you receive funds first or in the same atomic settlement. The bridge risk has been moved onto the solver, who is being paid to hold it. What you are exposed to instead is the escrow contract's correctness and the possibility of no solver bidding on an unusual route, which shows up as a quote that is worse than expected or a transfer that falls back to a slow path.
The most important special case. When the asset has an issuer who exists on both chains, no bridge is required: the issuer burns on one side and mints on the other. Circle's CCTP does this for USDC, and the result is canonical USDC on the destination rather than a wrapped claim on a bridge's reserves.
For stablecoin transfers this dominates every other option on risk, because it removes the bridge from the trust path entirely. The limits are coverage — it only works for assets with a cooperating issuer — and the fact that you are trusting the issuer, which you already were by holding the token.
Separate from the trust model is the question of what token lands. A canonical asset issued by the original issuer, or an official chain-team bridge asset, is fungible with everything else on the destination. A bridge-specific wrapped token is a claim on that bridge's reserves, and it depegs if the bridge is drained even when you did nothing wrong. This is covered in detail in native versus wrapped bridging, and it is the second thing to check after the trust model.
For stablecoins, use the issuer's own route. For assets with a canonical chain-operated bridge and no time pressure, use it. For speed on major routes, an intent or optimistic-with-relayer bridge gives fast fills with the risk priced into the fee. Treat an external validator set as the option of last resort, sized to what you would accept losing, and check the signer count before you use it.
Above all, do not leave value sitting in a bridge. Bridge exposure should be measured in minutes, not weeks — the bridge ratings weight trust model and time in production above fee and speed for precisely this reason.

Cross-chain bridges move billions between blockchains every week — and have lost billions more to exploits. Here's how the plumbing actually works and how to size up the risk before you use one.

A side-by-side breakdown of the two dominant rollup architectures, what each trades away to scale Ethereum, and where the gap between them is closing.

A side-by-side breakdown of how fiat-backed, crypto-backed and algorithmic stablecoins each maintain their peg, and the specific failure mode that has taken each category down.