# Cross-rollup bridges overview ## What are bridges? Bridges are connecting blockchains, services or other networks by enabling users to move funds from one chain to another. In simplest terms, bridging represents locking funds on one chain and releasing desired assets on another network. Bridge keeps track of the asset ownership and defines conditions to be met for claiming assets. ## L2 bridges There have been different kinds of cross-chain bridges for L1s or sidechains around for a while now. Some of them even support current Ethereum L2s as any EVM compatible networks fit into bridges with generalized approach. Nevertheless, today's rollups bring a new generation of *cross-rollup bridges* which are focused solely on L2s. As they can build on native L1<>L2 communication, cross rollup bridges could offer secure solutions for improving user experience of rollups. Usability of L2 ecosystem is limited in various ways which can be improved by cross-rollup bridges. * Partially solve issues with liquidity fragmentation * Liquidity across L2 ecosystem becomes more liquid * With various L2s, cross-rollup bridges allow transacting across arbitrary networks in single transaction * From rollup to rollup without touching the mainnet * Cheaper and faster bridging, easier onboarding to L2 ecosystem * Compared to native bridges, especially withdraws in optimistic rollups This document aims to track all bridges supporting or planning to support rollups. Including general cross-chain bridges as well as cross-rollup focused on L2s. ## Considerations Bridge functionalities generally have to operate on different levels. These include but are not limited to: - Smart contracts on both networks interfacing user assets - Validators verifing data integrity for communication between chains - Liquidity providers with their assets locked on one or more networks Each level represents its own challenge for security and decentralization. Being gateways for connecting networks, big amount of funds might go trough bridges. Points of failure in any part of the bridge can endanger not just user funds but stability of the network. Designing bridge brings problematics like trustless information transfer between chains and multichain liquidity providing. Solutions to these force projects to sacrifice security, capital efficiency, or drop generalized approaches supporting arbitrary data or networks.  Different security considerations expose users to various risks without their knowledge. Users are motivated by speed and price, rather than security. Liquidity providers for bridges are exposed to even more danger as their capital can be lost. ## Native bridges Native rollup bridges only allow L1 <> rollup transactions, cost higher fees, and, in the case of optimistic rollups, require a one-week period (DTD) to achieve finality.  ## Bridging solutions Many projects focusing on rollup bridges emerged. Some of them are trying to achieve trustless setup by set of permisionless validators and AMM liquidity providers, other are fully custodial and rely on a single party. * [Across protocol](https://across.to/) * Trust minimization using [UMA](https://umaproject.org/), Optimistic oracle * Audited by OpenZepelin * Only between L1 <> L2s, no alt L1s * Fees and speed depends on relay, liquidity utilization https://docs.across.to/bridge/how-does-across-work-1/fees * [Hop protocol](https://hop.exchange/) * Marks itself as Ethereum centric * Uses existing arbitrary messaging bridges (AMBs) and bonder (liquidity provider) with capital on L1 * Trust minimization by local verification * Incentives rebalancing using AMM with 'h' tokens * Exists optimistic rollups after one day after waiting full 7 days * Fees * 0.04-0.08% * Speed * 5 minutes * [Connext](connext.network) * Maximizes trust minimization * Users can't loose funds, liquidity routers have certain risks * Requires running offchain code * Intended for integration within apps rather than for end users * https://github.com/connext/nxtp * [Synapse](https://synapseprotocol.com) * Similar model to Hop * Multichain stablecoin nUSD consisting of bucket * [Multichain](https://anyswap.exchange) (Previously Anyswap) * Crosschain dex offering trusted bridge * Decentralized governance * Supports many various L1s * Fees * 0.1% * Speed * 10-30 minutes * [Celer cBridge](https://cbridge.celer.network/) * Build on Celer State Guardian Network (SGN) * PoS chain connecting to node gateways, monitoring L1 and passing L1<>L2 data * Managing liquidity pool * Fees * Gas + 0.2% * Speed * 3-5 minutes * [Socket](https://www.movr.network/) (Previously MOVR) * Routing protocol which agregates bridges and DEXs * Users could be able to find cheapest or trustless path * MOVR doesn't create an own bridge, just routes trough set of existing bridges * Agregates DEXs and bridges, allows to transfer token from one chain to another and swap in the same tx * [Orbiter](https://orbiter.finance/) * cross-rollup bridge with smart contracts only on the destination side * optimistic mechanism based on the SPV scheme, doesn't sound secure but should be cheap and fast * transfer to EOA, not contract? * Project is early, not all features enabled, limited docs * Fees * Gas + withholding fee for destination fees + 0.3% * [Optics](https://optics.app/) * Allows passing generalized data between arbitrary chains, cheap and slow * Tradeoff between being a locally and externally verified system * Verifiers incentivized not to submit fault data * Doesn't support Ethereum L2s for now * [Hyphen](https://hyphen.biconomy.io/) * Promises smooth L2 cross chain experience, however doesn't support any L2 (yet) * SAFE protocol * In development by Magmo * Uses HTLCs and focuses on gas optimization * https://ethresear.ch/t/optimizing-cross-chain-swaps These are bridges operating with EVM, Ethereum or its L2s. Any others to consider? Token specific bridges - [DAI wormhole](https://forum.makerdao.com/t/introducing-maker-wormhole/11550), trust minimized and fast, proposal to be implemented this year.  More complex overview of current bridging protocols would include more factors to consider: * Protocol design * Security/trust involved * Capital efficiency * Cost * Time to settlement * MEV resistance * KPIs * Transaction volume * Number of users * Fees consumed https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17