Introducing the Dai Card

Transact Instantly, Cheaply, and Securely in Dai

TL;DR

The Dai Card is now on mainnet! You can deposit up to $30 in Eth or Dai and send funds instantly and securely.

Today, we’re launching the Dai Card on the Ethereum mainnet! 🚢

The Dai Card is a simple, non-custodial, browser-based UI that sits on top of an Indra payment channel hub hosted by Connext. The Dai Card lets you make instant, trust-minimized, off-chain payments in Dai to anyone else who is connected to our hub.

Goals

We created the Dai Card for a few reasons:

To solve the difficulty of doing fast, cheap, stable payments today, in the simplest way possible without making too many trust concessions. By abstracting away the complexity of hosting your own payment channel hub, we’ve made integrating scalable Dai payments simple even for non-crypto companies. To quickly collect user data on running a payment channel hub. Hubs require complicated operational logic to balance the cost of keeping lots of value locked up in channels versus the cost of doing lots of onchain transactions. The fastest way to figure out how to minimize those costs was to incur them ourselves; instead of experimenting with theories, we just built it! To show the community what is possible with channels. Although payment channels have fallen out of the limelight in Ethereum lately, they are still the most well understood, trust-minimized, and stunningly effective scalability solution that exists today. We hope that community members who use the Card will be inspired to create their own projects using payment channels and hubs. To take the first mainnet step towards building a fully decentralized, stable payment network. By hosting this hub, we incentivize ourselves to distribute our costs and risk ASAP. We also make sure that the backbone of our network is in Dai — which we believe is the best base currency for what we hope becomes the underlying payment infrastructure of the internet.

Using the Card

You can load up your Card by sending ETH (or Dai) directly to the Card’s address. Deposited ETH will automatically be swapped into Dai in your channel. For now, we enforce a deposit maximum of $30. Any deposits above that amount will be refunded to the sending address(!).

Sending payments can be done in one of two ways. If the recipient has a Dai Card already and you know their address, you can send a payment directly to them using Send . Note that, if this the first payment they are receiving, the payment could take some extra time to complete while their channel is initialized.

Your friends don’t have Cards yet? Send them a Link instead. Links create an unspent payment object which can be redeemed by anyone that has a corresponding secret. If the recipient doesn’t have a Dai Card yet, one will be automatically set up for them.

Cashing out when you’re done is also very simple. Plug in any address and cash out directly in ETH.

How It Works

The Card uses our payment channel hub to transact value off-chain through https requests without sacrificing trust-minimization. A payment channel hub is a service provider that automatically opens channels with users and routes payments between them. You can think of a hub as a single Lightning Network node that everyone is connected to (for now).

Like the Burner Wallet and SpankCard, the Dai Card hosts an Ethereum wallet in your browser’s local storage. That address is both the signing key and the channel ID of your channel with the hub. When you send funds (under the channel maximum) to the address, it automatically calls the ChannelManager contract’s UserAuthorizedUpdate function to deposit funds into your channel.

From there, the majority of your interactions are instant. Rather than sending funds onchain, you send the hub a signed state update. If the hub has enough of its own balance in the recipient’s channel to complete the payment (i.e., the channel is “collateralized”), then a corresponding signed state update is generated in the recipient’s channel. The above process can be done in a way where, if the latter part of the transaction does not occur, the hub cannot receive value from the former part of the payment either.

Sending around only signed updates works because, at any time, users can submit their latest update onchain and withdraw funds. This is a completely noncustodial process — unlike plasma and sidechain implementations, your funds can always be withdrawn from the system, even if the hub gets censored or shut down completely.

For more information, check out the full contract/protocol specification.

Trust Assumptions

While the underlying protocol is completely noncustodial, there are trust assumptions to the Dai Card implementation which we want to make explicit. We plan to address these assumptions over the next few months.

Hub can intercept payments

For now, the payments themselves are trusted. In other words, a hub can steal your payment value while the transaction is in-flight. You would usually notice if this happened and leave the system with the rest of your funds, so the risk is limited to your payment itself.

The code for fully noncustodial payments is already in our codebase and is functional. We have left it deactivated for now to reduce complexity while we work on improving logic for channel collateralization. We plan on reactivating it within the next couple of weeks.

You don’t always have access to your state

Right now, if you go offline, the hub is the only entity that persists your channel’s state. From a usability perspective, this is great because it allows for easy cross-device support and keeps state in sync. Obviously, this is bad in the event that the hub goes down and you need to recover your funds from the contract directly using your latest state.

“Data availability” is a known problem for channels. To solve it, we need access to a highly reliable/available decentralized data store. Within the next 2–4 weeks, we plan to backup user state on IPFS as a temporary fix. We’re still researching a solution that would be effective long term and at scale.

Link payments and other async payments are trusted

Link payments and other async/offline payments are currently done by having the hub hold the payment until some condition for the payment can be proven to be resolved by the recipient.

This can be partly trust-minimized by allowing for conditional resolution of payments (i.e. “generalized state channels”) in our contract. The specification to do this has already been completed and will only require a change to <10 lines of the ChannelManager code (est. 4–6 weeks to ship). However, some service provider may need to be available to “receive” the state here, which we’re still researching how to resolve — everything in time, we’re working quickly.

Hub is centralized and can censor payments

Our hub is currently operated by us (Connext) and is centralized off-chain similar to how 0x relayers like Radar Relay work. This means that our hub could be censored, DDoS’d or shut down, which would mean that our payment service could go offline.

Hosting a hub is an interim solution to solve cheap, fast payments now while we work on building out the remaining pieces needed for a decentralized state channel network. We can fix our own centralization by allowing other Connext hubs (at that point, nodes) to be networked together, by making it easy for anyone to run a node, and by moving to sending state updates over some P2P messaging protocol rather than over https. These changes will require some quality of life improvements to our contract functions, however, so we expect to only start work on them after our next contract iteration is deployed.

FAQ

How can I integrate the Dai Card and/or connect to your payment channel hub?

Integrating is simple and requires very little use/knowledge of Ethereum development itself. Instantiate the Connext npm package and then call deposit , buy , withdraw to get started. More information available here.

What does it cost?

At launch, there is no cost to the Card. We plan on experimenting with a few different pricing models for users and businesses starting a few weeks after launch. Our goal is to keep fees as small and unobtrusive as possible.

Why is it called a Card?

Just like a debit card, you can top up your Dai Card with balance and spend it everywhere through your day. We want users to think of that experience as different from but complimentary to wallets where you typically store much larger amounts and transact less frequently. This way, wallets can also easily integrate Card functionality!

Channels vs Sidechains / Plasma?

Sidechains (and plasma) don’t need collateral to run, are extensible and have many of the same properties — information symmetry, programmability — as the base chain. However, it can be difficult to get into/out of them, they run into their own scalability problems, and are somewhat custodial in that they don’t handle mass user exits well.

Channels are the opposite — very cheap to use, very simple to set up and always noncustodial, but limited in their extensibility. They also require collateral to use and have some challenging availability assumptions. We expect that this means channelized networks are better for wide, horizontal infrastructure layers and plasma / sidechains are better for vertical, app-specific use cases.

How can I get involved?

Join our Discord! We are building the future of payments on the internet. Our entire stack is open source, so we would love your help getting there. We also have a grant profile on Gitcoin if you want to contribute Dai to the development of the Dai Card and payment channels!

Is this audited?

Yes! See: