Grants for voting neurons

TL;DR

  • An intermediate solution for incentivising voting neurons, while the long-term NNS-based solution is implemented
  • 2 grants for 4 of the most important proposal topics
  • Candidates can apply by presenting themselves here
  • The community will select who will get the grants
  • Grants are disbursed to the selected recipients once a month as long as they provide monthly evidence for their work

Context & Motivation

As shared in this forum post, to increase governance participation and decentralization in the NNS, we propose to introduce periodic confirmation and incentives for actively voting neurons.

While the final solution for incentivising voting neurons should be independent of any centralized party and built into the NNS, the implementation of such a solution will still take a bit of time. As an intermediate solution, we propose to start with grants that are provided by DFINITY and given to voting neurons elected by the community.

This intermediate short-term solution has the following advantages.

  • The funded neurons have the resources to already
    • establish a voting process
    • become experts for a proposal topic
    • establish ways to convince potential followers that they do good work, for example by sharing how they verify and vote on proposals
  • The NNS community
    • learns more about what is needed to incentivise voting neurons
    • establishes a culture of what is expected from a “good voting neuron”
    • gets to know new voting neurons that can be followed already now or taken into account when periodic confirmation is introduced
  • Users who submit proposals, e.g., DFINITY,
    • learn how to better explain and present the proposals’ content by getting more feedback

The goal is that the grants would last roughly long enough for the long-term solution to be implemented, so that (most of) the funded neurons can move to the long-term solution for incentivising voting neurons when it is available.

Grants - high level

DFINITY will provide 2 grants for each of the following 4 proposal topics that are most critical for the ICP’s security (8 grants in total).

  • Protocol Canister Management (as introduced with this design)
  • IC OS Version Election
  • Participant Management & Node Admin (we combine two topics here but refer both of them when we say “a topic to vote on” in the following)
  • Subnet management

Candidates can apply in this forum thread if they consider themselves as experts for a particular proposal topic from the above list. For each proposal topic, the community selects 2 candidates. The selected candidates receive their grants monthly in ICP, where the amount depends on the effort required for the chosen proposal topic. Candidates receive monthly grants for up to six months, provided they submit the required verification evidence each month. The grants are disbursed only upon the successful submission of evidence for the prior month.

In the following we describe each of those steps in more detail.

Effort / grants

Based on estimates established with the engineering teams we propose the following reward structure:

  • Protocol Canister Management
    • Effort: ~ 15h / week
    • Grant: $5000 / month
  • IC OS Version Election
    • Effort: ~15h / week
    • Grant: $5000 / month
  • Participant Management & Node Admin
    • Effort: ~ 2h / week
    • Grant: $750 / month
  • Subnet management
    • Effort: ~ 2h / week
    • Grant: $750 / month

What to do to get the grants

As a selected candidate, you are required to do the following to receive your grants.

  • Register in the tool “Submittable” where you will send your monthly reports

  • Share the neuron ID of the voting neuron

  • With this neuron, vote on at least 90% of the chosen topic

  • For each proposal and vote, share on the forum evidence that you verified the proposal by

    • Providing a summary of the proposal

    • Providing a reason why you voted to adopt or reject

    • Provide evidence that you verified the proposal, which includes the following

      • For Protocol Canister Management proposals

        • (1) Verify the build hash, (2) Look at most commits on a high level, considering the API changes (especially breaking changes), code quality, typical source of vulnerabilities, (3) Do an in-depth review of some commits as time permits
      • For IC OS Version Election proposals

        • (1) Verify the build hash, (2) Do an in-depth review of as many commits as time permits
      • For Participant management & Node Admin proposals

        • Add or remove node providers (topic participant management): look at least at (1) a proper forum introduction by the new NP (2) self-declaration and Identity documents are uploaded on the wiki (3) hashes of the self-declaration and identity document match the hashes in the proposal (4) if a new region or community, a check in the public chamber of commerce register (if chamber of commerce number is provided)
        • Add or remove Data Centers (topic participant management): look at least at (1) who submitted the proposal (normally only a new NP) (2) an Internet search whether this is a legitimate data center.
        • Update node config (topic node admin): in such a proposal, a node provider sets the number of nodes and the node_type (Gen1, Gen2). Check these against the originally approved node allowance (whether that allowance was approved, and whether it matches the IC Target topology using the github tooling)
        • Add node operator (topic node admin): this proposal sets the allowance for a particular node provider in a specific data center. (1) Check if it matches the IC Target topology using the github tooling. For example, currently such proposals should be rejected as the target topology has been reached. (2) Check whether the node provider-id and data center-id match with the previously submitted proposals (the add node provider proposal, and the add data center proposal)
        • Remove nodes from the network (topic node admin): this is a proposal to remove (unhealthy) nodes from the network. Check whether the nodes are indeed unassigned and not in a particular subnet.
      • For **Subnet management ** proposals

        • For node replacement proposals: check whether the nodes are replaced because they are dead/unhealthy or replaced for other good reasons.
        • For other proposals of this topic: check whether the reasoning in the proposal makes sense wrt which proposals need to be adopted in which order.
  • If you do not have enough information to make the above checks, report this in your summary of the proposal in the forum.

  • To get the monthly grant, submit a form with a link to the forum where you presented your work

Application process

You can apply for a grant for one or multiple topics from the list above.

To do so, present yourself in this forum discussion until Friday, July 19th.

You might want to include the following information about yourself. Overall, you should try to convince the community that you have the knowledge and resources to do the above tasks.

  • Your name
  • What topic(s) you apply for
  • Presentation of who you are (e.g., links to LinkedIn, other socials)
  • The size of your team
  • Relevant experience (overall, in web3, on ICP)
  • Technical knowledge (can include links to projects, e.g., on github)
  • Why you want to be a voting neuron
  • Why you need the grants to do so
  • Why you are acting in the long-term interest of ICP
  • Why you are interested in the topics you apply for
  • Why you remain a voting neuron in the long term, even after the grant is over
  • Whether you have some voting principles

Decision process

From the applications, the community will select 2 candidates for each proposal topic that will receive the grants.

To do so,

  1. a NNS motion proposal is submitted for each candidate and topic for which the candidate applied
  2. for each proposal, the result is computed as the number of YES minus the number of no votes (#YES-#NO)
  3. for each topic, the 2 candidates with the highest results get the grants

If there are too many applications for motion proposals to be practical, there might be a first round of election via another tool.

DFINITY plans to vote for candidates who convincingly show in their application that they are able to do the required verification tasks.

We are looking forward to many applications and to this next step towards a more active NNS DAO!

21 Likes

Thank you for starting this discussion @lara. The CodeGov team has been performing this work for IC-OS Version Election and Protocol Canister Management proposal topics for over a year, so we will apply for at least these two spots. I am traveling today and cannot submit an official application, but I should be able to do it tomorrow.

I look forward to seeing others in the community stepping up to perform this work, so I think it’s awesome that DFINITY is taking this approach to enabling the NNS to incentivize these contributions to the protocol.

5 Likes

Thanks @lara. This is a great inititive to further incentivise voting on complex topics that require a significant time investment.

How many people is this effort calculated for? A single person? Or a team of people?

I don’t know the numbers for CodeGov off the top of my head, maybe @wpb can provide more details, but there are a quite a few reviewers in CodeGov now and I’m not sure if this grant level can support all of them.

I think it’s sensible to include multiple people in the voting on these proposals, both for specialization and also for redundancy.

There’s many layers to the IC stack, in DFINITY we create teams that each specialize in a different layer of the stack and I think it’s sensible for developers that are voting on these proposals to do the same thing. Although I think developers should specialize in multiple layers, since they are only reviewing code, not writing it. This can be extended for the different canisters in Protocol Canister Management too.

NNS members will choose to follow these named neurons, so we should encourage choosing non-DFINITY neurons to improve decentralization. If those named neurons are not voting 100% of the time on these topics then that creates an incentive to follow DFINITY instead to maximise rewards. Redundancy helps named neurons ensure that they are voting 100% of the time.

Additionally, the 4 eyes principle also applies to these reviews in my opinion.

Do you agree with applying principles to reviewers? If so, would it make sense to additionally include a mandate of how many people each grant is meant to support? So that bigger teams, such as CodeGov, may potentially apply for a multiple of grants in order to support the whole team?

8 Likes

Thank you @lara. and the rest of the team.

Excellent initiative to further decentralize the IC. Incentives are extremely important when it comes to token based governance. People’s Goodwill should never be relied upon for network security and good governance.

1 Like

@lara will you please confirm that this topic is only intended to cover the one topic that is named Protocol Canister Management and not all the topics that are currently called System Canister Management? It’s a substantially different (lower) number of proposals, so I just want to make sure I understand.

For the proposals for the canisters listed under Protocol Canister Management in the link, there have been an average of 2.8 proposals per week (max of 6 proposals and min 0 proposals) over the last 13 weeks.

Hey @Lara,

I finally had a chance to read your full proposal in detail and think about how the CodeGov project could contribute. Unfortunately, it doesn’t seem like this new grant structure is designed to support an organization such as CodeGov. The grants that are offered are well below the funding level that would be needed to support the bounties that are offered to our reviewers, and that’s without also considering the administrative burden of the organization. My sense is that these proposed grants are intended to be offered to teams of 1 – 3 people. The CodeGov team currently consists of 8 reviewers, 1 marketing manager, and 1 project manager and in the ideal world we would add 4-8 more reviewers to the team to thoroughly cover the full scope of IC-OS Version Election and what is currently called System Canister Management (not just Protocol Canister Management). Hence, it doesn’t seem appropriate to apply for these grants as a CodeGov organization in the form that they are currently presented. Instead, I will offer feedback below based on our learnings from performing this work over the last year and then let the conversation go wherever it goes. If CodeGov as we know it today ceases to exist, then so be it. It will morph into something new that remains actively involved in NNS governance. I welcome anyone on our current CodeGov team to add their comments as they see fit and to also form smaller teams to apply for these grants if they feel that fits their interests. Our team members have put in a lot of work over the last year that would enable them to build a strong resume to justify their candidacy for the grants that are offered, and I would fully support their pursuit of the grants in smaller groups.

To give you a sense of our current bounties, our reviewers are offered $150/hr (max 3 hours per proposal) for in-depth review of IC-OS Version Election proposal commits plus $30 per build hash verification. Our reviewers are also offered $100/hr (max 3 hours per week) for in-depth review of System Canister Management proposal commits and build hash verification of all proposals plus $15 minimum bounty per proposal. There are nuanced differences between how these bounties are scoped based on our experience so far with these proposal reviews and an attempt to manage our limited budget appropriately. There are likely opportunities to open the max hour limits a little wider so our reviewers can go into more depth on the commits with the hours that they are allocated. There are also opportunities to add reviewers so each reviewer can develop a specialization in different layers of the stack while still covering every commit in aggregate among all reviewers. In both cases, it would require an increase in funding, not a decrease. For the past 4 weeks (since we started reviewing System Canister Management proposals), the total bounty payouts have ranged between $5k - $8.5k per week depending on how many reviewers have been available, how many proposals are submitted by DFINITY each week, and the difficulty level of performing the reviews. This does not include the perspective reviewers that have expressed an interest in becoming CodeGov reviewers and who were paid for the work they performed during this trial period (which is now on hold).

Clearly the bounties that are offered in this new grant program ($5k per month) are very small compared to our existing funding needs, and the expected effort proposed for these grants is significantly larger compared to our current expectations. These details are so far out of sync that I don’t see a benefit to applying as a CodeGov organization because it would require applying for all proposed grants, that CodeGov is the only applicant, and that we take on more proposal topics…and we would still be underfunded. I’m not interested in trying to pick the best of the best among our reviewers to form a smaller team because they are all good and have all had their moments of brilliance that manifests during their reviews or their interactions with DFINITY and the community on the forum or GitHub or our OpenChat community. It’s also not a win-win if CodeGov attempts to apply for all the grants that are offered because a very important and worthwhile goal of this new grant program is to incentivize other people or organizations to participate in technical proposal reviews. I wouldn’t want to take away from that opportunity. It’s entirely possible that there are people who have not yet thought to apply for developer grants for the purpose of funding reviews of NNS technical topics who may now make themselves available for this task since it is being offered directly on the forum. It’s an experiment that I can understand is worth conducting.

From my perspective, having an organization the size of CodeGov where reviewers are not competing for funds enables us to freely collaborate and support each other during our reviews. The bounties are offered as a very reasonable supplemental income for a modest amount of time commitment to developers who are active in the ICP community. We currently have 8 Followees for IC-OS Version Election proposals and 5 Followees for System Canister Management proposals, which means our reviewers don’t have to worry about always being on call to perform a review when they have other plans for the weekend / vacation, or the proposal reviews don’t fit with the demands of their day job or core ICP project. We can easily absorb the burden when individual reviewers are not available to review and vote. We also find that it only takes one reviewer to find something odd about a proposal to justify rejecting that proposal. When we have more reviewers, it is more likely that the discovery is made early and communicated internally in time for others to investigate and vote accordingly prior to our Followees reaching consensus on the proposal. I am also finding that many of our reviewers are very happy to help new reviewers become acclimated to the work process. There are a lot of conversations about what to look for in a proposal and how best to approach the builds, the commit reviews, the reports, and a variety of ways to automate some of the tasks that are required. Hence, there are many reasons why an organizational approach can be more favorable than an individual approach.

To be honest, I am concerned that these grants are not right sized for the skill level that is needed for this work. Reviewing these technical topics is real work that cannot be performed by everyone in the community. Not only do they need to have developer experience, they also need to have Rust experience (at least for the first two topics listed). They need to be willing to commit to performing technical reviews on every proposal that is submitted to the NNS for their selected topic no matter what day of the week is it submitted, they need to commit to always voting on those proposals in an educated way, and they need to be willing to document their reviews and justify their vote. These are minimum requirements to become a credible and effective option as a Followee that people in the ICP community might be willing to follow. These have been the minimum requirements for CodeGov since inception and they are essentially the same requirements laid out in this new grant program. These tasks can be very interesting work, but it can also be very mundane and inconvenient. It is not volunteer work. People who have the skill set to perform this work and willingness to perform this work might require a higher funding level than what is offered, especially if they plan to form teams. It will be interesting to see who expresses an interest. I personally have no intention of performing the work of organizing a review team for free or asking any current CodeGov team member to accept a substantially lower bounty payment that is not competitive with other opportunities that they could find. I want the bounties that are offered to always be a meaningful incentive for their commitment. In the ideal scenario, these bounties would attract many technical people to perform this work among many teams. It doesn’t seem like that is what is being offered at this t