Introduction

Ethereum L2s need interoperability. This can entail layer 2 exits and broader L2:L2 communication. With gas fees increasing, users would like to avoid having to go through Ethereum Layer 1. Liquidity is already getting fragmented across scaling solutions. Most interop approaches range from Rollups (native crosschain validation), MPC bridges like Ren to 1:1 swaps like Connext. At the end of the day many facets of interoperability boil down to the trustlessness of the bridges used. In this report we dive into two innovative solutions, Hop and Connext, that aim to facilitate the growth of cross-chain value transfer to create a better UX.

State Channels Refresher: Let’s go back to the bar tab analogy. At a bar, if you open a tab with your card you are locking up funds with them (collateral) and the bartender has the right to your card if you don’t pay. You could buy many drinks on the open tab but there’s only one transaction at the end. Instead of signing a transaction to Ethereum it’s handed to the counterparty (bar tab). Applying the crypto lens, instead of many transactions onchain, you can send the recipient however many cryptographic signatures instead, giving the end user the ability to draw up to a certain amount from the multisig.

How does Connext work? In its simplest form Connext is a state channel network. You have a set of liquidity providers or state channel nodes (routers) that front liquidity in a receiving side channel to get a payment in a sending channel. Essentially routers also function as LPs. To maintain profitability and offset charges like onchain transaction costs, server costs, collateral costs and more, they can either charge static fees or dynamic fees. One can send a payment in a state channel in ETH to a Connext router and it sends a corresponding payment in the state channel back to the user. Since channels are used, one can enforce that those two interactions are atomic (no way to lose funds, not complete once router has initiated process).

Connext expands on the concepts of state channels in that updates within channels have arbitrary conditionality between them, enabling conditional payments. This also circumvents the issue of needing to deploy a new multisig with each person transacted with. User A can pay User B (taking microfee) who pays User C (taking microfee). Since channels are linked by offchain communication it’s possible to transact in various currencies within the same flow across different chains. Another benefit that comes with Connext is the strong UX as it’s gas abstracted, making a frictionless onboarding experience.

As a mental model for Connext, think of it as a cross-chain clearinghouse that sits on top of any of the chains within the Ethereum layer 2 ecosystem and allows one to net off volume between them.

High Level Step by Step Walkthrough: Connext flow.

While the walk though above portrays a high-level flow of how Connext works, it does have some oversimplifications which are not entirely accurate.

The actual implementation of Connext leverages a particular op-code “Create2” supported by almost all connected chains such as Matic, Optimism, xDai, SKALE, Arbitrum. In simple terms, Create2 assigns addresses to particular contracts that do not exist yet on-chain but can be deployed if needed. Leveraging this capability of underlying chains, Connext allows users to create a channel without having to make an on-chain transaction. Instead, to create a channel, users commit to an off-chain transfer sending funds to a