Payments

Connext Network releases Dai Card, a browser-based wallet for low-cost, instant payments

Quick Take

  • Connext, a payment channels infrastructure project, has launched Dai Card on the Ethereum mainnet
  • Dai Card is an in-browser, non-custodial wallet that allows users to make instant, low cost, trust-minimized transactions
  • Arjun Bhuptani, Connext’s founder, sat down with The Block to discuss Connext’s conception, competition, architecture and use cases 

Yesterday, Connext, the payment channels project, launched its Dai Card product on the Ethereum mainnet.

The Dai Card is a non-custodial, browser-based wallet that leverages Connext’s payment channel hub infrastructure. Like Bitcoin’s Lightning Network, Dai Card users can now make instant, low-cost, trust-minimized payments in Dai.  

In the 24 hours since its launch, Dai Card has seen 205 channels opened, 220 payments, and an average payment size of just $0.62. The Dai Card contract shows over $6,900 in collateral.

The following is a conversation between Connext founder, Arjun Bhuptani and The Block’s Matteo Leibowitz, covering topics including Connext’s conception, architecture, competition, and future. The conversation has been edited for clarity and brevity.

Conception

Leibowitz: When did the idea for Connext first materialize?

Bhuptani: We started in April 2017. We were doing something completely different for the first 9 months of operations — something similar to what Ramp Network and Wyre are doing now but more linked with credit cards. We found through our experience working with the card industry that it wasn’t easy to integrate into this industry, and so we decided to roll our own payment network.

Leibowitz: When did you come up with the idea for Dai Card?

Bhuptani: We conceived it for the first time less than five weeks ago. It’s definitely still an MVP.

We’ve mostly been focused on making sure that it’s stable and functional. We’re not a wallet company and we don’t really want to be one: the goal with the card is to have this slick, simple UI that you can use and to inspire people to then integrate the card into their own application. Wallet providers can then optimize the UI and make sure that the users are using them in the best way possible.

Leibowitz: What kind of traction have you seen so far for Dai Card?

Bhuptani: We launched Dai Card to mainnet 5 days ago and just officially announced the launch earlier today. Traction has been going well. We’re taking an iterative approach so that we can handle all the incoming feedback.

We’re hoping to see more sustained usage. We expect to see a bunch of people try it in the first few days and then the goal is to have people use it for day-to-day business payments. We’ve been working closely with Ujo and they’re integrating Dai Card payments. They hope to have that live in the next couple of weeks.

Leibowitz: What’s Connext’s business model? Have you received any funding to date?

Bhuptani: We’re VC backed – we raised a million a while back and have been working on development and research and kept the costs low through this market downturn. We’ll probably raise funds again soon in order to get to the point where we can start growing pretty aggressively.

As far as business model goes, we’re not sure yet. We have a few things in mind that we want to experiment with. It’s sort of a two tier problem because we need to figure out sustainable business models for nodes, and then we also need to figure out sustainable business models for us.

Right now we’re focused on nodes aspect, and once we get that done, we’ll have something that can be used by other people and then we can start focusing on the network side.

There’s definitely a lot there that we can charge for. Like, the experience of running nodes is something where you’re making x amount of money per time, and you could make more money if you optimized how you reallocate collateral or how you deal with gas costs or how you parse state. We could probably offer a very minimal sort of pro thing, where people can pay for analytics, a usable dashboard, and for optimizations that save them 20% of their cost.

Architecture

Leibowitz: Could you walk me through the Connext architecture?

Bhuptani: So, a normal payment channel is a two person, or n person, thing where everybody has to agree on something and that’s when a transaction happens.

So you and I can open a payment channel between each other and the way that we do that is if I’m paying you a bunch of money, I would put some money into this, effectively, multisig wallet, and then just send you signed settlement instructions. And because the signed settlement instructions can be redeemed at any time, that’s effectively the same as sending you a payment.

The next step of singular payment channels is something called multi hop, which allows you to hop transactions between channels.

So, if I have a channel to you and you have a channel to Hunter, I can pay Hunter through you by paying you money and then you pay Hunter money.

The trick lies in making sure that you’re not able to intercept the payment or cheat there. Obviously, the really great thing about all of this is that, even if you do intercept the payment, the financial risk is that I lose that specific payment, but my funds overall are still secure. Those are always noncustodial. So, if I’ve sent $1 through you to Hunter, at most you could steal $1 and the other $10 in my account is always mine.

Leibowitz: Who pays for gas when depositing into and withdrawing from Dai Card?

It’s similar to meta-transactions. Users pay gas for deposits and the Hub pays gas for withdrawals. What we can do is have a micro-transaction happen in channel to redeem the cost of that withdrawal right before the withdrawal, so that the user can essentially pay for gas costs in Dai. We plan on adding charges in the next few weeks to mitigate those costs.

Leibowitz: So at what point are channels collateralized?

Bhuptani: When you receive a transaction or when you open a ‘link’, a redeemable payment, or when you deposit.

Leibowitz: How profitable, and easy, is it to run a hub node?

Bhuptani: A hub is a singular note system where everybody opens a channel to the same node and then can transact to anybody else who was connected to that node. It’s centralized in the same way that 0x relayers are centralized. There’s on-chain contracts and all of your funds are stored in a non custodial way and final settlement happens on-chain, but there is an off-chain relay, and that off-chain relay is the hub.

We want to make sure that the experience of running a node in the system is good and that you can run a node profitably and that there is a viable business model.

The cost of running a hub scales with the volume of payments and the ratio of recipients of payments. So, if it’s a unidirectional system where there’s a very defined set of payers and a very defined set of receivers, then the cost is lower because the amount of collateral you need is lower. And then, if it’s like the Dai Card and anyone can pay anyone, the collateral cost is higher.

Just like Lightning, nodes can charge fees and the hardware requirements are fairly lightweight. Right now we’re running our hub on a very small Amazon Web Services microserver. The main requirements are the fact that right now, for the sake of simplicity, all of the transactions happen over https. So you’re having to deal with all of this server infrastructure that you wouldn’t really need to deal with otherwise if you’re using something that was peer to peer.

The goal is to move to peer to peer soon. That way we reduce our own costs of bandwidth. My eventual goal is that the difficulty of running a node is very, very low and you can run one on your own computer, and without really having any sort of computational issues at all. Then, and this is a known criticism of payment channel like Lightning, the main requirement becomes access to collateral.

Leibowitz: So by directing payments through a hub, there are still some trust assumptions at play?

Bhuptani: The hub does have the ability to censor a transaction. So if we wake up tomorrow and a regulator has shut us down, payments will stop happening. Of course, you’d still be able to remove your money from the system. And the ease of setting up a hub is low enough that anybody else could go and set that one up as well. It’s not really that bad of a situation, but for now, it is a “centralized system”. The goal is to move away from that as soon as possible.

Leibowitz: Moving away would be encouraging more people to set up hubs?

Bhuptani: There’s three factors at play.

The first is that there’s several quality of life improvements that we want to make associated with things like collateralization and the ability to dispute more than one payment at once, so that users don’t have to spend significant time dealing with those issues at scale.

Second, there’s some minor changes that need to be made off-chain, and then only one minor change that needs to be made on-chain in order to activate the ability to hop multiple jumps before a transaction is completed.

The last thing that we want to do — and this is more of an equitable usage thing — we want to make it much easier to run a hub.

So, as soon as we do those three things, we would then go in the same direction as Raiden and Lightning and try to build a multi-hub network.

Leibowitz: What does the dispute process look like for a user?

For now we haven’t really shown the dispute process because we’re still trying to find a good way to show dispute user experience.

We have a bunch of codes sitting in a pull request right now that will have clients automatically respond to disputes that are initiated by a hub.

Hubs are also set up to do that where if a user initiates a dispute the hub will respond to it and submit their latest state, wait x amount of time and then resolve the dispute. So, it’s more just a matter of figuring out how best to automate it right now.

The one big issue that we see right now, which we plan on fixing within the next two to three weeks, is being able to dispute.

So anyone can dispute at any time as long as their funds are in the channel and as long as they have access to the state. Access to the state is actually the hard assumption that we’re making here, because right now you’re retrieving your state from the hub. That’s not a long-term solution at all and we don’t intend it to be, it was just something that we did to make it easier to have it work.

The easy way that we plan to solve this within the next two to three weeks is just push that state to IPFS. And so, worst comes to worst, you can go to an IPFS address that’s linked to your account address and retrieve your latest state, and then use that latest state to manually dispute.

Manually disputing is a pain in the user experience, but it’s an open system so either we will build a dispute tool or someone will build a dispute tool very quickly. A dispute tool would just be something where you plug in your state and you plug in your account address and then you just send that to the contract and it does everything for you.

Leibowitz: Can you explain why payments are currently capped at $10? Is that just because of collateral deficiencies in the hub?

Bhuptani: There’s actually two limits.

One is channel maximums, so channels themselves or are capped at $30.

This is similar to Lightning, where we want to slowly increase the capacity as time goes on. We want to get a better handle of how collateralization works and make sure that there’s distributed usage and not one person putting in 10 ETH, and then all of our collateral goes over there, which has already sort of happened on Rinkeby.

The $10 payment maximum is actually only for link payments. So, in the normal send transaction, you can send $30 if you want to, although you’ll probably have to wait for collateralization to happen.

Link payments on the other hand can only do up to $10. The reason is that if you do a link payment, it’s checking up to $10 when you collateralize. That’s something that’s hard coded into how the client works. We built link payments six days ago and we didn’t want to have to go and change that in the client, add more complexity and risk more bugs this close to putting it out.

Leibowitz: What’s the difference between link payments and channel payments?

Bhuptani: A normal send payment is a payment where both parties are online. It’s a synchronous payment.

So, the simplest way to send a payment is if I’m standing in front of you and scanning your QR code. But you need the other party to have a Dai Card, and you need their address, and sometimes that might not happen.

So a link payment is a redeemable payment where the user generates a payment object in the card itself, which has a secret attached to it. The secret is then sent to the hub. This is actually a trusted mechanism for now, but making this trust minimized just means adding the ability to dispute this specific type of transaction or resolve the specific type of transaction in the contract. That’s something that we plan to do within the next four to six weeks.

The secret gets stored by the hub and then anybody who produces that secret can then claim that payment. So link payments are basically like a referral link where I can send you a link to Dai Card with the secret in it. And even if you don’t have a Dai Card yourself what will happen is you’ll click the link, it’ll open up the Dai Card, and then it will redeem that payment for you.

Privacy

Leibowitz: What kind of privacy guarantees does Connext offer? I presume that hub operators have some kind of insight into transaction flow?

Bhuptani: The hub is sort of in its own isolated dockerized environment, so you have to really dig into it, but yes, right now we do have access to the transactions in the database and I’m not really sure if there’s a way around that. As an individual node, you will know about the transactions that pertain to you, which makes sense as it would be weird for you to send money to me and me not know how much you send to me.

People outside the node wouldn’t have insight into transaction history, and that’s definitely the type of privacy that we’re concerned about: we want to make sure that nodes aren’t broadcasting their transaction information.

The last sort of piece of privacy is the on-chain transactions part. We’re still trying to figure out the best way to do that. It might be possible to have that happen with zero knowledge proofs, but we’d only consider it if it wasn’t going to be a hindrance to user experience.

Leibowitz: Would it be possible for Dai Card to support something like ZKDai?

Bhuptani: That was something that we talked to Aztec about. I think it’s possible but, again, this is one of those things where it might also mean that getting into and out of the system takes a long period of time and that it costs a lot more money to deposit and withdraw. This is one of those situations where I think we would end up having to leave it up to the users to see if they even cared about that extent of privacy enough to be willing to pay that additional cost.

Layer 1

Leibowitz: How compatible is Connext with alternative smart contract platforms?

If it’s EVM compatible, super easy. All we need is an RPC provider and there might be a couple of dependencies that we have that are ETH specific for things like signing. It’s issues with our dependencies and it’s not issues with the core code.

Right now, we’re focusing on the Ethereum ecosystem. I think porting over would be the next step after making multi hop possible. Once multi hub exists, then doing these kind of cross chain payments or being able to facilitate the Dai Card existing on multiple different chains becomes valuable.

Leibowitz: How much transaction volume do you think you Dai Card can handle before Layer 1 throughput limitations become problematic?

Bhuptani: The only instances where layer one transactions occur are when users are depositing more funds, users are withdrawing their funds, or when the hub is recollateralizing a channel.

We have the ability to tweak recollateralization, so that, ideally, it recollateralizes in a way where it takes into account your payment behavioral patterns. That way, it knows whether you are a merchant that is receiving $100 a payment of day or a user that’s receiving $1 a day.

So there are all sort of the knobs that we’re having to tune here. Let’s compare by analogy. Lightning works right now, although obviously it has certain problems. People are still using it and it’s still being stress tested in different ways. And, that’s happening on a chain that is extremely congested, where block times are extremely high and the cost is absurd.

My expectation is that we should at least be able to handle enough throughput for a large scale application before we run into base Ethereum issues.

The main UX constraint is that the cost of depositing needs to be low enough that it even makes sense to use the channel. Right now our gas efficiency is very low — we haven’t gas optimized the contract yet but we’re hoping to do that for the next iteration. Because gas efficiency is low, leading up to Constantinople, it was costing a few dollars to deposit into the channel and that was definitely noticeably painful.

The more pressing issue is how much collateral we can actually put in the hub. This is the reason why we want it decentralized as quickly as possible. If we get 1 million people using our hub, and each user is depositing up to the channel maximum of $30, that’s at least $30,000,000 worth of collateral that we have to have in the hub, which is pretty extensive.

I don’t think we can have it work like Uniswap — we can’t just have external liquidity providers provide that collateral because of the trust assumptions at play. We’re still trying to figure that out.

Leibowitz: What do you think the implications for the layer 1 fee market are if mass transaction volume moves to layer 2?

Bhuptani: I think this is one of those “is it better to own a very large percentage of a small pie or a small percentage of a big pie?” situations. We’re growing the pie right now by opening up the ability for more people to come and start using Ethereum without breaking it. The last time they tried to do that it broke and slowed down and became unusable.

Theoretically, if we do our job correctly, this should bring a lot more people into the industry. There might be a couple more user experience things that needs to be fixed but as far as I can tell this is probably one of the last big infrastructure things that’s remained — scalability — before we can have actually usable applications at scale. I don’t think it’ll make a difference with respect to layer one security.

Competition

Leibowitz: What are some of the strengths and weaknesses of alternative State Channel and payment channel implementations?  

Bhuptani: Overall, as a class, channels are sort of becoming under appreciated now. I think it’s good that people are curtailing expectations, but I think what’s happening is channels are now in that trough of disillusionment where people are really overly critical of them without really watching to see how they play out. That’s probably a good thing, because it means that it’ll sort of taper off and people will have a realistic expectation of what they can do soon.

Lightning, despite what everybody says, is an extremely promising project for the fact that it’s a v1 project. What it’s doing is astounding.

Lightning does have problems and I think a lot of those problems are things that they can solve, like routing, collateralization, atomic multi path payments – all those things are being actively researched.

Lightning has one big limitation, which is that the Bitcoin blockchain itself is slow and expensive and that Bitcoin itself is also volatile, and I don’t think that those are things that they’d be able to solve. In that regard, it’s good that we’re on Ethereum and focusing on Dai right now.

Counterfactual is probably the project that’s the most similar to us. We’re both open source projects with no token. We’ve talked a lot about collaborating and our protocols are extremely similar. The way they have architected is a little bit more focused on the ability to install arbitrary applications and the way that we are architected is more focused on making the process of sending messages back and forth as simple as possible and as quick as possible. That’s the only real difference. I would to say that it’s decently likely that we’ll just interoperate relatively soon.

Celer is also similar in that it’s a State Channel network, but they have their own sort of ecosystem behind the network that they’re building associated with their token. I think the work that Celer is doing on the State Channel stuff is really important and useful but the ecosystem that they’re building is jumping the gun because those are issues that we should hack to solve until we get to the point where they are real problems and we understand them better. The way that we’re doing that now is just pushing state to IPFS. It doesn’t scale, but that’s fine — we’ll get to that hurdle when we reach it.

Perun is also very similar to Connext. We use a similar kind of construction for virtual channels — that’s actually what we were inspired by. The big difference is that Perun has a lot of really weird constraints around how they make payments. Payments exist for a certain time period and you have to define all of those things up front, which seems very inflexible for real world use cases.

Raiden is most similar to Lightning. The big differences between us and Raiden are that we don’t have a token and we don’t use hash locks. Instead, like Counterfactual, we use a dispute based mechanism where we assume that the payment will not be interrupted.

If the payment is interrupted, then a person can dispute that payment on chain. What Raiden does is they use hash lock system like Lightning where you have to send the secret around and then the secret is used to unlock the payment and then you need the secret in order to even redeem the payment on chain later. It’s kind of bad because if you lose the secret you could lose your money.

I think Interledger Protocol is really cool. I want to be a lot more like them in some senses. I think one of the really fascinating things about payment channel networks is that they’re a different thing entirely. Side chains and plasma are fundamentally public blockchains — payment channel networks or something completely different. We could have built payment channel networks long before blockchains existed. Interledger is the realization that if you can build this homogeneous network on top of any core architecture, whether that’s a blockchain, multiple different blockchains, sidechains, shards, Plasma chains, or even banks. And, I think Interledger is attempting to do that.

Leibowitz: What does the emergence of Dai Card mean for the xDai Burner Wallet?

Bhuptani: I think there’s definitely advantages to side chains. Channels are good for horizontal infrastructure that is meant to be used by every single person on the planet.

Plasma and side chains are a lot better for an application specific use case. Think of the Visa network versus Uber. Uber does a lot of payments internally, and having those happen on a plasma chain would be really cool. Then having users be able to cash out those payments through channels that exist on that plasma chain and then send those payments to other places would be ideal.

At scale Plasma and side chains also run into the same scalability problems that exist on Ethereum right now, so it’s just sort of kicking the can down the road.

Use cases

Leibowitz: What are some use cases that your most excited about?

Bhuptani: I think things that involve energy are really cool because you can create micro-markets on energy everywhere, which incentivizes people to be more efficient.

It’s probably too high friction for people themselves to participate in these micro markets, but you can always write bots to do that, essentially mining energy efficiency by just having a arbitrage bots that buy electricity low prices and sell it at high prices. This hasn’t really been possible up till now because of how electricity providers work, but will hopefully become possible with things like Grid+.

I think there’s a lot of use cases in association with decentralized infrastructure payments. Payments for small amounts of storage, small amounts of computation, payments for remote node hosting. Storj, Sia, things like that.  

Content is a big one. Our partnership with Ujo is super exciting because that’s the sort of thing that we really had an interest in exploring. I know that micropayments for video games are also super broken right now.

The eventual goal is to start targeting more traditional payments like retail. That will probably be the last one that will be disrupted because Visa is very entrenched there, but hopefully at some point that’s the one that we can tackle.

Ultimately this is the sort of thing where when you have a new market, it’s the users that fundamentally decide what is important and not you.

Leibowitz: Is the plan just to support Dai or will you open Dai Card up to any token? Does that have implications as far as refunding hubs for exit gas costs?

It becomes a lot more complex for us to collateralize depending on what we allow. Right now, we don’t even allow payments in ETH, because if we did, we’d have to collateralize in both ETH and Dai. Instead, we have ETH be the native currency, the bridge currency, and then Dai as the currency that you’re using in the actual system.

I think the better solution long-term is to allow users to swap assets between hubs. So, if I’m running a hub that is centered around Dai and ETH, and you’re running a hub that’s centered around Golem, my users could pay your service providers in a way where they’re paying in Dai but the service provider receives GNT. That could happen if the Dai Card user signs the exchange rate into their transaction.