L2BEAT Bridges is a work in progress. You might find incomplete research or inconsistent naming. Join our discord to suggest improvements!

Connext logoConnext

Connext is a multilayered system that aggregates various native AMBs in a Hub-and-Spoke architecture with Ethereum being the Hub receiving messages from other domains. It implements a liquidity network on top of its Hub-and-Spoke architecture.
  • Total value locked
    $1.09 B5.82%
  • Destination
    Various
  • Validated by
    Various AMBs
  • Type
    Liquidity Network
  • ...

    Tokens

    Choose token

    Bridged Tokens (Top 15)

    Renzo Restaked ETH (ezETH)
    Wrapped Ether (WETH)
    Tether USD (USDT)
    USD Coin (USDC)
    Dai Stablecoin (DAI)
    Metis Token (Metis)
    Alchemix USD (alUSD)
    Milestones

    Bacco Upgrade

    2023 Dec 7th

    Connext Amarok mainnet deployment

    2023 Feb 2nd

    Connext Amarok mainnet deployment.

    Learn more

    Connext Amarok announced

    2022 May 11th

    The new, modular architecture for Connext Amarok has been announced.

    Learn more
    Risk summary
    Technology

    Principle of operation

    The bridge can operate in one of two modes: Optimistic or Native. In both modes, so-called routers can accelerate the bridging for users by fronting liquidity (for token transfers) or a bond (for crosschain contract calls) at the destination. The routers are reimbursed after the message has arrived at the destination through one of the two modes.

    In optimistic mode the messages (bridging transactions) go through the central Connext sequencer, who reads them from the source chains, then sequences them and calculates an aggregate root offchain. This aggregate root can be proposed by a relayer at the destination triggering a disputeBlocks window where any watcher can turn the system back into native mode, invalidating the proposed root. Only the owner can set the system back into optimistic mode. Non-invalidated roots get finalized after disputeBlocks. In summary, optimistic mode skips the hub domain (Ethereum in the case of an L2-to-L2 transfer) and native arbitrary message bridges (AMBs) completely.

    In native mode, messages from various spoke domains are aggregated and periodically sent to Ethereum (hub domain) using the native (non-Connext) AMBs. When delivered to the hub domain, these message roots are aggregated again into a root-of-root of messages before being delivered to their destination (spoke domains). A custom delayBlocks value can be set individually in message-receiving Connext contracts to grant a time delay in which Connext-permissioned watchers could invalidate a potentially fraudulent message from the AMBs.

    In the case of a Connext router having accelerated a message by fronting liquidity, they will have to wait a certain time to get their liquidity back. In native mode, this is the time it takes to pass the message via AMBs and then verify / invalidate it during the delayBlocks period. In optimistic mode, it is the time to pass it via the offchain sequencer and finalize / dispute it during the disputeBlocks period. In both cases this reconciliation of funds for the router takes longer than the bridging for the user, while native mode has the longest delay for reconciliation.

    Although the values can be different for every message-receiving contract on each chain, current examples are 120 blocks for delayBlocks and 120 blocks for disputeBlocks on the MainnetSpokeConnector on Ethereum.

    Validation

    For speed, users mainly depend on the bids of routers to fulfill their bridging transactions at the destination. But ultimately, after a message has been passed to the destination via the optimistic or native way and the delay period has passed for watchers to invalidate it, there is no router needed to execute at the destination. This means that the users are ultimately dependent on the correct functioning of the sequencer or the AMBs, and the watchers. Note that for Optimistic Rollups (Arbitrum, Optimism) the AMB is (during Connext native mode) only used as a transport layer, and the 7-day optimistic challenge period is ignored.

    • Users can be censored if watchers disconnect certain connectors or pause the whole bridge.

    • Funds can be stolen if native AMBs that Connext uses or the centralized sequencer (in optimistic mode) forges messages and this is not caught by the watchers.

    • Funds can be stolen if connectors to optimistic rollups receive a fraudulent message within 7-day fraud-proof window and this is not caught by the watchers (CRITICAL).

    Permissions

    The system uses the following set of permissioned addresses:

    Connext Multisig 0x4d50…6625

    Owner of the main Connext Bridge Diamond Proxy. Can upgrade the functionality of any system component with no delay. Maintains the list of Watchers. This is a Gnosis Safe with 8 / 12 threshold.

    Connext Fee Multisig 0x7bE9…2b6A

    Collects fees from the bridge. Can manage Routers through its RouterAdmin role. This is a Gnosis Safe with 1 / 5 threshold.

    Those are the participants of the Connext Fee Multisig.

    Permissioned set of actors who can pause certain bridge components. On Ethereum L1 Watchers can pause RootManager and MainnetSpokeConnector, i.e. modules receiving messages. They can also remove connectors from the RootManager. List of watchers is maintained by the Connext MultiSig.

    Sequencer 0x4fFA…82E7

    Permissioned actor that collects bids from all chains, aggregates them and randomly selects router(s) to fulfill them. The sequencer will post batches of these bids to a relayer network, which will submit them to the destination chain

    Smart contracts
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    The system consists of the following smart contracts on the host chain (Ethereum):

    ConnextBridge 0x8898…63C6

    The main Connext contract. Following Diamond design pattern, it contains multiple Facets that implement various parts of the bridge functionality. This contract stores the following tokens: USDC, WETH, USDT, DAI, Metis, alUSD.

    RootManager 0x523A…9B3A

    Contract responsible for maintaining list of domains and building root-of-roots of messages. It keeps tracks of all hub connectors that connect to specific domain.

    WatcherManager 0x79e6…417d

    Contract maintaining a list of Watchers able to stop the bridge if fraud is detected.

    MainnetSpokeConnector 0x02fd…a1Cc

    Contract that receives messages from other Domains on Ethereum.

    PolygonHubConnector 0xE8cF…d116

    Contract for sending/receiving messages from mainnet to Polygon via Polygon FxChannel AMB.

    PolygonZkHubConnector 0x7ed4…26b1

    Contract for sending/receiving messages from mainnet to PolygonZkEVM via PolygonZkEVM AMB (shared PolygonZkEVMBridge).

    xLayerZkHubConnector 0x279f…c625

    Contract for sending/receiving messages from mainnet to PolygonZkEVM via X Layer AMB (shared PolygonZkEVMBridge).

    GnosisHubConnector 0xF1c7…020d

    Contract for sending/receiving messages from mainnet to Gnosis via Gnosis AMB.

    OptimismHubConnector 0x5c21…bb2A

    Contract for sending/receiving messages from mainnet to Optimism via Optimism AMB transport layer. Note that it reads messages from Optimism as soon as Optimism state root is recorded on Ethereum w/out waiting for the 7-day fraud proof delay window.

    NewOptimismHubConnector 0x23b7…9a94

    Contract for sending/receiving messages from mainnet to Optimism, duplicate of OptimismHubConnector.

    MantleHubConnector 0x5B0E…1e24

    Contract for sending/receiving messages from mainnet to Mantle via Optimism AMB.

    OptimismV0HubConnector 0x9Ba7…19Fa

    Contract for sending/receiving messages from mainnet to pre-bedrock Optimism based projects via Optimism AMB.

    ArbitrumHubConnector 0x8309…Eb82

    Contract for sending/receiving messages from mainnet to Optimism via Arbitrum AMB transport layer. Note that it reads messages from Arbitrum as soon as Arbitrum state root is recorded on Ethereum w/out waiting for the 7-day fraud proof delay window.

    WormholeHubConnector 0xae6B…99DA

    Contract for sending/receiving messages using Wormhole.

    NewWormholeHubConnector 0xf5a3…626b

    Contract for sending/receiving messages using Wormhole, duplicate of WormholeHubConnector.

    LineaHubConnector 0x56Ab…6255

    Contract for sending/receiving messages from mainnet to Linea via Linea AMB.

    ModeHubConnector 0x7b2b…663E

    Contract for sending/receiving messages from mainnet to Mode Network via Optimism AMB.

    The current deployment carries some associated risks:

    • Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).