Constantinople Token Model

Background

Read #119.

Model

There are two major features of this token model, they are introduced in the next two sections.

Fiat backed testnet tokens

Jsgenesis will maintain a pool of USD funds, called the reward pool, denoted by REWARD_POOL (USD), for which testnet tokens (tJOY) can be redeemed at any given time. The size of the pool will not only always be publicly known, but also the dynamics surrounding how it will be changed during the network lifetime will be known in advance. Additionally, the current circulating supply of testnet tokens will always be known, and the dynamics for how minting and burning will occur will also be known in advance. Based on the current reward pool and circulating supply, denoted by CIRCULATING_SUPPLY (tJOY), there will be an implied redemption price for testnet tokens. The initial value for CIRCULATING_SUPPLY is denoted by INITIAL_CIRCULATING_SUPPLY. Redemption involves a holder burning testnet tokens in exchange for funds from Jsgenesis, transmitted via Bitcoin payments to the desired address of the redeemer.

Performance-based reward

A set of Key Performance Indicators (KPIs), with associated evaluation criteria and value, are publicly known. Each has a pre-specified USD budget, called a KPI budget, which is an upper bound for how big of a reward can be unlocked over the given period, depending on the performance of the network in that period w.r.t. given KPI. Based on the evaluation and the available bounty, an actual payout quantity, called the KPI reward, is determined. The value is released by increasing the reward pool with the earned reward.

Reward Pool Replenishment

The reward pool serves as a source of value to finance the costly expenditures incurred by network actors over time. In order to make sure that there is sufficient value to operate the network, there will be periodic replenishment of the reward pool. Jsgenesis will as a first approach add a fixed increment, called the weekly reward pool top up, denoted WEEKLY_REWARD_POOL_TOP_UP, to the reward pool. The initial value of the pool, called the initial reward pool balance, is denoted by INITIAL_REWARD_POOL.

Membership Faucet

For people to get started and use the system in any way, beyond simple transfers, they will need to create a membership. Beyond this, to use the membership, for on the forum or applying to some role, they need sufficient balance to finance the transaction fees. A faucet, called the membership creation faucet, will allow users to get such a sufficient base tJOY balance, called the faucet membership balance, denoted by FAUCET_MEMBERSHIP_BALANCE, in the process of creating a membership. Any memberships transferred from Rome to Constantinople will also have at least this balance. There will not be a need to adjust this balance over time, as its only meant to cover these costs which are fixed in tJOY. The faucet will finance these by minting new tokens on demand.

Gated Faucets

The membership creation faucet is sufficient to get people started, however, for people to have access to staked roles, much larger quantities of tJOY will be required, and these tJOY quantities may change over the life of the network, as the council possibly makes updates to account for inflation and other concerns. Unlike the membership faucet, these tokens cannot be provided without any friction, as they would lead to Sybil attacks and concentration in the participant base. Therefore, there will be a variety of mechanisms available for the determined participant to get tokens for this purpose. The value offered in each faucet will be adjusted over time by Jsgenesis team, and the payouts will not debate tJOY holders, instead, the new tJOY minted will see a corresponding adjustment to the reward pool.

Value Flows

The described value flows can be summarised in the following figure.

KPIs

Each KPI is defined by a value for each of the following properties

• Measurement period: The interval over which performance is evaluated and possible rewards are made. In Constantinople, all events have the same period.

• Success event: An event with clearly defined identification criteria, which will generate a reward. Should ideally be publicly verifiable, but in some cases Jsgenesis judgment is unavoidable. The number of such events for the i'th indicator in a given measurement period is denoted by KPI_NUM_SUCCESS_EVENTS_i. For each such event a score is assigned that captures how successful the event was. Let KPI_SUCCESS_EVENT_SCORE_{i,j} be a value in the interval [0,1] and denote the score of the j'th such event for the i'th indicator, over the given measurement period. Indicators, where it is possible for this sore to be less than 1, are called indicators with graduated scoring, otherwise, they are indicators with binary scoring.

• Unit reward: An event-based reward earned per successful event in the measurement period. The unit reward of the i'th indicator in a given measurement period is denoted by KPI_UNIT_REWARD_i. A reward need not be defined for an indicator, in which case KPI_NUM_SUCCESS_EVENTS_i = 0 in all formulas that follow.

• Failure event: Analogous to success event.

• Unit penalty: Analogous of the unit reward.

• Budget: The KPI budget, where the budget for the i'th indicator in a given measurement period is denoted byThe budget of the i'th indicator is denoted by KPI_BUDGET_i.

• Annihilation: A condition, which if satisfied, it is as if KPI_NUM_SUCCESS_EVENTS_i = 0 in all formulas that follow. Let KPI_ANNIHILATION_i denote whether the condition was satisfied for the i'th indicator in a given measurement period.

• Sanction: A condition, which if satisfied, imposes some percentage penalty, denoted by KPI_PENALTY_PERCENTAGE_i for the i'th indicator, on the current reward pool.

Given this structure, the new value for the reward pool at the end of the measurement period for the i'th indicator

REWARD_POOL + min(max(REWARD_REVENUE_i - REWARD_COST_i, 0), KPI_BUDGET_i)

when the sanction condition was not satisfied, where

REWARD_REVENUE_i = KPI_UNIT_REWARD_i*\sum_{j=0}^{KPI_NUM_SUCCESS_EVENTS_i} KPI_SUCCESS_EVENT_SCORE_{i,j}

and

REWARD_COST_i = KPI_UNIT_PENALTY_i*\sum_{j=0}^{KPI_NUM_FAILURE_EVENTS_i} KPI_FAILURE_EVENT_SCORE_{i,j}

When the sanction condition is however satisfied, the new value is instead

REWARD_POOL*(1 - KPI_PENALTY_PERCENTAGE_i/100)

Constantinople KPI List

Here the specific KPIs for Constantinople are described, however actual values for the KPI properties are not yet determined. Notice that in some cases, the start of the measurement period is itself the success scenario, with the full budget as the unit reward. These indicators are meant to capture indicators where we only want to penalize failure of some availability requirements.

1. Runtime Upgrade

The proposal system will have a proposal type for upgrading the runtime, which only Jsgenesis can invoke.

• Measurement period: Council period.

• Success event: Council accepts a valid runtime upgrade proposal, originating from a designated Jsgenesis proposer membership, no later than a certain number of blocks after submission. The validity of the proposal depends on whether the WASM hash matches a the hash of the output of the build process for a git commit referenced in the proposal. Hence the councilors will have to build the runtime to confirm the runtime proposal integrity. Scoring is binary.

• Unit reward: TBD.

• Failure event: None.

• Unit penalty: None.

• Budget: TBD.

• Annihilation: None.

• Sanction: If a runtime upgrade proposal form any other source is accepted, or an invalid proposal is accepted. Penalty percentage is TBD..

2. Attract, Fund and Complete Projects

The network will have a proposal type which allows for minting tokens for some stated purpose. There is a tJOY denominated upper bound to the number of tokens that can be minted for this purpose over a given period of time.

Question: Should we give some suggestion projects?

• Measurement period: Council period.

• Success event: Jsgenesis accepts project as completed according the following criteria:

  1. Proposal admits to funding proposal document provided by Jsgenesis, and in some technical, social or community or other way advances the development of the Joystream platform.
  2. Must have been signaled completed within no more than 10% overrun in US business days from stated final deadline in initial proposal, unless a new arrangement has been reached with Jsgenesis at a time no later than 5 US business days before the deadline, due to extenuating circumstances. Completion is signaled by posting a summary, with relevant resources required to examine the result, to Joystream forums, and alerting Jsgenesis staff.
  3. Is judged by Jsgenesis to be a success based on the original funding proposal and delivered result. Scoring is graduated.

• Unit reward: TBD.

• Failure event: A proposal is accepted by the council, despite not satisfying the first point in the criteria above for being a success event.

• Unit penalty: TBD.

• Budget: TBD.

• Annihilation: None.

• Sanction: If a proposal is accepted that violates the funding guidelines provided by Jsgenesis.

Notice here that the proposal may have been submitted during the tenure of an entirely different council from the one in session when the project is signaled completed, and the reward may be released into the reward pool.

3. Publish Content

• Measurement period: Council period.

• Success event: A properly licensed public domain video, with accurate metadata, is published in the content directory. Jsgenesis staff is notified with the link. Scoring is binary.

• Unit reward: TBD.

• Failure event: None.

• Unit penalty: None.

• Budget: TBD.

• Annihilation: None.

• Sanction: None.

4. Curate Content

• Measurement period: Council period.

• Success event: The start of a council period is itself the success event. Scoring is binary.

• Unit reward: The full budget.

• Failure event: Any video uploaded with missing or inappropriate licensing, or otherwise clearly disruptive, which remains uncensored by curators for more than 48 hours after publishing. Here there will be active testing by Jsgenesis staff, in uploading clearly disruptive content. Scoring is binary.

• Unit penalty: TBD.

• Budget: TBD.

• Annihilation: None.

• Sanction: None.

5. Storage Benchmark

• Measurement period: Council period.

• Success event: The start of a council period is itself the success event. Scoring is binary.

• Unit reward: The full budget

• Failure event: An automated Jsgenesis test of download and upload functionality, which may be applied at any time without warning, where performance is below some stated profile. Scoring is graduated.

• Unit penalty: TBD.

• Budget: TBD.

• Annihilation: None.

• Sanction: None.

6. Block production consistency

• Measurement period: Council period.

• Success event: The start of a council period is itself the success event. Scoring is binary.

• Unit reward: The full budget.

• Failure event: An automated Jsgenesis load test on validators causes the rate of block production to fall below some stated limit over some given period of time. Scoring is binary.

• Unit penalty: TBD.

• Budget: TBD.

• Annihilation: None.

• Sanction: None.

Gated Faucets List

Here is a list of mechanisms which will be available.

Bounties

A list of bounties, of both technical and non-technical nature, which have an associated tJOY value, and which can be reserved and undertaken by members.

Mailing List

Airdrop to role mailinglist, if not main mailinglist.

Existing Memberships

Airdrop to existing memberships.

Spend to Charity

Prove you spend some amount on charity, in crypto.

Variables

Here is a list of all variables that require a value.

Policy Variables

These are set by Jsgenesis.

• INITIAL_REWARD_POOL

• INITIAL_CIRCULATING_SUPPLY

• WEEKLY_REWARD_POOL_TOP_UP

• KPI_BOUNTY

• FAUCET_MEMBERSHIP_BALANCE

• Values for gated faucet parameters.

• Values for all KPIs parameters.

Runtime Parameters

These are set by Jsgenesis via the runtime upgrade and subsequent SUDO operations. Also, any parameter marked with a (P) needs to be updatable via the proposal system.

• COUNCIL_PERIOD_LENGHT: Council period length.

• COUNCIL_ELECTION_POOL_SIZE: Council election pool size.

• COUNCIL_ELECTION_STAKING_LIMIT: Council election staking limit.

• COUNCIL_SIZE: Council size.

• COUNCIL_MEMBER_REWARD: Council member reward.

• VALIDATOR_COUNT(P):  Validator count.

• VALIDATOR_BAES_REWARD(P): Validator base reward.

• STORAGE_PROVIDER_COUNT(P): Storage provider count.

• STORAGE_PROVIDER_REWARD(P): Storage provider reward.

• STORAGE_PROVIDER_STAKING_LIMIT(P): Storage provider staking limit.

• CONTENT_CURATOR_REWARD(P): Content Curator reward.

• CONTENT_CURATOR_STAKING_LIMIT(P): Content Curator staking limit.