Adjusting SNS voting rewards

Dear SNS communities,

TL;DR. Last year, the NNS implemented spam prevention in the NNS reward calculation. DFINITY is now proposing to align the SNS reward calculation accordingly, as already suggested by community members.

DFINITY is proposing to change how voting rewards for SNS proposals are computed. The change would remove the incentive for creating spam proposals that extract higher voting rewards. Additionally, this would make the SNS voting rewards computation more consistent with the one in NNS.

Background. The SNS DAOs reward neurons who have voted on some proposals within each time period called reward round, which is by default set to 1 day. The rewards are given in the form of maturity increment for the respective neurons. The amount of rewarded maturity for each neuron is determined by SNS Governance’s distribute_rewards function, pro rata of the voting power exercised by a neuron within the reward round.

Proposed change

  • Right now, if a neuron votes on all proposals within a reward round, it gets a share of the daily rewards based on how much voting power was exercised by all neurons of that SNS within the same reward round.
  • With the proposed new design, if a neuron votes on all proposals within a reward round, it would get a share of the daily rewards based on the total voting power available, not just what was exercised.
  • In particular, the reward amounts for a reward round would be the same as they are now if every neuron voted on every proposal.

Metrics. Along with the changes described above, we propose to add new metrics to SNS Governance that show the total amount of available voting rewards and the actual distributed amount of voting rewards computed within the last reward round.

If these changes are adopted by the NNS, all SNS communities that upgrade to the latest version will start following the new voting rewards rules.

Next steps. Please let us know in this thread if you have any concerns. If there are no major concerns, DFINITY will implement this design and propose to publish a new SNS Governance wasm to the NNS-W canister.

3 Likes

Would you please change the category for this forum topic from Developers to Governance and also add an NNS tag? This doesn’t really seem like a developers issue. It seems like an NNS issue because the proposal is to apply a broad change to all SNS projects and that can only happen by an NNS proposal. Am I correct to assume this will first be presented as an NNS Governance Motion proposal and then will only be followed up with a technical change if that Motion passes?

3 Likes

Is this currently a problem on any SNS? I haven’t noticed this problem like what existed for the NNS previously. Do any SNS weight the rewards for Motion proposals to be higher than the other proposal topics? This was one of the root causes of spam for the NNS.

In hind sight, I wish we had not implemented this proposal for the NNS. The spam for the NNS was solved by simply removing the higher weight factor for the Governance proposal topic, which actually happened before the change in reward distribution was implemented. The change in reward distribution was a preemptive change based on a hypothesis that spam would be incentivized when the exchange rate proposal topic went away. We never got to test that hypothesis, so we actually don’t know if the change in reward distribution was actually needed. The reason I regret this change is that it lowered rewards for everyone who was an active participant in NNS governance. I would hate to see the same thing happen for SNS rewards. It just doesn’t seem necessary. If spam is a problem, then there are several other mechanisms that can be used to disincentivize it.

Is it possible for an SNS community to reject this change? If they do, then what happens on the next update? If they adopt any later updates, will it end up implementing this change? If so, then does an SNS actually have the ability to reject this change? Or will they forever be stuck on their current SNS version?

I have concerns and hope that I have explained them well. This change for the NNS was a major change to the incentive structure for the NNS. It resulted in the largest drop in voting rewards we have ever seen for active NNS participants. I’ll admit that I don’t pay too much attention to voting rewards for SNS projects, but I can imagine this proposal would have a similar impact. It seems highly unlikely that SNS project typically see 100% participation on their proposals. Hence, any SNS that offers voting rewards and that also see a lack of voting for a double digit percentage of total voting power will experience a noticeable change to voting rewards for people who are voting. I hope we don’t adopt this broad change to SNS projects as an NNS.

3 Likes

Is this actually a clearly stated and agreed goal somewhere, that voting rewards calculations for every SNS should remain consistent with that of the NNS?

It sounds like something that should be parameterised in the SNS configuration.

2 Likes

Thanks for voicing your concerns, @wpb.

Note this is an ongoing discussion. I thus suggest we refrain from drawing ultimate conclusions for a week, and hear everyone out.

Below, I try to clarify why we’re proposing this change in the first place.

How SNS projects benefit from this change

For context, the proposed change was requests, e.g., when DFINITY asked How to improve the SNS framework? - #9 by megrogan

So of course there are some strong arguments in favor, let me summarize those that I think haven’t yet been made explicit in this thread:

  1. Making voting rewards independent of the number of users who voted makes the rewards more predictable.
  2. This would reduce the SNS token inflation caused by few votes within some reward round.
  3. Consistency between the NNS and SNS generally improves user experience.

Whether we need a motion proposal for this change

Currently, the idea is to collect some feedback from this thread and see if many would doubt the usefulness of this change. The main reason is that the analogous change has been adopted in https://dashboard.internetcomputer.org/proposal/80970 for the NNS.

Most arguments outlined in ReProposal: Spam Prevention - Convert from system-based rewards to voter based rewards (where the corresponding NNS-related discussion took place) hold also for the SNS. (There are some minor differences that do not affect what’s discussed in this thread, e.g., unlike NNS proposals, there is no concept of proposal topics for the SNS, so all SNS proposals are of the same weight when it comes to voting rewards).

Forum topic

This indeed belongs to Governance rather than Development, thanks for pointing that out @wpb !

(Any change to the SNS framework is done via an NNS proposal to publish new SNS canister WASMs; so I don’t think this post should specifically have the “nns” tag.)

1 Like

While it isn’t carved in stone that the SNS design must comply with the NNS design, having conceptually different rules for the two makes the users’ life harder. For example, I’m pretty sure some users do not fully understand the current difference between voting reward computations in NNS and SNS right now.

Some aspects of the SNS rewards are already parameterised on the SNS, which would not change with the proposal discussed in this thread. However, the (in)dependence of voting rewards from the number of voted users, is a design choice that should apply to all SNS and NNS DAOs (IMHO).

2 Likes

Hey @megrogan would you mind expanding on your suggestion here? By the way, I really like all your other suggestions in that post. However, this one doesn’t quite resonate with me yet. Why is it important to have predictability on how much reward each individual neuron will receive?

It is currently very predictable how much total reward is distributed each day. This change would make the overall total reward distribution less predictable because you can’t predict who will vote on each proposal.

I get that this change reduces SNS token inflation, but is there any evidence that there is a large fraction of SNS token maturity that is being dispersed and sold and having a negative effect on token price? OpenChat was the very first SNS token swap and I participated via Neuron Fund. I still have no access to those tokens or maturity even in the neuron that has no dissolve delay. I assume the majority of participants are in a similar situation, but I don’t know for sure. If so, then there is at least a very large fraction of the token holders who cannot access the rewards anyway, which seems to make the inflation argument a moot point.

Do you think the OC community will have a negative reaction when they learn that their voting rewards have gone down if this proposal is implemented? The change seems most likely to be noticed by your most active users of the OC platform, who are also likely to be the most active voters.

Is there currently a spam proposal problem for OC that you think is driven by this reward distribution calculation? I haven’t noticed it…at least not of the same type and scale that we had to endure on the NNS. However, the change to the reward distribution calculation (the denominator in the equation in your post), was not the actual solution to spam for the NNS. The solution was to remove the high weight factor for the Governance topic, which happened before the reward distribution formula was changed. I didn’t see spam as a justification for this change in your post, so perhaps this was added by @aterga or someone else at DFINITY as a potential reason that this change might be important for the SNS framework. It would be helpful to know if you think the spam argument is a valid part of the justification from the OC perspective.

I see how the calculation is analogous, but I don’t see how the arguments that justify the change for the NNS are also applicable to an SNS. Proposal 80970 explicitly says…

Why Now?
The new exchange rate mechanism will make spam much more attractive. We need a quick fix and this is the quickest route to implementation.

and

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.

…these were the arguments that justified the change for the NNS and neither apply to an SNS. As far as I know, there is not a spam problem with any SNS and they don’t have a proposal topic weighting mechanism. The Exchange Rate proposal topic also doesn’t exist for any SNS. The spam problem for the NNS was resolved the moment that the Governance proposal topic weight was reduced from 20 to 1. That happened immediately after a global hackathon hosted by DFINITY that attracted a lot of new people to ICP who started asking questions about all the spam they were seeing. It was an embarrassment to DFINITY and to the entire ICP community, so DFINITY acted quickly to reduce the proposal topic weight factor for Governance topics. The concern about spam only resurfaced in the context of the exchange rate proposal changes and that concern was only a hypothesis that was never tested. In fact, if we don’t have an SNS spam problem AND there is no exchange rate equivalent proposal for an SNS that drives a guarantees daily reward, then this is likely strong evidence that disproves the hypothesis. Regardless, DFINITY was strongly behind that change at the time (again because it came on the heels of the spam embarrassment), so there was no point in trying to resist the change. Instead, the change offered an opportunity to consider an NNS treasury that could be used to help incentivize the long term decentralization of the NNS.

A result of this proposal will be a reduction in total minted ICP due to the fact that some voters do not vote on all proposals or follow a voter for all proposals. In a follow-on proposal, the NNS can determine what to do with that “abandoned” ICP. We suggest an NNS treasury but will leave it to a future proposal to finalize that.

That treasury never happened due to pushback from the community. Voting rewards drastically changed for active voting members of the NNS and many people were not happy. I think that was a primary reason why the community had a negative reaction to the treasury idea even though it offered one of the best potential opportunities to achieve the commonly held goal of true NNS decentralization. There are a lot of nuanced details and opinions tied up in all this history for this NNS change.

Anyway, I don’t really see the value of implementing this proposal in the context of SNS projects. The potential cons seem to outweigh the potential pros and there are some learning experiences from the NNS example that should be considered before applying it to SNS projects. The arguments that justified the change for the NNS don’t seem to be applicable to the SNS framework, so it seems unnecessary to implement this change.

Can we consider reverting the NNS change instead of forcing a new SNS change? I think we have evidence that the change was never needed as a spam prevention mechanism for the NNS.

1 Like

I’m concerned that this policy creates a negative feedback loop in regards to voter participation. If the number of non-voting neurons increases, the rewards given to the few voting participants leftover is reduced. Basically, the behavior of non-voters (on the margin) reduces the incentive of active voters. It should be the other way around.

If few people vote, then those few should receive a greater share of the reward. This way, the incentive for voting increases as voting decreases (which inspires more voting). It’s a positive feedback mechanism, rather than a negative one.

I think spam reduction and inflation should be addressed separately; especially since inflation can be adjusted directly by modifying interest rates. Let’s try to minimize unintended consequences and craft policies that directly target the specific problem.

2 Likes

I agree with Epic here.

2 Likes

This can also potentially be weaponized. Someone can create a large neuron and refrain from voting; which will cause active voting neurons to earn smaller rewards (by increasing the denominator).

1 Like

It also creates a number of unintended consequences:

  1. The reward allocation turns into a reward ceiling rather than an allocation. This makes it difficult to predict and advertise the protocol interest rate.

  2. As ICP grows it takes on larger and larger waves of inexperienced users. These users may not configure their neurons to vote, which can cause steep decreases in the voting/non-voting ratio; which then reduces every voter’s rewards by increasing the denominator.

  3. This achieves a level of deflation at the expense of voting incentive. It would be better to simply modify the total reward allocation, and keep the voting incentive as is (so that as voting decreases, voter reward increases).

3 Likes

I don’t see a problem with it. I think the NNS and the SNS should be in tune.

I agree that the rules should be applied consistently. The points I am making apply to the original proposal, and I think those changes should be revisited. I would suggest a proposal that reverses the voting incentive changes, and simultaneously lowers the total rewards. This way we can achieve a precise measure of deflation while continuing to incentivize voting whenever voter participation falls.

2 Likes

OpenChat barely gets any proposals you would consider spam so this point is not particularly relevant for us.

The main point for us is that it reduces token inflation. Whether or not the maturity has been disbursed yet doesn’t really matter - at some point it will be and so the inflation is inevitable.

As an example there are many occasions when the dev team deliberately abstains from voting. Most CHAT neuron holders follow the dev team neuron and so currently the few neurons that do vote manually get massive voting rewards. This is both unfair and unduly (in our opinion) increases inflation. I would say most of our neuron holders would prefer less token inflation.

A secondary but also important point is that for a given neuron the rewards it will earn if it votes are predicatable. The NNS dapp will be able to inform the neuron holders of the rewards they can expect.

I can understand that other SNSs might take a different view. In which case it would be better if both the old and new scheme were implemented and SNSs could opt in to the new scheme by proposal. This of course makes the code more complicated so I can understand why DFINITY might be reluctant to go that route.

5 Likes

I vote yes on these proposed changes.

In addition to the two reasons mentioned by @megrogan, the main reason for me is that right now there is a monetary incentive for a neuron-holder to try to have the least amount of other people vote as possible.

For a simple case, let’s say a neuron-holder knows about an ongoing proposal that most other neuron holders don’t know about. The way it is right now, the neuron-holder has a monetary incentive to not tell others about the ongoing proposal, which is bad for governance dynamics, and can get in the way of the neuron-holder’s natural want to talk about the ongoing proposal with others.

It can also cause bad dynamics with popular neurons (that many people follow), where right now the popular-neuron-holders have an incentive to not vote with their popular neuron on some proposals so that their followers don’t vote, and then the popular-neuron-holder can vote with his/her own private neurons to get the maximized rewards.

The proposed changes take away that bad incentive, so that the natural governance communications and conversations and votes can take place without the possibility of some neuron holders getting distracted by the chance for higher rewards.

4 Likes

Why would others not know about it? Given the proposal would be displayed with all the other proposals on the NNS frontend.

You can follow a quorum of neurons instead of only one to mitigate that risk.

In my view, the proposal introduces bad incentives, it would mean community members active in the governance are rewarded only up to their voting power value. However given they went the extra step and voted I believe they should be eligible for the possible share of community members that did not vote. Yes, there would be inflation, but it would not affect active voters.

If a DAO wants less inflation they can change their governance parameters instead.

If this happens in a DAO, this proposal would then only fix the symptom and not the disease.

4 Likes

Thank you for offering clarification on your suggestion. It helps a lot.

Would you mind explaining why the OC team believes this is unfair for voters to receive higher rewards when others including the OC team do not vote? Isn’t that an incentive for more people to vote? It seems like that problem should be more publicly advertised to bring awareness to the opportunity for community members, which seems like it would attract more active voting. I tend to agree with the arguments made by @EpicICP in this thread that allowing active voters to receive those higher rewards incentivizes more active participation and changing the formula so there is a cap on those rewards is a disincentive for active participation. Perhaps OC could sponsor a lot of bounties through MoonShift (or something else) to motivate the community to raise awareness of the discrepancies in voting participation so you don’t see as big of a gap. To me, this problem should be solved with education, not a change to the reward distribution calculation. I hold that opinion for both the NNS and SNS. It seems like there should be an incentive for community members to receive higher rewards for their active participation, even if it is just educating themselves on the rules and following others who help ensure they maximize voting rewards, AND the NNS and the SNSs should be doing more to ensure that the community is educated about the mechanisms by which they can maximize those rewards for themselves.

Also, if inflation is the reason for this change, then it seems much cleaner to simply reduce the overall reward allotment. That way you don’t negatively impact the incentives for active participation as described above.

The NNS dApp could always be configured to display the actual APY that each individual neuron is earning because is has access to that information for each individual user. This could be done today without any changes to the reward distribution calculation. In fact, the governance canister could calculate some statistics to determine the average, median, stdev, min, max, etc. across all neurons based on actual returns without revealing any private information. Then the dashboard, NNS dApp, etc could present this data to users as a more accurate representation of what voting neurons are actually receiving.

Short of that, the dashboard has always handled the presentation of voting rewards by calculating reward rates based on an assumption that all neurons always vote. It’s currently the best way to present a consistent estimation of rewards and it should always be accompanied by an explanation of the assumptions.

When the rewards are distributed based on voting participation instead of total voting power in the NNS or SNS AND there is a lack of participation in voting by a significant number of neurons, then the active participants will always receive more rewards than those quoted numbers. That is motivating to many community members. When we change the reward distribution calculation so the denominator is based on total voting power, then those estimates become a max cap on what someone can earn. I think that is demotivating.

The solution to the fairness problem in my mind is better education and promoting an awareness of the opportunity for increased rewards. It’s a great opportunity to incentivize the community to spread that awareness by offering them additional incentives to do so.

2 Likes

This is good incentives. Active people get rewards and inactive don’t. This is a good incentive for people to pay attention.

3 Likes

Yes it makes sense to have a mechanism to reward active participation over manual participation but it seems to me this is a side-effect of the current reward system rather than by design. For instance when the OC team does vote on a proposal the manual voters don’t get any extra reward. I would prefer to see the reward algorithm designed explicitly to reward active participation rather than as a side-effect of the current system. Also see the point made by @levi.

Regarding the NNS showing the reward for a neuron, this would be a simple formula in the case of the proposed algorithm vs a statisitical analysis of all the data to derive the expected rewards.

1 Like

Thanks everyone for providing good arguments, both in favor and against the proposed change.

We’ve decided not to proceed with this proposal.

Of course, there might be other proposals, e.g., for making voting rewards more coherent in NNS and SNS, stay tuned.

6 Likes