WalletConnect Now Supports Connext
Channels in every browser window with the ChannelProvider
tl;dr:
WalletConnect now supports Connext on mainnet!
This means a user’s channel can be injected everywhere they go using a new construction called a ChannelProvider. Wallets that use WalletConnect can add support by instantiating a Connext client and mapping to the ChannelProvider. Wallets that use a custom provider can implement the reference code themselves. DApps can now safely leverage channels *extremely* easily.
You can try this out yourself by activating WalletConnext under Settings in the Dai Card. This will open up a QR that can be scanned by any other Card or, eventually, by any wallet that supports Connext v2.0.
A huge complaint with v1 of Connext was that dApps needed to host user keys themselves so that their users could sign channel updates. This also meant users had to go through a secondary onboarding process — first to get Eth or tokens into a wallet and then to get that value into a Connext channel.
To fix this, we built a new way to communicate with channels, the ChannelProvider, as an extension to the existing Web3Provider standard. Using the ChannelProvider with WalletConnect gives dApps and users access to channels in every browser window.
Introducing the ChannelProvider
Review: What is a Web3Provider?
When users use Metamask on desktop today, they have a mnemonic hosted within the extension which is used to create a web3 object. This web3 object is kept isolated on your local machine because it gives unilateral access to a user’s funds.
In order to function, however, dApps need some safe way to connect to the user’s key, in order to request that a user signs transactions (effectively invoices) to make blockchain calls. To do this, Metamask generates a provider to the web3 object’s methods and injects it into the browser window. The provider is consumed by the dapp developer’s code so that, when a user makes a call to the blockchain, that call is handled by the provider which maps to the user’s web3 object hosted remotely in the extension for signing.
Why can’t we build channels this way?
Channels networks heavily rely on signatures to function. When we tried running Connext with an injected Web3Provider back in March, each transfer required the user to sign 3 or more popups (!). Even receiving funds required confirmation from the user.
This is weird because the user isn’t even signing to give permission for an action to be taken on their funds. In this case, they’re signing each step of the protocol execution for our network — something which end users should absolutely not need to be involved in.
Connext clients, as part of how they function, run “trusted” code which makes sure that when a user interacts with a counterparty in their channel, there is no risk to their funds whatsoever. This is a similar, but higher level, relationship to the “trusted” code that runs when a dApp calls signTransaction. In other words: to preserve trust-minimization, a user’s channel client should be run in the wallet (a trusted environment) only.
ChannelProviders
To resolve this, we adopted the standard Ethereum Provider API (EIP 1193) and extended Ethereum’s JSON RPC spec with new methods specifically for channels.
A full specification of the RPC interface is still in the works, but live code with a mapping from method name → channel function (based on the StateChannels framework API) is available here. For example, calling the chan_deposit method name would map to connext.deposit() in our case.
As a wallet, integrating this simple piece of code in addition to a Connext client means that dApps which leverage your product for Ethereum calls can now also have access to channels. For dApps, this means adding support for channels is now a 5 minute task max.
WalletConnect + Connext = WalletConnext ❤
As the pilot usecase for the new channelProvider, we’ve integrated with WalletConnect and integrated it into the v2 Connext Dai Card. This means you can now use your Dai Card either as a burner wallet with your key hosted in the browser OR as a secure instant payment dApp with the key in another Dai Card (or in any other wallet that supports v2 of Connext).
For the first time ever, dApp developers (and end users) have extremely easy access to channels in every browser window.
This opens up entirely new development patterns and use cases such as:
- Using channels for transfers by default with a fallback to onchain if the channel doesn’t exist yet or is too expensive.
- Adding microfees to dApps that are acting as public utilities or to wallets that are supporting Connext. (monetization for wallets/applications!)
- Easily using links to permissionlessly add an incentivization layer to existing content platforms and social networks. Examples: adding Cent-style seeding to Reddit posts, enabling a micropaywall for a premium article on Medium, creating skill cash games in Telegram.
And more that we can’t even think of yet!
Where can I try this?
To play with this yourself, browse to Settings in the Dai Card on your computer. There, you’ll see the Activate WalletConnext option:
Clicking this should refresh your Card and open up a QR code. Open up another Dai Card on your phone and scan the QR code with it (or, eventually, any other mobile wallet that supports v2 of Connext and uses WalletConnect).
How can I integrate this as a developer?
If you’re working on a wallet that uses WalletConnect, you can provide support for channels to dApp developers by instantiating a Connext client and mapping the WalletConnect ChannelProvider package to it as is being done here. It’s really that simple!
If you’re working on a wallet that uses a different provider implementation (e.g. Portis, Torus, etc.), do the above steps, but just implement and inject your own ChannelProvider that uses param objects (instead of arrays) and calls the chan_config RPC method upon instantiation. A reference implementation can be found here.
Lastly, if you’re a dApp developer, building support is even easier! Just either check your context for a ChannelProvider or create one using WalletConnect. Then, instantiate a Connext client by passing in the ChannelProvider and a URL to an Eth node (Infura, Alchemy, local node URI):
As usual, get in touch with us by:
And lastly, please share this with your friends in the ecosystem if you find it interesting. We can’t wait to help enable instant, low cost Ethereum transactions in wallets, browsers, and applications.
Thanks for your support,
Team Connext
