Fungible Token Bridge

The most common bridging model. Tokens are locked in a smart contract on the source chain, and an equivalent amount of wrapped tokens are minted on the destination chain. This mechanism maintains a 1:1 peg, as the original assets remain secured in the source chain's vault. Examples include Wrapped BTC (WBTC) on Ethereum and bridged USDC on various Layer 2s.

A model often used by native cross-chain tokens. To move assets, tokens are burned (destroyed) on the source chain, and a corresponding amount is minted on the destination chain. This requires a canonical token definition and a secure messaging system to coordinate the burn and mint events across chains. Chainlink's CCIP and some Layer 2 native bridges use this pattern.

Also known as liquidity network bridges, these do not mint new tokens. Instead, they use liquidity pools on both chains. A user deposits tokens into the pool on Chain A, and a relayer instructs the pool on Chain B to release the same asset to the user. This model is faster but introduces slippage and relies on sufficient liquidity. Examples include Hop Protocol and Stargate.

Bridges differ fundamentally in how they validate cross-chain transactions. Key models include:

• Externally Verified (Multisig/Committee): A set of trusted entities signs off on transfers. Faster but introduces trust assumptions.
• Natively Verified (Light Clients): Uses cryptographic proofs to verify the source chain's state on the destination chain. More secure but computationally expensive.
• Optimistically Verified: Assumes transactions are valid unless challenged during a dispute period, similar to Optimistic Rollups.

A critical distinction in bridged assets:

• Canonical (Native) Tokens: The official, issuer-approved representation on a foreign chain (e.g., USDC.e on Avalanche, bridged via the official Circle bridge). The issuer guarantees redeemability.
• Wrapped (Non-Canonical) Tokens: A third-party representation of an asset (e.g., USDC bridged via a DeFi protocol). Value is backed by the bridge's security, not the original issuer. This creates depeg risk if the bridge is compromised.

The core infrastructure that relays data between chains. It's the communication protocol that informs the destination chain about a deposit on the source chain. This layer can be:

• A set of off-chain relayers watching and forwarding events.
• A light client that cryptographically verifies block headers.
• A zk-SNARK proof of the source chain state. The security of the entire bridge depends on the integrity of this messaging layer.

Bridges are the primary conduit for moving liquidity between ecosystems. This is essential for:

• Enabling trading on Decentralized Exchanges (DEXs) on emerging Layer 2s or alternative Layer 1s.
• Supplying assets to lending protocols like Aave or Compound on their deployed chains.
• Creating yield farming opportunities by moving assets to chains with higher incentives.

Example: Bridging USDC from Ethereum to Arbitrum to provide liquidity on a Uniswap v3 pool.

Bridges facilitate user migration to networks with lower transaction fees (gas costs). Users often:

• Bridge assets from a high-cost chain (e.g., Ethereum mainnet) to a low-cost Layer 2 (L2) like Optimism or Polygon to interact with dApps affordably.
• Use bridges as an entry point, purchasing assets on a centralized exchange that supports a cheap chain and bridging to their destination.

This reduces barriers to entry and drives adoption on scaling solutions.

Decentralized applications and organizations use bridges to achieve chain-agnostic functionality.

• dApps deploy on multiple chains and use bridges to synchronize state or allow users to move assets seamlessly between instances.
• DAOs use bridges to treasury diversification, moving funds (like DAI or wETH) across chains for deployment in different ecosystems or for security.
• Enables cross-chain governance, where token holders on one chain can signal or vote on proposals affecting another.

Bridge usage is dictated by its underlying security model, which falls into three main categories:

• Trusted (Custodial): Users rely on a centralized federation or multi-sig. Faster/cheaper but introduces counterparty risk. Example: Multichain (formerly Anyswap).
• Trust-Minimized (Native): Uses the underlying chain's validators (e.g., light clients). Most secure but often slower. Example: IBC (Inter-Blockchain Communication).
• Optimistic & Zero-Knowledge (ZK): Newer models using fraud proofs or ZK-SNARKs to verify state. Example: Nomad (optimistic), zkBridge.

Bridges create two main types of cross-chain tokens, affecting composability and liquidity:

• Canonical Assets: The 'official' bridged version, minted by a canonical bridge (e.g., Arbitrum's bridged ETH). Often has native status on the destination chain.
• Wrapped Assets (non-canonical): A representation minted by a third-party bridge (e.g., Multichain's USDC). Can lead to fragmented liquidity if multiple wrapped versions exist.

Users must understand which type they hold for protocol compatibility.

The fundamental security of a bridge is defined by who controls the assets. Trusted (Custodial) bridges rely on a central entity or multi-signature wallet, introducing a single point of failure. Trust-minimized bridges use decentralized networks of validators or cryptographic proofs (like light clients or zero-knowledge proofs) to verify cross-chain state, reducing reliance on any single party. The choice dictates the trust versus complexity trade-off.

Bridges are implemented as smart contracts on both the source and destination chains. Vulnerabilities in this code are a primary attack vector, as seen in the Wormhole ($325M) and Nomad ($190M) exploits. Key risks include:

• Logic flaws in validation or mint/burn mechanisms.
• Upgradability features that can be misused if compromised.
• Oracle manipulation feeding incorrect price or state data. Rigorous audits and formal verification are critical, but not foolproof.

For bridges using a Proof-of-Authority or multi-party signature model, the security depends on the honesty of the validator set. Attacks can occur through:

• Sybil attacks, where an attacker controls multiple validator identities.
• Collusion of a supermajority of validators to steal funds.
• Key compromise of individual validators through social engineering or malware. Mitigations include requiring large, reputable validator sets and slashing mechanisms for malicious behavior.

Bridges can be attacked by exploiting their economic design or overwhelming their capacity.

• Liquidity Attacks: Draining liquidity pools on the destination chain to create insolvency.
• Replay Attacks: Submitting the same valid proof multiple times to mint extra tokens.
• Denial-of-Service (DoS): Spamming the bridge with transactions to halt operations or increase costs for users.
• Front-running: Exploiting transaction ordering in mempools to intercept bridge transactions.

The core technical challenge is proving an event (like a burn) happened on another chain. Insecure verification leads to forged withdrawals. Secure methods include:

• Light Client Relays: On-chain verification of the other chain's block headers (computationally expensive).
• ZK Proofs: A cryptographic proof (e.g., zk-SNARK) that a transaction is included in a source chain block, verified cheaply on the destination.
• Optimistic Verification: A fraud-proof system where transactions are assumed valid unless challenged within a time window.

Beyond protocol-level risks, users and operators face additional threats:

• Phishing: Fake bridge frontends that steal user approvals and private keys.
• Wrapping Asset Risk: Using a bridge introduces wrapped assets (e.g., wETH). Users are exposed to the bridge's solvency and the underlying collateral's security.
• Admin Key Risk: Centralized bridges hold admin keys that can freeze or confiscate funds, a regulatory and operational hazard.
• Chain-Specific Risks: The bridge's security is only as strong as the underlying consensus of the chains it connects.

The underlying communication layer that enables a bridge to transfer data and state between blockchains. Protocols like LayerZero, Wormhole, and Axelar provide the secure message-passing infrastructure that token bridges rely on. They handle the critical tasks of message verification and consensus across disparate networks.

A bridge model that uses pooled liquidity on both the source and destination chains to facilitate transfers, rather than locking and minting tokens. Examples include Hop Protocol and Connext. Key characteristics:

• Uses LP Pools: Users swap into a liquidity pool on the source chain and out of a pool on the destination.
• Faster & Cheaper: Often provides faster settlement and lower costs for high-volume assets.
• Relies on LPs: Requires sufficient liquidity provision from third parties.

The official, native bridge deployed by a blockchain's core development team to connect to another network (e.g., the Arbitrum Bridge from Ethereum, or the Polygon PoS Bridge). These are typically:

• More Trusted: Considered the standard and most secure route.
• Slower Withdrawals: Often have longer challenge periods for optimistic rollups.
• Mint/Burn Model: They lock the original asset and mint a canonical wrapped version on the destination chain.

A token representation of an asset native to another blockchain, created by a bridge. When a bridge locks an asset like ETH on Ethereum, it mints WETH on the destination chain (e.g., WETH on Arbitrum). These tokens are pegged 1:1 to the original asset and are only redeemable by burning them through the same bridge.

The trust assumptions and validation mechanism that secures a bridge's operations. The three primary models are:

• Trusted (Federated): Relies on a known set of validators or a multi-signature wallet.
• Trust-Minimized (Light Client/Relay): Uses cryptographic proofs verified on-chain.
• Optimistic: Assumes validity but has a fraud-proof challenge period. The choice of model directly impacts the bridge's trust assumptions and attack surface.

A standardized protocol for secure communication and value transfer between sovereign, interoperable blockchains, primarily within the Cosmos ecosystem. Unlike many Ethereum-centric bridges, IBC:

• Uses Light Clients: Enables blockchains to verify each other's consensus proofs.
• Standardized Packets: Transfers fungible tokens (ICS-20) and arbitrary data.
• Native Interoperability: It is a core protocol layer, not a separate application.