Announcing the Amarok Network Upgrade

Bringing Connext to the Next Level

For the past few months, we’ve been quietly collecting data on the key problems that users, developers, and routers face while interacting with Connext and researching their solutions.

Today, we’re excited to unveil our plans for Connext’s first network upgrade.

The upgrade, which we’re calling Amarok, involves extensive changes to our core protocol to massively improve the experience of being a user of the network.

Amarok is coming soon.

Why “Amarok”? We’ve chosen to name our network upgrades alphabetically after mythological creatures. Amarok is a giant wolf from Inuit mythology. 🐺

Motivation

The impetus for this upgrade is to solve the following key problems that currently exist for the different types of stakeholders in the network.

Problems for End Users

1. Gas Costs: The current flow relies on a two-phase prepare/fulfill process to complete transactions across chains, which cannot be easily batched.
2. Signing to Claim: Completing transactions requires users to sign a message to claim funds. This is what keeps Connext trust-minimized, but is a pain because it requires users to stay online until they sign.
3. Fund Lockup Risk: User transactions have a 1:1 relationship with a router. If that router goes offline or loses its connection to the chain mid-flow, the user’s funds can be stuck until the transaction expires (72 hours).
4. Speed: Because users are bound to a given router for their transaction, any delays that that specific router experiences are passed down to the user.
5. Liquidity Fragmentation: Liquidity provided by routers is path-dependent meaning that it is available between a given pair of chains. As the number of chains grows, it becomes harder for users to make large transactions.

Problems for Developers

1. Offchain Auction Dependencies: Most integrations in the space are contracts-only, but Connext currently requires running a client-side sdk to find a router for a given transaction.
2. Signing to Claim: The need to claim requires devs to track in-progress transactions and prompt users to sign at the right time. This adds a lot of overhead and complexity compared to a simple onchain transaction.
3. No Generalized Messaging: Connext already supports calling contracts across chains, but this can only be done safely in some cases. Requiring devs to learn when they can and can’t use this feature is a big hurdle.

Problems for Routers

1. Rebalancing: Routers send funds on the destination chain and receive funds on the origin. This means their liquidity moves around between chains/rollups and can get stuck, lowering capital efficiency.
2. Unclear ROI: Router ROI is notoriously difficult to track accurately because the two-phase flow means that the data needed to track returns is fragmented across chains.
3. Strict Liveness: As mentioned above, if routers become unavailable during a transaction, user funds can be locked for up to 72 hours. This strict liveness requirement increases the difficulty of being a router.
4. Gas Griefing: Transactions can be cancelled collaboratively by users or routers. However, when this happens, there’s no clear mechanism to reimburse the upfront cost of gas.

How were you originally expecting to solve these problems?

Our earlier thinking around this was that we could fix them with a combination of:

• Incentives — for example, using vAMM pricing to incentivize rebalancing and slashing to enforce liveness.
• Wallet integrations — by moving the Connext SDK code into wallets, we could abstract away the “sign-to-claim” flow from devs and users.

Our focus has been on ensuring that transactions are as trust-minimized as possible and the above hurdles were tradeoffs we were making to attain that security. Fortunately, over the last few months we’ve researched a much better architecture that obviates the above problems without introducing trust.

Welcome to Amarok

Modular Interoperability

The breakthrough in our thinking comes from our close partnership with Nomad. Nomad is an optimistic bridge that gives us fully expressive, trust-minimized communication on any chain, but with the tradeoff of 30 minutes of latency.

We realized that, similar to blockchains themselves, there is no monolithic architecture that gives us all of the desireable properties that we need out of bridges, but we can get close to the ideal outcome by modularizing the protocol stack.

The modular interoperability stack

A New Flow

The new flow heavily utilizes Nomad (and eventually other localized messaging layers!) for its security model. Rather than requiring signatures, the approach simply allows any router to front capital and execute calls for a user’s transaction, and claim against funds going through Nomad.

Because no router is explicitly specified upfront, a risk exists that routers can race each other in the mempool to complete a given transaction. This is a suboptimal outcome as losing this race still costs gas for routers. To fix this, we introduce a Sequencer (similar in concept to a rollup sequencer) that is responsible for collecting bids (attempted transactions) from routers and publishing them to chain in batches.

Note that the sequencer role in Connext does not affect the core security of the system or its funds in any way . It is instead simply a mechanism designed to fairly distribute fee revenue/work among routers, which can be done trustlessly if there is (a) data availability of all router bids for a given user transaction, and (b) a deterministic process for selecting the winning bid. We are currently researching approaches to this, including potentially having the sequencer post data to its own rollup OR having routers and the sequencer achieve Tendermint consensus.

Learn more about the new flow in our seminal Github discussions post!

Changes for Stakeholders

The Amarok upgrade enables a much better flow and featureset that solves the stakeholder problems we laid out earlier:

• Fire-and-Forget Flow: Instead of the two-phase flow with signatures, all transactions now happen in a single transaction on the sending chain, simplifying both UX and devX. We also no longer need cancellations, eliminating gas griefing costs for routers.
• 1-of-N-Routing: Any router(s) can complete a user’s transaction, removing the possibility of user fund lockups and significantly reducing the liveness requirements for routers. This also entirely removes the need for any offchain auction code for developers.
• Simpler Liquidity: Routers receive liquidity on the destination chain of a transaction, exactly where they provide it. Liquidity is also no longer path-dependent. This eliminates rebalancing headaches & fragmentation, massively improving capital efficiency and availability.
• Cheaper & Faster Transactions: The new flow cuts down the number of onchain calls from 4 →2, making transactions not only much cheaper but also faster.
• Arbitrary Message Passing: Perhaps the most exciting improvement due to Amarok is the ability for developers to now build fully expressive crosschain dapps. This unlocks powerful features like JS-style asynchronous development, including support for callbacks in Solidity. 🤯More on this soon!

What’s Next?

Timeline

We now have a fully functional private testnet running the Amarok upgrade. We are working with key community members, existing routers, and some high profile pilot partners to flesh out and test the network.

Over the coming weeks we plan to release:

• A breakdown of the integration flow, failure modes, and trust assumptions of Connext after the upgrade.
• A fully functional public testnet that anyone can build on.
• Guides on how to run a router and participate in the testnet.
• Solidity tooling/libraries for xchain callbacks.
• A repository of example crosschain dapps (xapps).

Audits for the upgrade are scheduled for May, with the goal of a live mainnet upgrade in June.

Build with Connext

Until now, our focus as a team has been on decentralizing our network and automating the process of operating a router. With the Amarok upgrade, we will open the gates for builders to come create an entirely new world of xapps.

What can you build? Here are some early usecases we’ve discussed with our pilot partners:

• Connecting DEX liquidity across chains in a single seamless tx.
• Crosschain vault zaps and vault strategy management.
• Critical protocol operations such as replicating/syncing global constants (e.g. PCV) across chains.
• Bringing UniV3 TWAPs to every chain without introducing oracles.
• Chain-agnostic veToken governance.
• Metaverse-to-metaverse interoperability.

Have an idea for a cool xapp? Reach out to us on discord or apply for our grants program!

About Connext

Connext is a network for fast, trustless communication between chains and rollups. It is the only interoperability system of its type that does this cheaply and quickly without introducing any new trust assumptions. Connext is aimed at developers who are looking to build bridges and other natively cross-chain applications. To date, over $1.3b in transactions have crossed the network.

Website | Documentation | Twitter | Discord | Github | Blog