Bridge Trust Assumption

A trustless bridge relies on cryptographic proofs verified by the destination chain's own consensus mechanism, requiring no trust in external validators. This is the gold standard for security.

• Mechanism: Uses light clients or validity proofs (like zk-SNARKs) to verify the state of the source chain.
• Trust Assumption: Users trust only the security of the two connected blockchains.
• Example: The IBC protocol, which uses light client verification for Cosmos SDK chains.

An optimistic bridge assumes transactions are valid unless proven fraudulent within a challenge period, relying on a set of watchers to submit fraud proofs.

• Mechanism: A small committee posts attestations; anyone can challenge incorrect ones during a dispute window (e.g., 7 days).
• Trust Assumption: Users trust that at least one honest watcher exists to submit a fraud proof.
• Example: Optimism's canonical bridge to Ethereum uses a form of this model.

A multisig or MPC bridge uses a predefined committee of known entities (a federation) that must cryptographically sign off on transactions, typically with a threshold (e.g., 8 of 15 signers).

• Mechanism: Relies on Multi-Party Computation (MPC) or a multisig wallet controlled by the committee.
• Trust Assumption: Users trust that the committee majority will not collude to steal funds or censor transactions.
• Example: Many early bridges like Multichain (formerly Anyswap) used this model.

A Proof of Stake bridge employs a decentralized set of validators who stake the bridge's native token to participate in attesting to cross-chain messages. Their stake can be slashed for malicious behavior.

• Mechanism: Validators observe events and vote; a supermajority of stake is required to finalize a transaction.
• Trust Assumption: Users trust the economic security of the validator set—that the cost of acquiring enough stake to attack outweighs the potential profit.
• Example: Axelar and most Cosmos-based bridges utilize a PoS validator set.

A centralized or custodial bridge relies on a single entity or a small group that has full control over the locked assets on the source chain. This is the simplest but least secure model.

• Mechanism: The operator mints/burns wrapped assets based on their own internal ledger.
• Trust Assumption: Users must fully trust the bridge operator's honesty, security, and solvency.
• Example: Early versions of Wrapped BTC (wBTC) on Ethereum, where a single custodian holds the BTC.

Many modern bridges employ hybrid trust models that combine elements from different categories to balance security, speed, and cost.

• Common Combinations: A PoS validator set that also implements fraud proofs, or a multisig that is governed by a DAO.
• Purpose: To create defense-in-depth, where breaching the bridge requires compromising multiple independent security layers.
• Analysis: Evaluating a hybrid bridge requires analyzing the failure modes of each component in its trust stack.

These bridges rely on a multi-signature committee of known, permissioned validators to attest to and authorize cross-chain transactions. Users must trust that a majority of these validators will not collude to steal funds.

• Security Model: Trust in the honesty of the committee members.
• Attack Vector: Consensus-level attack where a supermajority of validators becomes malicious.
• Example: The original Multichain (formerly Anyswap) bridge operated with a federated model.

These bridges use cryptographic verification, where one chain verifies the consensus proofs of the other chain directly. Trust is placed in the underlying blockchain's consensus mechanism, not a third-party committee.

• Security Model: Trust in the cryptographic security and liveness of the connected blockchains.
• Attack Vector: Liveness failure of the source chain or a 51% attack that allows forging of fraudulent state proofs.
• Example: The IBC protocol uses light client verification for Cosmos-SDK chains.

These bridges introduce a challenge period (like optimistic rollups) where transactions can be disputed. A small set of watchers or any user can submit fraud proofs if they detect invalid state transitions.

• Security Model: Trust that at least one honest watcher exists and is monitoring during the challenge window.
• Attack Vector: Liveness attack where all watchers are offline or censored, preventing a timely fraud proof.
• Example: Nomad bridge employed an optimistic security model prior to its exploit.

Also known as atomic swap bridges, these do not lock canonical assets. Instead, they use liquidity pools on both chains and hash time-locked contracts (HTLCs) to facilitate atomic swaps.

• Security Model: Trust in the cryptographic security of the HTLC and the liquidity providers' solvency.
• Attack Vector: Liquidity risk (insufficient pool depth) and griefing attacks that lock funds temporarily.
• Example: Connext and some implementations of Chainflip use this model for fast transfers.

The trust assumption directly determines the most likely failure modes:

• Validator Collusion: The primary risk for trusted/federated bridges.
• Signature/Key Compromise: Affects any bridge using a multi-signature setup.
• Bug in Verification Code: Critical for trustless bridges; a flaw in the light client or proof verification logic can be exploited.
• Upgrade Mechanism Control: If bridge contracts are upgradeable, control of the admin key becomes a central point of failure.

Bridges exist on a spectrum from fully trusted to fully trustless, with inherent trade-offs:

• Trusted Bridges: Higher capital efficiency and speed, but greater custodial risk.
• Trustless Bridges: Maximum security alignment with base chains, but often higher gas costs, latency, and implementation complexity.
• Hybrid Models: Many production bridges use hybrid models (e.g., trustless for verification with a trusted relayer for liveness) to balance security and usability. The choice fundamentally defines the bridge's security ceiling.

This model requires no trust in external parties. Security is derived from the underlying blockchains themselves. Bridges using light clients or zk-SNARKs verify the state of the origin chain directly on the destination chain. While maximally secure, this approach is often complex and resource-intensive to implement.

• Examples: IBC (Inter-Blockchain Communication), zkBridge.
• Security: Equivalent to the security of the connected chains.
• Trade-off: Higher gas costs and implementation complexity.

This model introduces a trust assumption with a security challenge window. A small committee of attesters or a single Proposer submits state updates, which are assumed to be correct. Watchers can submit fraud proofs during a challenge period (e.g., 7 days) to slash malicious actors and revert fraudulent transactions.

• Examples: Nomad (prior to exploit), Optimism's bridge to Ethereum.
• Security: Relies on the presence of at least one honest watcher.
• Trade-off: Introduces a withdrawal delay for full security.

Users must trust a predefined, permissioned set of entities. A multi-signature wallet or Multi-Party Computation (MPC) network controls the bridged assets. Transactions require a threshold (e.g., 8 of 15) of these guardians or validators to sign.

• Examples: Multichain (formerly Anyswap), early versions of Polygon's Plasma bridge.
• Security: Dependent on the honesty and security of the committee members.
• Trade-off: Centralization risk; compromise of the key threshold leads to fund loss.

This is the highest-trust model. A single, centralized entity custodially holds the original assets. The bridge operator mints a wrapped representation (e.g., wBTC) on the destination chain. Users' security is entirely based on the solvency and integrity of the custodian.

• Examples: Wrapped Bitcoin (wBTC) on Ethereum, centralized exchange bridges.
• Security: Equivalent to the security and trustworthiness of the custodian.
• Trade-off: Single point of failure; requires regulatory and operational trust.

Trust is enforced through cryptoeconomic incentives. Validators or relayers must stake a substantial bond (e.g., in the bridge's native token) to participate. Malicious actions, proven via fraud proofs, result in slashing—the loss of the staked bond. This aligns validator incentives with honest behavior.

• Examples: Across Protocol, Synapse Protocol (to a degree).
• Security: Dependent on the bond value exceeding potential attack profit.
• Trade-off: Requires a robust token economic model and dispute resolution system.

Many modern bridges combine multiple trust models to balance security, speed, and cost. A common approach is to use a federated multisig for liveness (fast attestations) backed by a fraud-proof system or escape hatch for security. This creates layered trust assumptions.

• Example: A bridge may use a 8/15 multisig for instant transfers, with a 7-day fraud proof window allowing users to recover funds if the multisig acts maliciously.
• Security: A compromise must defeat multiple, independent security layers.
• Goal: Optimize for the practical trade-offs between trust minimization and user experience.

A model that introduces a challenge period (like optimistic rollups). After a cross-chain message is relayed, anyone can submit fraud proofs to dispute invalid state transitions. This reduces the active trust requirement to a single honest watcher, but introduces a delay for full finality.

• Examples: Nomad (prior to its exploit), Hyperlane's optimistic verification mode.

Bridges that outsource verification to an external set of validators running their own consensus mechanism (e.g., Proof-of-Stake). This creates a new security domain separate from the connected chains. Users must trust the economic security and honesty of this external validator set.

• Examples: Axelar, LayerZero (with its Oracle and Relayer configuration), Wormhole (Guardian network).

This classification is based on official recognition by the underlying chain.

• Canonical Bridges: The officially endorsed bridge for a Layer 2 or appchain, often built by the core development team. It is typically the most secure route for that ecosystem.
• Third-Party Bridges: Independent bridges built by external teams, offering alternative routes, often with different trust/speed trade-offs.

Understanding this distinction is crucial for assessing protocol risk.