Open Governance canister for SNS | Design proposal

Roadmap
36

Hi all,

I recently joined the Dfinity research team with a particular focus on governance & tokenomics and I am very much looking forward to working with the community! To start the collaboration, please find below a design proposal for a simple SNS reward scheme.

Summary of the proposal

  • Following the overall strategy to deliver SNS functionality in stages, we plan to introduce a first simple scheme for SNS rewards. The proposal covers voting rewards and usage rewards.
  • To facilitate a timely delivery, we suggest leveraging the concepts and code base of the NNS reward scheme.
  • A SNS will have the flexibility to configure the reward scheme to a broad set of use cases.

Community conversation & Timeline

To get the design approved by the community, we propose the following schedule:

  • April 25th - May 3rd: Design discussion on this forum thread
  • May 3rd: Community conversation about the topic
  • Afterwards initiate the implementation of the design, including potential feedback from the community.
  • We consider this design as a concrete, detailed suggestion on how to realize parts of the larger design adopted in December 2021. Therefore, we propose not to submit a separate motion proposal and rather discuss it in the forum here and in the community conversation.

Looking forward to hearing your inputs on this!

Björn

Details of the proposal

Objective

  • We provide a draft design for a Service nervous system (SNS) reward scheme.
  • We consider two categories of rewards
    • Voting rewards to incentivize users to take part in SNS governance.
    • Usage rewards to incentivize users to become early adopters and active users of the SNS.
  • In this design we focus mainly on voting rewards, which enables a SNS to run a truly decentralized set-up. For usage rewards we provide a generic design only, assuming that the precise mechanism of usage rewards will have to be tailored to the individual SNS.

Background & context with other projects

Linkage to overall strategy

  • As outlined in the motion Long Term R&D: 3-year Plan Dapp Governance, the overall strategy is to release SNS features in phases, allowing for a step-by-step adoption by the community.
  • Following this strategy, we plan to introduce a first simple scheme for SNS rewards. Based on the collected experience from developers and the community, this can be enhanced in future phases.
  • We suggest using a reward scheme that is based on the voting rewards used in the Network nervous system (NNS) of the Internet Computer, which however can be flexibly configured by each SNS. This approach has the following advantages
    • The community is already familiar with key concepts of the NNS.
    • We can leverage the existing code base of the NNS facilitating the initial release.
  • We are conscious of the fact that a SNS might require only a subset of the NNS voting features. Therefore, we suggest that the SNSs will have the flexibility to configure the reward scheme to a broad set of use cases, including the ability to disable certain elements.
  • In general, rewards can be paid out by newly minted tokens or by tokens from the initial supply, which has implications for the tokenomics of the system, in particular the inflation. In the proposed design for SNS voting rewards we focus on the former approach, while also explaining how the according inflation can be limited. Alternatives are considered at the end of the proposal.

Recap on NNS voting rewards

Overall idea: Within the NNS, voting rewards are paid out daily, based on an overall reward pool. Each neuron receives a pro-rata amount of that pool according to the voting power with which the neuron voted and in how many proposals the neuron participated.

Detailed description:

  • Determination of the total reward pool

    • For a time t between G (genesis time) and G + 8y the annualized reward as a percentage of total supply is R(t) = 5% + 5% [ (G + 8y – t) / 8y ]²
    • For a time t after G+8y, we have R(t) = 5%.
    • The total pool of voting rewards for a given day is calculated as ICP supply (total supply of ICP tokens on that day) * R(t) / 365.25.

  • Voting power of neurons

    • Only neurons with a dissolve delay of more than 6 months are eligible for voting. The maximum dissolve delay is 8 years.
    • The voting power of a neuron is computed as neuron_stake * dissolve_delay_bonus * age_bonus
    • In particular the dissolve delay bonus and the age bonus are cumulative.
    • The dissolve delay bonus is a value between 1 and 2 and a linear function of the dissolve delay (capped at eight years).
    • The age bonus is a value between 1 and 2 and a linear function of the age of the neuron (capped at four years). A neuron starts aging when it enters a locked state.

  • Allocation of reward pool to neurons

    • The reward pool is allocated in proportion to the voting power of proposals that are settled on this day, i.e.
      • Determine the set of proposals that are included in this reward period (a day): these are the proposals that are not yet settled with respect to voting rewards, and no longer open for voting.
      • The total voting power of neurons contributing to these proposals is added up.
      • Each neuron is rewarded in proportion to the voting power it contributed to these proposals.
    • When a neuron is rewarded for voting, these rewards are recorded in an attribute of the neuron that is called maturity. Maturity expresses that a neuron has a claim on a given amount of governance tokens, which are however not yet minted.

  • Neuron management with respect to rewards

    • In the current NNS set-up the following neuron management operations exist: merge maturity, spawn maturity and exchange maturity.
    • Please note: The NNS neuron management will be enhanced as described in the following Motion proposal on compounding maturity.
    • To keep the SNS scheme simple at start, this enhancement is currently not planned for the first phase of the SNS. Depending on community feedback this can be added later.

Proposed design for SNS rewards

Voting rewards

Overall idea: As highlighted in the background section, we intend to leverage the NNS voting reward scheme and allow for flexibility to configure the scheme. In particular, we suggest that a SNS has the ability

  • to influence the shape of the reward function.
  • to configure the various parameters driving the voting power of neurons.

Detailed description:

  • Determination of the total reward pool
    • A SNS can influence the shape of the reward function, by configuring the start point rmax, the end point rmin and the transition length tdelta.
    • In particular, for a time t between tstart and tstart+tdelta the annualized reward as a percentage of total supply is R(t) = rmin+ (rmax-rmin) [ (tstart+ tdelta – t) / tdelta ]²
    • For a time t after tstart+tdelta, we have R(t) = rmin
    • For the special case rmax = rmin the reward function is constant, namely R(t)=rmin
    • The total pool of voting rewards for a given day is calculated as SNS supply (total supply of SNS tokens) * R(t) / 365.25.
    • Rewards will also be calculated and distributed for days where no voting took place. Enhancing the mechanism (e.g. accrue the rewards on days without voting) are considered too complex for a short-term delivery. This could be adjusted & fine-tuned in a later stage.
    • Voting rewards are minted, i.e. generating new supply. In case that the SNS would like to stop a token supply increase after tstart+tdelta the SNS should set rmin=0.
  • Voting power of neurons
    • Dissolve delay
      • The SNS has the ability to configure the minimum & maximum dissolve delay and minimum & maximum dissolve delay bonus.
      • The special maximum dissolve delay bonus = 1 results in no dissolve delay bonus.
    • Age
      • The SNS has the ability to configure minimum & maximum age and minimum & maximum age bonus.
      • The special case maximum age bonus = 1 results in no age bonus.
  • Allocation of reward pool
    • The reward pool is allocated in proportion to the voting power of proposals that are settled on this day (same as for the NNS).
  • Neuron management with respect to rewards
    • To keep the set-up simple in the first phase only the following functionality will be available
      • Disburse maturity which directly mints & disburses the maturity-equivalent of tokens into an account.
      • Merge maturity which adds the maturity accrual directly to the staked token amount.
    • In a later phase, additional functionality can be added.
  • There should be a flag which activates the calculation and distribution of voting rewards, as a SNS might choose to go through a ramp-up period without voting rewards, or with no voting rewards at all.

Usage rewards

  • The purpose of usage rewards is to foster early adoption and active usage of the SNS. Given that the meaning of usage and the according usage rewards can vary greatly across individual SNSs we suggest a very simple set-up at start.
  • In particular, we suggest that some tokens (reserved for usage rewards) can be held in an account that is controlled by a canister. This canister can then codify when the rewards are paid out and to whom.
  • This solution allows paying out existing (non-minted) tokens. If it is required that usage rewards trigger minting, this could be added in a later phase.
  • Also, in case that common characteristics/metrics for usage rewards are established over time, this can be integrated into the SNS reward scheme, depending on the feedback of the community.

Security

The reward function influences the token supply and minting and thus is security relevant. Therefore, we plan that both the design and implementation will be reviewed by DFINITY’s security team.

Alternatives considered

  • Alternative 1: Very simple set-up
    • Voting power is allocated according to the quantity of SNS tokens. No staking and minimum looking period, no voting rewards.
    • Advantage: This set-up is easy to understand and easy to implement.
    • Disadvantage: This set-up might be desirable for some SNS teams, however might not be flexible enough for others. Also the Long Term R&D: 3-year Plan Dapp Governance clearly articulates the visions to allow staking and rewards for SNSs.
    • The proposed approach described above can be configured to Alternative 1 by choosing an appropriate configuration, while allowing at the same time a solution which is aligned with the long term plan.
  • Alternative 2: Even more flexible
    • Allow for further flexibility in the determination of voting power and allocation. For example, allow other kinds of reward functions R(t).
    • Advantage: Further flexibility for SNS teams to come up with their own solutions.
    • Disadvantages: Additional implementation complexity. Difficult to judge at this stage what additional flexibility is really required for a first version.
    • Given that the need for further flexibility is currently unclear, it is suggested to use the current proposal for the first phase. If the need for further flexibility arises, this can be included in a second phase.
  • Limiting inflation
    • As described above, a SNS can limit or eliminate token supply inflation by choosing an appropriate configuration of the reward function R(t).
    • As an alternative, instead of newly minting voting rewards (which are determined as a percentage of total supply), one could also define a dedicated pool for voting rewards whose size decreases over time.
    • Given that it is possible to eliminate token inflation in the proposed set-up, this alternative is not considered to be required for the first phase.
9 Likes