ReProposal to restrict rewards qualification to a threshold - Fix advertising Spam

Continuing the discussion from Proposal to restrict rewards qualification to a threshold:

Now that we’ve handled incentivized spam, I’m re-proposing this as a quick fix for advertising spam.

I’ve adjusted the percentage down from 3% to 1%. Thanks to @Kyle_Langham 's analysis we think that 0.5% would be safe, but I haven’t gone that low…we can debate the exact number.

We can also discuss if we want the check box to default to checked to hide items that have not qualified for rewards. I think it makes it more powerful and it is hard to argue that a check mark is a huge “gate”. Anyone who wants to be a power user can be by unchecking the box.

Motion Text:


  • 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 advertising or grief 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 dApp to not show proposals that have not at least met the 1%(or modified) threshold of Accept votes required to pass unless a user chooses to unhide them.

  • Update the NNS canister to skip rewarding proposals that have not received at least 1%(or modified) threshold of Accept votes.

  • Update the NNS canister to extend the end date to match the initial voting period when the proposal passes the 1%(or modified) Accept vote proposal.

  • Proposals that do not meet the Accept threshold will still have their ICP burned as a reject fee.

Implementation for Proposed Solution

**Note: The NNS dapp has been re-written since the original text was created so the NNS App line source has likely changed, but the concept translates directly to the new app.

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 oldYesRatio < 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(and will not miss out on rewards) until it reaches a 1% threshold of yes votes.

  • Once the 1% 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 1% 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 1% 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 1% support threshold and proceed to a live vote on the NNS.

NNS App UI Changes

  • Add a checkbox to allow power users to unhide the proposals that have not met the threshold.

  • 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 10 ICP. It would not affect rewards

Keep in mind that even for some of the spam NNS proposals that garnered more than 1% 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 they likely would not have reached the threshold

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

Rebuttal to (2) : If more than 1% of the overall NNS voting power support a spam attack, increasing the proposal cost would have little to no effect. The solution to this would be another proposal that further raise the minimum support threshold for governance proposals.

  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. In fact, after this proposal goes live we could lower the proposal cost back to 1 ICP. If someone 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 1% voluntary support, it’s unlikely that proposal will achieve a majority of voting power and pass when it goes live.

  1. This is gatekeeping and keeps out NNS proposers that do not have popular support or a network with which to reach the 1% threshold.

Rebuttal to (4) : It is likely important to keep the threshold as low as possible such that it is still effective against spam. This proposal does increase the risk to un-networked proposers that they may lose their proposal stake without their proposal being considered. We would argue that this risk is not insurmountable and that any good faith proposal should be vetted with the community to an extent that it can garner at least the minimum before it is submitted. In short, this proposal does create a low hurdle, but one which is likely a net gain for everyone in the system. Given that time and resources are not unlimited forcing well-thought-out and minimally supported proposals makes governance possible as activity and interest increase.

Vote Accept to:

  • Update the NNS dApp to not show proposals that have not at least met the 1%(or modified) threshold of Accept votes required to pass unless a user chooses to unhide them.
  • Update the NNS canister to skip rewarding proposals that have not received at least 1%(or modified) threshold of Accept votes.
  • Update the NNS canister to extend the end date to match the initial voting period when the proposal passes the 1%(or modified) Accept vote proposal.
  • Proposals that do not meet the Accept threshold will still have their ICP burned as a reject fee.

This seems like a no brainer to me. The only thing I wonder about is whether a spam proposal that is hidden due to being below the 1% threshold passes the 1% threshold right before the vote ends.

I believe we should extend the vote in that scenario. We can mimic the mechanism (can’t recall what it is exactly) of how a vote is extended when a vote flips right before the vote ends.

There are two mechanisms in that case. This proposal would extend the vote to the original amount…so if it is designated as a four-day vote, you always get at least 4 days after it passes 1%. The second mechanism is the wait for quiet. It would take over after the extension. I guess it would in theory operate before the extension as well, but that should not affect much. Even if someone gamed all the wait for quiet to occur before the exertion, it would still get extended once it passes 1%.

Is this even a problem right now? Who is actively spamming?

I think it would make more sense to wait on this and not try and fix something that isn’t even a problem right now. There may be bigger priorities.

I agree on the premise but imo it shouldn’t be based on “no” votes, NNS should have abstain and spam buttons so people can partake in governance as usual and only actual spam is filtered, other DAOs have a similar system too.

I lean toward agreeing with you in general…but in this specific case, while we’ve only had one really “grief” spam, the cost to do this is editing like 6 lines of code and the devs are going to be in the code anyway. The cost in this case is exceedingly low. (DFINITY can speak up and contradict this as I don’t want to speak for the actual work).

1 Like

It isn’t based on no votes…or maybe I’m misinterpreting what you mean. The trigger is “Accept” votes. Until at least 1% of the NNS thinks the proposal should be accepted, no one has to see or vote on it.

This is the part I don’t agree with, if there were a distinction between “I don’t support this” and “this is spam ”, there’d be no reason to hide highly disliked proposals.

The NNS is the best tool we have to gather the community’s consensus, mixing the 2 options into 1 and filtering proposals will make it less useful at that. If stakers don’t like a change they should all be able to see it in the NNS and vote accordingly cause even knowing how much something is disliked can be valuable info, especially if down the line we get an abstain option too.



Simple Majority requires 3% to pass and wait for quiet extends the voting period with every lead change. So exposing a proposal at the end of the voting period because it exceeds 1% doesn’t necessarily mean it will automatically pass unless it swings from <1% to >3% AND the lead doesn’t change. There are actually a lot of voting blocks that could cause this to happen under the right conditions.

I personally don’t want to see the spam at all and would prefer to disincentivize it. Public neurons like ICPMN will likely be monitoring below the threshold, which would be a hassle if advertisement spam were prevalent.

One thing to note is that the vast majority of folks won’t be looking behind the curtain so to speak. That’s the whole point of not exposing them to potential spam.

We must admit then there might be bit of centralization for people making decisions about spam who are looking behind the curtain. Of course, this won’t be structural centralization as anyone could look behind the curtain if they wanted to, but it will still be centralization nonetheless.

I think it is still definitely worth still moving forward as the benefits far outweigh the costs just something to flag.

1 Like

I think some examples would be good if this is true. I would consider a temperature check proposal that couldn’t get >1% accept would be “spam” in the sense that it is a waste of everyone’s time if you are that out of touch with what the NNS voters want.

I think that this produces a bit of. “Stand-off“ situation where you won’t be seeing spam because :grinning: will vote no and it won’t pass the threshold and reach its audience. The likely hood of the spam being produced and the execution of the mechanism occurring is drastically reduced because the mechanism exists.

Think about how eth PoW works. People don’t submit bad blocks because the mechanism is in place to reject them. The juice isn’t worth the squeeze.

1 Like

We have set up Neuron 17762192467656896776 to make the proposal for ****. You can fund it by sending ICP to 7dc178d1ef3b65e5499dffcf58c913a94dde53d0b23b017af3160f72cd3cbf26. When the account collects 10 more ICP(21 total) we will make the proposal.

I plan to make the proposal on Friday provided we get the 10 ICP.

Please retweet for attention:
Distrikt: [Internet Computer Content Validation Bootstrap ](Internet Computer Content Validation Bootstrap)
dscvr: DSCVR

@skilesare Is that the right address? It seems like it was funded over a week ago. Im happy to fund but it seems like it’s already there

1 Like

1 Like

It was stated during the last proposal that the funds would be merged into the ICDevs neuron as a donation. I donated the last amount and understood that to be the case. I’m still fine with that but i’m curious how that approach differs from incentivizing accepted proposals. (purely a philosophical question; im always happy to support ICDevs)

Well…that was fast. Oh…actually someone already donated during the last one. I considered starting a new neuron and should have. That was lazy. :frowning:

Ok…so I’ll take it from here and I guess it needs to get to 31. In response to @LightningLad91, it is a good question. I’d taken the crowdfunding signal from @wpb as at least a hurdle to get over before submitting it. It just happened to also be a nice fundraising mechanism for ICDevs. It is not the best environment out there for charitable fundraising. I should be more explicit on the post and will be from now on.

1 Like

To be a bit more nuanced, A donation as a signal that ends up as a reward is different than a reward that is always available and mechanized. I guess there is a bit of humanizing element in it? If someone set up a smart contract to always fund a request that humanism would go out of the window. Then again, my understanding is that Wenzel didn’t submit his proposal increase because no one funded it…so as trivial a signal as it appears to be, apparently it works in practice.


Alright. Threw a few coins that way

Agreed! It’s a great signal and also a great way to donate to organizations such as ICDevs. Thanks for taking the time to answer my question.