L2BEAT Bridges is a work in progress. You might find incomplete research or inconsistent naming. Join our Discord to suggest improvements!
Connext
About
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.
About
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.
Connext Amarok announced
2022 May 11th
The new, modular architecture for Connext Amarok has been announced.
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,
- connectors to optimistic rollups receive a fraudulent message within 7-day fraud-proof window and this is not caught by the watchers,
- a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).
Users can be censored if
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.
The system uses the following set of permissioned addresses:
This is a Gnosis Safe with 7 / 9 threshold. It uses the following modules: OptimisticGovernor. Owner of the main Connext Bridge Diamond Proxy. Can upgrade the functionality of any system component with no delay. Maintains the list of Watchers.
Those are the participants of the Connext Multisig.
This is a Gnosis Safe with 1 / 5 threshold. Collects fees from the bridge. Can manage Routers through its RouterAdmin role.
Those are the participants of the Connext Fee Multisig.
Permissioned set of actors who can perform certain bridge operations as a service.
Permissioned set of actors who can front liquidity, speeding up message delivery.
The system consists of the following smart contracts on the host chain (Ethereum):
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.
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.
Contract maintaining a list of Watchers able to stop the bridge if fraud is detected.
Contract that receives messages from other Domains on Ethereum.
Contract for sending/receiving messages from mainnet to Polygon via Polygon FxChannel AMB.
Contract for sending/receiving messages from mainnet to PolygonZkEVM via PolygonZkEVM AMB (shared PolygonZkEVMBridge).
Contract for sending/receiving messages from mainnet to PolygonZkEVM via X Layer AMB (shared PolygonZkEVMBridge).
Contract for sending/receiving messages from mainnet to Gnosis via Gnosis AMB.
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.
Contract for sending/receiving messages from mainnet to Base via OP stack AMB.
Contract for sending/receiving messages from mainnet to Mantle via OP stack AMB.
Contract for sending/receiving messages from mainnet to Metis via Optimism AMB.
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.
Contract for sending/receiving messages using Wormhole.
Contract for sending/receiving messages using Wormhole, duplicate of WormholeHubConnector.
Contract for sending/receiving messages from mainnet to Linea via Linea AMB.
Contract for sending/receiving messages from mainnet to Mode Network via OP stack 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).