L2 Bridge Landscape: Understand 23 Cross-chain Bridges in One Article
TechFlow Selected TechFlow Selected
L2 Bridge Landscape: Understand 23 Cross-chain Bridges in One Article
Why are cross-chain bridges important for L2?
Navigating Web3 tides with focused insights
Author: Andreas Freund, L2 Standards Working Group, Enterprise Ethereum Alliance (EEA) Community Project
Translation: Kyle, DeFi Dao
We live in a multi-chain world, with billions of dollars worth of assets locked across more than 100 blockchains. Owners of these blockchain assets behave much like holders of traditional financial assets—they seek arbitrage opportunities to profit. However, unlike the traditional financial world, where an asset from one country can be used for arbitrage in another without transferring ownership through trusted intermediaries, this approach did not work for blockchains for a long time due to three reasons:
-
Cross-chain transfer of assets,
-
New decentralized applications (dApps) and platforms that allow users to access the advantages of various blockchains—thereby enhancing their capabilities,
-
Developers from different blockchain ecosystems collaborating to build new solutions.
To address inefficient capital utilization on blockchains—and to profit in the process—enterprising individuals created blockchain bridges to tackle these three challenges and began connecting blockchain ecosystems. Yes, you can now trade Bitcoin on Ethereum. Of course, cross-chain bridges can also serve other functions; however, their primary purpose is improving capital efficiency.
What Is a Blockchain Bridge?
At a high level, a blockchain bridge connects two blockchains and enables secure, verifiable communication between them via the transfer of information and/or assets.
This creates numerous opportunities such as:
-
Cross-chain transfer of assets,
-
New decentralized applications (dApps) and platforms that allow users to access the strengths of multiple blockchains—enhancing their capabilities,
-
Developers from different blockchain ecosystems collaborating to build new solutions.
There are two fundamental types of bridges:
1. Trusted Bridges
Rely on a central entity or system to operate. They involve trust assumptions regarding custody of funds and bridge security. Users primarily rely on the reputation of the bridge operator and must relinquish control over their crypto assets.
2. Trustless Bridges
Operate using a decentralized system, such as smart contracts with embedded algorithms. The security of the bridge matches that of the underlying blockchain. They allow users to maintain control of their funds via smart contracts.
Within these two trust models, we can distinguish several common cross-chain bridge design patterns:
-
Lock-Mint-Burn Token Bridges: Provide instant guaranteed finality because minting of assets on the destination chain can occur immediately, with no possibility of transaction failure. Users receive a synthetic asset on the target blockchain, commonly known as a wrapped asset, instead of the native asset.
-
Liquidity Networks with Pools of Native Assets: A single asset pool on one blockchain connects to pools on other blockchains, sharing access to each other's liquidity. This approach does not guarantee instant finality, as transactions may fail if shared liquidity is insufficient.
However, all designs—and any trust model—must address two key challenges inherent to blockchain bridges.
Ryan Zarick of Stargate introduced the "Bridging Trilemma," which states that a bridge protocol can only achieve two out of the following three properties:
-
Instant Guaranteed Finality: Assurance that assets will be received on the target blockchain immediately after execution on the source blockchain and finalization on the target blockchain.
-
Unified Liquidity: A single liquidity pool for all assets between the source and target blockchains.
-
Native Assets: Receiving the actual native asset on the target blockchain rather than a bridged token minted by the bridge representing the original asset on the source chain.
Arjun Bhuptani of Connext proposed the Interoperability Trilemma, stating that an interoperability protocol can only achieve two out of the following three properties:
Trustlessness: Security guarantees equivalent to the underlying blockchains, with no additional trust assumptions.
Scalability: The ability to connect diverse blockchains.
Generality: Support for arbitrary data message passing.
Beyond the trilemmas—which can potentially be mitigated through clever design—the biggest challenge for blockchain bridges is security, as demonstrated by numerous hacks in 2021 and 2022, including incidents involving Wormhole, Ronin, Harmony, and Nomad. Fundamentally, a bridge between blockchains is only as secure as the least secure blockchain involved in the connection. However, for Layer 2 (L2) platforms both anchored to the same Layer 1 (L1) blockchain, this concern is mitigated because they inherit identical security guarantees from the shared L1.
Why Are Cross-Chain Bridges Important for L2?
So far, we have not specifically discussed L2 platforms designed to scale L1 blockchains while inheriting their security guarantees, because L2s are technically a specific type of bridge: native bridges. However, when building bridges between L2s, differences among platforms—such as optimistic rollups vs. zk-rollups vs. Validium rollups vs. Volition rollups—become significant. These distinctions matter because L2s differ from L1s and from each other in terms of trust assumptions and finality.
The reason L2 bridges are important mirrors that of L1 bridges: L2 assets seek capital efficiency, portability, and other functionalities across different L2s.
As previously noted, differences in native trust assumptions on L2 platforms can be overcome if the bridged L2s are anchored to the same L1. In such cases, the bridge does not require additional trust assumptions. However, differences in how L1 anchors finality for L2 transactions make trust-minimized bridging between L2s challenging.
Types of L2 Blockchain Bridges: Overview
Delving deeper into L2 bridges, ideally an L2-to-L2 bridge should meet the following criteria:
Clients must be abstracted from each L2 protocol they connect to via an abstraction layer—following a loosely coupled paradigm.
Clients must be able to verify the validity of data returned from the abstraction layer, ideally without altering their trust model relative to that of the target L2 protocol.
Interface L2 protocols should not require structural or protocol changes.
Third parties must be able to independently build interfaces for target L2 protocols—ideally standardized ones.
From the current landscape, it appears most L2 bridges treat L2s as just another blockchain. Note that fraud proofs used in optimistic rollups and validity proofs used in zk-rollup solutions replace the block headers and Merkle proofs typically used in standard L1-to-L1 bridging.
Current Landscape of L2 Bridges
Below, we summarize the current and highly diverse landscape of L2 bridges, including name, brief description, and bridge design type:
1. Hop Exchange
A rollup-to-rollup general-purpose token bridge. It allows users to send tokens from one rollup to another almost instantly, without waiting for the rollup’s challenge period.
https://hop.exchange/whitepaper.pdf
Design Type: Liquidity Network (uses an AMM)
2. Stargate
A composable native asset bridge and dApp built on LayerZero. DeFi users can swap native assets across chains in a single transaction on Stargate. Applications compose Stargate to create native cross-chain transactions at the application level. These cross-chain swaps are supported by Stargate’s community-owned unified liquidity pool.
Design Type: Liquidity Network
3. Synapse Protocol
A token bridge that uses validators between chains and liquidity pools to execute cross-chain and on-chain swaps.
Design Type: Hybrid Design (Token Bridge / Liquidity Network)
4. Across
A cross-chain optimistic bridge that uses participants called relayers to fulfill user transfer requests on the target chain. Relayers are then reimbursed by submitting proof of their actions to an Optimistic oracle on Ethereum. The architecture leverages a single liquidity pool on Ethereum and independent deposit/reimbursement pools on target chains, rebalanced using canonical bridges.
Design Type: Liquidity Network
5. Beamer
Enables users to move tokens from one rollup to another. Users request a transfer by depositing tokens on the source rollup. Liquidity providers then fulfill the request by sending tokens directly to the user on the target rollup. The protocol focuses on maximizing ease of use for end users. This is achieved by decoupling two distinct concerns: service delivery to end users and fund recovery by liquidity providers. Service is provided optimistically as soon as a request arrives. Refunds from the source rollup are secured by its own mechanisms and are separate from the actual service.
6. Biconomy Hyphen
A multi-chain relay network leveraging smart contract-based wallets for users to interact with liquidity providers and transfer tokens between different (Optimistic) L2 networks.
Design Type: Liquidity Network
7. Bungee
Description: The bridge is built on Socket infrastructure and SDK, with the Socket Liquidity Layer (SLL) as its core component. SLL aggregates liquidity from multiple bridges and DEXs and also supports P2P settlement. Unlike liquidity pool networks, this single meta-bridge dynamically selects and routes funds through the optimal bridge based on user preferences (e.g., cost, latency, or security).
Design Type: Liquidity Pool Aggregator
8. Celer cBridge
Description: A decentralized, non-custodial asset bridge supporting over 110 tokens across more than 30 blockchains and L2 rollups. It is built on the Celer Inter-chain Message Framework, which itself runs on the Celer State Guardian Network (SGN). SGN is a Proof-of-Stake (PoS) blockchain built on Tendermint that acts as a message router between different blockchains.
Design Type: Liquidity Network
9. Connext
Description: Orchestrates and processes messages related to sending funds cross-chain. Uses custodial funds for canonical assets, fast liquidity, and stable exchange. Connext contracts use the diamond pattern, consisting of Facets that act as logical boundaries for functional groups. Facets share contract storage and can be upgraded individually.
Design Type: Hybrid Design (Token Bridge / Liquidity Network)
10. Elk Finance
Uses ElkNet with the following features:
-
Cross-chain utility token ($ELK) for value transfer
-
Secure and reliable transfers compared to traditional bridges
-
Cross-chain value transfers within seconds between all blockchains supported by Elk via ElkNet
-
Bridge-as-a-Service (BaaS) provides developers with infrastructure to build custom bridging solutions using ElkNet
-
Cross-chain swaps across all connected blockchains
-
Impermanent Loss Protection (ILP) for liquidity providers
-
Non-fungible tokens (Moose NFTs) with unique abilities and traits
Design Type: Hybrid Design (Token Bridge / Liquidity Network)
11. LI.FI
A bridge and DEX aggregator that routes any asset on any chain to any desired asset on a target chain, available via SDK at the API/contract level or as an embeddable widget in dApps.
Design Type: Liquidity Pool Aggregator
12. LayerSwap
Transfers tokens directly from centralized exchange accounts to Layer 2 (L2) networks (Optimistic and zk-rollups) at low fees.
Design Type: Liquidity Network (uses an AMM)
13. Meson
An atomic swap application using Hash Time-Lock Contracts (HTLC), combining secure peer-to-peer communication with a relay network of liquidity providers for supported tokens.
Design Type: Liquidity Network
14. O3 Swap
O3’s Swap and Bridge cross-chain mechanism aggregates multiple liquidity pools across chains, enabling simple one-time approval transactions with planned gas stations to address gas fee requirements on each chain.
Design Type: Liquidity Pool Aggregator
15. Orbiter
A decentralized cross-rollup bridge for transferring Ethereum-native assets. The system has two roles: Sender and Maker. A “Maker” must first deposit excess collateral into Orbiter’s contract to qualify as a cross-rollup service provider for a “Sender.” In the typical flow, the ‘Sender’ sends assets to the ‘Maker’ on the ‘Source Network,’ and the ‘Maker’ sends assets back to the ‘Sender’ on the ‘Destination Network.’
Design Type: Liquidity Network
16. Poly Network
Allows users to transfer assets between different blockchains using a Lock-Mint mechanism. It uses the Poly Network Chain to validate and coordinate message passing between relayers on supported chains. Each chain has a set of Relayers, and the Poly Network Chain has a set of Keepers who sign cross-chain messages. Chains integrated with Poly Bridge must support light client validation, as cross-chain message verification includes validating block headers and transactions via Merkle proofs. Some smart contracts used in the bridge infrastructure are not verified on Etherscan.
Design Type: Token Bridge
17. Voyager (Router Protocol)
The Router Protocol uses pathfinding algorithms to identify optimal routes, leveraging a router network similar to Cosmos IBC to move assets from source to target chains.
Design Type: Liquidity Network
18. Umbria Network
Umbria consists of three main protocols working together:
-
Cross-chain asset bridge: Supports asset transfers between incompatible blockchains and cryptocurrency networks.
-
A staking pool: Users earn interest on their crypto assets by providing liquidity to the bridge. UMBR liquidity providers earn 60% of all fees generated by the bridge.
-
Decentralized Exchange (DEX): An automated liquidity protocol powered by a constant product formula, deployed via smart contracts and fully managed on-chain.
Two protocols work together to enable asset migration between cryptocurrency networks.
Design Type: Liquidity Network (uses an AMM)
19. Via Protocol
The protocol is an aggregator of chains, DEXs, and bridges to optimize asset transfer paths. This enables asset bridging in three ways:
-
Multiple transactions across different blockchains.
-
One transaction via a decentralized bridge integrated with DEXs.
-
One transaction via a semi-centralized bridge that triggers a second transaction on the target chain.
Design Type: Hybrid Design (Token Bridge / Liquidity Network)
20. Multichain
Multichain is an externally validated bridge. It uses a network of nodes running the SMPC (Secure Multi-Party Computation) protocol. It supports dozens of blockchains and thousands of tokens via both token bridges and liquidity networks.
Design Type: Hybrid Design (Token Bridge / Liquidity Network)
21. Orbit Bridge
Orbit Bridge is part of the Orbit Chain project. It is a cross-chain bridge allowing users to transfer tokens between supported blockchains. Tokens are deposited on the source chain, and “representative tokens” are minted on the target chain. Deposited tokens are not strictly locked; the Orbit Farm may use them in DeFi protocols. Accrued interest is not passed directly to token depositors. Bridge and Farm contract source codes are not verified on Etherscan.
Design Type: Token Bridge
22. Portal (Wormhole)
The Portal Token Bridge is built on Wormhole, a message-passing protocol that uses a specialized network of nodes to execute cross-chain communication.
Design Type: Token Bridge
23. Satellite (Axelar)
Satellite is a token bridge powered by the Axelar network.
Design Type: Liquidity Network
The L2Beat project maintains a list of blockchain bridges related to L2s, along with their Total Value Locked (TVL), descriptions, and brief risk assessments (if available).
Risk Profile of L2 Bridges
Finally, when users use L2 bridges—or any bridge—they must proceed with caution and evaluate the following risks for any given bridge:
Loss of Funds
-
Collusion among oracles, relayers, or validators to submit fraudulent proofs (e.g., block hashes, block headers, Merkle proofs, fraud proofs, validity proofs) and/or relay unchallenged fraudulent transfers.
-
Compromise of validator/relayer private keys.
-
Malicious minting of new tokens by validators.
-
Failure to timely challenge false claims (Optimistic message protocols).
-
Reorganization of the target blockchain occurring after the dispute window of an Optimistic oracle/relayer has passed (Optimistic message passing protocols).
-
Unverified contract source code involved in or used by the protocol contains malicious code or features exploitable by contract owners/administrators.
-
Misconduct by token bridge owners, or initiation of time-sensitive emergency actions affecting user funds without proper communication to the user base.
-
Suspension of protocol contracts (if such functionality exists).
-
Protocol contracts receiving malicious code updates.
Frozen Funds
-
Relayers/liquidity providers failing to act on user transactions (messages).
-
Suspension of protocol contracts (if such functionality exists).
-
Protocol contracts receiving malicious code updates.
-
Insufficient liquidity for target tokens on the bridge.
User Censorship
-
Oracles or relayers on the source, target, or both L2s failing to facilitate transfers (messages).
-
Suspension of protocol contracts (if such functionality exists).
While this list is not exhaustive, it provides a solid overview of the current risks associated with using bridges.
Ongoing developments using Zero-Knowledge Proof (ZKP) technology aim to mitigate some of the above risk factors and resolve the two bridge trilemmas. Specifically, ZKP usage enables the following bridge design characteristics:
-
Trustless and secure, because correctness of block headers on source and target blockchains can be proven via zk-SNARKs, which are verifiable on EVM-compatible blockchains. Thus, no external trust assumptions are needed, assuming the source and target blockchains and the light client protocol used are secure, and there is at least one honest node in the relay network (1-of-N).
-
Permissionless and decentralized, as anyone can join the bridge’s relay network without requiring PoS-style or similar validator schemes.
-
Scalable, because applications can retrieve ZKP-verified block headers and perform application-specific validation and functions.
-
Efficient, thanks to new, optimized proof schemes with short proof generation and fast verification times.
Although still early, these developments hold promise for accelerating the maturity and security of the bridge ecosystem.
Summary
We can summarize the above discussion and overview of L2 bridges as follows:
-
L2 Bridges are vital glue for the L2 ecosystem, further promoting L2 interoperability and efficient use of assets and applications across the entire ecosystem.
-
L2 bridges used between L2s anchored to the same L1, such as Ethereum Mainnet, are more secure than bridges between L1s—assuming the codebase is secure, which is often a significant assumption.
-
As with all distributed system architectures, critical trade-offs must be made, as expressed by the two trilemmas—the Bridging Trilemma and the Interoperability Trilemma.
-
L2 bridges have vastly different trust assumptions, e.g., trusted vs. trustless bridges, and very different design choices, e.g., lock-mint-burn vs. liquidity networks.
-
The L2 Bridges ecosystem is still in its infancy and rapidly evolving.
-
Users are advised to conduct due diligence to assess which L2 bridges offer the best risk-return profile for their needs.
-
New developments leveraging cutting-edge ZKP technology are effectively addressing both bridge trilemmas and contributing to improved overall bridge security.
While still in the early stages of standardizing L2 interoperability frameworks, these are important developments that deserve serious attention, as any of these projects could become *the* bridging framework.
Special thanks to Tas Dienes (Ethereum Foundation), Daniel Goldman (Offchain Labs), and Bartek Kiepuszewski (L2Beat) for carefully reviewing the manuscript and providing valuable content suggestions.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
