Canonical Bridge

A canonical bridge is the official, sanctioned bridge created and maintained by the core development team of the underlying blockchain (e.g., Ethereum Foundation for Optimism, Arbitrum). This distinguishes it from third-party bridges. Key implications include:

• Security Priority: It is the most security-audited and battle-tested bridge for that specific L1-L2 route.
• Protocol Alignment: Its design and upgrades are synchronized with the core protocol's roadmap.
• Standard for Composability: DApps built on the L2 are designed to interoperate with assets from the canonical bridge.

These bridges enable bi-directional movement of assets, specifically tokens that are native to the parent chain (e.g., ETH on Ethereum). The process involves two distinct operations:

• Depositing (L1 → L2): Users lock tokens in a smart contract on L1, and an equivalent amount of a canonically-wrapped token (e.g., WETH on Arbitrum) is minted on L2.
• Withdrawing (L2 → L1): Users burn the wrapped tokens on L2, initiating a challenge period (fault proof window) after which the original tokens are released on L1. This ensures the L2 state is finalized.

Canonical bridges for optimistic rollups and zk-rollups employ cryptographic and economic mechanisms to minimize trust assumptions, unlike many third-party bridges that rely on multi-signature committees.

• Optimistic Rollup Bridges: Rely on fraud proofs. Anyone can challenge invalid state transitions during a multi-day challenge window (e.g., 7 days).
• ZK-Rollup Bridges: Rely on validity proofs (ZK-SNARKs/STARKs). A cryptographic proof is submitted to L1 to instantly verify the correctness of L2 state batches.
• Economic Security: The security is ultimately backed by the consensus and staking mechanism of the underlying L1 (e.g., Ethereum's ~$100B+ staked ETH).

They govern the authorized supply of assets on the Layer 2. When bridging from L1 to L2, the bridge contract does not simply lock tokens; it authorizes the minting of a canonical representation on L2.

• Minting: The L2 protocol mints new tokens that are recognized as the official, liquid version of the L1 asset.
• Burning: To withdraw, these L2 tokens are destroyed (burned), providing the cryptographic signal to the L1 contract to release the original assets.
• Supply Verifiability: The total supply of the canonical token on L2 is always cryptographically verifiable on L1, preventing unauthorized inflation.

Beyond simple asset transfers, advanced canonical bridges enable generic message passing. This allows smart contracts on L1 and L2 to communicate, enabling complex cross-chain interactions.

• L1 → L2 Calls: An L1 contract can trigger a function in an L2 contract (e.g., governance execution).
• L2 → L1 Calls: An L2 contract can send data or a request to an L1 contract (e.g., reporting a price to an oracle).
• Use Cases: This enables decentralized sequencers, cross-chain governance, and advanced DeFi composability where logic is split across layers.

Assets bridged via the canonical mechanism become the standard, liquid, and composable version of that asset within the L2's ecosystem. This creates a unified financial layer.

• Ecosystem Default: DEXs, lending protocols, and other DeFi applications on the L2 are built to integrate seamlessly with these canonical tokens.
• Liquidity Unification: It prevents liquidity fragmentation that occurs when multiple third-party bridges bring over different, incompatible wrapped versions of the same asset (e.g., USDC.e vs. native USDC).
• Example: On Arbitrum, the canonical bridged ETH is the native gas token and the primary liquidity pair across all major DEXs.

While Wormhole is a generic cross-chain messaging protocol, it often functions as the designated canonical bridge for specific ecosystems. For example, it is the official bridge for Solana's native assets to Ethereum and other chains via the Token Bridge module.

• Role: Provides canonical token representations (e.g., wSOL on Ethereum) for non-EVM chains.
• Guardians: Relies on a decentralized network of Guardian nodes for message attestation.
• Modularity: Its generic message passing allows for more than just asset transfers.

A third-party bridge (or external bridge) is built by an independent entity, not the core chain developers. It offers an alternative, often feature-rich path for cross-chain transfers but is not considered the canonical route.

• Examples: Multichain (formerly Anyswap), Synapse Protocol, Celer cBridge.
• Trade-offs: May support more chains or assets but introduces additional trust in the bridge operator's security and governance.

A liquidity network bridge uses pools of assets on both the source and destination chains to facilitate instant transfers, often without minting/burning wrapped tokens. It is a common design for third-party bridges.

• Mechanism: Users deposit assets into a liquidity pool on Chain A and withdraw from a corresponding pool on Chain B.
• Canonical vs. Liquidity: A canonical bridge typically uses a mint/burn model, while liquidity bridges rely on pooled capital, which can lead to fragmentation.

A wrapped asset is a token on a destination chain that represents a locked asset on the source chain. It is the primary output of most canonical bridges (e.g., Wrapped ETH on Arbitrum).

• Function: Enables the native asset to be used within the destination chain's DeFi ecosystem.
• Redemption: The wrapped token can be burned via the bridge to redeem the original asset on the source chain.

This spectrum defines a bridge's security model based on its trust assumptions.

• Trusted (Custodial): Relies on a central entity or multi-sig to hold user funds. Higher counterparty risk.
• Trustless (Non-Custodial): Uses cryptographic proofs (like light clients or zero-knowledge proofs) to verify state transitions. Minimal trust beyond the underlying blockchains.

Most canonical bridges aim for trustlessness but may have trusted components in early stages.