Proposal to restrict rewards qualification to a threshold

Much of this is taken from [Proposal] Introduce an incubation period and minimum support threshold for governance proposals which I like, but consider to be too complex and involve too many moving parts in the short term. I’m putting this forward because I think it could be implemented quickly by DFINITY. Thanks for the format @justmythoughts


  • Decrease incentives to submit spam governance proposals
  • Protect the NNS from censorship, and preserve the current accessibility of submitting NNS governance proposals (i.e. does not increase the cost or difficulty of submitting an NNS proposal).
  • Protect NNS voters from governance proposal spam

Note : In this post, all references to “proposal” refer to all proposals, those could be restricted to governance proposals, but I don’t think that is necessary.


  • Update the NNS app to not show proposals that have not at least met the 3%(or modified) threshold of Yes votes required to pass.
  • Update the NNS canister to skip rewarding proposals that have not received at least 3%(or modified) threshold of Yes votes.
  • Update the NNS canister to extend the end date to match the initial voting period when the proposal passes the 3%(or modified) Yes vote proposal.

Implementation for Proposed Solution

After line 6027( ) add the equivalent Rust code to the pseudocode below:

if( proposal.tally.yes/ < MIN_NUMBER_VOTES_FOR_PROPOSAL_RATIO){continue;}

After line 5274(ic/ at 35acac6c1113a23e2cb92329f1431c5254567e6e · dfinity/ic · GitHub) add the equivalent Rust code to the pseudo code below:

let oldYesRatio = proposal.tally.yes /;

After line 5284(ic/ at 35acac6c1113a23e2cb92329f1431c5254567e6e · dfinity/ic · GitHub) add the equivalent Rust code to the pseudo code below:

If (proposal.tally.yes / >= 0.3 and oldYeRation <0.3){proposal. deadline_timestamp_seconds = deadline_timestamp_seconds + (now() - proposal.proposal_time_stamp_seonds);

After line 158(nns-dapp/Proposals.svelte at e9dd304d8aaa96f82e91936f23d1bf0c781ae9c5 · dfinity/nns-dapp · GitHub), wrap line 159 in:

{if proposalInfo.tally.yes/ []( < ($UserConfiguredMinYesThreshold | 0.3)}
    Line 159

The NNS front app team will need to add a widget to allow for changing the UserConfiguredMinYesThreshold and storing the preferred value in webStorage.

How does this affects me as an NNS voter?

  • Voters have no obligation to vote on a proposal until it reaches a 3% threshold of yes votes.
  • Once the 3% yes threshold is reached, voters should vote or follow a voter to claim rewards(No change)

Why this proposal works

  • NNS Participants only view and vote on spam proposals because they are required to. Not voting results in lost governance rewards, which are then directly split amongst those who do vote on the spam proposal. Introducing an incubation period and minimum support threshold removes the requirement to view and vote on each and every proposal that hits the NNS.
  • Since NNS Voters are no longer required to vote for proposals that can’t meet the threshold, each proposal must reach the 3% yes minimum support threshold on its own merits and value proposition in order to receive attention from the whole community.
  • This proposal does not increase the proposal creation or rejection cost, and therefore does not impose a greater financial burden on NNS Proposal Creators.
  • Extending the time period at the point of crossing the 3% threshold keeps the consideration time the same.

Additional Benefits of this proposal

  • Adding a minimum support threshold allows governance proposals to be visible on the NNS for a longer period of time, ensuring that less active NNS voters have the opportunity to vote for incubated proposals they support.
  • Adding a minimum support threshold encourages NNS proposal creators to advertise, receive feedback, and iterate upon their proposals before submitting in order to ensure they will pass the 3% support threshold and proceed to a live vote on the NNS.

NNS App UI Changes

  • Add a slider to let users that want to see votes under the threshold if they want to.
  • Make sure a proposer create can hotlink directly to a vote so they have something to use when they promote their proposal.(I think you can already do this…ie Internet Computer Content Validation Bootstrap, but if you are not authorized you lose your redirect…I think this is an easy fix)

Arguments Against/Potential Issues

  1. This will not stop the current spammer from submitting NNS Proposals.

Rebuttal to (1) : Looking at one of the recent spam proposals by @ysyms, Internet Computer Network Status, we can see that only 0.2% of the total voting power is voting to accept these NNS proposals. This means that this would never be shown to most people, the vote would fail and the spammer would be charged their 1 ICP. It would not affect rewards

Keep in mind that even for some of the spam NNS proposals that garnered more than 3% of the vote, many of these votes were novelty votes that were only cast because the item was visible. If the proposer had been forced to garner social momentum the likely would not have reached the threshold

  1. It may be possible that more than 3% of the overall NNS voting power would be interested in continuing spam proposals for financial benefit.

Rebuttal to (2) : If more than 3% of the overall NNS voting power support a spam attack, increasing the proposal cost would have little to no effect. There are two potential solutions in this scenario.

  1. As an NNS Proposal submitter, I feel like this minimum support threshold places an additional financial burden on me to submit proposals to the NNS.

Rebuttal to (3) : The proposed solution does not change proposal submission costs for NNS creators. If one is submitting a proposal that they do not feel will receive the minimum support threshold by a voluntary vote, then they should advertise their proposal and timeline on the forums and social media (Twitter, DSCVR, Distrikt) to garner the necessary support before submitting a proposal to the NNS. If a proposal cannot reach 3% voluntary support, it’s unlikely that proposal will achieve a majority of voting power and pass when it goes live.

Discussion Lead


Thanks to @justmythoughts for doing all the work here on the formatting. I think that proposal is a great long term proposal as an incubation period is great for discussion, etc…but they could be spammy as well and now we have to look at them for 2 weeks. :joy:

1 Like

Interesting idea on making proposals quiet until the proposal lead generates enough Yes support to open the proposal to everyone. I suppose that would advantage whales who can quickly generate that threshold of support, but maybe it’s worth flushing out further.

I think it is a hard sell to convince people to not vote for something if that results in lower voting rewards for them compared to voting for it. Hence, I would avoid taking this idea in that direction.

It’s hard for me to tell because there are so many ideas people have presented with a lot of comments, but it is possible that someone is working on something along these lines.

1 Like

They can vote, just vote reject if they think it is spam. We are all doing that anyway. Maybe @Kyle_Langham cam do an amlysis.of hoany of the spam proposals would have become visible, adjusted for the liklyhood that most would not have seen it.

Maybe wait for quiet kicks in as soon as you pass 3% yes.

1 Like

Thank you for the suggestion but in my opinion any limitations in visibility of proposals and restrictions on who can vote to limited group(s) are opposite of decentralisation.

For this reasons I’m suggesting to cancel the proposal Rejection Cost and relace it with Spam Rejection Cost, where the cost would be significantly increased and Spam would be identified by more than 50% of votes (check box Is Spam with every proposal, equivalent option for cli…).
(rejection cost was meant to be spam rejection cost anyways)

In my opinion this would even encourage serious proposers as there would be no cost of good-faith (discussed here etc) rejected proposals.
Spam would be gone due to high Spam Rejection Cost, and would be decided by whole community via simple click during voting (or adding --is-spam on cli)

1 Like

My concern about a spam rejection cost is is that it can be used as a sword to attempt to punish. I prefer financial ploughshares.

I’d argue(with moderate conviction) that if your really interested in decentralization of the IC, your battle is in finding a way to distribute ICP to non-current holders. I don’t know that the NNS and voting the right arena for that.

My proposal takesno votes away from anyone as any activated proposal must be presented to all voters.

It punishes no one but does raise the price of an activated proposal in the currency of social capital which seems to be the developing resource driving crypto communities.

As someone who woke up on the wrong side of a whale voter and had a couple non-spam proposals rejected when there was 0 evidence beforehand that they would be(or at least with the first one) I’m a bit sensitive to the reality that this world throws curve balls at you and it is an absolute possibilty that if you give someone a gun they are equally likely to shoot you with it as they are to defend them selves from evil in the world.


Edited the proposal to include wait for quite when a proposal pases 3% yes.

  1. First, please, let’s omit any hard feelings in this discussion, I’m pure InternetComputer supporter.
  1. Second, some serious concerns about your possible proposal were expressed already here
  1. Third, there will always be a
  • now there’s actually much more mighty sword to attempt to punish (with Rejection Cost increased to 10 ICP) than would be with Spam Rejection Cost
  1. And fourth, NO
  • NNS and voting is exactly the place where decentralisation happens, what you’re suggesting (in quoted text) is close to (Lenin’s) communism - I was born&living in it and won’t vote for it (ever)

@skilesare I have a flushed out proposal that touches on some similar points, introducing an incubation period and minimum support threshold.

Would appreciate any spare cycles you have to give feedback - [Proposal] Introduce an incubation period and minimum support threshold for governance proposals

First post updated with code edits, more official format, and blatant plagiarism of @justmythoughts excellent write-up of his complementary/similar proposal.

I have no hard feelings…I’m just relaying my lived experience as an example of the volatility that exists in the world. I learned a lot from the experience!

The entire NNS is designed to benefit the largest stakeholders that can organize. I’ve updated the proposal with @justmythoughts rebuttal to this point.

10 ICP is a fine number and about what it used to cost when the price was up at $85/ICP. I’m fine with a bit higher number, I prefer to denominate it in XDR so it is constant. The point of spam is to get your attention and expose you to something. By requiring a spam vote you are giving the spammer what they want. From my inbox I can see that spammers are willing to spend a lot to get my attention.

  • NNS and voting is exactly the place where decentralization happens , what you’re suggesting (in quoted text) is close to (Lenin’s) communism - I was born&living in it and won’t vote for it (ever)

There is social decentralization, governance decentralization, and financial decentralization. We can talk about the merits of all of them. There are certainly extremes and 20th-century communism has certainly been shown to be a boob and barb of a concept. There is still a lot of ground to explore in the middle between financial oligarchy and just airdropping everyone an equal amount of tokens. The answer is in the middle there is somewhere where the market can bring its power to the economic arena and people’s rights and chances at opportunity can be honored. Right now the NNS is too centralized…I think we mostly agree with that. I’d just like to explore how you can modify the tokenomics to make sure that new entrants have a chance at opportunity as well.


i think all of this would be easily fixed by a filter/sort function in the NNS app which is a simple fix on the web front end… let users decide thresholds for themselves.

if i want to see virgin proposals with 0 votes then let me, if i only want to see stuff that has 10% engagement or higher then let me do that, if i just want to see proposals that are about to close in 60 minutes let me see those… this shouldn’t be dictated to folks.

hiding information even if some people consider it “spam” is not smart…

i’m not sure setting a minimum level of voter engagement in order to pay out rewards is a good idea. we want people engaged even if they have to vote “no” to what they think is spam or a stupid idea.

1 Like

I think you are right about the filters being a good idea. The gotcha here is that without a proposal to not reward for votes unless they reach a threshold of yes votes means that you have to pay attention and vote. If the filter matches the level at which you need to care then you never need to care about things that are filtered out.

I’d disagree that this is anything close to “hiding” information. For the proposal to go into effect it has to be seen. Also, there is too much information in the world to not hide some things. Our entire brains are abstraction machines that hide information inside of reasonable topics so we can all talk about them.

Regardless, this proposal gives all users the ability to see everything if they want to.

1 Like

it’s in the economic interest of anyone who can reach or help reach this 3% to vote, even if they have to write a script to vote no each time.

in which case if they are not voting to ensure they maximize their profits they are not rational actors

My proposal is for a 3% YES threshold. Perhaps I’m missing something, but if items that don’t reach a 3% yes threshold do not figure into rewards, then why vote on them? They are safe to ignore.

Are you arguing that with the current set up it is advantageous for us all to vote at least 3% Yes so we get more rewards? I guess that is possible. Perhaps this proposal needs to be adjusted to remove the massive bonus for governance proposals. Would that remove the incentive to vote with a spammer just to get the proposal “on the books”.

so someone could spam “do you want to get paid your governance reward today and maximize your profits?”

a rational actor would vote yes, as they would make more money. only an irrational actor would vote no or not vote.


“vote yes if you think this is spam?”

then anyone who votes no or doesn’t vote their next votes should be discounted (weigh less) as they clearly are not rational thinkers… lol

u can monetize the identification of spam by identifying users who can’t or won’t read, or who can’t think rationally

also if you reward people for yes votes, then people will skew to vote yes by default to reach the 3% to get paid more

Yeah…I think this is tied to the fact that governance proposals have a multiplier. We should probably remove those and even the reward weights all back out to 1 or this will continue to be a problem.(ic/ at 79bbd3177f6532037eb29d62b3e52a364a8103ee · dfinity/ic · GitHub ← code that does the calculation).

I think that is a separate issue though…or should I add it to this one?

1 Like

The issue here is that even if we get rid of the direct financial incentive to spam, we still have the indirect(I want something seen by a bunch of people). Admittedly this proposal addresses the second one more than the first. I think if you fix the first, this one also fixes the second.

i think in general you want more engagement not less, so lowering that would lower the engagement.

i don’t see what that guy is doing as spam btw i see it as someone acting rationally given the design of the system. he is adding value for himself and others.

1 Like