Grants for voting neurons

Thanks for these ideas.
Originally my concern was that if there is a new post for each proposal it might be harder to find them. But indeed, maybe we could have guidelines for naming and e.g., have a new topic or so so that these posts are easy to find.

we hit a road block on posting to the forum due to current restrictions

do you know what is blocking this exactly alread? I assume that this is some sort of bot protection? I am happy to look more into whether this would be easy to change.

1 Like

Thanks, that a very good catch!

Indeed, I confirmed that the type “update unassigned nodes to latest replica” is now under the topic “IC OS deployment” and would not be part of the topic “Participant management & Node Admin”. I will try to edit my original post to reflect this.


Jesse, you got my vote ser🫡

1 Like

Thanks for raising this concern @dfisher and @wpb.

I think it is also interesting to consider how this could be achieved without additional incentives. For example, as @wpb mentioned, it might have an effect if some larger neurons just sit out a few proposals (e.g., if they anyways have a clear outcome). Or indeed it could be an outcome that it is better to have a larger team behind a known neuron. Or different smaller known neurons could span together and e.g., vote most of the time but follow the other known neuron’s vote in case where they missed a proposal… I am not saying that any of these are necessarily the best solution, these are just a few ideas to illustrate that it could be interesting to also think about processes etc and not only features to address certain problems.

In any case, I agree that this is an interesting problem to consider, but also think it does not take away the value from this initiative. I agree that this could be discussed in the context of the longer-term solution or as a follow up to the priodic rest of following - which is more targeted at this “side” - e.g., at motivating voters to change their following rather than at motivating voting neurons.



I am very interested but the compensation is quite low. The workload can vary and the compensation needs to reflect that.

I think this is already reflected to some extent - the estimates that we got from engineering teams were rounded up. It is also deliberately kept a bit open how many commits should be reviewed in depth to account for the fact that it is not possible to go into the same depths every week.

Also, can the engineering team provide some example reports for each task so we can understand the standard of work you require. This would really help us gauge the total workload.

We don’t currently have such an example. Maybe as a first step it could help if you look at an example by CodeGov to have a better feeling for the effort? I think what is shared in detail is also something that might evolve. But I expect that the larger effort will be to actually read and interpret the proposal - maybe to undersand this better you could look at a few concrete proposals from the topic that you are interested in?

Also some statistics of expected proposals per month would be helpful.

I think a good estimate for this is to look at the number of past proposals. To do so, you can e.g., go to the dashboard and filter the proposals for a certain topic and average over the last few months and years. We also did so for the estimates. I don’t have the exact numbers handy anymore, but I think it roughly the average proposal per week was:

  • Protocol canister management: ~2.2
  • IC OS election: ~2
  • Participant management & Node Admin: ~5
  • Subnet management: ~4

Does applying as an individual hurt one’s chances for selection? It is confusing on how much manpower you expect for the amount you are willing to pay.

As mentioned by others, maybe a group of people will have an easier time to ensure no proposals are missed. Other than that I can’t think of a reason why one person would have a disadvantage, but in the end this will be up to the voters.

1 Like

Thanks I think this is another thing we can think about, but might address another goal.

Note that for some of the topics you don’t need a PhD in cryptography. For example I think the topics “Participant Management & Node Admin” can be learned with less technical knowledge.


Sam, as suggested by Lara, I’m providing a few links to our reports that can be found posted in the CodeGov community on OpenChat. Feel free to browse around all you want. These reports are in public channels. All CodeGov reviewers are expected to write a report that summarizes their finding from their reviews. Each reviewer does it a little differently.

IC-OS Version Election
Proposal 130083

System Canister Management
Proposal 130821 - Governance canister

Invite code to the CodeGov community on OpenChat

Current Codegov team members include @Zane @ZackDS @Lorimer @hpeebles @cyberowl @massimoalbarello @ilbert @tiago89. They have all been excellent resources about reviews of these types of proposals. Perhaps they can give additional advice if you reach out to them.


Hey @NathanosDev would you mind explaining the issue as you discovered from discussions with DFINITY? Why did we decide we can’t automate submitting our final summary report to the forum through the GaaS App? Was it restrictions on automated posts? Or was it the difficulty in finding the right forum post? Or both? What is needed to enable this kind of automation?

We need an API key that only the Discourse admins can generate.

1 Like

I’ll throw out another idea of a process that you could consider @lara

DFINITY controls the ICA neurons, but ICA was originally intended to be an independent organization and it has significant voting power through 40+ neurons. You could take the total voting power of ICA and divide it equally among all the known neurons that are selected by the NNS to participate in this grant program.

Whoever actually controls the ICA neurons could configure those neurons to follow each elected known neuron on the specific topics where they are elected. This would give these elected known neurons a meaningful voting power that is cast when they vote as soon as the program starts. As time passes, if the elected known neurons change, then the following can also be changed for these ICA neurons. In other words, this change in following doesn’t have to be permanent.

DFINITY could commit to not voting on the specific proposal topics that are included in this grant program. After all, DFINITY is the sole contributor to the changes that are implemented under those proposal topics. Wouldn’t it be nice if the adoption of those proposals were largely influenced by known neurons other than DFINITY? This would drive changes in follow patterns, especially among people who only care about voting rewards.

If DFINITY depends on voting rewards from these proposal topics, then they could always vote for most of the proposals with DFINITY owned voting power (not the ICA neuron) according to the votes cast by the elected known neurons. Not voting on a small fraction of these proposals is probably enough to drive changes.

DFINITY can still vote if they find a sudden need to reject a proposal after it was submitted. To my knowledge, there is no need to rush a rejection since nothing changes.

Since DFINITY still controls the ICA neurons, they can even trigger a manual vote on these neurons if it is a critical proposal. I would think that can address any security concerns associated with needing an absolute majority on critical proposals.

The ICA neuron maturity could also be used to fund this grant program (assuming DFINITY or ICA isn’t using it for other purposes already). There is probably considerable maturity associated with ICA neurons that could substantially improve the incentives for this grant program.

The ICA neurons could play a central role in helping advance decentralization of the NNS on technical topics since they were originally conceived for this type of decentralized purpose anyway. It’s not a perfect process, but it seems to get us much closer to decentralization. It’s also 100% process related that doesn’t depend on any code changes. Hence, it could be implemented immediately. It also seems like a reasonable baby step on the path to full decentralization over a long time period.


Hi all, I am applying for the protocol canister management category.

For those who don’t know me I’m Léo, ex-DFINITY. I worked for DFINITY for about 2 years as a software engineer. I contributed to various projects such as ckBTC, ckETH, and ckERC20. You can check out all my commits here. I submitted about 35 canisters-related proposals and reviewed even more.

I am also a contributor to WaterNeuron, which aligns with this initiative of having more external contributions to governance. Hence I will vote with what I think is best for the long-term interest of ICP. Feel free to send me a message on the forum or on X if you have any questions.


Hmm, give me a moment to figure out the best way to explain this.

Ideally, you want to use the voting rewards directly to incentivize this behavior. Here, we’re acknowledging that voting rewards are a bit useless and redirecting some to the grants. Taking into account that we’re printing about half a billion dollars in rewards per year, we probably want to make them useful.

1 Like

That’s exactly what the long-term solution is likely to look like (as I understand it). These grants are just a short-term interim solution to get the ball rolling and encourage some new faces and competition into the mix (as exemplar followees). I think this is explained in the announcement.

Taking into account that we’re printing about half a billion dollars in rewards per year, we probably want to make them useful.

I think your right to point out the privilege and responsibility that followees hold. There are certainly cases where they should be held to a higher standard - I hope this will happen over time. But first we need more skilled people to get involved, and we need to incentivise people to follow neurons that can evidence that they do a better job than other neurons. On a related note, you may find this week’s IC-OS proposal interesting in this respect →

I think @skilesare is onto something with his suggestions. I think ultimately we’re going to need consequences for irresponsible voters (but then we’d need a way of bating/detecting irresponsible voters, and this would come with a whole load of implications - but I still think it’s going to be needed in some shape or form). Competition is pointless without a selection pressure.


Hi Austin,

This is going into the “should we motivate with a carrot or with a whip”?

I always tend towards the “carrot” alternatives, the “whip” options frequently have unexpected effects, especially under a context where the “demander” actually has little power over the “subjects”.

Allow me to exemplify, imagine such a system goes live, I am afraid that:

  • we will put a responsibility onto Node providers, that they are not prepared to assume. Wouldn’t they feel frustrated? How would that affect in terms of some of them leaving or new ones not joining? We are putting a significant stress (because it’s not easy for them), without any real power over them.

  • If the motivation is only “avoid being slashed”, aren’t you afraid that their efforts will stop as soon as that is ensured? They can hire a team whose only purpose is to detect and avoid any “basic flaw”, but what about helping the Dev teams with comments / requests for clarifications? What about requesting that all significant changes are in the logs? What if a reviewer sees a potential bug / downtime / security issue?

In the end, the question is, do we (as NNS) want the best possible review service (because they avoid bugs, downtime, security, misalignment) and want to design a system that provides for that, or we just want to prevent bad behaviour. I think your solution was targeting the latter, while I feel the NNS wants the first.

Do you agree that the problem should not be a responsibility of Node Providers, because it’s not under their zone of expertise? so we shouldn’t suddenly add / request such a significant responsibility into them, for sure it will go wrong.

Hope these arguments help somehow improve the final design.


Hi @lara ,

Apologies for the delay in replying, only now had a good opportunity to dig deeper into this thread again.

Will try to answer all questions below:

Our worry is more on the final design, not these grants phase only. If you are already splitting into smaller teams and each having known neurons, we assumed the final design would be for NNS to payout bigger amounts to higher VP known-neurons and smaller payouts to lower VP / individual known-neurons.

But from your replies am seeing this might be more “equal” payments for “equal” work and try to spread out over as many teams as possible, with maybe a rotation system. We can definitely leave this discussion for a future thread :slightly_smiling_face:

The “core team” / “council” should be small, and be facilitators of the reviewers. Many initiatives can be done by the reviewers themselves, but the finding of funding / requirements, project management, will probably be from the core team.

I am only worried that already on this grants phase we have and are capable of paying for this coordination team, that pays back by generating efficiencies between the reviewers.

Probably the best decision for now is to assign this responsibility to CodeGov / Wenzel and see how it evolves until the final design is ironed out.

1 Like

Hi @lara ,

So, after reading the discussions so far and thinking things deeper, would suggest the following changes for consideration:

  1. Addition of a “Facilitator” Grant, ~1500$-2500$ a month, expecting a team of 2 or 3 part time man-power, responsible for:

    • facilitate bi-weekly calls between all reviewers.
    • with the reviewers define which benchmarks they agree to be tracked and compared about on each type. (that should be facts that a third party / anyone else could audit, like failed votes, etc.)
    • by the end of each month, release the latest results.
    • communicate frequently in all relevant channels, with Dfinity and NNS token holders, a summary of results and most important issues found and if they were considered addressed.
    • gather reviewers needs, transform into initiatives or requests of dev grants to develop shared tooling / best practices / collaboration opportunities.
    • ensure and look after the reviewers well being, that the conditions are attractive and that potential new reviewers have equal chances of being trialed out and onboarded.
  2. Increase significantly the amount for IC-OS proposals (~2x-3x) OR already define layers of expertise and increase the number of teams. While the other grants are “attractive”, think the IC-OS is completely off / “unattractive”. A few reasons / diffs:

    • The learning curve for IC-OS is vastly bigger, has several OS, many layers, it’s very complex! Even on CodeGov we have many times desired to split ourselves in “areas of expertise”, as it’s ineffective to “superficially” review all areas. For reviewers to deliver better work on IC-OS, they should specialise by layers (either through the grants or inside each IC-OS team).
    • IC-OS is the “main” work of Dfinity, meaning the quantity of changes at the end of the week is a lot more than Protocol System Management (PSM). It makes absolute no sense to pay them the same amount, it should be at least 3x higher than PSM.
    • Also the chances for finding a critical bug (or by questioning/commenting on something, helping Dfinity teams to avoid a critical bug) are much higher than on other proposals. Almost all downgraded performance has happened after an IC release (or better, when it was released on a subnet). Avoiding one of these immediately pays back the investment we are making monthly here.
  3. Decrease the amount payed to Protocol System Canister reviews to 1500$~2500$ a month. I find the amount of work and expertise needed to be more fair in that range.

And that’s all. Looking forward for this week’s discussions and eventual final design before code gov applies. Thanks again for this work. :pray: