🎉Our First Hub is LIVE on mainnet!

And it’s magical to use.

We are proud to announce that Spankchain, the first Connext Hub, is officially LIVE on the Ethereum mainnet. This is BIG NEWS for Ethereum: our Hub is the first non-custodial payment channel hub that is not only deployed on mainnet but is also already being used for real payments on a production platform. More importantly, it’s an early example of how state channels can enable a highly scalable dApp that is still backed by the security of the blockchain.

📖 TL;DR

ETH and ERC20 token transfers using Connext Hubs offer dramatic confirmation time and cost savings over transactions on the blockchain, while preserving the security and decentralization of the underlying blockchain. Right now, a user of a Connext Hub can trustlessly pay any other user of the Hub without needing to pay gas or wait for block confirmation. Yes, you read that correctly.

Spankchain utilizes this technology to enable their content microtipping ecosystem. Compared to traditional Ethereum user experience, using their camsite beta almost feels like magic. You can check it out now at Spank.Live, and also learn more on their announcement post!

Come join our Discord for progress updates (testnet hubs coming soon!).

💁‍ How does a Connext Hub work?

Let’s consider a few parties that want to transact: Alice, Bob, Charlie, and Dany. For Alice and Bob, a state channel works great: they lock their funds into a smart contract and can pay other as frequently as they want without incurring block confirmation times or paying gas.

But isn’t so great for larger ecosystems with many participants. Think of it this way: in a group of n participants that all want to pay each other, the number of channels necessary works out to n(n-1)/2. Among just Alice, Bob, Charlie, and Dany, it’s costly and inefficient to juggle so many channels.

With Connext Hubs, Alice and Bob each open a channel with the Hub rather than with each other.

Wat?

Connext Hubs enable “threads”, a peer-to-peer payments methodology based on Perun’s virtual channel framework. For details, check out Eric Olszewski’s explainer or our own State Channels for Babies e-series.

Once Alice and Bob have opened channels with the Hub, they are able to open a thread amongst themselves by passing a message to the Hub with their initial balances. Then, they can send state updates containing (i) their updated balances and (ii) an incrementing “nonce” back and forth, all for free. Thus, threads allow any two parties that are connected to a Hub to transact with each other without opening a new channel! When the payee receives a balance update in a thread it becomes “double-signed”, meaning that it is now valid and can be used to unlock funds on-chain.

This gives transactions with Connext Hubs a property known as “instant finality”, which is a radical improvement over the 15–30 second block times we all know and hate. Plus, transactions via threads are free!

When Alice and Bob have finished transacting, Alice submits the most recent state update to the Hub. If everything makes sense, the Hub does a bit of math and turns the new balances into two transactions: one from Alice to the Hub and one from the Hub to Bob. Boom, thread closed.

What if Alice tries to submit an old balance update to cheat Bob out of money that she paid him? As soon as Alice submits an update to the Hub and tries to close the channel, a “challenge period” starts and Bob gets the chance to submit a more recent (higher nonce-d) update.

Nice try, Alice!

In dispute cases like that, the underlying smart contracts serve as the ultimate arbiter of whose state update is more recent— the process is entirely trustless.

Quick review: Connext Hubs let Bob, Alice, and anyone else transact off-chain with very low fees and instant finality.

🤔 Why is this useful for Spankchain?

Spankchain’s goal is to become the default payment provider for the entire adult industry. Their current focus is on providing low cost payments for camsites, where traditional payment processors take hefty fees from performers. In these ecosystems, users are typically tipping very tiny amounts ($0.10–$1.00) very frequently to live performers.

As camsites are currently structured, viewers have to give personal credit card information and then trust that the site will accurately reflect their payments 😬. Performers similarly have to trust that camsites will pay them out fairly, and also have to bear the cost of the camsite’s payment processors.

Spankchain circumvents these complexity and trust barriers by building their payments ecosystem on Ethereum. However, cost and transaction latency remained an issue because of the sheer frequency of low value transactions. Using a custodial hub, like Spankchain’s previous implementation, solved these issues but also increased the burden of trust on Spankchain and their customers.

A non-custodial payment channel hub provides the best of both worlds.

Using our Hubs, Spankchain is able to allow users to pay small amounts of money as frequently as they wish, directly to any performer who is in their ecosystem. However, they don’t retain the ability to intercept, censor or otherwise interfere with the payment.

📦 The Challenges of Implementing for Production

It turned out that, while payment/state channel hubs are generally understood in theory, there is still significantly more work to take a state channel implementation to mainnet than most people expect.

UX, in particular, adds a whole new dimension of complexity to building an implementation.

For instance, we found that while payment channel hub theory had suggested that channels and threads should be very similar entities, it actually made much more sense to ensure that they behaved very differently. Threads, we noted, were ephemeral and the real cost of creating a new thread was both users’ availability burden to have to sign the initial opening state. Closing a thread had a similar burden.

It turned out that this burden is actually a pretty big one for payments ecosystems. With Spankchain’s implementation, for example, there would likely be a high frequency of viewers suddenly “becoming unavailable in the channel” because their mom walked into the room. The result would be opened threads which would then have to be forcibly closed on chain if the performer wanted to end their show; this would have severely impacted performer UX.

Nothing to see here

Instead, it made much more sense to make sure that all threads had to act unidirectionally even though the underlying channel contract was bidirectional.

Then, users could “fire and forget” (💦) their payments and performers could countersign to receive them at their leisure. So what if the users need to send payments back and forth in both directions (either because that’s what the ecosystem requires, or for rebalancing channels)? Well, since there’s no gas cost to opening new threads, the same behavior could be emulated with two threads pointing in opposite directions.

We (Connext and Spankchain) found similar quirks and workarounds for other UX problems including allowing viewers to rapidly switch between multiple threads, withdrawing/depositing into open channels without having to end a performer’s show, and allowing users to quickly exit their locked up funds and continue viewing other streams if a performer suddenly went offline during a show.

Spankchain, in particular, has done a wonderful job of hiding this complexity in their wallet and camsite experience:

The complexities of state channels are abstracted away, so you can focus on just the tips

Be sure to check out Spank.Live if you want to do any further (technical) research. 😉

🙀Okay, this is awesome. How can I get one of these bad boys?

Glad you asked! We’ll be releasing testnet hubs to the general public just as soon as we finish deploying them. Come join us in our community chat to keep up with our progress and ask us questions!

You can also drop us a line at support@connext.network.