Cross-Chain Bridge

Bridges are fundamentally categorized by their trust assumptions. Trusted (Custodial) bridges rely on a centralized entity or federation to hold assets, offering speed but introducing counterparty risk. Trust-minimized (Decentralized) bridges use cryptographic proofs and decentralized validator sets, aligning with blockchain's core ethos but often at the cost of complexity and latency. The choice dictates the security and permissionlessness of the transfer.

These are the two primary mechanisms for representing assets across chains. In Lock & Mint, the native asset is locked in a vault on the source chain, and a wrapped representation (e.g., wBTC) is minted on the destination chain. Burn & Mint involves burning the asset on the source chain to mint a canonical version on the destination, often used by native cross-chain tokens. The mechanism impacts the asset's supply and redeemability.

Beyond simple asset transfers, advanced bridges enable arbitrary message passing, allowing smart contracts on different chains to communicate. This unlocks complex cross-chain applications like:

• Cross-chain lending: Collateralize assets on Chain A to borrow on Chain B.
• Cross-chain governance: Vote on a DAO proposal using tokens from another chain.
• Interchain NFTs: Move or use an NFT across multiple ecosystems.

These are the network actors that facilitate state verification. A Relayer is an off-chain service that submits transaction data (block headers, receipts) from one chain to another. A Prover (or Light Client) generates cryptographic proofs (like Merkle proofs) that a specific event occurred on the source chain. Trust-minimized bridges use economic incentives and fraud proofs to ensure these actors behave honestly.

Some bridges operate as liquidity networks or pools, rather than minting synthetic assets. Users swap assets via liquidity pools on both chains (e.g., Chain A's USDC pool to Chain B's USDC pool). This model, used by bridges like Hop Protocol and Connext, minimizes slippage for stablecoins and established assets but requires deep, incentivized liquidity on both sides.

Bridges are high-value targets, and their design introduces unique risks:

• Smart Contract Risk: Bugs in the bridge contract can lead to catastrophic fund loss.
• Validator Risk: Collusion or compromise of a majority of a bridge's validators.
• Censorship Risk: A trusted bridge operator freezing or blocking transactions.
• Economic Attacks: Manipulation of oracle prices or liquidity pools. Understanding these is critical for risk assessment.

The most common model for tokenized asset bridges. Assets are locked in a smart contract on the source chain, and an equivalent wrapped token is minted on the destination chain. To return, the wrapped token is burned, and the original is released. This creates a 1:1 pegged representation.

• Examples: Wrapped BTC (WBTC) on Ethereum, Wormhole's Portal bridge.
• Trust Assumption: Relies on the security of the custodian or multi-sig controlling the lockbox.

Also known as atomic swap bridges or DEX-based bridges. They use liquidity pools on both chains instead of locking assets. A user swaps Asset A on Chain 1 for Asset B on Chain 2 via liquidity providers, facilitated by relayers or HTLCs (Hashed Timelock Contracts).

• Examples: Thorchain, Chainflip.
• Key Feature: No wrapped assets are created; it's a direct swap.
• Trust Assumption: Relies on the economic security of the bonded validators and liquidity depth.

Employs a fraud-proof window similar to Optimistic Rollups. A set of attesters or a Notary sign off on state transitions. These attestations are considered valid unless challenged during a dispute period. This reduces operational cost but introduces a delay for finality.

• Examples: Nomad (original design), Across.
• Security Model: Security is cryptoeconomic, relying on bonded parties to submit fraud proofs.
• Finality: Has a challenge period (e.g., 30 minutes) before funds are fully releasable.

A cryptographically secure architecture. Light client smart contracts on the destination chain verify Zero-Knowledge proofs (e.g., zk-SNARKs) that attest to the validity of transactions on the source chain. This provides trust-minimized bridging without external committees.

• Examples: zkBridge, Succinct Labs, Polygon's zkEVM bridge.
• Trust Assumption: Relies solely on the cryptographic security of the proof system and the source chain's consensus.
• Benefit: Near-instant cryptographic finality.

Relies on an external, off-chain committee of validators using Multi-Party Computation (MPC) or a multi-signature wallet to observe and attest to events. This is a trusted or federated model, where security is equal to the honesty of the committee members.

• Examples: Many early bridges (Multichain, early Polygon PoS bridge).
• Operation: Validators run oracle nodes; a super-majority must sign to approve a transfer.
• Risk: Centralization and private key management are the primary attack vectors.

The bridge is built and maintained by the core development teams of the connected chains (e.g., L1 to its L2). It uses the underlying chain's own consensus mechanism and state proofs for verification, making it the official and often most secure route.

• Examples: Ethereum's official bridges to Arbitrum, Optimism, and Polygon zkEVM.
• Trust Model: Inherits the security of the two chains it connects.
• Key Trait: Typically uses a Lock & Mint model but with native, audited contracts.

A two-way peg model where assets are locked in a smart contract on the source chain, and an equivalent wrapped token (e.g., wBTC, WETH) is minted on the destination chain. This is the most common bridge architecture.

• Example: Wrapped Bitcoin (wBTC) on Ethereum.
• Process: User deposits BTC, a custodian locks it, and wBTC is minted on Ethereum.
• Trust Assumption: Relies on the integrity of the custodian or federation holding the locked assets.

These bridges use liquidity pools on both chains instead of locking and minting. Users swap assets via these pools, facilitated by liquidity providers who earn fees.

• Example: Chainscore's Hop Protocol and Connext.
• Process: A user swaps ETH on Ethereum for MATIC on Polygon directly through a pooled liquidity bridge.
• Advantage: Faster for frequent, small transfers; no minting/wrapping delay.
• Trust Assumption: Relies on the security of the bridge's smart contracts and the economic incentives of liquidity providers.

Bridges secured by a decentralized network of external validators or light clients that verify state proofs. They aim for trust minimization by using cryptographic proofs instead of social trust.

• Example: Chainscore's IBC (Inter-Blockchain Communication) and Chainscore's Gravity Bridge.
• Process: Validators monitor both chains, relaying and verifying Merkle proofs of transactions.
• Security Model: Security scales with the validator set's decentralization and stake.

A model where a federation or committee of known entities controls the bridge via a multi-signature wallet. Transfers require a majority of signatures to approve.

• Example: Early versions of the Polygon PoS Bridge (Plasma Bridge) and Chainscore's Binance Bridge.
• Process: User locks assets; a transaction to release funds on the other chain requires signatures from federation members.
• Trust Assumption: High reliance on the honesty of the federation members; a significant centralization risk.

Inspired by optimistic rollups, these bridges introduce a challenge period after a transfer is initiated. During this window, anyone can submit fraud proofs if they detect invalid state transitions.

• Example: Chainscore's Nomad (pre-hack) and Across Protocol (using optimistic verification).
• Process: A proposer posts a bond and asserts a state root; others can challenge it.
• Advantage: Can be more gas-efficient, as verification is only needed if a challenge occurs.

The canonical bridge provided and often maintained by the core development team of a Layer 2 or sidechain. It is the official portal for moving assets to and from a specific chain.

• Example: The Arbitrum Bridge, Optimism Gateway, and Polygon PoS Bridge.
• Key Role: Essential for the initial seeding of liquidity on a new chain.
• Trust Assumption: Users must trust the security and integrity of the chain's core team and its smart contracts.

A trustless method for exchanging cryptocurrencies across different blockchains without an intermediary. It uses Hash Time-Locked Contracts (HTLCs) to ensure that either the entire swap executes or funds are returned.

• Mechanism: Both parties lock funds into a smart contract with a cryptographic hash. The swap completes only if the secret preimage is revealed within a set time.
• Limitation: Requires both chains to support the same cryptographic hash function and is typically limited to simple asset swaps, not complex messages.

A standardized framework or suite of protocols enabling communication and value transfer between disparate blockchain networks. Bridges are one implementation of a broader interoperability vision.

• Examples: The Inter-Blockchain Communication (IBC) protocol, used by Cosmos SDK chains, is a prominent example. It establishes secure, permissionless connections between sovereign chains.
• Scope: Goes beyond simple asset bridging to include general cross-chain messaging, allowing smart contracts on one chain to trigger actions on another.

Tokenized representations of a native asset from one blockchain that exist on another chain. They are the most common output of cross-chain bridges.

• How it works: A bridge locks the native asset (e.g., BTC) on the source chain and mints an equivalent amount of the wrapped version (e.g., WBTC on Ethereum) on the destination chain.
• Custody Model: The security of the wrapped asset is directly tied to the custodial or trust model of the bridge holding the underlying collateral.

A common trusted or federated security model for cross-chain bridges, where a committee of known entities validates and authorizes transactions.

• Mechanism: A multi-signature wallet or a set of Proof-of-Authority validators holds the locked assets or signs off on mint/burn instructions.
• Security Trade-off: This model introduces trust assumptions; users must trust that the majority of the committee will not collude or be compromised. It is a primary target for exploits.