Trust Models: Native, Light Client, Multisig, Optimistic

A taxonomy and the actual security each level provides — Vitalik's framework, applied to real bridge designs in production.

35 min · expert · part of Cross-Chain Engineering & Bridge Design

Why Trust Model Is the First Question

Before you can reason about whether a bridge is safe, you have to know what assumption you are making when you use it. Every bridge ultimately reduces to a question: "Who or what is allowed to tell the destination chain that something happened on the source chain, and what stops them from lying?" The answer to that question is the trust model, and trust models are not interchangeable. They differ in who has unilateral power to forge a message, how many of them must collude or be compromised before the bridge breaks, and what kinds of bugs can take down the system even when nobody acts maliciously. Vitalik Buterin's January 2022 essay "Cross-chain bridges are fundamentally limited" laid out the taxonomy most of the industry now uses. The categories are: **native** verification (the destination chain itself verifies, via shared sequencers, validators, or a rollup's settlement layer); **light client** verification (the destination chain runs a verifier for the source chain's consensus); **external validator** verification (a separate set of attestors, usually a multisig or MPC committee, signs off); and **optimistic** verification (anyone can submit a claim, and any honest watcher can dispute it during a challenge window). Real protocols are rarely pure. Wormhole's Guardian set is external validation, but it composes with the Wormhole VAA (Verified Action Approval) signature scheme that has its own verification properties. LayerZero uses a "decentralized verifier network" architecture in V2 where multiple DVNs (Decentralized Verifier Networks) can be configured per application. CCIP layers an external committee with an independent **Risk Management Network** that can veto suspicious traffic. The categories are useful as a starting frame, but every production bridge ends up hybrid. This lesson defines each category precisely, gives the actual security each provides in practice, and shows where production protocols sit on the spectrum. By the end you should be able to look at a bridge's documentation and answer: "If this fails, what specifically had to go wrong?"

Also in this lesson

Native Verification: Shared Security with the Destination
Light Client Verification: IBC and Beyond
External Validator Verification: Multisigs and MPC
Optimistic Verification: Single-Honest-Watcher
Hybrid Designs and the Trust-Cost Frontier

Key terms

Trust model: The specific assumption that must hold for a bridge to remain secure: who or what is authorized to attest to cross-chain events, and what stops them from lying.
Native verification: A trust model in which the destination chain itself verifies source-chain events, typically because the chains share a settlement relationship (e.g., rollup-to-settlement) or a validator set.
Light client verification: A trust model in which the destination chain runs a verifier for the source chain's consensus (e.g., IBC's Tendermint light client) and validates Merkle proofs of inclusion against accepted headers.
External validator verification: A trust model in which a separate set of attestors (multisig, MPC committee, or PoS validator set) signs off on cross-chain messages; common in Wormhole (19 Guardians), Axelar (75 validators), and Chainlink CCIP.
Optimistic verification: A trust model in which any party can submit a claim and any honest watcher can dispute it during a challenge window; relies on at least one honest watcher being attentive, as used by Across and original Nomad.
VAA (Verified Action Approval): Wormhole's standardized message format containing a payload plus a quorum of Guardian signatures (13-of-19 threshold). Any destination chain can verify a VAA against the Guardian public keys.
DVN (Decentralized Verifier Network): LayerZero V2's abstraction for the entities that attest to cross-chain messages. Applications can require any combination of DVNs (e.g., LayerZero Labs DVN, Google Cloud DVN, Polyhedra zkLightClient DVN, custom DVN).
Risk Management Network (RMN): Chainlink CCIP's independent veto committee that can curse (block) suspicious cross-chain transmissions even after the primary DON has approved them. Layered defense beyond the primary committee.
Single-honest-watcher: The security assumption underlying optimistic bridges: as long as at least one watcher is honest and online during the challenge window, fraudulent claims will be reverted.
Challenge window: The time period during which optimistic-bridge claims can be disputed; typical values range from minutes (Across relayer repayments) to 7 days (Arbitrum/Optimism canonical withdrawals).

Continue this lesson — 5 more sections in the CryptoBipto app.

Open lesson

Educational only — not financial advice.