[Proposal] Introduce an incubation period and minimum support threshold for governance proposals

Governance
, ,
1

Objectives

  • 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 governance proposals


Solution

  • Introduce an 2-week incubation period in which after a proposal is submitted, it is “incubating” and remains locked (not live) until it reaches a minimum support threshold. (Let’s say 2% of all voting power).
  • Once the proposal meets the 2% minimum support threshold, it is transitioned to a live vote on the NNS, and treated the same as any NNS proposal that is currently submitted to the NNS.
  • Any incubating proposal that does not reach the 2% minimum support threshold within 2 weeks of being submitted falls off the ballot and never reaches a live vote.
  • Voting on any incubating proposal is voluntary, in that it applies an NNS voter’s voting power towards the reaching the minimum support threshold, but does not create or grant any governance rewards to the voter.

Flowchart for Proposed Solution

NNS Proposal Flowchart.drawio
NNS Proposal Flowchart.drawio894×718 63.4 KB


How does this affects me as an NNS voter?

  • Voters have no obligation whatsoever to vote on proposals while they are incubating, and are not penalized nor are they directly rewarded for if they abstain or vote on a proposal that is incubating.
  • Voters are only rewarded for voting on live proposals (that have passed the minimum support threshold and are no longer incubating) in order to receive voting rewards.

Why this proposal works

  • Currently, 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.
  • If this proposal is implemented, NNS Voters will no longer be required to vote on incubated proposals, and each proposal must reach the 2% minimum support threshold on its own merits and value proposition in order to be unlocked.
  • This proposal does not increase the proposal creation or rejection cost, and therefore does not impose a greater financial burden on NNS Proposal Creators.
  • Adding an 2 week incubation period allows governance proposals a significant amount of time to garner voluntary support and meet the minimum support threshold. If the proposal fails to meet this threshold within the incubation period and falls off the “ballot”, the NNS proposal creator can work to improve and advertise their proposal and resubmit it to the NNS.

Additional Benefits of this proposal

  • Adding an incubation period and 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 voluntary 2% support threshold and proceed to a live vote on the NNS.

NNS App UI Changes

  • Add an additional filter/tab for viewing and voting on incubating proposals. Incubating proposals should be ignorable and visibly separated from live proposals in a way that makes the UX for voting on incubating proposals feel voluntary or optional.
  • Add search functionality for incubating proposals that allows NNS voters to search for an incubating proposal by topic name or ID. This way, a voter does not have to scan through or view potentially hundreds of proposals in order to find the one they wish to support.
  • For each incubating proposal the UI should also contain:
    • A graphic demonstrating how far the incubating proposal is from being unlocked
    • The time remaining until the incubating proposal will fall off the ballot

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 after two weeks, this particular spam proposal would fall off the ballot and never make it out of incubation.

Screen Shot 2022-04-16 at 17.29.29
Screen Shot 2022-04-16 at 17.29.291867×578 96.4 KB

Keep in mind that even for some of the spam NNS proposals that garnered more than 2% of the vote, many of these votes were forced, in that NNS voters were required to make a selection in order to receive governance voting rewards. The introduction of an incubation period and minimum support threshold in which all votes are voluntary further reduces the chances that a spam proposal will pass.


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

Rebuttal to (2): If more than 2% of the overall NNS voting power support a spam attack, increasing the proposal cost would have little to no affect. 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 2% voluntary support, it’s unlikely that proposal will achieve a majority of voting power and pass when it goes live.


Discussion Lead

@justmythoughts

I’m only putting this discussion lead section here so you know who to reach out to with any questions or concerns if you don’t feel comfortable posting publicly in the forum. This section of the post will not appear in the formally submitted proposal to the NNS.

9 Likes
2

I updated my post to implement most of this with 4 code edits. I think these two are very similar, but by using the existing infrastructure we can get most of the same effect much sooner:

2 Likes
3

Cheers - some great ideas using the existing NNS threshold, and agree that this would be implementable in a week or two! Appreciate the work on your part digging through the NNS frontend app - about as specific and actionable as can get without submitting the PR yourself. I left my support and opinion here.

1 Like
4

I like the idea, but I think we’re putting a lot of implementation burden on the (already overburdened) NNS team.

It’s easy to vote for something like this, but I think it’s important to also consider the cost of complexity and implementation. (Hopefully one day, we in the community can build these features ourselves…)

3 Likes
5

The treshold is a very sensible parameter here. It has to be low enough to not make it super hard to become a live proposal and high enough not to a allow an individual or group to move their potential “spam” proposals to live proposals easily.

Some people still need to view every proposal that hits the NNS. You’re just minimising the burden to a smaller group of people. Is that good?

Still, this is the best I read so far.

4 Likes
6

Hey @cryptoschindler, glad you enjoyed reading the proposal.

I think I may have written that passage in a confusing manner, what it should say is…

Currently, NNS Participants only view and vote on spam proposals because they are required to…

This is stating that in the current system, the reason why spam proposals are a problem is because all NNS voters who vote manually are required to view NNS proposals. I’ll make sure to update the proposal with this clarification.

The introduction of this incubation period would mean that if the changes in this proposal are implemented, only the proposals that pass the minimum threshold and go live on the NNS would need to be viewed by all manual voters.

This “search by proposal ID or proposal topic name” NNS App UI functionality would allow voters that wish to voluntarily support a proposal while it’s incubating to search only for the proposal(s) they wish to vote for, effectively ignoring all other proposals. An NNS voter can also choose to scroll through every incubating proposal instead of using the search feature, but this is now a choice and not mandated.

3 Likes
7

But someone has to see them and vote on them for those proposals to even reach the minimum threshold, that’s what I meant when I said you’re minimising the burden to a smaller group of people. I’d imagine that there would be some sort of filter for manual voters that excludes proposals that didn’t reach the threshold yet. This is helpful for people that don’t want to be bothered with “spam” proposals, but also puts the power in the hands of a smaller group of people, because those people that actually look at every proposal decide which ones are able to proceed to the next stage and some (good) proposals might never reach the surface because of the smaller group of people that actually look at all the proposals dislike them.

2 Likes
8

These are some great points. Before responding, lets take a step forward into the future of the NNS, assuming the IC is wildly successful. In this future:

  • Hundreds of proposals hit the NNS every day. Maybe 200-300 are spam, but at least 20 are legitimate proposals.
  • Some new proposals contain wasm and/or code that will hooked into the updating the actual governance code/constants of the NNS, meaning that many proposals are now more technical in nature.
  • There are many more issues with canister content and censorship, in the sense that a canister may contain objectionable or copyrighted content and a proposal is created to take that canister down.
  • Many more proposals are created to bring attention to various campaigns, or to preach a certain philosophy or vision for the future of the IC.

This future is therefore one full of proposals that have interesting ideas, are actionable or tightly integrated, with lots of spam mixed in.

Now imagine being an NNS voter in this environment. What is your voting strategy?

Are you going to take the time to read and vote on every single proposal (like a local political activist)? Are you going to follow a few trusted neurons to vote for you and check in every now and then to vote on a particular proposal you care about?

In the case where you choose to follow a few trusted neurons and sometimes vote, you’re putting the majority of your votes in the hands of those who’s judgment you trust, but then manually vote on a few specific issues that you care deeply about. In your own words, the followee system we currently have already…

I see this as an identical process to the incubation period, in that your votes can be cast by you or your followees to bring proposals out of incubation, but if you really want to vote on a specific incubating proposal → you can manually go in and vote on it. The only difference is that proposals that are live on the NNS last 2-4 days, whereas incubating proposals last up to 2 weeks, meaning voters have more time to exercise or refuse their voluntary support for an incubating proposal than a live proposal.

The 2% minimum support threshold also puts an onus on proposal creators to bring their proposals to the community (on the Developer Forum, Twitter, Medium, etc.) before submitting those proposals to the NNS in order to gauge support, gather feedback, and iterate on feedback from the community to improve the proposal further.

Proposals that skip this feedback step and are published straight to the NNS risk being ignored completely, but by not engaging with the community before suggesting a change to the system, the proposal creator is actively taking that risk. As noted in the “Additional Benefits of this proposal” section, this also has the side effect of incentivizing proposal creators to make their ideas for changing the IC public, which allows proposals to be viewed, challenged, and vetted to a degree in order to reach that necessary minimum support threshold and pass incubation.

Arguments Against

  1. Proposal Creator: “What if I have a really great idea, but no one knows who I am and I have no support/voting power. Surely I have no chance of my proposal passing”.

Rebuttal to (1): Make your governance proposal idea public on the forums, tag a few prominent members of the community, engage people on Twitter. If your proposal is worth its salt, it would easily pass the minimum support threshold if got approval from this community. In fact, support from any one of @wpb, @Kyle_Langham, @skilesare, Bob Bodily, or DFINITY employees/alumni like @nomeata, @paulyoung, @claudio, or @kpeacock would probably get you past the 2% threshold.


  1. This proposal puts the voting power in the hands of an even smaller group of individuals.

Rebuttal to (2): In the current voting system, we have those who vote manually, those who follow neurons for all votes, and those who do a little of both. Voting that takes place during the incubation period would have the exact same rules and therefore, the same “voting power dynamics” as voting on “live” proposals. This proposal just reflects the power dynamics of the current system.

It also incentivizes the voters who are most active and knowledgable in a particular area of the IC to engage with those proposals. As NNS Proposals become more diverse and specialized, certain NNS Voters may actually be more inclined to go in and manually vote for a proposal that covers an area they specialize in (say boundary nodes, or cryptography) to ensure that proposal passes incubation and receives a live vote.


  1. No @justmythoughts, you weren’t listening! (that’s me :sweat_smile:)
    Introducing a filter hides proposals from the public and reinforces the voting power inequity of the NNS.

Rebuttal to (3): There’s no perfect solution here, but I think there’s a balance that can be reached between usability and accessibility. Asking NNS voters to read and vote on tens to hundreds of proposals per day just isn’t scalable, nor is it accessible. It wears out NNS voters, and doesn’t allow them to due the due diligence to read and vote on the proposals they most care about. We want people to make good votes, not rushed votes or even worse, give up and just default vote.

To build a system that scales for NNS voters, we have to build a system where they feel empowered to vote, and not overwhelmed. This means:

  • Searching for and voting on proposals an NNS Voter truly cares about, or has expertise in
  • Allowing an NNS voter to ignore a proposal or delegate their vote to a neuron they trust to do the proper due diligence on a proposal.

The NNS App already has filter functionality, but this could be extended to be able to search for proposals with a specific ID or topic name as the system scales up and more proposals come in. I actually see this search functionality not just for the incubating proposals, but soon for proposals that are live on the NNS (i.e. I’m looking for proposal 178988 that Wenzel just posted about on Twitter and the forums saying its live).

2 Likes
9

You convinced me, I’d vote yes if you put this forward. You should work out a very detailed UI/UX before you put this forward and get feedback on it, this way we know exactly what we are getting and the foundation has an actionable plan.

2 Likes
10

@peterparker tagging you here as I would love input from you and the rest of the NNS App frontend team on the proposal in terms of difficulty of implementation, UX/UI suggestions, and any additional feedback you have.

I’d ideally like to understand various edge cases and potential concerns from DFINITY and flush out the UX/UI so voters can visualize the changes a bit more before voting.

For reference, I see this proposal as more of a long term fix (not a quick fix), so I’m willing to take the time and back and forth to get things right :slightly_smiling_face:

2 Likes
11

To be honest with you, I feel like the subject of the proposal if a bit outside my field of expertise (frontend development) therefore not sure my two cents about it here would be really useful.

Being said, regarding the proposed “NNS App UI Changes” I would say nothing sounded like a technical red flag, adding information, list and filters sound reasonable from a frontend developer point of view. Only concern would be making the features understandable by anyone. From newbie to expert, it should be clear to anyone. But these are UI/UX related and that’s why we have a UX expert in the team :wink:.

3 Likes
12

@justmythoughts it seems like this is a good proposal to address spam that occurs for the purpose of advertisement and announcement. I would vote in favor of this proposal, but with the caveat described below.

I’m concerned about whether it would work to stop spam for the purpose of personal financial gain. We need to assume people will always select options that result in higher financial gain. Hence, I think they will be inclined to seek out and vote for the spam so it can make it into the system in a way that earns then higher rewards. Whales have incentives to do this themselves, but I think the smaller investors would also do the same to ensure the proposal meets the threshold. That means a lot of votes getting cast as yes when they might otherwise be willing to vote no. Personally, I think the solution that addresses this issue is proposal 55651 because it takes away the financial incentive for spam.

Hence, I see proposal 55651 as the solution for spam that exists for financial gain and your proposal as a reasonable solution for spam that exists for advertisement and announcement.

One point I’d like you to clarify…would people who vote during the incubation period be rewarded for their votes if the proposal makes it out of incubation? Currently I think the proposal says they would not be rewarded. It makes sense for them to not be rewarded if the proposal never goes live, but I don’t think it makes sense for everyone who votes when live to get rewarded but not the people who voted when it was in incubation. Could you please clarify and, if needed, update the proposal accordingly?

13

This still does not solve the core issue which is the incentive to spam proposals. If neurons are gaining higher rewards for voting on governance proposals it still opens the door for abuse. A group of large neurons could just continuously push proposals all day long through the incubation period.

If you increase the threshold to try and solve this you could eventually just end up with a clone of the NNS, plus increasing the threshold would make it harder to pass proposals in general. Meaning good proposals from community members may just vanish after two weeks along with their ICP. If they were not loud enough.

If you set rewards to be released weekly, it only creates patient spammers.

Now hiding away proposals also creates a loudest voice in the room type situation, meaning the most followed or most well known community members will always have more sway then the common neuron. We all know information is power and those that control the flow of it will effectively control what proposals are passed to the NNS. you run the risk of having the smaller voices fall into the ether. I really don’t want to fall back into a party system, The NNS at this time allows anyone globally to have their idea immediately present and available for voting.

I do think if there are hundreds of proposals being submitted all at once it could become overbearing but your are able to search for proposals via their I.D at this time as well.

I still think we need live reviewers. either we remove the governance rewards or we have live reviewers who filter for spam/quality. I had to remove my initial idea, I could not entrust a static mechanism to control for all error.

1 Like
14

@MrPink13 and @wpb

You are both 100% correct! While this proposal addresses spam and quality control concerns, it does not remove the financial incentive if enough voting power wishes to pass as many governance proposals as possible.

If you read the Arguments Against/Potential Issues section of this post, under argument (2) I bring up your exact concern, and provide potential solutions. I favor solution 3 brought up in Community Discussion: Revise Governance Voting Rewards to Fix Proposal Spamming Rewards Exploit, which talks about fixing the governance rewards as a percentage of the overall voting rewards. This way, regardless if we have 0 or 1000 governance proposals that hit the NNS, the rewards payout is the same and both spammers and voters have no financial incentive to vote on spam proposals.

I chose not to include that in this proposal, as I feel that removing the financial incentive to pass spam proposals can be solved in a separate, but complementary proposal. There are many different ideas out there that tackle the financial incentives directly. I believe my idea to fixing the governance rewards over a week-long period will solve this issue, but it also received a decent amount of pushback and I believe it might be hard for the voters to digest such a big change all at once if the Incubation Period + Minimum Support threshold changes were tightly coupled with a change to Fix Governance Rewards.

Therefore, I want to continue gathering feedback from the community with respect to fixing governance rewards for the time being, and will later submit a distinct proposal that hopefully addresses these concerns. If you have any ideas/concerns regarding fixing the governance rewards and removing the financial incentives to vote on spam proposals, please leave those comments in Community Discussion: Revise Governance Voting Rewards to Fix Proposal Spamming Rewards Exploit.

2 Likes
15

Are you suggesting that an NNS voter would search just for a single live proposal to vote on? What about the other 100-1000 that hit the NNS? Would they auto reject the rest, rely on default followers?

The issue with not providing an initial quality/spam filter layer is that voters are then required to vote on every proposal that goes live on the NNS if they want to receive rewards.

Therefore, this system does not scale as the number of proposals submitted to the NNS increases, and just opens up incentives for NNS voters to not do their own due diligence on all the proposals due to the sheer number of them. In fact, it creates incentives for developers to create NNS voting bots that default reject or accept all open proposals. We want quality over quantity to be presented to voters, and to create a system that scales well in terms of accessibility for each user, not over burdening NNS voters.

In terms of your concerns about this proposal consolidating NNS voting power, I will direct you to this response I gave to @cryptoschindler, who shared similar concerns.

1 Like
16

@wpb Good question. I had not clarified this specific detail, but will give my interpretation of how I imagine things working out.

All votes cast on incubating proposals count towards reaching the 2% minimum support threshold. Once a proposal reaches the minimum support threshold, any votes that were cast in support are now applied as “Approve” votes towards the live proposal. This means that a vote of support during the incubation period automatically applies as a vote of support if that proposal reaches 2%, and subsequently any voters that supported the proposal during the incubation period are rewarded at the end of the live vote.

Let me give two examples for clarity:

  • Example 1:
    • Voter A votes in support of incubating proposal P1. Voter B does not vote to support incubating proposal P1
    • P1 reaches the 2% minimum support threshold, and goes to a live vote. At this point the proposal time remaining for P1 is reset, and wait for quiet rules are applied in order.
    • At this point, Voter A’s vote of support of P1 while it was incubating will be applied to the live vote for P1. Voter A will receive rewards regardless of if the live vote passes or not, Voter B will need to vote on P1 to receive rewards
  • Example 2:
    • Voter A votes in support of incubating proposal P1. Voter B does not vote to support incubating proposal P1
    • P1 fails to reach the 2% minimum support threshold within the 2 week incubation period, and drops off the ballot.
    • Neither Voter A nor Voter B receive and governance rewards.


This proposal is very similar to (Proposal to restrict rewards qualification to a threshold) in many ways, but differs in how incubating proposals are treated differently than live NNS proposals in the following ways:

  • Incubating proposals stay open for 2 weeks, whereas live proposals stay open according to wait for quiet rules
  • Incubating proposals can only be approved (or ignored), whereas live proposals can be approved, rejected, or ignored

I see the major difference (in terms of backend implementation) as the amount of time that proposal is available, and ensuring that reject votes cannot be cast until an incubating proposal goes live.

I’m curious what the community thinks about automatically counting a support vote on an incubating proposal as an “Approve” vote on the live proposal should that proposal reach the 2% minimum support threshold. The alternative would be to make voters vote again the proposal when it goes live, which I don’t believe is necessary. I’m inclined towards the former, but this isn’t a make or break decision in my opinion. I’ll update the initial post to clarify once there’s more consensus and feedback around how this will work.

2 Likes
17

I like the simplicity of Proposal to restrict rewards qualification to a threshold and restrict visibility and I’ve asked the board to let me move forward with submitting it. It is a stepping stone to this more in-depth proposal anyway. As @cryptoschindler said, it mostly works now. A few changes will get spam off the big board and anyone who puts forward some effort to get their motion considered will get their full time of diligence. You can think of mine as the equivalent of the Robert’s book of order, which might be a decent thing for us all to take a look at, where on a board someone has to ‘second’ a proposal before everyone considers it. The bar is low, but it is off the ground.

3 Likes
18

I think it makes sense either way.

I do like the idea that the incubation period is just a time of waiting for a threshold of voting power to “second” the proposal to make it go live. Offering to second the proposal doesn’t mean you have to
vote in favor. It could just mean you think it is a proposal that is worthy of full consideration by the voting body.

1 Like
19

I think this plan is very bad

  1. Do you know the state of the NNS before the weight of the motion proposal was increased? You can check it out, #34839 proposal. In fact, Not even 2% engagement without great incentives,Even less likely to reach a 2% approval rating

  2. If you look at the voting curve of the motion proposal, you can see that many people actually have more than 2% of the voting weight, and setting a 2% threshold will only give certain people privileges

20

also

  1. It cannot solve the reward problem, I only need to change the content, you can let the whales have enough reasons to support my proposal to get the benefits. You can check my early proposal

  2. It cannot solve the Attack proposal. If most voters will view the incubation-based proposal, then the latency design does not solve any problems, it will still become the broadcast of the community,
    If most voters do not need to see the incubation proposal. The incubation proposal will only be manipulated by the giant whale. (34839 proposal forum post has more than 200 replies, there is no 2% participation)