Developers provide users with a catalog of software code that takes the form of cards. It’s like an app store, where developers publish their apps, which users then download and use.

Developers and providers have an economic relationship. The developers build software, which is then hosted by service providers, who get paid for their services by the subscribed users who end up using the software. The subscription revenue, which the providers receive from the users, is collected in a reward pool — part of which is then distributed to the developers. After all, the developers are the ones who build the software the users are using in the first place, plus the ones who maintain and improve that software continuously. They are the ones whose code makes the users willing to pay. Thus, they earn a fair share of the reward, which is calculated based on actual usage analysis. This means: The reward goes from the user through the provider to the developer, so that both the provider and the developer get compensated fairly for their contribution to the network.

Businesses and providers are connected through the Tally Protocol, which calculates how much of the revenue each of them should get, based on actual usage data. How many gigabytes of storage, how many thousands of API calls — that’s all information that exists on-chain, off-chain, or in the cloud. Tally looks at the shared accounting between the businesses and the providers and determines how the network should distribute the money.

Businesses and users collaborate using Card Flow. Cards are objects that encapsulate data and functionality, but when they move between organizations — like an invoice moving in, a payment going out — that’s where business gets done. Between businesses and users, it’s all about the exchange of cards. This workflow system is the basic aspect of their relationship, combining a conversational UI with logistics and action-chaining.

The Card SDK

The Card SDK (software development kit) is a composable UI system, allowing developers to easily build card templates, which end users then use to make their own cards. The Card SDK is deployed to the Cardstack Hub, which is the server. But that server is unique: In most systems, the developers run the server, so the users’ files are stored in the developer’s data center, being controlled by the developer. In our situation, developers deploy their cards to the hub, which is run by service providers of their choice. This way, all users have their own hub, their own server, their own little personal cloud, where they have all their code — whether it’s for note-taking or music-making or image-editing. It is run by a service provider, but it belongs to them.

The Card Catalog

Using the Card SDK, developers create cards that they add to the Card Catalog. There are different types of cards:

A Content Card could be a blog post or an image you can edit. A Data Card could be a form to do a survey. An Asset Card is similar to a Data Card, but may track conversion rates through an external database, providing the information you need for your cryptocurrency exchange. For instance, an Asset Card tells you the USD value for a certain Bitcoin or Ethereum transaction. But content, data, and assets are much more than just screenshots — they are actually live and real apps.

An Action Card is more like a strategy. To name a few examples of what Action Cards can do: They allow users to send data, extract funds, convert their assets into other assets via decentralized exchanges, put their data into CRM (customer relationship management) software, publish content to the Web, get it distributed all around the world, and much more.

The user experience

Content, data, asset, action — all these cards go into the Card Catalog. Once they are in the catalog, they can be experienced by users in different ways.

A developer who believes in the Card UI and wants to build an entire stand-alone website, which is indistinguishable from what you see today, can compose the cards into an experience that takes up the full screen. Other developers may prefer to embed the card within their websites or workflows, just like a YouTube video. Alternatively, they could say, “I have enough capability within this website. I want to show a list of cards to pick, or a list of addresses to choose from when sending cryptocurrency!” An overlay allows the user to pick and choose between several cards. So, whether it’s standalone or embedded or in an overlay, they’re all just different ways of packaging these cards in the Catalog for the user to see.

Identity representation

Card-based identity representations make users’ lives easier, allowing them to say, “You know who I am.” Cards can represent a credential, a login, a username and password. In that sense, they are almost like ID cards, which users can use to bypass signups. Once they have a Credential Card from one site, they can go to another website or card-based experience without having to log in again.

A Subscription Card works similarly. If you subscribe to a hosting service, you can create content without worrying about limits of the free version. Plus, we offer cross-honoring, where the subscription is honored on various websites; as long as they all accept Cardstack’s subscription, the subscribed users get a pass through all of them. It’s almost like a class pass, where you can take yoga classes from anywhere in your town once you buy a subscription.

We cross-honor this subscription because it’s essentially a membership. It’s deeper than a payment. You’re joining a community. This could be a corporate membership, which allows you to access certain features that your company has paid for — with your Membership Card. It could also be a personal membership, offering you a nice little pool of new features if you go to the platinum tier.

It could also be a simple Contact Card containing personal information, which users can create and reuse for all kinds of different purposes and workflows.

Payment methods

People like Amazon because they have their credit card stored there; they like Starbucks because they can reload their balance whenever they need it. The Cardstack experience will offer these various payment methods too, so that users can choose how to pay. They can ask service providers to deduct against their balance, using a Reward Card, a Prepaid Card, or a Credit Card.

A major part of the CARD Protocol — the economic model that makes this ecosystem sustainable — is about using these identity and payment cards as the basic connection between different instances or service providers, allowing them to share and bill mutual customers. This is all part of the front-end, the Card UI, which contains templates, schema definitions, and data source mapping. But the idea is that all these cards, these mini-apps, get aggregated into a kind of super app — whether it’s stand-alone, embedded, or overlay.

The Cardstack Hub

The Cardstack Hub is a decentralized application server that powers the entire system, sitting between the cards and the rest of the world. The data sources it connects to could be devices, clouds, or blockchains (because the hub has plugins for Ethereum and supports integration with different smart contracts, it can treat the blockchain as if it were just another data source).

The cards that are built using the Card SDK can talk to any hub, enabling the hub to get the data it needs, to query, or to transfer content easily. If you want to send a card to another person, the inbox of that person is just another space or queue within that person’s hub. Our focus is to make the experience simple for the end user.

The Cardstack Hub is quite mature. It has been running on multiple apps and is running continuously in the cloud. This ensures that, if you make a transaction on the blockchain, it is automatically reflected in all cards that use the hub as a data source.

The CARD Protocol

To bring the Card SDK and the Cardstack Hub together in a decentralized way, we need the CARD Protocol.

If you only have one service and one SDK (for example, Instagram with an Instagram SDK), developers can only deploy their software to one company. But in our open-network approach, inspired by blockchain and implemented using open-source technology, we can essentially build a multi-currency payment and billing network.

The CARD Protocol allows a user to choose any service provider who runs a hub and say, “I pick you to help me store my image files, or manage my wallet, or count my sales, or process my credit card payments or cryptocurrency transactions.” Users are not limited to one provider or one hub. They can have different hubs and different service providers serving different cards, because one provider may be good at dealing with data, while another one may be better at dealing with a content management system. But it’s all built using the same Card SDK, thus offers one cohesive experience. And the Cardstack Hub is the server where it all comes together.

Users are customers who deposit money to pay the service providers. Their funds get accumulated in a reward pool. Based on the rendered service and billable usage, the service providers receive a portion of that reward pool, which they can withdraw. The hub reports the relevant data to the protocol.

A multi-currency payment network requires a few more aspects, as we want to shift the risk between the buyer and the seller; it should be as if they were exchanging money at the time the service was performed. Therefore, the market rates factor into the value of the currency the users choose as payment. The protocol has to figure out how much the user’s token or USD was worth at particular times. This is done through a market rate oracle — a service that keeps track of spending, due dates, currencies, exchange rates, etc. That information is captured at the time of purchase. If you pay in USD, the oracle determines how much USD was worth at that moment. And based on how much is left in this particular pool, you get the spendable balance. Let’s say you put in a British Pound; suddenly, Brexit happens and the British Pound loses half its value. In that case, your spendable balance would be halved as well. This means: As long as a user hasn’t paid for a rendered service, the user (not the service provider) will take the risk of the currency exchange. However, if the user has already paid for the service (before the value of the currency was cut in half), then the service provider would be the one taking the risk.

The CARD Protocol coordinates between these six aspects — deposits, market rates, billable usage, withdrawals, purchases, and spendable balance — to ensure that this is a fair network. When it comes to payments, you get what your underlying asset is worth; so customers can be billed in a fair and accurate way.

Tally keeps track of the market rates and determines the reward, which is an on-chain smart contract that locks the tokens and the equivalent tokens (if you pay in USD, we lock an equivalent amount of the stablecoin pegged to USD, so we can actually measure on-chain, with some off-chain conversion data, exactly what it’s worth).

To bill a user, we need to know how much of the offered service the user has actually used. Being deployed to a cloud, the hub reports this usage data. If there is a monthly subscription, it’s easy; you can just bill the users monthly, as long as they don’t cancel the subscription. But first, there needs to be some money that has been deposited; and that’s where the cryptocurrency wallet comes in. This wallet can come from the end user or from a service provider who manages the wallet for the user, depositing the user’s money into the stake pool on his behalf. This stake backs the value of the billing entry. If there are USD 100,000 worth of stake in this smart contract, you can feel confident that, if you bill the user up to USD 100,000, there’s enough money there you can withdraw. Though the billing will most likely happen on a side chain, it is always redeemable on-chain.

That billing ultimately funds the rewards for the service providers and the developers (which is calculated by Tally, running on the Cardstack Hub). It also concerns the service providers and businesses who want to have a say in how this network operates. For instance, this could be about the rate that open-source developers get for their work. If the portion of the developer’s revenue is too high, the service providers will not be interested in providing services, because they’re not making sustainable margins; but if it’s too low, the developers will not be interested in building the tools. The mechanism of the stake pool thus governs the network, to determine the values of these important percentages, so as to balance the interests of all four parties.