Community Discussion: Revise Governance Voting Rewards to Fix Proposal Spamming Rewards Exploit

justmythoughts · April 5, 2022, 2:26am

Goal

As a community, revise the current governance voting rewards system to disincentivize proposal spamming for profit, while still incentivizing voter participation and allowing anyone to easily submit an NNS proposal (no censorship).

Motivation

Over the past week, a flurry of governance proposals have spammed the NNS in order to take advantage of an increase in rewards from voting on governance proposals, which was changed earlier this year.

Here is a list of those proposals:

This isn’t the fault of the person creating these proposals - it simply demonstrates a flaw in the governance rewards system and should be remedied ASAP (given adequate time for community discussion and input) to stabilize the rate at which rewards are disbursed from the NNS.

Potential Solutions

Here are a few rough solutions that I have come up with, but I welcome the community to add to, expand upon, and rip apart each of these ideas. Each idea aims to remove financial incentives to creating NNS proposals, while retaining governance voting incentives and limiting any barriers to creating proposals (protecting NNS proposal censorship).

1. Fix governance voting rewards on a per time period (week, month, etc.) basis

The idea here is that regardless of the number of governance proposals submitted, the voters are rewarded for their participation divided by the number of proposals submitted in the time period, and these proposals are disbursed at the end of the time period to ensure the correct voting reward per vote cast, and that no vote on a single proposal is worth more than any other proposal with that time period.

If the NNS receives 1 or 1000 proposals within a time period, a participant that votes on all proposals will receive the same voting rewards. The governance rewards paid out over time will therefore be predictable and stable, and the fixed governance rewards will remove an financial incentives or potential conflicts of interest in creating an NNS proposal.

The community can decide how to handle the case where 0 proposals are submitted in a time period, as there are many different ways to handle this.

2. Governance voting rewards decrease by a factor on a per time period basis

This idea is similar to 1, except governance voting rewards are no longer fixed within the chosen time period.

After each proposal is created within the time period, the amount of rewards disbursed decreases by an agreed upon factor (1/2, etc.). This allows rewards to be paid out after each proposal instead of waiting until the end of the time period, but means that some governance proposals would have greater rewards than others. While a strong financial incentive remains in creating governance proposals and participating in voting, this incentive drops off depending on the rate at which the governance voting rewards decrease.

3. Governance Proposals have a minimum week-long incubation time before going live, and governance voting rewards are fixed on a weekly basis

This idea builds off of 1, in that weekly governance voting rewards are fixed and therefore predictable, but adds a minimum incubation time during which the proposal is locked to voting, but visible to all NNS users. After the incubation period, the proposal goes live and is unlocked, allowing voting. The incubation period gives the community the necessary time to review and discuss a proposal before it goes live, and allows a submitter to withdraw and revise the proposal if they would like to do so.

The general timeline would look like this:

An NNS user submits a governance proposal to the NNS. This proposal is available for viewing, but locked to any voting.
(recommended, but optional) The NNS user creates a post on the Developer forum/IC community channels outlining their proposal and inviting discussion. They can choose to do this before or after step 1 (submitting their proposal to the NNS).
Every Sunday, proposals submitted between 1-2 weeks prior (between 2 Sundays ago, and the previous Sunday) unlock and are live for voting.
The proposals submitted the prior week (between that Sunday and the previous Sunday) are queued up and available for viewing in the NNS (but still locked), such that a voter will be able to view and understand which proposals will unlock and go live the next Sunday.
The process repeats each week.

While more complicated, this approach has several benefits over 1 and 2.

Voting rewards remain predictable while allowing immediate voting reward payout, as the NNS knows how many proposals will be live in a given week, and can therefore determine the total voting rewards for a given proposal.
The incubation period allows NNS voters time to reflect, discuss, and potentially improve governance proposals
The incubation period allows NNS users to do their due diligence on a proposal and bring up any flaws or issues with it, helping protect the community against a flawed or malicious proposal from reaching the NNS without opportunity for oversight
Proposals submitted during a given week will all be queued for viewing together (step 4), and will go live/unlock together (step 3), meaning that NNS users will be able to predict and schedule adequate time for both reviewing a proposal and voting on that proposal if they choose to do so. This could potentially allow more NNS users the time to manually cast votes, instead of needing to follow neurons due to a lack of time.

alejandrade · April 5, 2022, 3:00am

Going forward we will need a way to quality control proposals. Maybe it’s time to think about implementing representative democracy type system. Where a few representative we voted for are paid to read and sponsor bills.

ArjaanBuijk · April 5, 2022, 3:06am

I love the idea of an incubation period.

I like to propose an idea that mimics the process of having to gather a number of signatures before a proposal can be entered.

During the period a proposal is locked, a certain number of neurons must vote to unlock it. Neurons can not vote to keep it locked, but only vote to unlock it.

If a locked proposal does not receive sufficient signatures, ie. unlock votes, the proposal never gets unlocked and is deleted.

justmythoughts · April 5, 2022, 3:59pm

This is a great addition!

A pro of this approach is that it ensures that unpopular or opaque proposals will most likely never reach the voting floor. I see this as very similar to propositions needing a minimum # of signatures to get on a state ballot.

A con of this approach is that it does complicate the voting process somewhat, and make it more involved.

Would be curious what the NNS team has to say about this in terms of how difficult it might be to implement @jwiegley, in addition to the solution 3 described in the original post.

jwiegley · April 5, 2022, 4:02pm

I’m not clear yet on how adding a 1 week no-voting period at the beginning of the proposal cycle helps. For those who want to use spam as a way of advertising to the neuron holder community, this just gives them an extra week of visibility. Implementing this scheme would not be difficult at all, but where is the incentive to raise the quality of proposals?

icme · April 5, 2022, 4:16pm

This doesn’t fully block governance proposals from reaching the NNS, but by fixing the amount of governance rewards disbursed in a 1-week period, it helps by reducing any financial incentives that would come from spamming the NNS (which is why we are receiving spam proposals currently). In fact, this makes it cost prohibitive to spam more proposals (as there is no longer an increasing payoff to creating additional proposals and reaping the additional governance voting rewards).

Decreasing visibility would most likely mean setting up an automated spam filter, which I’m happy to discuss but might be better suited to another forum topic, as in my opinion it would be important to set this up without introducing any features that would over-censor proposals.

@ArjaanBuijk had a great addition to make sure that spam proposals would never see the voting floor.

Zane · April 5, 2022, 4:26pm

I like this proposal.

Fix governance voting rewards on a per time period (week, month, etc.) basis

I assumed this was already a thing.

justmythoughts · April 5, 2022, 4:31pm

@icme Exactly!

@jwiegley Glad to hear there aren’t any significant technical hurdles required in implementing this scheme.

In response to your concerns, these specific solutions don’t block any proposals from reaching the NNS, but it does reduce any financial incentives that would be gained from creating more NNS proposals. By spamming proposals, the spammer is now essentially burning ICP for visibility.

I believe creating a template for NNS proposals coupled with a spam filter for NNS proposals would tackle the proposal quality issues more directly, as long as that spam filter is not too restrictive. I really like this approach as it would be complementary to solution 3 detailed above.

Now the NNS would have the following guards:

A spam filter in place to handle the proposal quality issue
Fixed governance rewards over a given time period, resulting in an increasing financial burden (and no financial incentive) to anyone attempting to flood the NNS with governance proposals.

plsak · April 5, 2022, 8:54pm

Just FYI if this was not considered yet:

Mlo787 · April 5, 2022, 9:11pm

What if you had to burn 25 icp per proposal submitted? That should do it.

willguest · April 5, 2022, 9:45pm

@justmythoughts I’m really happy you put this up. I am quite intrigued by how this will play out.

With regard #1 it seems that, when only the participation % is important, you can no longer connect the amount of governance done to the benefit to the network (rewards). The governance itself kind of loses value.

Tangent: This means that an organisation founded with the purpose of crafting readable, packaged proposal of exactly the type we need has little financial incentive to operate. Whether they produced 1 or 1000 in a week, the overall network benefit would not be recognised through rewards. Overall that would make it harder (or less likely) that such a organisation/DAO would exist or even engage with this process, which works against the goal of having better proposals.

For #1 and #2 (and generally), I find financial (dis)incentives a bit old-fashioned. They work proportionately to the wealth of the person and can also be considered costs and/or market tests. A “disincentive” fee could even work to facilitate the testing of public opinion via the NNS (diluting quality) as it provides a clear cost structure.

I like incubation as an idea because it follows a social route for proposal checking. Personally I can see how the SNS could do a lot to help this, maybe with an (open-source) automated spam filter between NNS and SNS followed by community-driven decision making.

A juror-type system could be one scalable option – accounts getting called up by the NNS (or SNS) to review something – and could offer additional rewards for time spent. Reviewers could be chosen at random, or from a pool depending on topic, or according to some criteria or (self) reported expertise. If I could choose, it would be 1 reviewer-1 vote, but I can also see how weighting based on previous attendance or participation could work.

Maybe this is all water under the bridge, if DFINITY will present a clear path forward. As someone seeing an SNS implementation on the horizon, I really hope that this does not get left to money and the markets, but falls to the community to resolve.

Based · April 6, 2022, 12:04am

This is the solution, everyone’s getting worked up and spazzing for no reason, its not even a requirement to log in every day to vote since anyone can blindly follow a neuron for governance and if you cant even do that then I couldn’t care less if you miss out on your auto pilot “rewards”, call it a tax for not paying attention and thanks for the extra tokens. Don’t like it? Then vote ta da

justmythoughts · April 6, 2022, 1:06am

@plsak Thanks for bringing this up I was not originally aware of this roadmap item! As mentioned above, I believe a spam filter or “mechanism” would be complementary to fixing the governance voting rewards within a given time period. The one thing to be careful of with a spam mechanism is that it is not too restrictive - I’d be interested to hear from @diegop and the foundation on what their plans are for this spam mechanism.

justmythoughts · April 6, 2022, 1:07am

Hi @willguest thanks for your input!

A few points:

I’m not quite clear on what you mean here, can you elaborate on this a bit?

With respect to your comment on financial disincentives if the reward is fixed by time period, I think it’s important that voters participating in governance proposals are rewarded for their time - the question what is the appropriate reward amount for a week of proposal votes is up to the community.

In the case where we have a bad actor that is not affected at all financially by the cost to create a proposal (say a whale or even a foreign country), @ArjaanBuijk had a idea that would act as a great solution

Based on this suggestion of a minimum support “signature” threshold, I’m imagining a future where the IC is massively successful and 1000s of governance proposals are created on the NNS each week. Many are spam and are caught in the filter, but let’s say 50-100 make it through. That’s still too much work for one person in any week. Proposals that have garnered the necessary support from the community will be well known, and default followee neurons/active members will search for the proposals that they support. As long as a proposal receives some minimal number/percent of votes, it would make it to the next round. The majority of spam/unpopular proposals would therefore “fall off the ballot” at this point, with no necessary action needed to be taken by the community in terms of reading/interacting with the spam proposals.

The question remains on how to motivate individuals or entities to vote on proposals that would pass that minimum threshold. Your juror-type system is an interesting and satisfactory solution, albeit a bit more active of a solution than I would like to be involved in personally, especially if I have a busy week and am chosen to review 10-20 of these incubated proposals. I believe that like a state ballot proposition, there should be enough organic support not tied to any financial compensation for an individual proposal to pass some minimum support threshold and unlock after the incubation period to make it to a “live vote”.

The property that governance rewards are fixed per time period/basis ensures that NNS voters don’t feel financially obligated to vote on proposals in incubation that have not reached a minimum support threshold. In this way, NNS participants then are not forced to read through and vote on 50-100 proposals just to find the ones they care about, but are only rewarded by voting on proposals that hit the minimum support threshold and unlock (or go “live”) on the NNS.

Definitely agree that this would be a neat feature to have to an SNS - although I’d imagine each application would want to have a lot of control over each of the “toggle-able” weights and features. I’m optimistic given the recent influx of input around this solving this proposal spam issue that the community will come to a satisfactory resolution in due time!

wpb · April 6, 2022, 1:09am

On idea 1, I don’t really understand how it is different than the system today other than averaging over 7 days (or a month) instead of 1 day. Is it because voting rewards would only be derived from governance proposals and nothing else? If so, I could back that idea (it’s effectively the same as resetting default following for All Topics Except Governance). Would you please clarify further?

On idea 2, how would you decide which is the most important proposal for voting? And the second most important? Etc? Does it matter or are you assuming everyone will vote on every proposal? That may be reasonable, but I’m just trying to understand the mechanics of the proposal weight degradation.

On idea 3, I like the idea of a delay period. I have a recommendation for a slightly different twist. When the proposal is submitted to the NNS, a forum topic should be created automatically that requires deliberation for 1 week. At the end of 1 week, the proposer is required to submit a revised proposal before voting is initiated. Not perfect, but I do like the idea of ensuring deliberation. During deliberation, I suppose you could implement a Spam button to prevent the proposal from moving forward, but it seems that could be abused by people who don’t like the topic. Hence, I’m inclined to think the forced deliberation part is good, but maybe not the spam identifier. I also don’t think this disincentivizes spam proposals. People will just be willing to let them play out. The goal of spam proposals is either low cost advertising or higher voting rewards, so this idea doesn’t seem like it solves that problem.

I still think spamming will continue until the root cause is eliminated, which is people going after voting rewards of people who are not voting on governance. Eliminating default rewards for routine business proposals is one way. Another is to let the spam play out until 95% of the voting power is configured to vote on governance. I’m afraid the later will take a while.

By the way, I love how you are focused on ideas that keep proposal cost low and encourage higher voter participation. I think we have these ideals in common.

wpb · April 6, 2022, 1:16am

Governance rewards are fixed per time period…I’m trying to understand this idea. Are you saying something like 75% of total awards available for a 7 day period are dedicated to governance no matter how many proposals are submitted?

justmythoughts · April 6, 2022, 2:29am

Hi @wpb, thanks for your feedback and the positive vibes!

I agree that #2 has a few flaws, specifically that this makes certain proposals more valuable than others. There may be a few tricks to make users unable to predict which proposal would be worth the most, such as delaying rewards to the end of the voting period (1 week, etc.) and then randomly assigning the decreasing rewards to each of the proposals within that period, but I agree that this would not be optimal.

I’d be happy to clarify if you can elaborate on how this would be the same as resetting default following for All Topics Except Governance, I’m a bit confused on that equivalence.

With this proposal, I’m only talking about extending the rewards for governance proposals to average over one week - this does not include other proposal topics. I believe the this change for governance proposals starts to make more sense when a 1-week incubation period is introduced in idea #3.

This fixed rewards allocation over a 1-week time period instead of a 1-day time period does several things:

It gives NNS participants more time to evaluate and vote on a proposal as well as allowing some predictability with respect to when a proposal will be live for voting.
It stabilizes the amount of governance voting rewards allocated, (which I believe are currently majority of voting rewards).
It requires NNS participants to stay active, but does not require them to have a part-time job as an NNS proposals reviewer.
- NNS participants should be rewarded for staying up to date on governance proposals, but anything quicker than a weekly cadence turns into a part-time job/serious hobby.
It places an emphasis on requiring voters to check in and vote weekly on any governance proposals in order to maximize voting rewards, and removes the need to submit daily governance proposals in order to maximize voting rewards.

I really like this idea and support it - just a few edge cases/questions

This locks the deliberation period for one week - what if the creator of the NNS proposal wants a longer deliberation period, or to post the proposal with prior to submitting it to the NNS?
This requires a hook from the NNS into the forums, and centralizes the forums as the goto place to discuss Governance Proposals. What about people who want to submit a proposal on Twitter, Medium, or DSCVR?

Look into my comments above with respect to @ArjaanBuijk’s suggestion on a minimum support “signature” threshold. I think the positive filter is better than requiring people to label a post as spam, which as you say could be abused. The best approach for handling spam is putting in place an automated and unbiased mechanism or filter, which it looks like DFINITY has on the roadmap for Q2.

wpb · April 6, 2022, 2:40am

Can you be more specific about the fixed reward allocation? Voting reward allocation is already fixed every day. Are you saying a certain percentage of that allocation would go to governance? Are you thinking 25%, 50%, 75%, 100%? I understand the 7 day average part. I’m trying to figure out the fixed allocation part.

justmythoughts · April 6, 2022, 3:04am

Yes, I think the percentage of the total voting awards attributed to participating in governance proposals over a 7 day period should be fixed to whatever the community aligns on (50%, 75%, 80%, etc.), regardless of the number of governance proposals submitted during that time period (0 to infinity).

I’m arguably not an expert on governance voting rewards and do not work for DFINITY, so my initial observations have simply come from noticing my mergable maturity, and following discussions on the forums.

Therefore, I did a bit of peeking into the code behind voting rewards and found this. I could be wrong, but I’ll take each piece of code at a time in how I’m interpreting it.

The following code snippets are taken from the most recent commit as of this post (4ed64eb628db52d378c2b3c7db09f9f0ab6c3331)

github.com

dfinity/ic/blob/4ed64eb628db52d378c2b3c7db09f9f0ab6c3331/rs/nns/governance/src/governance.rs#L1502


      
              /// When voting rewards are distributed, the voting power of
              /// neurons voting on proposals are weighted by this amount. The
              /// weights are designed to encourage active participation from
              /// neuron holders.
              fn reward_weight(&self) -> f64 {
                  match self {
                      // Default following is not enabled for proposals on the
                      // governance topic. Thus, we provide significantly higher
                      // voting rewards for neuron holders who actively vote on
                      // these.
                      Topic::Governance => 20.0,
                      // There are several (typically over 100) exchange rate
                      // proposals per day.
                      Topic::ExchangeRate => 0.01,
                      // Other topics are unit weighted. Typically a handful of
                      // proposals per day (excluding weekends).
                      _ => 1.0,
                  }
              }
          }

This essentially means a governance vote is 20x any other vote, and 2000x an exchange rate vote. Based on the estimates in the code, the breakdowns per day assuming a single governance proposal is cast each day look like this

governance = 1 * 20 = 20
exchange = ~100 * 0.01 = 1
others = (a handful) 5 * 1 = 5;

Therefore, if one governance proposal per day is submitted we would have roughly 20/(20+1+5) or 76% of all voting rewards attributed to governance.

github.com

dfinity/ic/blob/4ed64eb628db52d378c2b3c7db09f9f0ab6c3331/rs/nns/governance/src/governance.rs#L6028


      
          let considered_proposals: Vec<ProposalId> =
              self.ready_to_be_settled_proposal_ids().collect();
          
          // Construct map voters -> total _used_ voting rights for considered proposals
          let (voters_to_used_voting_right, total_voting_rights) = {
              let mut voters_to_used_voting_right: HashMap<NeuronId, f64> = HashMap::new();
              let mut total_voting_rights = 0f64;
          
              for pid in considered_proposals.iter() {
                  if let Some(proposal) = self.get_proposal_data(*pid) {
                      let reward_weight = proposal.topic().reward_weight();
                      for (voter, ballot) in proposal.ballots.iter() {
                          if !Vote::from(ballot.vote).eligible_for_rewards() {
                              continue;
                          }
                          let voting_rights = (ballot.voting_power as f64) * reward_weight;
                          *voters_to_used_voting_right
                              .entry(NeuronId { id: *voter })
                              .or_insert(0f64) += voting_rights;
                          total_voting_rights += voting_rights;
                      }

This piece of code calls the aforementioned reward_weight() function for each proposal, and then for each voter ballot increments the voting rights by the reward weight for both the individual voter, and the total voting rights of all voters on the NNS.

github.com

dfinity/ic/blob/4ed64eb628db52d378c2b3c7db09f9f0ab6c3331/rs/nns/governance/src/governance.rs#L6053


      
          
          for (neuron_id, used_voting_rights) in voters_to_used_voting_right {
              match self.get_neuron_mut(&neuron_id) {
                  Ok(mut neuron) => {
                      // Note that "as" rounds toward zero; this is the desired
                      // behavior here. Also note that `total_voting_rights` has
                      // to be positive because (1) voters_to_used_voting_right
                      // is non-empty (otherwise we wouldn't be here in the
                      // first place) and (2) the voting power of all ballots is
                      // positive (non-zero).
                      let reward = (used_voting_rights * distributed_e8s_equivalent_float
                          / total_voting_rights) as u64;
                      neuron.maturity_e8s_equivalent += reward;
                      actually_distributed_e8s_equivalent += reward;
                  }
                  Err(e) => println!(
                      "{}Cannot find neuron {}, despite having voted with power {} \
                          in the considered reward period. The reward that should have been \
                          distributed to this neuron is simply skipped, so the total amount \
                          of distributed reward for this period will be lower than the maximum \
                          allowed. Underlying error: {:?}.",

This piece of code calculates the reward for each voter based on (used_voting_rights * distributed_e8s_equivalent_float / total_voting_rights)

What this says to me is that even though total daily voting rewards on the NNS are capped by the distributed_e8s_equivalent_float, the more governance proposals there are per day, the more that percentage reward allocation due to governance proposals could go up. For example, let’s look at if we now have 2 governance proposals per day.

governance = 2 * 20 = 40
exchange = ~100 * 0.01 = 1
others = (a handful) 5 * 1 = 5;

All other proposal topics equal, if 2 governance proposals are introduced per day then roughly 40/(40+1+5) or 86% of all voting rewards are attributed to governance.

One can imagine if then someone submits, 5, 10, 20, etc. governance proposals per day that are voted - which may very well happen if someone reads this post. People will not have the time to keep up and vote on everything, which will cause more centralization around followee neurons in order to ensure NNS participants don’t miss a vote. Those submitting the spam proposals would be counting on NNS participants missing a vote, and therefore taking rewards from those who missed a vote in this zero-sum game.

This is another strong reason of why governance proposal voting rewards per time period should be fixed. The logic shifts the incentives towards creating more governance proposals, instead of placing a focus on the NNS participants voting on the governance proposals that are created, regardless of how many proposals are created in a given time period.

wpb · April 6, 2022, 3:23am

That’s a perfect explanation. I understand now and definitely agree. In fact, your initial calculation feels right to me. It seems a governance reward allocation of 75% of total available voting rewards is the right ratio. I would not be opposed to 85% either. You are definitely correct that this kind of fixed allocation would disincentivize low effort proposals.

Of course it would need to be averaged over many days instead of daily simply because there are not enough governance proposals for daily allocation (as you have pointed out). I think a 7 day (or 30 day) rolling average would work though. It doesn’t have to be a fixed 7 day time period. That way proposals can come out any day and voting rewards can be paid out every day.

Topic		Replies	Views
A suggestion for a long-term solution of governance proposal spam Governance Discussing	3	694	July 25, 2022
Proposal to fix governance proposal rewards at 75% on a daily basis Governance community-consideration , nns , Proposal	17	1959	May 16, 2022
Way forward on spam - Proposal for tactical fix Governance	177	5937	August 17, 2022
Adjusting SNS voting rewards SNS Project Governance sns	24	508	September 12, 2024
DFINITY Foundation’s vote on Governance proposal #56798 Governance	14	1790	July 8, 2022

Community Discussion: Revise Governance Voting Rewards to Fix Proposal Spamming Rewards Exploit

Goal

Motivation

Potential Solutions

1. Fix governance voting rewards on a per time period (week, month, etc.) basis

2. Governance voting rewards decrease by a factor on a per time period basis

3. Governance Proposals have a minimum week-long incubation time before going live, and governance voting rewards are fixed on a weekly basis

Related topics