Connext: Interoperability protocol between EVM-compatible blockchains
In this report, we will cover the following:
· Connext: An overview
· Project development
· How it works
· Technique architecture
· Token & tokenomics
· Risks and countermeasures
· Supported chains
· Team & community
1. Connext: An overview
Launched in January 2021, Connext is an interoperability protocol that enables fast, non-custodial cross-chain transmission and contract invocation between EVM-compatible blockchains. It enables users to transfer funds 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. xPollinate is an application of NXTP, Connext’s general cross-chain swap protocol.
As of March 10, 2022, Connext has registered an available liquidity of $44,124,434 and a total trading volume of $773,318,479 through 648,334 transactions.
2. Project development
On September 28, 2021, NXTP was officially launched on the mainnet to support Arbitrum, Polygon, xDAI, BSC, and Fantom.
On October 7, 2021, Connext started to support Avalanche.
On November 10, 2021, Connext released the Ecosystem Grants Program.
On November 17, 2021, Connext integrated Moonriver into its L2 interoperability protocol.
On November 19, 2021, Connext integrated Optimistic Ethereum into its L2 interoperability protocol.
On January 10, 2022, Fuse integrated Connext.
On January 12, 2022, Connext started to support and was launched on Moonbeam.
On January 13, 2022, Connext entered into a partnership with Nomad.
On January 14, 2022, Connext integrated Swing.
On February 8, 2022, Connext brought its interoperability protocol to zkSync.
3. How it works- Connext cross chain solution
Connext builds liquidity pools on supported chains and uses state channels to achieve atomic swaps.
Connext deployed NXTP to achieve internal verification of cross-chain information. The roles of Router and Relayer will be involved in the cross-chain process. The user’s transfer request is broadcast to the network. Each router bids and then the transaction is transferred across chains. Relayer is responsible for the internal validation of cross-chain information and the user will be able to get the cross-chain assets after the confirmation of Router and Relayer .
4. Technique architecture
a. Key technology
This iteration of the Connext network uses NXTP, a lightweight protocol for general-purpose cross-chain transfers.
The Connext network uses NXTP for cross-chain transfer. NXTP is made up of a simple contract that uses a locking pattern to prepare and fulfill transactions, a network of offchain routers that participate in pricing auctions and pass calldata between chains, and a user-side sdk that finds routes and prompts onchain transactions.
Transactions go through three phases:
· Route Auction: User broadcasts to our network signaling their desired route. Routers respond with sealed bids containing commitments to fulfilling the transaction within a certain time and price range.
· Prepare: Once the auction is completed, the transaction can be prepared. The user submits a transaction to Transaction Manager contract on sender-side chain containing router’s signed bid. This transaction locks up the users funds on the sending chain. Upon detecting an event containing their signed bid from the chain, router submits the same transaction to Transaction Manager on the receiver-side chain, and locks up a corresponding amount of liquidity. The amount locked on the receiving chain is sending amount — auction fee so the router is incentivized to complete the transaction.
· Fulfill: Upon detecting the Transaction Prepared event on the receiver-side chain, the user signs a message and sends it to a relayer, who will earn a fee for submission. The relayer (which may be the router) then submits the message to the Transaction Manager to complete their transaction on receiver-side chain and claim the funds locked by the router. A relayer is used here to allow users to submit transactions with arbitrary calldata on the receiving chain without needing gas to do so. The router then submits the same signed message and completes transaction on sender-side, unlocking the original amount.
If a transaction is not fulfilled within a fixed timeout, it reverts and can be reclaimed by the party that called prepare on each chain (initiator). Additionally, transactions can be canceled unilaterally by the person owed funds on that chain (router for sending chain, user for receiving chain) prior to expiry.
b. Technical Architecture
Contracts — hold funds for all network participants, and lock/unlock based on data submitted by users and routers.
Subgraph — enables scalable querying/responding by caching on-chain data and events.
SDK (User) — creates auctions, listens for events and creates transactions on the user side.
TxService — resiliently attempts to send transactions to chain.
Messaging — prepares, sends, and listens for message data over nats.
Router — listens for events from messaging service and subgraph, and then dispatches transactions to txService.
5. Token & tokenomics
No tokens yet.
6. Risks and countermeasures
No risk events have taken place so far.
Connext Bridge has the following risks:
Risk of losing funds: when the system code is hacked, when the user makes mistakes, when the chain is attacked, leading to loss of funds on the router, and when the user does not correctly verify whether the correct amount of funds/transaction data is prepared on the receiving chain (Note: Connext SDK will automatically handle this problem for the users and developers.)
DoS and griefing: If a router with malicious intent promises to execute a transaction but does not submit a corresponding ready transaction on the destination chain, user funds may be locked upon expiration. In the future, Connext plans to explicitly punish such malicious behavior from routers through slashing.
Centralized router network (risk of centralization): According to Connext’s technical document, the Connext team is working closely with a whitelist of routers that only the team can update. This is a temporary solution recommended by Connext’s security auditors. The team plans to implement a reduction mechanism in the future.
Risk of censorship for messaging: In the early days, the network’s messaging infrastructure is hosted by the Connext team and relies heavily on the team to maintain a high uptime. This may lead to a risk of censorship. The Connext team is working to eliminate this risk in the coming months.
Technical risk: Although the Connext infrastructure has been audited, it remains vulnerable to technology risks due to the nature of its operations.
Connext audit reports:
https://drive.google.com/file/d/1l42vxzHwLXrKU10v3FutG2DWthU43vB8/view
7. Supported chains
Ethereum, BSC, Avalanche, Fantom, Polygon, Arbitrum, Moonbeam, Moonriver, Optimism, Fuse, and Gnosis Chain.
8. Team & community
a. Project team
Connext has a strong core team with years of experience working in the crypto ecosystem, especially Ethereum. The team, led by Connext’s co-founders Arjun Bhuptani, Rahul Sethuram and Layne Haber, was one of the first to do L2 researches. As such, the current iteration of Connext is the result of years of valuable experience developing scalable and interoperable solutions. Their goal has always been to improve the user experience of Ethereum and the wider Web3 ecosystem. The team believes that a decentralized network will transform finance and give value back to users.
b. Community
