Connext’s Amarok Upgrade is Live

The Next Wave of dApp Development Is Here

After almost a year of R&D, we are incredibly excited to announce that Connext’s Amarok upgrade is publicly live. This means that as of today:

1. The Connext public Bridge UI and Explorer point to the new network.
2. Users can now passively LP into the system in USDC and ETH.
3. Anyone can run a router to become an active LP in the network.
4. Developers can permisssionlessly build any kind of crosschain application on top of the network.

This announcement post will recap why Connext and the Amarok upgrade exist, how the new system works, the trust & security assumptions for users, and how you can get involved.

Let’s dive in! 🤿 🌊

A Fragmented Today

Connext has always had a fairly straightforward mission:

Help bring Ethereum to a billion users.

Our mission comes from a belief that blockchains can become the backbone of a more secure, fair, and transparent internet, unlocking new ways for people to coordinate with each other around the world.

Scaling Ethereum to get to a billion users involves moving users, funds, and data to multiple parallel domains (sidechains, rollups, and other chain-like constructions). This, however, creates a new challenge: a fragmented, multichain user experience.

Take, for example, Aave. When you use Aave today, you experience this fragmentation firsthand:

1. When you supply liquidity, you supply to whatever chain you are connected to instead of whichever chain gives you the best price.
2. When you borrow funds, that position remains on a single chain. Migrating your position to another chain entails a complex process involving repaying your loan, bridging to a new chain, and then recreating your position.

This type of UX is not good enough to get us to a billion users. Users don’t want to handle multichain complexity themselves. Ideally, they don’t even want to know they are using multiple chains, to begin with.

A Cross-Domain Tomorrow

To overcome the UX limitations that exist today, we need to move towards crosschain-native apps (xApps); applications that abstract away the “chain” entirely for users, instead providing a single, seamless experience that spans multiple chains.

A good Web2 analogy for this is Youtube.

Today, when you search for cat videos on Youtube, you don’t need to know anything about Google’s complex distributed database infrastructure. You just interact with the app, which handles this in the background.

Similarly, decentralized applications in the space need to abstract away the complexities of interfacing with multiple chains. In the same way web applications today interact asynchronously with resources all over the internet, dApps must eventually interact asynchronously with users, funds, and data living on multiple chains.

Why aren’t we there yet?

Connext isn’t the only system to enable crosschain messaging and application development (though devs have been building crosschain apps on Connext for a very long time). There are dozens of other bridges that allow for sending funds or passing messages between chains.

Where they fall short are security & trust-minimization. In the past two years, billions of dollars have been lost due to bridge hacks.

Developers are scared, and rightly so. Cross-domain communication is a difficult-to-understand topic with a large amount of misinformation & propaganda spread by bridge projects, and high potential for disaster if done incorrectly.

What can we trust?

So, what infrastructure can we trust? This is the key question we at Connext asked ourselves when building our Amarok upgrade.

What we realized is that there is already an ecosystem of battle-tested bridges out there that secure all user interactions for a given chain: canonical bridges. Examples of these include the Optimism & Arbitrum Rollup Bridges, the Polygon PoS Bridge, and the GnosisChain Arbitrary Messaging Bridge.

These bridges are already the basis for trust for a given chain. In the case of rollups, they are also trust-minimized — and note, we mean this in the strictest possible sense: there is no possible system out there that will provide more secure communication into or out of a rollup than its own native bridge.

In cases where there aren’t canonical bridges, for example, for L1–L1 communication, we also know that zk-SNARK verified light client bridges will eventually provide the best possible security. There are a number of awesome teams working on this, such as Succinct Labs, Overreality, zkIBC, and Wormhole.

Rather than recreate the wheel, we decided to bet on the following ideas:

1. The future will be largely rollup-centric.
2. Mature zk light client implementations will eventually exist as public goods for non-rollups.
3. We can minimize risk for users by plugging into battle-tested canonical bridges to transport and secure messages rather than by building a new system from the ground up.

Modular Interoperability

Connext is the first Modular Execution Bridge, enabling trust-minimized communication between domains (chains & rollups) by optimistically relaying data between domains and falling back to the security of canonical bridges if something goes wrong.

Every crosschain message that passes through Connext goes through Ethereum L1 in a hub-and-spoke pattern.

Messages in Connext are added to a merkle root on every chain, relayed to Ethereum L1, aggregated into a combined merkle root there, and then relayed back to every other chain. This process happens largely offchain by the Connext Sequencer, with data availability of the aggregated root guaranteed on L1 by canonical bridges if something goes wrong.

Those who are paying close attention will realize something interesting:

This model makes Connext an (application-specific) Optimistic Rollup — one specifically designed to synchronize the state of other rollups!

There are a LOT more technical details involved in how Connext works that are outside of the scope of this announcement post. We’ll be publishing a technical deep dive soon that will jump into the specifics of exactly how the system fits together.

Trust Assumptions & Security

One of our core values as a project is radical transparency and integrity. As such, we have a long-standing tradition of outlining the trust & centralization assumptions in our system for every launch blog post.

Core Assumption: Reliance on Underlying Canonical Bridge

Disputes within Connext are adjudicated by the canonical bridge to a given chain. If fraud is observed within the system then the system will fall back to that bridge. For trustless systems, like rollups, this gives the best possible security, as successfully passing fraud through Connext would require a failure of the Connext Watcher system and fraud on the part of the rollup sequencer.

However, for chains where a canonical bridge is not available or trust-minimized, the best that Connext can do is inherit the security properties of the underlying bridge, and resolving potential fraud requires manual action on the part of the Connext protocol admin. The main instance where this is relevant at the moment is BNB chain, where Connext currently utilizes Multichain to transport and verify messages. There are already plans to move to zk light client verification for BNB chain ASAP.

Upgradeability

We have historically avoided upgradability at the protocol layer. However, given the new modular nature of Connext and our focus on delivering the best possible experience for developers, we have chosen to start heading toward DAO-controlled upgradeability at the protocol layer.

At launch, the protocol is controlled by a 3-of-3 multisig to simplify configuration. Within the next two weeks, the plan is to expand this to a 5-of-7 multisig, with ownership fully being transferred to the DAO as soon as the NEXT token is launched. Most admin functionality is subject to a 1-week timelock, with the goal to move everything to a standard timelock pattern by the time the DAO launches.

Limited Watcher Set At Launch

Watchers in Connext are responsible for (1) monitoring messages that are passed optimistically between chains, (2) monitoring the underlying canonical bridges, (3) pausing the system if they detect a problem with either of the above.

At launch, Connext has a whitelist for Watchers and only 1 Watcher run by the core team active and monitoring the network on mainnet. We plan to expand this set within the next two weeks to additionally include three other Watchers run by DeFi Wonderland, P2P, and Bware Labs. Once the NEXT token is live and staking/slashing is introduced to the network, Watching will become permissionless, and Watchers will ship as part of the Connext router stack by default.

Trusted Relayer Fee

When users make transactions in the network, they supply additional gas fees on the origin chain to pay relayers to execute their transactions on the destination. Accounting for this mechanism is secure for the user but fully trusted for Connext itself as Connext Labs fronts fees to the relayer network (Gelato), and is repaid by users.

This is a totally acceptable trust assumption, as only Connext Labs is affected by it. This assumption exists because some chains do not yet implement the BASEFEE Opcode. Once these chains add support for EIP1559, this construction can be made trustless (and we can add support for refunding unused user gas 😄).

Sequencer Censorship/MEV/Downtime Risk

Routing in Connext is fully decentralized — there are already 8 routers live, with an additional 30+ migrating from the legacy network, and hundreds that participated on testnet or signed up for our waitlist last year. Individual user transaction censorship becomes impossible as only a single router needs to be willing to route a tx for it to go through. Note that routing is subject to a whitelist at the moment, but this is only to stop frontrunning by MEV bots in the mempool.

Sequencing, on the other hand, is centralized in Connext at the moment. The Connext Sequencer (run by Connext Labs) has the ability to order/select transactions which could lead to lost router fee revenue if done unfairly. Additionally, downtime of the sequencer could cause a widespread halt of the network.

Both the router whitelist and centralized sequencing can be fixed after NEXT token staking/slashing is implemented within the protocol.

Security Considerations

The protocol has been audited 4 times already, with additional security reviews and formal verification planned for the future. There is also an active Immunefi security bounty.

How Can You Get Involved?

Now that the Amarok upgrade is live, there are several ways you can start interacting with the network:

• Use the Connext Bridge to transfer funds between supported chains.
• Provide liquidity into Connext’s pools.
• Run a router to help operate the network and earn fees.
• Build a xApp on the network.
• Get involved with our kick-ass community.

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 secure bridges and other natively cross-chain applications. To date, over $1.5b in transactions have securely crossed the network.

Website | Build xApps | Twitter | Discord | Crosschain Bridge