Asset Bridge

The most common bridging model. Native assets (e.g., ETH) are locked in a smart contract on the source chain, and an equivalent amount of wrapped tokens (e.g., WETH on another chain) are minted on the destination chain.

• Example: Bridging ETH to Polygon via the PoS Bridge locks ETH in an Ethereum contract and mints WETH on Polygon.
• Security: Relies entirely on the security of the bridge validator set or multi-sig controlling the lock contract.

Used by native canonical bridges for a blockchain's own token. To move assets, tokens are burned (destroyed) on the source chain and minted on the destination chain, maintaining a consistent total supply.

• Example: The official Polygon POS bridge uses this model for MATIC.
• Key Trait: The bridge is the authorized minter on the destination chain, often managed by the chain's core development team or DAO.

Uses liquidity pools on both chains instead of minting. Users deposit assets into a pool on Chain A, and a relayer signals the pool on Chain B to release funds from its liquidity.

• Examples: Hop Protocol, Across Protocol.
• Advantages: Often faster and can support many chains via a common canonical token (e.g., hETH for Hop).
• Security: Relies on the honesty of relayers and the economic security of the bond they post.

The fundamental security spectrum for bridges.

• Trusted (Federated/Custodial): A multi-signature wallet or committee of known entities controls the locked assets. Users must trust these entities not to collude. Example: Early versions of Multichain.
• Trustless (Decentralized): Security is derived from the underlying blockchains themselves, using light clients or zero-knowledge proofs to verify state. Example: IBC (Inter-Blockchain Communication) protocol.

Modern bridges are generalized message-passing systems. Beyond moving assets, they can trigger arbitrary actions on another chain.

• Functionality: A bridge can call a smart contract function on the destination chain, enabling cross-chain swaps, governance, and NFT bridging.
• Example: A user deposits USDC on Ethereum, and the bridge message triggers a swap into ETH on Arbitrum, delivering the final asset.

Bridges are high-value targets. Key risks include:

• Validator Compromise: A majority of a federated multi-sig or proof-of-stake validator set is taken over.
• Smart Contract Bugs: Exploits in the bridge's locking, minting, or verification code.
• Economic Attacks: Manipulation of oracle prices or draining of liquidity pools.
• Transaction Malleability: Risks in the relayer or message verification logic.

The most common model where assets are locked or burned on the source chain and an equivalent wrapped representation is minted on the destination chain. The bridge custodian (smart contract or multi-sig) holds the original assets.

• Example: Wrapped Bitcoin (WBTC) on Ethereum.
• Trust Assumption: Relies on the custodian's integrity and security.
• Process: User locks BTC → Custodian verifies → WBTC minted on Ethereum.

A variant using decentralized liquidity pools on both chains instead of a central custodian. Users swap assets with a pool on the source chain, and a corresponding pool on the destination chain provides the output asset.

• Example: Connext, Hop Protocol.
• Trust Assumption: Relies on the security of the underlying AMM and bridge routers.
• Advantage: Faster for high-volume assets; no centralized custodian.

The native asset is burned (destroyed) on the source chain, and an identical native asset is minted on the destination chain. This requires a canonical, synchronized registry (like a Token Bridge Program) to track total supply across chains.

• Example: Wormhole's canonical bridges, Polygon POS Bridge.
• Trust Assumption: Relies on the security of the bridge's validator set.
• Key Trait: Maintains canonical supply; the bridged asset is not a wrapper.

A trust-minimized, peer-to-peer model using Hash Time-Locked Contracts (HTLCs). Two parties atomically swap assets on different chains without an intermediary, based on cryptographic proof.

• Trust Assumption: Minimal; relies on cryptographic security and chain finality.
• Limitation: Requires counterparty discovery and liquidity alignment.
• Use Case: Often used for direct, large-value transfers between parties.

Employs a fraud-proof system similar to Optimistic Rollups. Transactions are assumed valid unless challenged during a dispute period by a network of watchers. This reduces operational cost but adds a delay to withdrawals.

• Example: Nomad (historically), Across Protocol.
• Trust Assumption: Assumes at least one honest watcher will submit fraud proofs.
• Trade-off: Lower cost, faster posting, but introduces a challenge period delay.

Uses Zero-Knowledge proofs (e.g., zk-SNARKs) to cryptographically verify the state of the source chain on the destination chain. A light client on the destination chain validates proofs of inclusion.

• Example: zkBridge, Polygon zkEVM Bridge.
• Trust Assumption: Highest cryptographic security; trustless if the proof system is secure.
• Advantage: Near-instant finality with strong cryptographic guarantees.

Arbitrageurs and Maximal Extractable Value (MEV) searchers are sophisticated actors who exploit inefficiencies created by bridges. Their activities include:

• Cross-chain arbitrage, capitalizing on price discrepancies for bridged assets (e.g., USDC on Ethereum vs. USDC.e on Avalanche).
• Exploiting latency in bridge finality for risk-free profit opportunities.
• Monitoring bridge transaction mempools for profitable MEV strategies, such as front-running large cross-chain transfers.

Everyday users interact with bridges for basic asset transfer and exploration. This includes:

• Speculators moving funds to new Layer 1 or Layer 2 chains to purchase native tokens early.
• Users seeking lower transaction fees by bridging assets from a high-fee chain (e.g., Ethereum Mainnet) to a low-fee chain (e.g., Arbitrum, Polygon).
• Participants in airdrops or community events requiring interaction with a specific chain.

The fundamental security model of a bridge dictates its risk profile. Custodial bridges rely on a single entity or a multi-signature committee to hold user funds, creating a central point of failure. Trustless bridges (or decentralized bridges) use cryptographic proofs and smart contracts to validate cross-chain transactions without a central custodian, but they depend on the security of the underlying blockchains and their light clients or relayers.

Bridges are implemented as complex smart contracts, making them susceptible to code exploits. Common vulnerabilities include:

• Logic bugs in the mint/burn or lock/unlock mechanisms.
• Reentrancy attacks where malicious contracts repeatedly call bridge functions.
• Signature verification flaws in multi-party validation schemes.
• Oracle manipulation if the bridge relies on external data feeds for consensus. The 2022 Wormhole bridge hack ($325M) and Ronin bridge hack ($625M) were primarily due to compromised private keys and validator node control, highlighting the criticality of secure key management and contract design.

Many bridges use a validator or relayer network to attest to events on one chain and submit proofs to another. If an attacker gains control of a supermajority (e.g., 2/3 or 4/6) of these nodes, they can forge fraudulent transactions and mint illegitimate tokens on the destination chain. This is a consensus-level attack on the bridge's own security layer, separate from the security of the connected blockchains.

Bridges face risks related to the assets they manage. Wrapped asset de-pegging can occur if the bridge's reserves on the source chain are drained or frozen, causing the minted tokens on the destination chain to lose value. Liquidity fragmentation across multiple bridges for the same asset can lead to slippage and arbitrage issues. Furthermore, bridges with their own governance tokens are exposed to governance attacks, where an attacker acquires enough tokens to maliciously upgrade bridge contracts.

Even if funds are safe, a bridge may fail to operate. Censorship can happen if validators refuse to process certain transactions. Liveness failures occur when the relayer network goes offline, halting all transfers. For trust-minimized bridges relying on light clients, a data unavailability attack on the source chain can prevent the destination chain from verifying transactions, freezing the bridge.

To manage bridge risks, developers and users should:

• Audit rigorously: Use multiple reputable firms to audit bridge contracts and cryptography.
• Implement circuit breakers: Include pause functions and daily limits to cap potential losses.
• Diversify bridges: Do not concentrate all liquidity in a single bridge; use a multi-bridge strategy.
• Verify proofs: For users, prefer bridges that use cryptographic proofs (like zk-SNARKs or Merkle proofs) over purely social consensus.
• Monitor for anomalies: Use monitoring tools to detect unusual minting or withdrawal patterns.