The CARD Protocol Explained
Lightly edited transcript of Chris Tse’s tech talk
The CARD Protocol unites the Cardstack Ecosystem. It is the economic layer that organizes the buyers and sellers — the customers, retailers, and service providers — and makes the whole network worthwhile for all participants. This tokenized SaaS system will provide end users with the software they need, to do what they need to do, at a great price!
CARD stands for “Customer Acceptance and Revenue Distribution”, which are the two basic components of the protocol:
“Customer Acceptance” (CA) means that we want to have a network where ecosystem participants welcome and serve mutual customers without payment and billing friction. Once you are part of this network, you accept CARD; you accept the Cardstack Ecosystem’s built-in mechanism for coordinating customer memberships as well as payment and billing. This is similar to accepting Visa cards. Once you accept CARD, you get a seamless experience for your users.
In return, you get a part of the “Revenue Distribution” (RD). You receive the correct portion of the overall revenue, sharing the risks or rewards. Rewards and risks are inherent in any type of business. If you pool together and share customers, you get paid — when someone is using your services, redeeming miles in your airline, using your lounges, taking classes in your yoga studio. You want to make sure that, when you open your doors to the people who hold a membership card or use this payment method or honor this coupon or prepaid card, you will actually get paid for the services you provide, because you are part of this network.
Basic concept: prepaid card (min 2:45)
The basic idea of the CARD Protocol centers around a prepaid card. You deposit an amount of value into a prepaid card; then, you can use that prepaid card wherever Cardstack is accepted. A prepaid card has an address, similar to a credit card number. It has an original value; when you buy a prepaid card from a drug store or retailer or corner store, you give them USD 100, for example. But you can’t give a USD 100 bill to the smart contracts on the network — you have to pay in some sort of token, in order to be able to spend the balance on this prepaid card. This is where SSC come in, Software and Services Coupons. But because CARD can pay for anything that is accepted in this network (not just software and services), we have renamed SSC and now call it “Spent Supply Coupon”.
In this case, you have spent USD 25.91 so far. The § symbol stands for USD 1 cent. The accumulation of how much you have spent is measured in (not pegged to) USD cents. What’s available now is what’s remaining; so, out of your USD 100, you have USD 64.13 left. Note: This number does not entirely add up to 100, because the CARD Protocol manages the exchange rate or the risk of fluctuations of the underlying currency. So, if you pay in Ether, and Ether goes up and down in price, the amount you have to spend may differ. If Ether halves in value, then what is available now could be USD 32; if Ether doubles in value, you could suddenly have USD 90 left. It really depends on what asset you pay with to create the prepaid card. We remember what you paid with and when you paid with it, figure out what it’s worth now, and adjust the available balance accordingly.
This is a little different than prepaid cards or gift cards you buy in a store, because those are typically pegged to the currency of the country those cards were issued in — whether it’s USD or British Pounds or Euros. But with a prepaid card that is based on the token ecosystem, it’s very important to both make it easy for people to understand what’s going on and provide the capability to be fair.
So, the customer buys this prepaid card, deposits value, gets original value, and spends it. We figure out what’s left, based on calculations of the market value of the underlying asset that generates this prepaid card. Then, the service providers — those who are willing to accept CARD and provide a service — say, “You have USD 64 left. You can store this large video on my server or use my protocol or my smart-contract network and pay gas fees.” And when the users have actually used that service, the service providers deduct from the users’ balance, by adding to the spent records.
The reason we use USD to express it is not because we’re pegging the value of the prepaid card to USD. We just do the accounting in USD, for ease of reasoning; people roughly know what a USD is worth, in terms of storage and smart contract fees.
Multiple services — whether that’s a traditional app charging you five bucks a month for subscription, a dApp charging you a fee when you do something, or an API charging you 10 cents for every 1,000 API calls — can say, “When you have this prepaid card and we establish an agreement, we’ll just deduct from it.” So, this prepaid card is not just like a gift card for an electronic store, which is the only place where you can spend it; it’s more like a Visa gift card, which anybody will accept. And that’s a broader network than just saying, “I have purchased this particular credit for this airline.” It’s more like something that has fungibility across the Alliance network. People’s acceptance of this means that they are willing to implement or have implemented a protocol to deduct from this balance in a standard way.
What’s nice about prepaid cards is that you can buy them in person. You can say, “I would like to buy a USD 50 gift card,” and a retailer will sell it to you. In the traditional prepaid card market, those retailers are corner stores, big-box stores, or even pharmacies that sell you a non-refundable Visa gift card, for example, which you can reload at the cash register. At Cardstack, we have this concept of a retailer too, who has prepaid cards available in different denominations. In the crypto market, those retailers are online merchants who have access to blockchain and can obtain cryptocurrencies / tokens through mining or trading. They help customers reload their prepaid balance in the CARD Protocol, and the customers pay them in whatever currency the retailers accept, which will likely be something like credit cards, PayPal, Venmo, or WeChat Pay. This is like topping off a game card they sell, which you can activate and add to your account. So, prepaid cards are the simplest concept within the Cardstack Ecosystem; but there are many more things you can do, which we will talk about later.
So that’s the basic idea: A customer buys a prepaid card. The service provider, who accepts the CARD Protocol, can deduct from this card — without having to set up a new subscription or get credit cards involved. The prepaid card is a store balance that will facilitate the providing of services on the Cardstack Network.
Acceptance network (min 8:33)
This acceptance network is a very powerful idea — because, at the end of the day, what credit card has really done is build five or six networks (Visa and Mastercard in the West; American Express in the US and beyond; Alipay and WeChat Pay in China), which are all acceptance networks.
What we want to be able to do is this: Customers hold different types of currency. Sometimes, that’s fiat currency; most people have a credit card or even cash. That can be converted into cryptocurrency. The idea is that a prepaid card is pegged to a currency we can measure with a smart contract in a protocol network. Obviously, we need a native measurement and accounting unit within the CARD Protocol — the CARD Token serves that purpose. And if you put in USD and ETH, we’ll measure how much it is worth, based on the exchange rate at the time of the creation of the card, the time the service was performed, and the time the merchant or service provider can withdraw the money. We essentially share the risk, depending on when that happens. We do the right thing. If the currency went up tremendously, we would try to make sure that whoever holds the token (or the pegged value of the token) at that particular time benefits or is protected from the fluctuation.
Because these tokens, which are backed by a prepaid card, can be redeemed by the merchants or service providers, they can look at this “available now” balance and say, “I know that there is this amount of underlying assets” — whether it’s crypto or fiat (fiat will be represented by a stable coin) — “and that I can safely provide a service, knowing that the smart contract / the network / the calculation engine will give me the proportion when I want to withdraw this.”
And these USD 1 cent increments are divisible; so, you can actually bill less than USD 1 cent (we will have as many decimal points as we need). Hosting services or cloud services typically bill no more than USD 1 cent. That allows us to make it more user-friendly and avoid giant numbers like Gwei. We can do something that is human-scale — roughly USD 1 cent for API calls — as a way to grok what’s going on.
A lot of what we are trying to do is lift the standards of understanding away from the low-level crypto protocol and even payment systems, and say, “All you have to do is understand this card, this idea of this physical card.” By the way, this prepaid card is rendered using the Card SDK; so, it synthesizes data from on-chain data, from the smart contract, from exchange rates, caches it, and aggregates user history. We’ll get more into detail about how that works using Cardstack as a framework, a hub, and a development toolkit for the UI. But this is not just looking at Web 3.0 and looking at a dApp. This is actually a synthesis of much information — but in a way that’s easy for the user to understand.
So, the acceptance network is what we are trying to build, using this prepaid card as the first type of card you can issue in this network.
Overall schematics: introduction (min 11:50)
In addition to the customer and the service provider, there are four other concepts. The retailer is someone who sells you the card with the prepaid balance. The token pool or value pool is where all the cards, Ether, USD-pegged coins, and CARD tokens are pooled together; it exists on a smart contract that you can look at and say, “How much is in this network across all these cards that are being issued?” Then, we’re going to do usage accounting — how many times has someone redeemed USD 10 or 15 cents and what kinds of service were provided (not only by one service provider, but by all of them)? As for the Tally workers: Since a lot of this requires conversion rates, aggregation, calculating proportions, etc., there has to be quite a bit of analytics performed on the data that is available (the customers’ data, the usage accounting, the token pool, the retailers), to determine what everybody’s getting. The Tally worker informs not only what’s on the prepaid card; but when a service provider says, “I would like to withdraw the money every month, so that I can diversify it or use it to pay my employees,” the Tally worker is the accountant or the bookkeeper who says, “Okay, you’ve charged people this much money, and based on exchange rates, this is how much you can redeem right now.”
Overall schematics: the 6 players in the system (min 13:19)
The customer uses the prepaid card to pay the service provider — that’s the first relationship. To do that, the customer is either directly or indirectly staking / putting / depositing a certain amount of value or assets into the token pool, which is based on smart contracts. If the customer does not have cryptocurrency (which 99.99% of humanity does not possess directly or even indirectly through exchanges), we want to leverage an existing retail network — it could be e-commerce or it could be in-person — to sell these prepaid cards. When they give users the prepaid cards, the staking is done by the retailers. This means: The retailers can sell these prepaid cards and give people access to the underlying network, without having the customers deal directly with tokens themselves. Finally, the Tally workers mark the prepaid cards, the value, and the spend history to the market — so that everybody knows how much something is worth, how much they can deposit, how much that deposit is worth, and how much can be withdrawn. The usage accounting is a part of the network that’s done partially on-chain and off-chain. So: Use, pay, stake, sell, meter, and mark.
Technical mechanics in detail: workflows between the 6 players (min 15:17)
A lot of times, when people think of protocols, they focus too much on the technical aspects of how to implement a step in the protocol; they are not really thinking about the interaction between players — what they care about, what they want to do, and what the risks and rewards of performing those actions are. So, what we’re going to focus on is the workflow between the different parties: customers, service providers, card retailers, token pools, usage accounting, and Tally workers.
Mark to market
Let’s start with what cryptocurrency people understand as a token ecosystem. The simplest way to use a token is to interact with a smart contract. In this case, we have two different types of smart contracts on-chain — the token pool and the accounting. It could be layer 1 or layer 2, but they are essentially blockchain-type technology. The other people (the retailer, the customer, the Tally worker, the service provider) are basically running their UI or APIs or systems and services in the cloud. We have designed the Cardstack Hub so that it contains all the code, modules, and functionality for the customer, Tally worker, service provider, and card retailer to do the work. So, most of what we’re talking about is running the back-end Cardstack Hub; we spent a lot of time designing it, so it can interact with a fairly narrow set of capabilities that we’re going to put on-chain, and still achieve the prepaid card and other derivations of that.
The simplest thing a customer can do is use the UI. In Card Folio, we provide a UI for you to transfer tokens: You deposit a token and say, “I would like to pay you 10 bucks.” Then, you transfer that from one account to the other account, to the service provider; and when that deposit (btw: this was the way we conducted the token event) reaches the smart contract, we automatically trigger the provision of service — that could be granting access to dashboards, creating new entries in databases, or unlocking a domain name for you to start using under your name. So, the service provider runs the Cardstack Hub, listens to all the changes in the smart contract (in this case, the ERC20 contract of the CARD token), and provides the service.
This is very simple. It is about the integration of the UI and API tiers, running the Cardstack Hub, using the smart contract as a way to translate this message and as proof that something has happened, and using that to govern access control and on/off switches (in some cases, it can be more sophisticated, like taking smart contracts and creating new profile pages or generating new off-chain transactions).
That’s what we have been building so far. What we are adding on top of that capability is the idea of a token pool. Customers usually deal with not only one service provider; their catalog of cards may touch many service providers, with some of them providing APIs to give them exchange rates, some doing storage, some doing video conversion, and some doing it on-chain, while others are doing it in a cloud. Our approach to this is similar to the way people deal with multi-signature contracts. They just say, “let’s pool our funds together into a group account,” and that’s what the reward pool is. We’re building this additional smart contract, called a “reward pool,” that allows customers to deposit and withdraw the tokens in this shared way. In America, we tip waiters and waitresses, who pool their funds together by putting their tips inside a jar; and that’s what the reward pool is at the end of the night, when they determine (based on some usage accounting) what portion of this tip jar or this reward should go to each person. That’s the basic idea. We just pool funds together and delay the settlement.
These token pools are secured inside an on-chain smart contract. The flow of tokens between the pools works like this: When external value (such as DAI) comes into the reserve pool, CARD tokens are moved out of the reserve pool and into the reward pool, so as to convert this reserve into circulating value. These movements are controlled by the logic of the smart contract and happen automatically on-chain. We take utmost care in the design of the smart contract, leverage best practices, and use well-tested libraries like OpenZeppelin as building blocks. Before the smart contract goes on mainnet, multiple rounds of third-party security audit will be performed to ensure the safety of the pooled tokens.
Along the way, we need to know how much that reward pool is worth, assuming that the token is not just one token. One token will fluctuate; but if you have multiple tokens (like Ether, Bitcoin, and CARD tokens) inside this reward pool, it’s going to be very hard to know how much it is worth. So, we take the on-chain transaction history and send it to the Tally workers — the people who are monitoring everything (Tally workers are actually pieces of software, but you can imagine them acting like accountants). They know what transactions are going on; and because Tally is running on the Cardstack Hub, it can access services that provide cryptocurrency-to-fiat-currency exchange rates on a given day or time, so it can figure out what the current market rate of the pool would be. That allows us to know more than just the token balance and smart contracts, in terms of what the network is worth.
Once we know what the network is worth, we can start measuring and sending things out to users, telling them how much they have and what they can spend, in an easily understandable denomination like USD. So, when you deposit the token in the reward pool, we generate this idea of a prepaid card, which is backed by something called SSC (a spent supply coupon account), to show you how much money you have spent and how much you can still spend. That’s the creation of a ledger in usage accounting. In the old days, this would be a punch card (you bought 20 of something, and every time you used one, you punched one of them). So, this is creating a blank card that will keep track of your usage.
Now, we know what the current value of the underlying tokens is. With the prepaid card (the SSC account that has been created), we can tell each user how much has been used, assuming that some usage has already been done; if you haven’t used anything, but staked a currency that’s fluctuating (which will be marked-to-market), the “available now” balance will go up and down with the underlying asset of the prepaid card.
CLUTCH mechanism
People who do not have tokens to deposit can just buy a prepaid card from a retailer — instead of buying the token, they can buy usage via the prepaid card, which allows them to use the network. So, as a customer, you go to the retailer, who offers you a card. You can buy this prepaid-usage coupon with a minimum of USD 5, for example. What happens afterwards is what the people in the Ethereum space or broader ecosystem call “decentralized finance.” But we’re trying to do this in a way that is not specific to a particular ecosystem. This can be done in any type of back-end or service that is being used. So, the retailer receives USD 5 — either in cash or through a credit card API — from the customer. Now, the retailer needs to get those USD 5 into the token pool, which he does by buying USD-pegged coins. Based on the currency the user is bringing in, the retailer will buy a pegged coin from a centralized or decentralized exchange, which he will then deposit and lock in the “reserve pool” on behalf of the user / the customer. The reserve pool is another part of the token smart contract that locks up these coins, noting that this amount has been deposited. We do native measurement and movement in CARD tokens. Think about that as the membership reward points from American Express or the ultimate reward points from Chase, which you can transfer. In the Cardstack network, the CARD tokens are in the reward pool.
We need to take the reserve pool and see how much value has been put in there. Using the exchange rate provided by the Tally workers, we calculate how many CARD tokens to put into the reward pool. We’re trying to keep the value balanced, so that you put something in, you take something out, and you put it in the reward pool. Now the reward pool is funded with the tokens — this would be as if the customers had their own CARD tokens, but instead, they’re going through a retailer to do that operation for them.
This is what we call the CLUTCH mechanism. The idea is that someone is doing this operation for you. Unlike other tokens that you put in yourself, you can’t withdraw these tokens; you have put them into this pool for the service providers to redeem when they perform the service. It’s a one-time non-transferable purchase. Yet, any person in this network would know that the reward pool just grew by USD 5, which allows them to perform up to 5 USD worth of service. This also allows us to calculate bonuses. It’s like saying, “If you buy some points today for this airline, you get a bonus of 20 percent.” We can do that to incentivize people to make deposits, to use the network. And that’s one of the nice things about having the CARD token as a native token: We can incentivize customers, service providers, and retailers, showing that it makes sense for them to use this network, to begin forming this acceptance network — knowing that, the earlier they participate, the more value they’re going to get, by earning bonuses for doing the right things. Credit cards do this too, offering 1,000 points of sign-up balance when the cards first launch, which later becomes 25,000, because they’ve got the users, they’ve got the network effects going, so they will reduce the bonus. And we’re going to follow a similar launch strategy for point systems.
Payment authorization
Now, we have a reward pool for customers who deposit directly or through a retailer. The next step is for the service providers to start looking at this reward pool and say, “I want to serve these customers, because they have value in this pool, and if I provide the service, I will get some part of it.” The first thing they need to do is sign up. We have to make sure they are taking some risk. So, they’re staking some amount of CARD tokens (the native governance token of the system). They say, “I want to deposit USD 1,000, so I can bill up to USD 1,000.” This way, if there are some weird shenanigans going on, we can slash their stake and either refund the customer or replenish the reward pool for the good performers (the people who are doing things correctly). So, the service providers create an account or an entry within a smart contract; having staked some amount of tokens as protection, they can now perform the services. The ratio of how much stake you need to perform how much service you can bill for can be adjusted on-chain and evolve, as the smart contract gets smarter. But that’s the basic idea. You have something at stake before you start serving customers, so that, if you provide really bad services or you try to just bill people, then there are ways for us to pull that back and say, “You’re doing the wrong thing, I’ll slash your stake.” But generally speaking, once you put your stake in, you are part of this database or part of this ledger, and people can start working with you.
When a customer says, “I would like to start using this Web host who accepts CARD as my hosting service,” he will have to go to a Tally worker and say, “I would like to create a payment authorization for my chosen service provider.” This is like saying, “How much value in USD can I send to the service provider; how much can I give him the ability to deduct against?” Then, the Tally worker says, “Based on the market value and the volatility of the underlying asset, you can spend USD 64.13.” If the asset is very volatile, the authorization could be for less than that, maybe USD 40. So, the Tally worker uses a formula; whether that’s simple statistics or machine learning in the future, or it could be CPU Database, which is what the current generation of Tally is using, but it could also use GPU as a way to accelerate certain types of detection to say, “Given that we know everything that’s going to the network and we know the exchange rate — how much can we authorize?” That authorization becomes billable usage up to the available amount; and that authorization is handed to a service provider, but not on-chain.
The service provider can then accept that authorization to enable billing. He uses that balance and the provable usage data, using off-chain calculation (but cryptographic in origin), to say, “Here’s usage: The customer had USD 5 and did this or that, played this game, etc.,” and then that spending history accumulates for the service provider. That’s how the customer spends.
When it’s done, that usage data continues to go to the Tally worker, allowing us to deduct the actual value — what’s been used up. So the spent (the 2,591) keeps going up as the service is accumulating, while the available balance goes down. That allows us to update the UI and prevent you from authorizing too many payments. You can only get one authorization, which Tally uses as underlying data. This is pretty close to how credit card systems work. And delayed settlement allows us to do micro-transactions, especially with long-term billing relationships, which is what we want to facilitate.
Withdrawals
The last step is withdrawal. When the service provider wants to withdraw, he goes to the Tally worker and says, “Look at not only what one customer is spending, but all the customers (there could be a million customers, each with different prepaid cards and balances). How much can I withdraw?” And it works in a similar way. The Tally worker would say, “You can withdraw up to this withdrawal limit. You can forward the authorization to the accounting system, which allows you to see how much SSC you have. And then, through a side-chain main-net protocol, you can redeem the CARD tokens and get them transferred to your particular wallet.”
This is our overall plan for the network. We’re going to take incremental steps, starting from a smart contract and Tally, and working our way out to authorization and machine learning, to determine and adjust for risks in the overall network.
One of the nice things to note is that Cardstack is running all the complicated stuff. What’s going on in the token pool (depositing tokens and creating an account) is basic smart-contract stuff. Most of the really interesting layers are actually implemented using our functional reactive properties in the Cardstack Hub. That’s one of the reasons we felt like we need to do a lot of work in making sure the hub can do this processing logic and, more importantly, all these API calls — like requesting authorization, purchasing, and forwarding things. That’s all protocol done in the Web way. It’s protocol that’s done in the middleware in the API. It influences (using cryptographic primitives) what goes on-chain. Some things get validated on-chain before getting distributed. But a lot of the protocol is actually what we call “cloud protocol” — and that’s totally fine. PayPal is a 100% cloud protocol. You can look at Stripe, doing credit card payments, as a protocol, but it’s all done in the cloud. So, the idea here is a mix of on-chain and off-chain, to create that user experience and illusion.
Use cases for payment cards (min 31:52)
With this type of infrastructure, we can do quite a bit more, using the CARD Protocol.
You can have a Game Card — a card that’s denominated in the in-game currency. It’s not pegged to anything; it’s just something you can use. And you don’t really need to mark it to market, because it’s just the native currency. So, you can use the CARD Protocol for usage billing and the underlying SSC as a way to measure it.
Many new users want to use dApps, but don’t have any Ether, so they can’t pay gas. A dApp can provide a Gas Card — that’s just like a card for you to fill up your gas if you’re doing delivery for a company. This allows the users to be subsidized, to have a certain amount of Gwei to use over time. But you’re not giving the person Ether. This is non-transferable; the amount can only be used through meta-transactions and other types of funding mechanisms, where we are only going to pay people who are providing transactions and putting things on mainnet, for example. You can’t just sign up for 100 accounts and get several Gas Cards to accumulate a nice number of ETH. This is a non-transferable spend-for-transaction-only Gas Card. It could be implemented in different ways, with meta-transaction relayers; and we’re also working on something called “transaction refueling,” which basically means that we deposit in an address that is multi-sig-controlled.
Someone could sell you such a card, but it could also be a gift as part of a free trial. The Free Trial Card can be denominated in the local token. This would be similar in concept to what companies and entities and protocols are trying to do — how could people try out your service without having tokens? This would be another non-transferable way of doing it; so, they can’t trade or sell it, they can only use it to redeem services. It’s about this idea of signing up and then getting a balance that is non-transferable, using the CLUTCH mechanism — it can only be spent for services, it cannot be extracted or withdrawn in a more traditional token way. This could be a good way to make sure that people don’t pull these tokens together for financial gain, but actually try out the service and learn what the network means.
On the other hand, when customers or workers (people who are working in your network) are doing something very valuable — facilitating usage, facilitating the network — they can be given a Reward Card. This reward is something that is earned with action; it’s what we call “quantifiable work.” It’s about thanking someone for their work through an extra bonus. And that can actually be something that can be redeemed directly in the network. So, you can use these earned rewards almost like a credit card reward to earn more flights or other things. But it can also be transferred out, because it is proof of useful work; it is something that people have done real work to deserve, it’s not just a vehicle for moving numbers around. Those people should be able to say, “Here’s an invoice. This is what I’ve done for the network and I got USD 13.19 worth of value from that.”
As users start having ongoing relationships with service providers, it makes sense for them to switch from pay-as-you-go and micro-transactions to subscription. It’s worth USD 5 a month for them to be a charter member of this network. That just means that the deposit, which goes into the reward pool, is ongoing. The user automatically puts in USD 5 to repeat the payment to the retailer, either through a credit card transaction or through an allowance to a smart contract. Ultimately, that subscription is what we’re trying to do. But the concept of a prepaid card helps us understand the basic operating principle of what the Cardstack Ecosystem is. The Subscription Card is just another type of card that automates certain processes, so you don’t have to do it every month and you don’t have to top it off, for example.
Payment cards & the UI / Card SDK (min 36:21)
You can even prepay this stuff. The idea is that all these things are “value in” — whether it’s gifted or earned or purchased by the different participants in our network. With our UI, you just double-click on a card and you see what’s going on; it’s almost like opening up a wallet on your smartphone — very easy to do.
The Card SDK is our front-end technology and the way we create the schema, the model, and the templates for these things. We always intended for these kinds of identity, payment, and membership cards to be an integral part of how we unlock the value of this software and services network. After all, you can make Content Cards, Data Cards, and Asset Cards. But if people are just using your app for free and you have to find a way to bill them for it (maybe charge them a transaction fee, hold their wallet, or put ads on them), then it’s hard to make the Web a real ecosystem; because the websites you’re using are not really serving you, they’re serving the advertisers. By having Reward Cards, Subscription Cards, and Prepaid Cards — at the core of which is the same SDK — we can find a way to say, “You’ve earned USD 13.19, which you can use to pay for a subscription, which costs USD 5 a month. And by the way, you still have a USD 64.30 balance, which you can use as spendable balance to bill the network.”
Deposits & withdrawals (min 37:48)
This is a six-sided thing centering around the reward pool, the locked reserve (where non-CARD tokens are locked to back the value of the services, being contributed to the reward pool through this automated balancing mechanism we’re doing on-chain), and the rendered services (the billable usage). Between the billable usage and the deposits (which the users can make themselves, or they can have retailers make them on their behalf) are the purchases (the actual new value coming into the network), the market rates (telling everybody what the deposits and earnings are worth), and eventually, the withdrawals (you could withdraw directly to a wallet or through the Card SDK and the integration with the Cardstack Hub; you could also use financial intermediaries, whether that’s traditional or crypto ones, which provide services where things get deposited directly to your bank account, Venmo account, or even Libra Coin, if that’s what you want to do). But the idea here is that the interaction with the protocol is basically just like a cloud subscription. Everything’s happening in the background, deducting against your balance, until you say, “I want to take the money out and make a deposit,” to interact with what we know as the banking or crypto or financial service organizations.
Product grid of providers, developers, users (min 39:49)
That’s how the Card SDK (the UI and the logic), the CARD Protocol, and the Cardstack Hub are doing a lot of the calculation and analysis — serving as the basic runtime for Tally, for retailers, and for service providers (who are providing all kinds of services, from database to courier services). That’s been our basic technical framework. Hopefully, the CARD Protocol — which sits in the middle, allowing users to use multiple types of services — will help coordinate this multi-currency payment and billing network across multiple providers.
We’ve been working very hard to not only build the protocol aspects of it, but also think about how this would actually end up being used. We have this idea of a product grid. It’s not really a product line. Other product lines do this for businesses, that for end-users, and this for developers. But in our network, they all overlap. The service providers want to be staking, billing, and getting a reward, and know that a third party (Tally) is telling us how much it is all worth. The developers build on the Card SDK and the hub, so they can also get a portion of the reward. Therefore, the reward is where they overlap.
Beta Tally (min 40:36) and Beta Folio (min 44:54)
Tally is doing a lot of the work; there are a lot of management levers — you have to stake and withdraw and create relationships, etc. Folio is less low-level; it’s more like what the user would see. A folio will be similar to the iOS wallet app. You can say, “this is my mileage card, this is my credit card, this is my prepaid card, this is my Apple card,” and we have a similar concept. Tally is for the provider mostly; it’s more low-level, more of an accounting system. Folio is more like, “How much money do I have? How much can I spend? What membership do I see?”
Tally and Folio are works in progress, and we hope to launch the beta very soon. But let’s take a look at some of the work that we’re doing on the template and how it looks.
Because of the way the Card SDK works, when we’re building a template, we’re also building an API; so, the same thing that powers the user — the same logic, the same computation — also serves data to the oracle, so that on-chain data gets the same approach.
In Tally, we have two concepts: One concept is this prepaid card, because we need to mark the card — the value of the underlying asset — to the market. The other one is the service provider — someone who is billing for and accumulating usage across different user bases, charging different users who have different prepaid cards. They will have a page that summarizes what they are doing.
In this example, the prepaid card is funded using the Aragon token (ANT). It could be funded using any other token, but in this case, we are using an ERC20 token as a deposit. The available balance has to be some continuous calculation of this stuff, so we created something called SSC ID, which is the account number (a hash of a bunch of stuff), and a subscriber address (who holds this prepaid card?). The usage is accumulated over time, showing how you have used the balance that you have deposited and staked for various types of service. The active service providers show how many service providers you are using. One could be hosting your photos, another one could be dealing with your accounting system, and a third one could be paying gas fees for you. Because of the way Cardstack works, one card can tap into 10 different services and different cards can tap into different crypto networks, so the diversity of this pie chart may change. Finally, you can use this to subscribe to a new service provider.
If you take a look at what the providers are doing for you, you see that you’re using Card.Space, which is hosting a website for you, so you can have an on-ramp. Then, there’s Hubs’R’US. They provide Cardstack Hub service and all the things that can be included in plugins — for which you have been billed USD 11.23 thus far. Then, you can go see the provider details and you can say, “I don’t want to do subscription with you. I want to revoke your ability to bill my account, because you’re overbilling me.” That’s how the consumers / the users / the customers can manage the relationships with the (currently three) active service providers who can bill them.
From the service provider’s point of view: These are all the service providers who are listed or who have staked CARD tokens. Their stake determines the limit of how much they can bill. And now, they can go inverse and pivot the other way, data-wise. In this example, Card.Space has 23 subscribers and is billing 15 bucks per month on average. As much as cloud services are growing, this could be a big thing. And that’s the idea here: The service providers manage the customer relationships from their angle and Tally is the neutral, administrative accounting Web dashboard that makes it happen.
So that’s Tally. The capability and UI of Tally will be launching soon. And this is actually acting as the oracle to the smart contracts, so that the data that users see in a Tally node is the same data that informs activity on-chain.
Folio is a lot simpler than Tally. We want to say, “You have a prepaid card, you have a membership card, and this is the current balance.” We don’t need to get into a lot of detail. That’s it: You have some assets in Ether and CARD. And you could have a MetaMask wallet, for example; in the future, we will also support other types of wallets, whether that’s Trezor or some of the custodial or non-custodial apps that use it. And we just report to you what the USD value (or whatever value that you’re shown) is, using the mark-to-market and the market oracle.
Tally is something that’s new, while we shipped an alpha of Card Folio already, to show the basic capability, and we open-sourced the Card Folio codebase in January; it’s actually powering both Tally, which is more administrative and more complicated, and the new Card Folio. So, these are the two things that will be launching soon! If you have a MetaMask account, you can start using Folio. And to use Tally, you can actually stake to become a service provider and start experimenting. Tally will initially launch on testnet, because there are a token pool and stake pools involved in it, so we want to make sure that those are working correctly. Card Folio is basically a read-only app, like an explorer or wallet. For now, it uses MetaMask for transactions. So that’s going to go on testnet, and you can use that and play with it soon.
Smart contract / GitHub (min 46:19)
This is an interesting description of the underlying smart contracts. We call it the “smart contracts necessary for the CARD Protocol.” Most of the heavy lifting is actually done in the Cardstack Hub in off-chain land. So there are some parts of the protocol that need to happen: There are contracts and oracles and integration and creating various-level pools, whether it is the reward pool or stake pool or reserve pool.
The basic idea here is that we are trying to keep the service area of smart contracts as small as possible. Smart contracts are high-capability, because we’re building this mechanism in Ethereum — for two reasons: One is that the tools are mature and we’re using the OpenZeppelin library, so it’s upgradable, we can improve it over time. But more importantly, there’s a lot of representation of assets — stable coins like Dai or USDC or TrueUSD. There is capability for you to participate in the money market; you can take loans against it, if that’s what you want to do. And with this idea of creating a deposit, it makes sense for us to leverage all these other decentralized finance or DeFi innovations and essentially provide a pool — a smart contract that allows those things to be converted and staked, to create this much more dynamic and user-focused billing mechanism.
So, we have the reward pool, the reserve pool, the oracle, and then the active service registry, showing which customers and service providers have a relationship, and that can be cancelled from both sides.
The reserve pool and the reward pool are essentially a smart contract that locks these things together and provides capability. The reserve pool is mostly about how many other tokens you’re putting in; it’s kind of a multi-sig wallet. The reward pool is denominated in CARD tokens; and any reserve that is deposited will create the correspondent reward pool. The withdrawal and the payout come from the reward pool. Then, with integration (we hope to integrate with a decentralized exchange like Uniswap and maybe even Kyber), you can automatically convert it back to what you have. And the reserve pool would be there to say, “this is the total network value that is in the system.” So, the CARD Protocol has these relatively small pieces of modular code that support all the things that are going on in the smart contract, while the smart contract supports the overall protocol.
What’s next? (min 48:49)
1. Card Folio is the first end user-facing launch pad for new types of cards that tap into and wrap the power of decentralized networks in a composable way. We’re using it to show what you can do with the Cardstack UI, the Card SDK. Right now, we’re doing prepaid cards, because there are a lot of moving pieces; and with prepaid cards, you basically get all the Tally and the usage billing things right. Once you have that, you can use the prepaid card to pay for registering on Ethereum Name Service. You can buy crypto collectables to a degree that make sense, if they are unclutched (if they’re clutched, you can only pay the fees on them). We will be integrating with other DeFis (decentralized finance), DAOs (decentralized organizations), and DID (decentralized identity), taking a look at what’s going on both within the Ethereum space and beyond, like the Decentralized Identity Foundation that Microsoft is sponsoring. And we reflect that stuff in a card way. If it’s a card and it’s built on the Card SDK, Card Folio is like the standard UI for you to visualize all this stuff. The most important thing about Card Folio — or the Cardstack UI that underlines it — is that you can wrap the power and then chain this together: “Please take this and do that with it, and when it’s done, go and send it to this person.” This kind of orchestration allows us to use these basic units as building blocks almost like songs in a playlist; and then, your playlist could decide how to orchestrate everything together. So, Card Folio is for end users.
2. Tally is the administrative layer to coordinate the four-sided economy. We want to do as much computation as possible using the functional reactive properties of the Cardstack Hub; so, when you update one cell (almost like in Excel), all the other formulas propagate through the sheets. That’s technically possible in Ethereum, but each time, you have the wait for block time and you have to pay gas, which is not always possible. By doing this off-chain computation in the Cardstack Hub, we can keep all these numbers up-to-date. They’re indexed. And the process is accelerated through databases, Postgres, and all these kinds of JavaScript capability. In the future, we’re going to be tapping into machine learning algorithms, so that the calculation of risk can be done by looking at all this data that is available in the Tally database. Then, we can say, “I believe it’s USD 40 worth of risk,” and that can influence users.
What we want to do is interact with the chain with a technique that’s proven. A lot of people are inventing new stuff we keep track of (we just hosted a workshop for state channels). We’re looking at different types of capability. Right now, oracles are the easiest way to do it. But this is not centralized; Tally is running on top of Cardstack, and the Cardstack Hub can run anywhere. So, you can have 50 different Tally nodes in different countries running the same algorithm, performing the same analysis on the same on-chain data. Then, you can choose which one will be your payment or withdrawal authorizer, and they will have some risk. If they tell you they are withdrawing USD 40, but you actually do not have USD 40 worth of value, a Tally worker essentially has to slash the stake as well. Tally workers will become analytic miners — providing analysis service using the Cardstack Hub’s functional reactive properties. They get chosen either dynamically, randomly, or through a long-term relationship, to provide the service for the different participants of the network, acting as the accountant of this decentralized economy.
3. We are going to continuously evolve what’s on-chain and what’s off-chain into what we call the “on-chain / off-chain mix” to balance all the qualities that matter in real Web apps: ease, speed, cost, trust model, security, etc.
A lot of projects, especially in the Ethereum space, want to do as much as possible on-chain, because that makes sense when you’re dealing with decentralized finance, where you want to have a very accurate on-chain measurement of the underlying assets. When you get into payment systems and membership systems, it’s possible for us to use off-chain techniques and serious cryptographical primitives like SSL and HTTPS (it is not on-chain, but it is cryptographic), to make sure that things are not drifting too far away from what’s been staked on-chain. The key here is that real Web apps — ones that serve millions of users every day — need to be easy to use and fast in terms of the UI. They have to be cost-effective, they need to have a decent trust model (what we have right now, with the centralized digital super powers, leaves a little bit to be desired), and obviously, they need to be secure — not in terms of theoretical security, but in terms of the risk of people losing their funds and stuff like that.
This is pretty high-bar. Blockchain and smart contracts have a lot to offer if we inject blockchain in the right part of the ease, speed, cost, trust model, and security qualities. Currently, our spend supply (the accounting ledger for usage) is done using the Cardstack Hub. It would make sense for that to be done in a side chain or plasma chain, so that the different service providers know how much has already been billed. They share that information in a more efficient way than going to a main net — which is good for large amounts, but not for 20 cents, when your gas fee of recording that small transaction costs 20 cents on a bad day.
What’s nice about the CARD Protocol is that we could swap out the implementation to use a plasma chain, if one became available, without changing much of the rest of the protocol. So, we’re going to continue looking at this, analyzing it. Think of Cardstack as the payoff. Cardstack has all these working systems and UI. And we can say, “that’s ready to go to plasma chain, so let’s switch over to that”; and suddenly, everybody is like, “hey, we’re using plasma chain underneath.” It’s almost like saying, “we’ve switched from the Amazon Web Server to Azure or Google Cloud.” The users who are booking a card don’t really care; they wouldn’t care whether we’re using the plasma / side chain underneath. But between ease, speed, cost, trust model, and security, we will improve by switching to these kinds of protocol when they’re ready to go.
Another aspect of it is that we really want to improve the end user experience. We like MetaMask in terms of giving people an understanding of what it means to be a direct participant in this ecosystem (by using MetaMask as their wallet); but for most use cases, for people who are buying a prepaid card, it doesn’t make sense to ask them to use MetaMask to hold their balance. That’s why we want to have a hosted (yet non-custodial) wallet, which balances security and ease and trust. There’s a lot of really nice research on threshold multi-sig and new products coming to the market. We’re keeping an eye on that space and seeing how we can turn that into an abstracted scheme. The goal is that, with Card Key, you can sign your transaction in three different ways — the traditional MetaMask way, through a Trezor wallet, and maybe using a future type of threshold multi-sig, where you may just use an iPhone plus a hosted service.
The goal of Cardstack has always been about bringing the decentralized protocol to the surface, so people can understand the protocol and the composability of the Cardstack UI. Signature, balances, prepaid cards, and relationships with service providers are just different aspects of these units of relationship, and those can all be represented using cards, both on the front-end and as a way to orchestrate the back-end.
For us, Cardstack is at the center of this network, and we see the CARD Protocol as the economic layer to make it all worthwhile. People do not just participate in it because they believe in open source or decentralization — but because this is the best way for them to access the greatest number of customers, the greatest network of collaborators and other businesses, so they can provide seamless service to mutual customers. And hopefully, the CARD logo will become as ubiquitous as a Visa and Mastercard logo, so that everyone says, “They’re using Cardstack! They accept the CARD Protocol, so they can serve me, and I’m going to get everything I need for a reasonable fee.” This will allow us to build the Web 3.0 that not only has the qualities of the connected Web, but that decentralizes the value part, that decentralizes what is now locked into app stores, including advertising support effects.
We will release the source code of our smart contract; but more importantly, we will let people play with it on Rinkeby testnet, as we want to be able to get community feedback on how this is working. Then, the payment mechanism will evolve. As we add more services, more cards, and more community features, it will become more obvious why this prepaid card becomes the pass for all of the things you can do on the decentralized Web.
Learn More
- So what’s the product? — Cardstack Strategy Talk
- Card Makers: Who Are They? — Cardstack Tech Talk
- We Need to Decentralize Publishing… Again
- Cardstack.com
Star Cardstack on GitHub and join our Discord channel or our Telegram group and announcement channel to get all our latest updates.
