Adjusting SNS voting rewards

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