Non-Custodial Bridge

This is the foundational mechanism. When a user bridges an asset, it is locked or burned on the source chain. A corresponding wrapped asset is then minted on the destination chain. The bridge's smart contracts autonomously enforce a 1:1 peg, ensuring the total supply of the wrapped asset never exceeds the locked collateral. For example, locking 1 ETH on Ethereum to mint 1 wETH on Arbitrum.

Instead of a single operator, a network of independent validators or relayers is responsible for verifying transactions and updating state between chains. Common models include:

• Multi-signature (Multi-sig) Committees: A set of signers must reach a threshold to authorize a transfer.
• Light Client Relays: Relayers submit cryptographic proofs (like Merkle proofs) from one chain to another for verification.
• Optimistic Verification: Assumes validity unless a challenge is submitted within a dispute period. This distribution of trust is the core security improvement over custodial models.

Advanced bridges use cryptographic proofs to verify the state of another chain with mathematical certainty. The two primary types are:

• Zero-Knowledge Proofs (ZKPs): Generate a succinct proof (e.g., a zk-SNARK) that a transaction occurred on the source chain, which can be verified cheaply on the destination chain. This offers the highest security.
• Optimistic Proofs: Rely on a fraud-proof window where anyone can challenge an invalid state root. While more capital-efficient, they have longer finality times. These systems minimize trust assumptions in external validators.

Bridges must facilitate liquidity on the destination chain. Two main models exist:

• Lock-Mint (Pooled Liquidity): Assets are locked in a communal pool. Users mint from/deposit to this pool. This requires significant Total Value Locked (TVL) to function efficiently.
• Liquidity Network (Atomic Swap): Uses a peer-to-peer network of liquidity providers (LPs). The bridge finds a counterparty for an atomic swap, eliminating the need for a central pool. This can be more capital-efficient but relies on LP availability. The model directly impacts bridge speed, cost, and maximum transfer size.

This distinction defines a bridge's relationship to the native asset.

• Canonical Bridge: The officially recognized bridge for a Layer 2 or appchain, often deployed by the core development team. It mints the canonical wrapped asset (e.g., Arbitrum's bridge for ETH). Using it is typically safest for that specific asset.
• External (Third-Party) Bridge: A general-purpose bridge built by a separate protocol (e.g., Across, Hop) that connects many chains. It mints its own wrapped asset (e.g., hopETH). This offers connectivity but fragments liquidity across different wrapped versions.

Non-custodial does not mean risk-free. Key considerations include:

• Smart Contract Risk: The bridge's code is a prime attack vector for exploits.
• Validator Set Risk: Compromise of the multi-sig committee or relay network can lead to theft.
• Liquidity Risk: Insufficient liquidity in pools can delay or prevent large withdrawals.
• Technology Risk: Novel cryptographic systems or complex interchain messaging may have undiscovered vulnerabilities.
• Censorship Risk: While decentralized, validator sets could theoretically censor transactions.

A canonical bridge model where assets are locked in a smart contract on the source chain and an equivalent wrapped representation is minted on the destination chain. This model is common for bridging to Layer 2s and uses optimistic fraud proofs or multi-signature governance for security. Stargate Finance popularized this model with a unified liquidity pool system.

• Security Model: Relies on the underlying chain's validators or a decentralized validator set.
• Example: Bridging ETH from Ethereum to Arbitrum.

These bridges use automated market makers (AMMs) and liquidity pools on each connected chain instead of locking and minting assets. Users swap for a bridged stablecoin (e.g., hETH, nextETH) on the source chain, which is then redeemed on the destination chain.

• Key Feature: Enables fast, capital-efficient transfers without a central minting authority.
• Security: Relies on the security of the canonical bridges for asset backing and the AMM smart contracts.

Facilitates direct, peer-to-peer asset exchanges across different blockchains using Hash Time-Locked Contracts (HTLCs). No intermediary custodian holds funds; the swap either completes atomically or fails, returning funds.

• Mechanism: A cryptographic secret must be revealed to claim funds on the destination chain within a time limit.
• Use Case: Often used for cross-chain DEX swaps without wrapped assets.

Uses light client smart contracts that verify block headers from another chain. Relayers (permissionless or permissioned) submit proof that a transaction was finalized on the source chain.

• Gold Standard: The Inter-Blockchain Communication (IBC) protocol uses this model for Cosmos SDK chains.
• Security: Derived from the cryptographic economic security of the connected chains' consensus mechanisms.

Employs an optimistic security model where a single watcher (or a small committee) can submit fraud proofs during a challenge period. Transactions are assumed valid unless proven otherwise, speeding up transfers.

• Efficiency: Lower gas costs and faster optimistic confirmations.
• Fallback: Relies on a slower, cryptographically secure fallback bridge (like a canonical rollup bridge) if fraud is detected.

The core security of a non-custodial bridge rests entirely on its smart contracts. These are complex, custom-built systems that are high-value targets for attackers. Common vulnerabilities include:

• Logic flaws in the cross-chain messaging or validation protocol.
• Reentrancy attacks on asset lock/unlock mechanisms.
• Upgradeability risks if admin keys are compromised.
• Oracle manipulation if the bridge relies on external data feeds for validation. A single bug can lead to the complete loss of all user funds locked in the bridge, as seen in the Wormhole ($325M) and Nomad ($190M) exploits.

Most non-custodial bridges use a decentralized validator or relayer network to attest to events and sign messages. The security model depends on this set:

• Byzantine Fault Tolerance: The bridge's security threshold (e.g., 2/3 majority) defines how many malicious validators can compromise the system.
• Sybil Attacks: If validator stakes are low or identity is cheap, an attacker can amass enough nodes to control the network.
• Liveness Failures: If validators go offline, the bridge may halt, freezing user assets.
• Economic Centralization: A small number of entities often control the majority of stake, creating de facto centralization.

Bridges that use liquidity pools (like many rollup bridges) or mint synthetic assets are exposed to financial engineering attacks:

• Liquidity Drain: An attacker can exploit imbalances between the bridged asset's value on the source and destination chains.
• Infinite Mint Attacks: Flaws in the mint/burn logic can allow an attacker to mint unlimited synthetic tokens on the destination chain.
• Oracle Price Manipulation: If the bridge uses a price feed to peg assets, manipulating that feed can drain liquidity pools. These attacks don't always require breaking cryptography; they exploit economic incentives and market mechanics.

The fundamental action of a bridge is relaying a message (e.g., "release 100 ETH on Chain B") from one chain to another. Risks include:

• Signature Forgery: Compromising the validators to sign fraudulent messages.
• Replay Attacks: Reusing a valid message from one transaction to illegitimately trigger another.
• Race Conditions: Exploiting timing windows between message attestation and execution.
• Destination Chain Execution Risks: Even a valid message can trigger a vulnerable smart contract on the receiving chain, leading to loss.

Decentralization aims to prevent censorship, but non-custodial bridges can still suffer liveness failures:

• Validator Censorship: A cartel of validators could refuse to attest to transactions from specific users.
• Network Congestion: If the bridge design requires transactions on a congested chain (like Ethereum mainnet), high fees or delays can make it unusable.
• Governance Attacks: If bridge parameters are controlled by a token vote, an attacker could seize governance to halt operations or divert funds. Unlike a custodial bridge that can manually process transactions, a stalled decentralized system may have no recourse.

The security burden shifts significantly to the end-user in a non-custodial model:

• Private Key Management: Users must securely manage wallets on both chains. Loss of keys means loss of bridged assets.
• Transaction Complexity: Bridging often involves multiple steps across different UIs and chains, increasing the risk of misdirected funds.
• Front-end & Phishing Attacks: Malicious websites impersonating the bridge interface can steal user approvals and drain wallets. The Ronin Bridge exploit began with a phishing attack on Axie Infinity developers.
• Approval Risks: Users must grant token approvals to bridge contracts, which, if overly permissive, can be exploited later.