Right. What I meant is that we will use the “standard” that is defined by the current ledger implementation. I don’t think this standard has a name in the sense of ERC20, but it does implicitly define how a token is defined and what APIs are available for a token that uses this ledger implementation. In that sense it defines a standard and we intent to use this one.
Infinityswap has informed us that they will support the native ledger from the beginning.(this may have changed, but I don’t think it has cc: @Maxfinity )
This standard thing has become a real pain in the ass and I wish everyone(including dfinity) would lean into interface namespacing(Proposal to Adopt the Namespaced Interfaces Pattern as a Best Practice for IC Developers) before the problem gets even bigger and we have a real problem on our hands. The groups who have defined the standards and who haven’t properly Namespaced their functions are really holding back the ability for DiFi and service composability to move forward. It isn’t their fault as this is an entirely new space where everyone shares the same function naming universe. It’s a whole new problem and we really need to solve it.
DIP20, EXT, and the NNS ledger all need to have namespace functions added to them so that we can all move forward and retro fit as we move forward. There is nothing keeping anyone from implementing both transfer and transfer_dip20 to their existing canisters. The one case where this becomes an issue is when we have blackholed canisters with no upgrade path. As far as I know, that number is currently small. Once it gets big we won’t be able to go backward.
Origyn will be releasing some stuff in the future and the one thing that has kept it moving is that DIP721 was namespace. As a result, Origyn will support both EXT(which needs namespacing added) and DIP721 as well as the enhancements that are added to the standards stoup. Every single one of the proposed functions will be namespaced.
a brief end-of-the week update & introduction:
As described in this forum post, we plan to work on a first simple version of a reward scheme for the SNSs.
The design efforts are lead by @bjoernek, who is currently finalising a concrete design proposal that he will share on this thread next week. We also plan a community conversation about this in the coming weeks and will share the date of it as soon as it is confirmed.
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!
Details of the proposal
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
Hi all, as a short update to the above post on SNS rewards: To align better with the timing of the several Supernova hackathons, we are currently looking into finding an alternative slot in May for the community conversation on SNS rewards. I will confirm once this is clear.
I wonder if it even makes sense to have a reward pool.
For example, what if inflation is dynamic? In other words, the number of tokens minted as rewards is proportional to the number of proposals created. Tokens can be minted at proposal decision time (instead of upfront), and voters can be rewarded with these newly minted tokens.
That way, no tokens need to be minted on days where no voting took place.
It can be refined, so that there is a cap on the number of tokens minted in a day, a minimum threshold of votes on a proposal for there to be rewards, etc…
I believe this model doesn’t work for NNS, given that node providers are rewarded based on their uptime, which is continuous and not discrete. For discrete events like voting on a proposal, I think a dynamic inflation scheme may make more sense to prevent superfluous inflation.
If we make the rewards dependent on whether a proposal is submitted or not then you create an incentive to submit spam proposals.
Right, I think this could be addressed in a similar way that spam proposals are addressed now, e.g. with a proposer stake that gets forfeited if the proposal gets rejected, a minimum threshold for proposals to pass, etc. The rewards would be minted at the very end of voting, not when the proposal is submitted.
The proposed design could definitely be enhanced further. The current proposal was based on the goal of delivering something practical quickly (and thus leveraging as much as possible from the NNS).
Makes total sense, looking forward to seeing how it turns out!