Proposal: Convert from a system-based rewards model to a voter-based reward model.
The current system determines a reward rate, total supply, and then determines the total reward to give each day by multiplying the (reward rate * the total_supply)/day. The total rewards are then handed out based on each neuron’s share of the total voting weight for the day.
The new system will determine the reward rate and multiply the rate by the weighted vote-completion percentage and bonus rate of each voting neuron.
A result of this proposal will be the reduction in total inflation of ICP due to the fact that some voters do not vote on all proposals or follow a voter for all proposals. The following illustration shows the handing out of rewards in the old vs new system.
Spam is neutralized because additional proposals will not affect the ability of a neuron to gain rewards. Any neuron’s maximum reward for the day is generated by Reward Rate *(Actual Vote Weight/Possible Vote Weight) * Age Bonus. Adding extra, superfluous heavy weighted votes only increases the Possible Vote denominator and thus does not increase the number of rewards handed out in a day.
Weights can remain in the calculations to encourage participation due to the fact that each voter is only competing against themselves to achieve 100% voting for the day.
This scheme can be easily implemented in the existing code by manipulating the distribute_rewards function to iterate over all considered_proposals, finding the weight of each proposal and creating a target sum. Instead of creating a map of voters_to_used_voting_rights, the map will also need to keep track of each vote’s absolute weight. The reward function on ic/governance.rs at 73983e05ebbab239ce39492a05fb39a83ce5dce5 · dfinity/ic · GitHub will need to be adjusted to be used_voting_rights * (total absolute vote weight/target vote weight). The used_voting_rights has the age and lock bonuses built in. (Note - The reward function is mapping twice as much data, so performance may be an issue here).
A worked example:
4 proposals are eligible for rewards on a day. The reward rate is 15%.
Proposal 1 - XDR Exchange Rate - Weight 0.01
Proposal 2 - Subnet management - Weight 1
Proposal 3 - Node Rewards - Weight 1
Proposal 4 - Governance Proposal - Weight 20
Total Possible Vote weight: 22.01.
Voter 1 - Passive whale votes with 10,000 voting reward on proposals 1-3. Total executed weight is 2.01. Thus the reward is 10,000 * (.15/365) *(2.01/22.01 = 0.3752 ICP(~1.3%)
Voter 2 - Active holder votes with 100 voting reward on proposals 1-4. Total executed weight is 22.01. Thus the reward is 100 * (.15/365) *(22.01/22.01 = 0.041 ICP (~15%)
Why Now?
The new exchange rate mechanism(New Exchange Rate Mechanism - #28 by THLO) will make spam much more attractive. We need a quick fix and this is the quickest route to implementation.
A few more notes from the discussion with the community/foundation(h/t to @bjoernek for compiling):
- Proposal: The reward mechanism assumes that everybody votes on all proposals. If you vote on all proposals you get rewards corresponding to your share of voting power compared to the total voting power. You get reduced rewards if you miss votes, but those lost rewards don’t go to active voters.
- Impact on total rewards/inflation: This proposal reduces the rewards which are allocated on a daily basis, depending on how many participants miss votes. This reduces inflation. In a second stage (out of scope of this proposal) we could consider allocating these un-distributed rewards to an NNS treasury.
- Impact on financial incentives: This proposal removes the direct financial incentive to submit spam proposals, i.e., active votes will not gain additional rewards in case of spam proposals. However there is still an indirect financial incentive as the new mechanism reduces the inflation; this creates a benefit for ICP holders (staked/unstaked)
- Impact on reward weights: As this proposal removes the direct financial incentive for spam we could consider to reset the reward weight for governance proposals back to 20.
- Implementation effort: This proposal requires only an update of a few lines of code within the function distribute_rewards in governance.rs. Thus this can be implemented relatively quickly.
- Why bring up this proposal now again?
- In connection with the new exchange rate mechanism we require a quick solution.
- Earlier concerns on the ability to influence the inflation rate (and thus also reduce the predictability of total supply) are much less of an issue now, given that maturity modulation included anyway further uncertainty on this.
- Connection to periodic confirmation of following: We already have an approved motion proposal for spam prevention namely periodic confirmation of followees. However, this still requires some enhancements wrt to the handling of time-sensitive proposals (for which a few ideas are under discussion). Periodic confirmation of followees could still be valuable, even if this proposal is implemented because it strengthens active voting participation.
Personal note: I think putting the inflation into an NNS treasure is a great idea. This gives orgs like ICDevs a place to go to seek funds for specific projects that need to be built and hands control of those decisions to the NNS without as much work required by the foundation. This proposal is a step one toward doing that as it gives us an obvious chunk of value to use. It is also a win/win for the passive staker that may miss votes as the funds are still used for the benefit of the community and could, in theory, a much higher financial impact than liquidating them today. It is hard to find win/win scenarios, but we have one here.