End-users pay for subscription with dollars or equivalent but internally they are converted to CommonCents tokens. A token is valued as a share of the platform’s total subscription revenue. As the usage of resources, services, code, and data are tracked by the platform, recipients receive their share in tokens based on the rules described above. Recipients can choose to automatically redeem the tokens for dollars but if they choose to hold them their value will grow as the platform grows, enabling the tokens to be used for investment and funding. Thus the tokens provide a bootstrapping mechanism to incentivize everyone to get involved early. Though CommonCents tokens utilize the block chain for security, privacy, and low transaction costs, they rely on a unique market mechanism that guarantees liquidity and price stability.
When used internally CommonCents tokens function as utility tokens, not securities, and are designed as such to make participation easy by avoiding the regulatory burden of securities. But when end-users or investors purchase them directly (as opposed to buying subscriptions) it is likely they will be treated as securities in that case.
CommonCents tokens are tokens placed on the DataCommons blockchain by the execution of the smart contracts that implement the rules described below. These tokens don’t required expensive “mining” as they are minted by the same entities that are already entrusted with tracking usage and maintaining financial reserves, so no additional trust is granted – they already have equivalent opportunities to cheat the system.
Users purchase subscriptions from financial custodians, who maintain a cash reserve (or guarantee) and reserve of CommonCents tokens. Different financial custodians can provide service in different jurisdictions or allow different payment methods.
As subscriptions are purchased the cash reserve increases and as subscriptions are consumed the pool of available (unissued) tokens diminishes. In order to ensure that there are enough tokens to process this month’s subscriptions, we price unissued tokens at a price high enough to buy the same number of subscriptions as were purchased in the previous month. (Note that subscriptions renew every month – in this way the number of current, paid-for subscriptions serves as our measure of the size of the platform.)
We also maintain enough of a reserve of hard currency to redeem provider- and contributor-held (and registered for sale) tokens at the current token price. This ensures there is always liquidity to redeem tokens for hard currency.
These two rules determine the price of the tokens: as the number of unissued tokens diminishes and the number of subscriptions increase the price of each token goes up:
price floor = upcoming subscriptions / available tokens
This sets a floor on the price of a token.
But as the number of provider-held tokens registered for sale increases or as the cash reserve diminishes the price will go down, so:
price ceiling = cash / redeemable tokens
This is sets a ceiling on the price of a token. If the floor is higher than this ceiling, then we will issue more tokens to increase the available token pool and drive down the floor price to match the ceiling. Otherwise we will use the floor as the price.
If the price ceiling is higher than the floor, then the cash reserve will exceed the amount of cash needed for the redemption of the tokens. This extra cash can be invested as capital to fund the growth of the platform.
As the number of active subscriptions grows the value of each token grows. And if contributors or end-users hold onto their tokens instead of redeeming them (for cash or subscriptions, respectively) the price further goes up. Conversely, as they redeem their tokens the price goes down. Thus tokens can serve as means of raising capital for the development of the platform – the more tokens that are held as an investment, the greater the excess cash reserve available to use as capital.
CommonCents tokens are utility tokens when used internally, not securities, and are designed as such to make participation easy by avoiding the regulatory burden of securities. But when end-users or investors purchase them directly (as opposed to buying subscriptions) it is likely they will be treated as securities in that case.
Below are some ideas on how smart contracts for allocation could be used to provide liquidity, investment opportunities, and more efficient and fair means of rewarding contributors.
Each project chooses how a token received by the project is distributed to its members and these rules are implemented as smart contracts. These smart contracts can encode wide variety of rules, such as:
Different type of projects will need different approaches to token distribution and we would try to provide a model of smart contract templates to adopt. For example:
Many projects will be like traditional open source projects in that they are simple voluntary efforts whose participants are not motivated by direct monetary gain. In that case, they could use a simple allocation model based on tiered participation. For example, each contributor would be placed in a tier based on simple metrics (# of commits, tickets handled etc.) or through voting and endorsement mechanisms.
But other projects may need to provide for more immediate and guaranteed compensation more akin to contract work. For those, we envision more complicated allocation models for qualified contributors, with multiple components, such as:
We would like a means to allow projects to securitize token allocations to enable liquidity because these allocations are percentages of an on-going, uncertain token flow, and thus are risky and slow to generate returns.
This can be accomplished outside the platform by allowing participants to assign their allocation contracts to other entities. For example, a commercial entity would have their employees assign their allocation rights developed on the job to their employer. In this way they are providing their contributors with liquidity in the form of a salary.
We could provide an internal mechanism for liquidity by allowing projects to maintain capital accounts of tokens. These accounts could be used, for example, to boost the incoming token flow so that an allocation results in a guaranteed amount of tokens.
These accounts could be capitalized with a per-project investment mechanism where investors supply the tokens in exchange for assignment of the allocation contracts. Or the accounts could be funded internally by having the project allocate a percentage of the incoming token flow to that capital account, thereby providing a mechanism for old work to fund new work. Or the investment could come from other projects, such as a site operator that needs to fund the development of a particular feature.
To reduce the volatility of the value of capital in the form of tokens, investment could take the form of hard currency that is put in an escrow account run by a financial custodian, who uses those funds to buy tokens as needed at the current price (as opposed to buying them upfront).