Motion proposal: Countering proposal spam by allowing auto-filtering proposals by neuron ID


This is a governance motion proposal describing a proposed mechanism for preventing proposal spam via user determined whitelist blocking. That is we propose a rough mechanism for preventing proposal by allowing users to optionally configure the neurons they control to automatically reject all proposals from neurons that are not part of a user configured whitelist.

This is a motion proposal and does not directly result in changes to the IC. Rather voting to support the proposal is an indication that work should begin on turning this into actual code. If it passes, then I shall work with Dfinity or other parties to propose specific code changes, which will then be submitted as a new proposal to modify governance canister code.


Recently we have seen a large number of spam proposals which have become a nuisance. @ Kyle_Langham and Wenzel Bartlett @wpb have called for actionable proposals to resolve this issue. This proposal will be deliberated until the 18th of April and will then (unless there are strong arguments against it or that indicate strong opposition) be submitted to the NNS as a governance motion proposal.

What we are asking the community:

  • Provide feedback on this proposal within this thread.
  • Vote accept or reject on NNS Motion
  • Participate in technical discussions as the motion moves forward

3. Proposed mechanism and implementation


Users may optionally configure their neurons

  1. With a ‘whitelist’ of neuron IDs that they will consider proposals from.

  2. To automatically reject all proposals from neurons that are not part of a user configured ‘whitelist’. All proposals from whitelisted neurons will be subject to voting as per normal.

Proposed changes

  • Modify the Governance canister to allow NNS neurons to be configured with a whitelist.

  • Modify the Governance canister to allow auto rejection of proposals by neurons.

  • Modify the NNS interface to allow whitelist and auto-rejection settings to be easily configured and edited within the interface.

suggested UX and implementation details

  • [Suggested UX] This list should have sensible defaults. e.g. all named neurons should be whitelisted by default.

  • [Suggested UX] The user should be able to edit the list for all the neurons they control in a single operation.

  • [Suggested UX] The user should be able to toggle auto-rejection on or off for all the neurons they control in a single operation.

  • [Implementation Detail For discussion] Where the neuron follows another neuron for a given topic these liquid democracy based follow relationships should override any auto-rejection. That is if you follow cycleDAO and cycleDAO votes approve on a proposal from a non whitelisted node your neurons still vote approve even though you have selected automatically reject.

  • [Optional additional feature for discussion] If the Auto-filtering is adopted we should consider making it possible for a proposal to be submitted by a canister rather than just by a neuron. This will allow named on-chain processes like DAOs or Aedile board managed by a working group to submit proposals.


The impact of the proposal has a number of nuances and second order effects. I lay these out here so as to guide discussion.

  • Positive First order effect: Essentially we automate the process of rejecting spam proposals people are currently doing manually. This will stop spam proposals being annoying for those that apply whitelist based filtering. Furthermore if most people opt in spam proposals will no longer have an impact on the distribution of NNS rewards.

  • Positive First order effect: If large numbers of people opt into this auto filtering system it will become almost impossible for a proposal by an unknown bad actor to be ‘accidentally’ approved.

  • Negative first order effect: If large numbers of people opt into this auto filtering system whitelisting will tend to exclude proposals from unknown parties and privilege proposals from known parties. That is this proposal itself would be automatically rejected if submitted by me as my neuron would not be known ahead of time.

I do not consider this to be a serious problem because I would argue that In most circumstances proposers of credible proposals are likely to be known or able to convince some known party to submit a proposal on their behalf. Even where it is important for a proposer to be anonymous for example due to legal risk they will still be able to advertise the neuron though some means and ask to be added to the whitelist. Furthermore if follow relationships should override any auto-rejection then it should still be possible for credible anonymous proposals to be approved

  • Positive Second order effect: If large numbers of people opt into this auto filtering system people will be discouraged from submitting spam proposals in the first place as they will have no financial or nuisance value.

  • Positive Third order effect: In most cases a proposer will have to build community reputation over time or convince a well known organisation or DAO to submit on their behalf. I predict that this will have the effect of encouraging the the formation of [multiple] secondary chambers, DAOs, processes or working groups which vet proposals prior to submission. That is working groups or other processes will tend to be the main entities submitting proposals. However since users are free to edit their whitelists none of these processes will be enshrined. We thus push governance innovation to the edges. When combined with the optional additional feature of allowing proposals to be submitted by a canister I think this could lead to a lot of innovation for example onchain workflows for vetting and workshopping proposals prior to submission.

It is also worth mentioning a possible argument against all anti proposal spam proposals, that proposals spam is a mere irritant that has not actually risen to the level at which it is a serious issue and therefore we should not make any changes to combat it at all especially if these changes complicate the governance protocol.

Security concerns

No security concerns have been identified at this time.

1 Like

The recent spams do not care if their proposals are rejected, they just care about getting a bigger share of rewards from motion proposal than from other type of proposals (i.e. people who are passive followers of foundation neurons and who didn’t configure their neurons for governance topics).

So I don’t think having a white list (or automatic rejection) does much in that front.

There are two choices:

  1. All neurons are opted into automatic rejection with the default whitelist being named neurons.

If we opt for this design choice then active neurons no longer get a bigger share of the pie and entirely passive neurons get the same rewards as actively managed neurons.

  1. Neurons have to explicitly opt into automatic rejection.

If we go for this design choice then neurons which fail to either actively vote or opt in to automatic rejection will continue to be punished and spamming will result in proportionately greater rewards for active neurons. However spam proposals will no longer be an problem for anyone who does the bare minimum of logging in to configure their neurons once as they will no longer be abstaining on spam proposals but actively voting “reject”.

This is a design choice that should be made however personally I think (2) is probably the best choice as:

  • NNS rewards are intended to incentivise for participating in governance and it is entirely reasonable that completely passive neurons that are punished provided span does not inconvenience other participants.
  • Spam proposals that are automatically rejected simply burn ICP without inconveniencing anyone.

Hmm, but the rule is regardless of voting outcome, whoever vote gets rewarded. YES or NO, or PASS or REJECTED, doesn’t matter.

Spammers are taking avantage of the fact that there are a significant number of passive holders who DID NOT configure their neurons to follow governance topics. Those people DID configure their neurons to vote on non-governance topics due to default settings, but they are not passively voting on governance topic and lose out.

Reality is that they don’t. They didn’t do it when governance reward was changed. They didn’t do it when spam proposals become a problem. They will not do it even if your proposal is adopted and deployed.

  1. Spam requires continous attention of those people who have chosen to manually vote on governance issues.
  2. Spam results in unequal rewards.

My proposal aims to solve 1, it does not aim to solve 2, I’m totally ok with passive holders being penalised indeed I believe this is a good thing. I want to encourage people to vote actively.

I decided not to submit this to the NNS for the following reasons:

  • Lack of a clear signal that people support this. - this indicates it is unlikely to pass.
  • Lack of feedback on the proposal. - I think proposals - even motions - should be debated and critiqued in depth before submission to uncover issues.
  • I had a change of heart and believe that spam proposals are not really that big an issue and that there is a real risk of messing with governance too much, that the cure could be worse than the disease.
1 Like

That said it is potentially helpful with respect to preventing a repeat of this situation.