Introduction to the Noncustodial Xdomain Transfer Protocol (nxtp)

Nxtp is Connext’s protocol for enabling fully trustless transfers and contract calls between Ethereum-compatible domains (domains = chains & L2s).

Overview of Connext’s interoperability stack

nxtp

Protocol for enabling fully trustless transfers and contract calls between Ethereum-compatible domains

Crosschain Bridges

Generalized crosschain bridges specific to a pair of domains

Connector Protocols

Protocols that are used to connect the entire stack into one seamless system



What is nxtp?

nxtp is used for enabling generalized xchain/xrollup transactions that retain the security properties of the underlying execution environment. As such, it does not rely on external validators but uses the validator set of its execution environment (e.g. Ethereum’s validator set). Nxtp consists of a simple contract which uses locking patterns to prepare and fulfill transactions. Secondly, a network of offchain routers that participate in pricing auctions and are responsible for passing call data between chains. Thirdly, the protocol also consists of a user-side sdk for finding routers and prompting onchain transactions.

Core elements of nxtp

Locking Patterns

For preparing and fulfilling transactions

Offchain Routers

For pricing auctions and passing call data between chains

User-Side Sdk

For finding routers and prompting onchain transactions

Transaction Lifecycle

Transactions that are routed through the nxtp go through a total of three phases:

• Route Auction The process is initiated when a user broadcasts to the Connext network by signaling their desired route. Routers then respond to this broadcast with sealed bids. These bids include the routers’ commitment to fulfill the transaction within a predefined time and price range.
• Preparing Transaction Step one (Route Auction) is completed once a router won the auction. In the next step, the transaction is prepared. To do this, the user submits the transaction to the TransactionManager contract on the sender-side chain which includes the router’s signed bid. As a result of the transaction, the user’s funds are locked up on the sending chain. Once the router detects an event that contains their signed bid, the router submits the same transaction to TransactionManager on the receiver-side chain. At the same time, the router locks up the corresponding amount of liquidity. To incentivize the router to complete the transaction, the amount locked on the receiving chain is sending amount - auction fee
• Fulfilling Transaction The user who initiated the broadcast signs a message upon detecting the TransactionPrepared event on the receiver-side chain. The message is sent to a relayer who earns a fee for submission. The message is then submitted by the relayer (who may be the router) to the TransactionManager. This completes the transaction on the receiver-side chain and the relayer can then claim the funds locked by the router. A relayer is used in order to enable users to submit transactions containing arbitrary call data on the receiving chain and without the need to pay gas. The original amount is unlocked once the router successfully submits the same signed message to complete the transaction on the sender-side.

Transaction Lifecycle Overview