Connext was started in 2017 with the following thesis: “Decentralized protocols have the power to put value and ownership back into the hands of individuals. This can only happen if using them is simple enough that they are accessible by anyone.” In 2018, the team at Connext felt that UX was the most significant barrier to the adoption of L2s, so they focused intensely on user experience. Over the years, Connext has built a large community of supporters and stakeholders as they have increased the adoption of Ethereum’s ecosystem through their network of liquidity pools and their increasingly impressive UX.
Launched in January 2021, Connext is an interoperability protocol that allows users to send fast, fully non-custodial transfers or contract calldata between Ethereum Virtual Machine (EVM) -compatible chains and/or rollups.
It enables users to transfer capital or calldata using its NXTP protocol. NXTP is a trustless, low-cost, and easily extensible base protocol launched in September 2021 with a vision to become the Internet Protocol (IP) of the Ethereum multi-chain ecosystem. According to the team, NXTP has the following distinct advantages over other systems:
Trustless - NXTP does not introduce an external set of validators that control user funds. Instead, the protocol utilizes a lock/unlock mechanism that makes the transfer of funds more secure. This mechanism makes it impossible for user funds to get stolen, even if the transaction validation mechanism defaults.
Extensible - Since the protocol has an extensible architecture and can work the same way on any system, it can be easily expanded to new sidechains, L2s, and other L1 chains. Moreover, given the protocol’s existing liquidity, it can also be extended to build and integrate new kinds of interoperability protocols.
Low-cost - The NXTP protocol was designed to address the scalability and high fees issues associated with the Ethereum network. Since NXTP does not interact with Ethereum L1 when passing through L2s or sidechains, it solves the problems of high gas fees and slow transaction times.
Given its features, Connext has two types of users:
Cryptocurrency Users - Using its network of liquidity pools on different chains backed by routers, Connext allows users to swap value between these pools. This essentially works like AMM DEXes like Uniswap. For instance, if a user has funds on Arbitrum and wants to use an application on Polygon, they can do so by directly calling the contract on Polygon using funds they have on Arbitrum. This way, users can bypass Arbitrum’s 1-week waiting period and L1 fees. Moreover, Connext enables users to do so without relying on any trust assumptions or third-party validators that control their funds.
Developers - Connext provides a toolkit for cross-chain money legos. Using this toolkit, developers can add widgets to their application, utilizing the Connext infrastructure to enable simple cross-chain swaps. The widgets can simply be dragged and dropped; the integration process can take as little as five minutes. Moreover, developers can also integrate with Connext’s lower-level API to add other features like cross-chain contract calls.
The Connext network uses NXTP for cross-chain transfers. The NXTP protocol is a smart contract that utilizes a lock/unlock mechanism. This contract has three phases.
Here is a visual representation of the transaction life cycle:
Route Auction - In the first phase, the user broadcasts to the network and signals their desired route to execute the transaction. The routers in the network respond to this broadcast with sealed bids that contain time and price range commitments to fulfill the user’s transaction.
Prepare - As the router’s bid is accepted, the auction is completed, and the transaction can be prepared. The user must submit a transaction containing the router’s signed bid to the Transaction Manager contract on the sender-side chain.
Doing so will lock the user’s funds on the sending chain. Once the router detects an event containing the signed bid from the chain, it submits the same transaction to the Transaction Manager on the receiver-side chain, thus locking up the required amount of liquidity.
Here, the required amount is the sending amount minus the auction fee given to the Router as a reward for completing the transaction.
Fulfill - After detecting that the transaction has been prepared on the receiver-side chain, the user must sign a message and send it to a relayer. Typically, the relayer is another Router that earns a fee for this submission. The role of the relayer is to submit the message received from the user to the Transaction Manager, completing the transaction on the receiver-side chain. By doing so, the relayer unlocks the Router’s locked funds and claims them.
Here, a relayer allows users to submit transactions containing arbitrary calldata without worrying about paying gas fees to do so on the receiving chain. After receiving the signed message, the Router submits it and completes the transaction on the sender-side chain, thus unlocking the original amount.
The Connext infrastructure consists of the following pieces:
Contracts - The funds of all network participants are held in contracts. Moreover, contracts are vital in facilitating the lock/unlock mechanism NXTP protocol uses based on the data submitted by users and routers.
Subgraphs - By caching on-chain data and events, subgraphs enable scalable querying or responding.
SDK (Users) - Users on the network are responsible for creating the auctions, listening for events, and creating transactions on the user-side chain.
TxService - Continuously attempts to send transactions to the chain.
Messaging - The messages are responsible for sending data about the preparation, status, and transfer of funds and calldata.
Router - The routers on the network listen for events from the messaging service and subgraph. Based on these messages, they dispatch transactions to the txService.
Here’s a visual representation of Connext’s architecture:
Based on the factors mentioned below, we can evaluate Connext’s architecture and design as follows:
Security - User funds can never be lost or stolen as Connext’s security is equal to the underlying protocol it is bridging. Thus, it reduces the trust assumptions involved.
Speed - Connext can execute transactions at high speeds because it utilizes locally verified systems. For instance, in the data set, we found that out of the 50,732 transactions conducted on Connext using
infrastructure, 91% have taken below 1 hour to be finalized.
Connectivity - Connext has good connectivity because it supports a wide range of destination chains.
Capital Efficiency - Compared to other solutions, Connext is very capital-efficient considering its significant amount of economic throughput.
Statefulness - The trade-off of capital efficiency is statefulness. While Connext can pass around calldata, it is limited in its ability to transfer specific assets and execute cross-chain contract calls.
To validate cross-chain transactions, Connext uses a pool of liquidity networks backed by routers. This offers the following benefits:
Enhanced security - Connext network will not be any less secure than underlying blockchains because it leverages their security.
Funds are never lost - Users’ funds will never be lost since the network uses a lock/unlock mechanism that ensures that routers cannot steal them.
Native assets - The assets provided by the routers are native to the destination chain instead of being derivative assets. As a result, these assets are fungible.
Connext adopts the same core security model as the one used by other locking systems such as Hashed Timelock Contracts (HTLCs). This type of security model offers the following benefits:
Time-bound transactions - Connext's infrastructure guarantees the timely execution of transactions. This ensures that users know the maximum amount of time a transaction has to go through. If a transaction is not completed within this period for any reason - malicious or non-malicious - the transaction is stopped, and the user safely recovers their funds.
Minimizes counterparty risks - Since the settlement of each transaction is assured, the counterparty risks are reduced since the 'what-ifs' of a transaction have been removed. Thus, by creating a time-based escrow, Connext's security model reduces counterparty risks in their contracts.
The Connext system uses routers to provide liquidity and relay calldata between chains to execute swaps. The routers earn a fee for each transaction that they facilitate.
Interacting with Connext Bridge has the following risks:
Loss of funds - User can lose their funds in the Connext system in the following scenarios:
The system is hacked.
The user makes an error.
The corresponding prepare-transaction on the destination chain does not have the same transaction data as the one sent by the user on the original chain.
The chain is attacked, creating the possibility that the routers lose funds
A router goes entirely offline for an extended period of time while a transaction is in progress.
DoS and griefing - If a Router with malicious intent commits to executing a transaction but does not submit a corresponding prepare-transaction on the destination chain, user funds may get locked up for the duration of the expiry.
Censorship risk on routers - Routers can censor users and disable them from transferring their assets using the bridge.
Centralized router network - According to Connext’s technical documents, the Connext team is working closely with a whitelist of routers that only the team can update. This is temporary; the team plans to implement a slashing mechanism in the future. For now, there is a risk of the router network being centralized and thus attempting to grief users if they wish to.
Censorship risk on messaging - In the initial stages, the messaging infrastructure of the network is being hosted by the Connext team. This places significant reliance on the team to maintain high uptime on the infrastructure and thus introduces a risk of censorship by the team.
Technology Risks - While the, it is still susceptible to technological risks, given the nature of the operation.
Given its extensible nature, Connext is very easy to support on any chain. However, the process of integrating with Connext differs based on whether or not the chain is EVM-compatible.
EVM-Compatible - These chains can reach out to the Connext team with their
if they wish to get contracts deployed on their chain.
Non-EVM-Compatible - These chains can build support for Connext by porting the contracts and rewriting them to the network’s txService.
It is important to note that users will only connect to Connext-supported chains that have liquidity provided to them from routers.
According to Connext Documentation, supported chains at the launch of NXTP include the following:
From the chains mentioned above, Li.Finance’s infrastructure supports the following mainnets:
Binance Smart Chain
You can stay updated with Connext and its community through the following: