V2.0 is on testnet!

Mainnet launch date, technical details, and more.

tl;dr: V2.0 is live on testnet! We also give some details on how it works. Reach out to us on Discord if you want to help us test and/or get a head start enabling instant transactions in your dApp, wallet, or infrastructure project!

🚢 Wen mainnet?

Contract audits are in progress and we’re hoping to go live sometime around ETHBerlin (8/23–8/25).

📦 What’s in the box?

We spoke a little about what’s up with v2.0 in a recent update. This post will give some more technical detail on the following:

How the Counterfactual framework works. Some of the prefabricated Counterfactual apps that you can expect to see supported by default in this update. Integrating the Connext client into wallets vs. dApps. How we’ll be sunsetting v1.

Let’s dive in!

🔧 v2.0 is built on the Counterfactual framework

Counterfactual is an approach to channels that maximizes modularity and minimizes onchain footprint. Most contract applications typically hold user balances, store internal app state, and specify logic for how state is changed:

Payment and state channel constructions change this paradigm by moving state storage offchain and mutating it based on the channel’s onchain logic:

This approach is really useful for channels which have one specific function (in the case of our v1 contracts, the function was simply “update balances”). However, adding in more logic for mutating state requires changing the contracts themselves.

Counterfactual takes this a step further, and separates the onchain funding (stored as a per-person multisig), the application state (held by the user offchain), and the application logic (specified in a stateless contract stored in a global registry).

This is a whole new way to think about channels and writing blockchain applications. Users can store their funds in a generic multisig, and then never have to make another onchain transaction until they choose to withdraw funds.

What does this look like in practice?

1. Deposit into multisig [Onchain]

Users deposit the funds they’d like to use in any offchain applications to a generic multisig. Depositing initializes a FreeBalance — the amount of money they have in the channel which can still be allocated to applications.

2. Install App [Offchain]

Users then bind any portion of their respective FreeBalance to an app, which points to an appDefinition — an onchain contract which defines the state of the app and specifies how the balance allocated to the app can be disbursed.

3. Update State [Offchain]

Users can now update their state per the rules laid out in the appDefinition . In the simple transfer case, this would just be an update to the users’ sum transfer amounts. In a more complex case like a game of tic-tac-toe, this would update a board with an ABI encoding like uint8[9] board .

4. Uninstall App [Offchain]

When they’re done making updates, users uninstall the application. Uninstalling turns the application state into into a set of finalized balance, and adds them back into each user’s FreeBalance .

5. Withdrawing from multisig [Onchain]

At any time, users can withdraw all or part of their FreeBalance from the multisig onchain. This is done by submitting the latest FreeBalance state onchain, which contains the signatures needed to unlock the channel multisig.

If you’d like to read more about the Counterfactual framework, head over to their docs!

🧩 How does this fit in with Connext?

Connext extends the core Counterfactual framework over one (and soon many) noncustodial intermediaries. This means that, rather than deploying a new multisig for every counterparty that a user wants to interact with, a user can keep all of their funds in one multisig and interact with anyone.

We also prepackage the following “common” Counterfactual apps which wallets, dApps, and projects can easily access via our API.

Simple transfers

Simple transfers of any asset supported by the hub to a counterparty over Connext. These are ephemeral apps that only last for the duration of the transfer and are uninstalled almost instantly.

“Link” transfers

As in v1, Link transfers let users create referral links which can be redeemed via a QR code or URL. Links are a great way to onboard new users to Connext. Unlike in v1, v2.0 links are also completely noncustodial.

Swaps

Swaps let users instantly swap between two different assets with the hub. In v1, this was used most commonly to instantly swap to Dai from Eth when depositing into the Dai Card. V2.0 replicates the same experience but with any two assets that the hub supports!

Subscriptions (coming soon)

With subscriptions, users can preload an app with funds and have it debited on whatever transfer schedule is mutually agreed upon! This can be very granular (down to a transfer every block) or look more like a traditional monthly subscription.

Event-driven transfers (coming soon)

Transfers that are conditional based on an onchain event or the state of some onchain contract. These can also be used for offchain data streams via protocols like Chainlink or Witnet!

And more!

We’re on the lookout for common applications that we should support natively. If you have a usecase that you think should be implemented by default in Connext, hit us up.

You can also write your own apps. The Connext client exposes low level Counterfactual functions directly!

🎁 Integrating the new Connext client

With this update, we’re making a lot of changes to the Connext client to make it sleeker and more usable.

Instantiating the client now happens differently for wallets vs. dApps. Wallets integrate the client by passing in a function for generating ephemeral keys for installing and updating each app. Similar to how the web3 object works, the core Counterfactual code (and, by extension, Connext) exposes a JSON RPC interface. Wallets then create a provider to that interface which can be safely passed around while the user’s channel code and keys remain safe.

Like with the web3 provider object, dApps can make calls to a user’s channel simply by searching for an injected channelProvider object. With the Metamask extension, for instance, this would look like:

if(window.channels)

const client = new Connext(window.channels)

Doing it this (more familiar) way means that dApps never have to deal with a user’s keys or seed phrase, but will eventually have access to channels wherever they have access to Ethereum itself!

To learn more, check out our v2.0 documentation.

🌅 V1 Sunset

The v2.0 client does not maintain backwards compatibility with the v1 node. After we launch v2.0 to mainnet, we will set a deprecation date for the existing hub and give 30 – 45 days’ notice before shutting it down.

If you are running v1 in any form, please reach out to us in our Discord so that we can support you in your transition: https://discord.gg/yKkzZZm

❓More questions?

We’ll be publishing additional documentation and updates in the lead-up to the release of V2. In the meantime, feel free to contact us with any and all questions using the links below!