Bridge Security Models

What Are Bridge Security Models?

A bridge security model defines who (or what) you trust when moving assets between blockchains. Every cross-chain bridge makes a fundamental choice: it either delegates verification to a set of trusted parties, or it uses cryptographic proofs to verify state transitions directly on-chain. The security model determines what can go wrong, how much money is at risk, and what an attacker needs to compromise in order to steal funds.

The spectrum runs from fully centralized (a single custodian controls the bridge) through federated multisig, optimistic verification, on-chain light clients, and finally zero-knowledge proof verification. Each step reduces trust assumptions but typically increases cost, latency, or engineering complexity. No single model dominates: real-world bridges choose their position on this spectrum based on the chains they connect, the assets they support, and the tradeoffs their users will accept.

The Security Spectrum

Bridge security models can be grouped into five broad categories, ordered from highest trust requirements to lowest.

Centralized Custodian

The simplest bridge model: a single entity holds assets on one chain and issues wrapped tokens on another. Centralized exchange bridges (Binance, Coinbase) operate this way. Users deposit BTC or ETH, and the exchange credits them with a wrapped version on the destination chain.

The trust assumption is total: the custodian controls the private keys, and users rely entirely on the entity's operational security, legal accountability, and solvency. If the custodian is hacked, goes bankrupt, or acts maliciously, users lose their funds. Wrapped Bitcoin (WBTC) originally operated under a custodial model managed by BitGo, though it has since transitioned to a multi-institutional custody arrangement.

Federated Multisig

Instead of trusting one entity, a federated bridge distributes control across a committee of signers. Transactions require a threshold of signatures (for example, 3-of-5 or 5-of-9) to authorize withdrawals. This is the model used by most bridges today, including Wormhole's Guardian network and the Ronin bridge that secured Axie Infinity.

The security guarantee is only as strong as the signer set. If an attacker compromises enough keys to meet the threshold, they can drain the bridge. The critical parameters are: how many signers exist, what threshold is required, how keys are stored (HSMs, cold storage, or hot wallets), and whether the signer set is permissioned or permissionless. A permissionless set with a high threshold (like tBTC's 51-of-100) is meaningfully more secure than a small, permissioned committee.

Optimistic Verification

Optimistic bridges process cross-chain messages immediately but include a challenge window during which any observer can submit a fraud proof demonstrating that the relayed message was invalid. If no challenge succeeds within the window, the message is accepted as final.

Across Protocol uses this model through UMA's optimistic oracle: a relayer fills the user's order on the destination chain, then a dataworker submits a claim to the oracle. The claim is bonded and enters a challenge window (typically one hour for Across). If disputed, resolution goes through UMA's Data Verification Mechanism. The trust assumption is that at least one honest watcher exists to challenge invalid claims during the window.

The Nomad bridge also used an optimistic model, but a faulty smart contract update initialized the trusted root to 0x00, bypassing verification entirely and enabling a $190 million exploit in August 2022.

Light Client Verification

Light client bridges run a lightweight version of the source chain's consensus on the destination chain. When a cross-chain message arrives, the receiving chain verifies it against the stored block headers using Merkle proofs: no external signers are needed.

The Inter-Blockchain Communication (IBC) protocol, used across the Cosmos ecosystem, is the most widely deployed example. Each connected chain maintains a light client of every other chain, continuously verifying block headers. When one chain sends a packet, it includes a cryptographic proof of inclusion in that chain's state. The receiving chain verifies the proof against the known header: if a relayer submits invalid data, the light client rejects it.

The trust assumption reduces to the honest majority assumption of each chain's validator set: the same assumption you already make by using that chain at all. No additional trusted parties are introduced. The tradeoff is cost: maintaining on-chain light clients requires gas for header updates, and not all chains support the necessary on-chain verification primitives.

Zero-Knowledge Proof Verification

ZK bridges replace on-chain light client state tracking with succinct zero-knowledge proofs. Instead of storing and verifying every block header, a ZK prover generates a compact proof that the source chain's consensus was valid, and the destination chain verifies this proof in a single transaction.

Succinct's SP1 zkVM is one implementation powering this approach: it generates ZK proofs of chain consensus (Tendermint, Ethereum light client protocol, and others) that replace multisig verification. SP1 reduced Tendermint light client proving time from 2.2 hours to 4.6 minutes and secures over $1 billion in on-chain assets.

ZK bridges offer the strongest security guarantees: no trusted signer set, no challenge period, and trust assumptions grounded purely in cryptographic soundness. As proving costs decrease, this model is expected to progressively replace multisig and optimistic bridges for high-value transfers.

Major Bridge Exploits

Bridge exploits accounted for 69% of all cryptocurrency stolen in 2022. The pattern is consistent: attackers target the weakest link in a bridge's trust model.

Ronin Bridge: Social Engineering Meets Weak Multisig

The Ronin bridge used a 5-of-9 validator multisig. North Korea's Lazarus Group targeted a Sky Mavis engineer with a fake job offer containing a malicious PDF. This compromised four Sky Mavis validator keys. The attackers then exploited a gas-free RPC node to obtain the Axie DAO validator signature, reaching the five-key threshold needed to drain the bridge. The exploit went undetected for six days.

Wormhole: Undeployed Security Fix

Wormhole's Solana contract used a deprecated function (load_instruction_at) that did not validate the system address for the Instructions sysvar. The attacker created a fake sysvar account that mimicked a successful signature verification call, then used the forged Validator Action Approval (VAA) to mint 120,000 wETH. A fix for this exact vulnerability had been committed to the public GitHub repository but not yet deployed to production.

Nomad: A Single Line of Code

A routine upgrade accidentally initialized the trusted root to 0x00, which matched the default value for unproven messages. This meant any message was automatically considered valid. Once the first attacker demonstrated the exploit, hundreds of copycats replicated the transaction, draining $190 million in what became a chaotic free-for-all. Some "white hat" actors later returned approximately $32 million.

What Makes a Bridge Secure

Analyzing the exploit history reveals consistent patterns. Secure bridges share several properties:

• Minimized trust assumptions: fewer trusted parties means fewer targets. A ZK proof has no signer set to compromise; a 2-of-5 multisig has a small and brittle one.
• Defense in depth: key management using hardware security modules, geographic distribution of signers, timelocked withdrawals, and independent monitoring systems.
• Rate limiting and circuit breakers: capping maximum withdrawal amounts per time period so that even a successful exploit cannot drain the entire bridge at once.
• Audited and battle-tested code: smart contract bugs (Wormhole, Nomad) are as dangerous as key compromise. Multiple independent audits, formal verification where feasible, and bug bounty programs reduce this risk.
• Transparent signer operations: for multisig bridges, the signer set, threshold, key storage practices, and rotation procedures should be publicly documented.

Bitcoin Bridge Challenges

Bitcoin's scripting language is intentionally limited: it lacks loops, has no concept of external chain state, and cannot verify arbitrary cryptographic proofs on-chain. This makes trustless bridge design on Bitcoin significantly harder than on Turing-complete chains like Ethereum or Cosmos SDK chains with IBC support.

The UTXO model adds further constraints. Because every spend must be predetermined, bridges cannot easily support arbitrary withdrawal amounts: users must deposit set denominations so that matching pre-signed withdrawal transactions exist. There is no native mechanism for "making change" on a withdrawal.

Current Bitcoin Bridge Approaches

Given these constraints, Bitcoin bridges have adopted several strategies:

• Federated multisig with large signer sets: tBTC uses a 51-of-100 threshold signature scheme with a permissionless node operator set. This distributes trust more broadly than smaller multisigs. tBTC has reported zero security incidents and secured approximately 5,835 BTC as of early 2026.
• BitVM-style verification: BitVM enables optimistic verification on Bitcoin by encoding computation in Bitcoin Script and using a challenge-response protocol. A bridge can accept deposits immediately and rely on a dispute window where any watcher can prove fraud. This approach is still maturing but offers a path toward trust-minimized Bitcoin bridges without script changes.
• Atomic swaps: using HTLCs or adaptor signatures, users can swap Bitcoin for assets on other chains without any intermediary. This is peer-to-peer and trustless but limited to swap-style operations rather than arbitrary bridging.
• Layer 2 protocols: solutions like Spark extend Bitcoin's capabilities without modifying the base layer, enabling richer functionality (including stablecoin transfers) while inheriting Bitcoin's security through on-chain settlement guarantees.

Comparing Security Models

Use Cases

Choosing a bridge security model depends on the specific use case and risk tolerance:

• High-value institutional transfers: ZK or light client bridges with the fewest trust assumptions, or centralized custodians with legal recourse and insurance
• Retail DeFi bridging: optimistic or multisig bridges that balance speed with acceptable trust tradeoffs, especially for smaller amounts
• Bitcoin DeFi access: federated threshold bridges like tBTC for accessing wrapped Bitcoin on Ethereum and other chains
• Cosmos ecosystem interoperability: IBC light clients for native, trustless transfers between Cosmos SDK chains
• Stablecoin transfers across chains: intent-based bridges like Across for fast cross-chain stablecoin movement with optimistic security

Risks and Considerations

Smart Contract Risk

Even bridges with strong security models are only as safe as their code. The Wormhole and Nomad exploits were both smart contract bugs, not failures of the underlying security model. Any bridge holding significant value should have multiple independent audits, and users should check audit history before depositing funds.

Signer Key Compromise

For multisig bridges, key management is the primary attack surface. Harmony's 2-of-5 threshold was dangerously low. Ronin's 5-of-9 was higher but still vulnerable to a targeted social engineering campaign. Users should evaluate how many signers exist, what threshold is required, and whether keys are stored in HSMs or cold storage.

Liveness Assumptions

Optimistic bridges assume honest watchers are online to submit fraud proofs during the challenge window. If all watchers fail or are censored, invalid messages can be accepted. Light client bridges require periodic header updates: if the relayer stops submitting headers, the light client becomes stale and the bridge halts.

Honeypot Dynamics

Bridges aggregate enormous value in a single contract, making them the highest-value targets in crypto. Over $55 billion in TVL sits in bridges as of 2025. This concentration of value means that even a small vulnerability can lead to catastrophic losses. For a deeper analysis of bridging risks in the stablecoin context, see the stablecoin cross-chain bridging risks research article.

The Future Direction

The industry is moving toward trust-minimized verification. ZK proofs are becoming cheaper and faster, making ZK light clients viable for an expanding set of chains. Meanwhile, Bitcoin-specific innovations like BitVM and improved threshold signature schemes are reducing trust requirements for Bitcoin bridges without requiring protocol-level changes. The long-term trajectory points toward bridges where cryptographic verification replaces human trust entirely.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.