NOTE: OBSOLETE

Token Allocation

At the beginning of the subscription period the subscription fee is converted to CommonCents tokens using the current market price of a token. At the end of the subscription period those tokens are allocated to the cloud providers and site operators of the apps and services that the user utilized, directly and indirectly, with the split between the cloud provider and the app and service operators on dependent on resource consumption and the type of service.

A fixed percent is also allocated to a general fund for shared infrastructure management and development.

A portion of operator’s share is allocated to the developer projects that created the source code upon which the operator’s apps depends on (and also possibly to users that are authors of the data it depends on) – there are system-wide default percentages for different types of projects but operators and projects can negotiate different allocation terms directly. The developer project dependencies is determined by following the code dependencies between developer projects, starting with the ones the app explicitly utilized. As a consequence, when code from one project is reused in another project, allocation rights associated with each author’s contributions are preserved (because the original project would still be treated as a dependency by the app utilizing the derived project).

After tokens are allocated to a project, it is up to each project to choose what rules to follow to distribute these to its members and contributors. Just like the upstream allocations they are implemented as smart contracts. These smarts contracts can also be used to funding mechanism for individual projects. For more details see Allocation.

Determining how to measure and value contributions is fundamentally a hard problem. Ultimately, the value will be market-based, driven be the needs of the site and platform operators. rules to prevent free-riders: if one operator grants special allocation rights than all operators need to follow them. (hmm… this could encourage highly custom code that others wouldn’t want to reuse…)

Project Income flow and capitalization

How Tokens are Distributed to Contributors

Each project chooses how a token received by the project is distributed and these rules implemented as smart contracts. These smart contracts can encode wide variety of rules, such as:

• Support assigning a contributor’s allocation to another owner so there is an investment mechanism for that capital.
• Treat allocations like shares that dilutes the other allocations as more shares are created.
• Allocations that terminate when it maxes out at some total. This enables fixed sized payments if the token flow is guaranteed (e.g. through the capital account described below).
• Recursive contracts that allocate shares to another allocation contract instead of an owner. This enables functionality such as a milestone that divvies up its work into allocations and those milestone are allocated amongst themselves. An even more sophisticated contract could have each milestone’s share get smaller as they age (beyond the dilution).

Allocation models

Different type of projects need different approaches to token distribution and we would try to provide model 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 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:

• A baseline allocation for participation that is earned immediately and is measured by effort (not results).
• An upside allocation that is based on real-world criteria measured upon completion or later after its value becomes clearer (e.g. based on success metrics, milestones and schedule, etc).

Capitalization

There needs to be a way to securitize these allocations to enable liquidity because allocations are percentages of an on-going, uncertain token flow; and thus are risky and slow to generate returns.

Most simply this can be accomplished outside the platform by allowing participates to assign their allocation contracts to other entities. Most commonly, a commercial entity would have employees assign their allocation rights developed on the job to their employer. In this way they are providing their contributors liquidity in the form of a salary.

An internal mechanism for liquidity is provided by allowing projects to maintain capital accounts of tokens that are used to boost the incoming token flow so that an allocation results in a guaranteed amount of tokens. This could be applied in many ways, for example only to certain baseline allocations.

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 allocated 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 instead be hard currency that is put in an escrow account run by the financial custodian, which uses those funds to buy tokens as needed at the current price (as opposed to buying them upfront).

Investment Capital

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.