Grants for voting neurons

Governance NNS Governance
, ,
1

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: $7500 / month
  • Participant Management & Node Admin
    • Effort: ~ 2h / week
    • Grant: $750 / month
  • Subnet management
    • Effort: ~ 2h / week
    • Grant: $750 / month

Team grant: If you are a large team (e.g., 5+), and you have enough redundancy to be able to commit having at least 3 reviewers per proposal, you can apply for a team grant. If you do this and get selected for the grant, you receive $10K / month for protocol canister management, $15K / month for IC OS version election, $1.5K / month for participant management & node admin, and $1.5K / month for subnet management.

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 the following steps. If you are a large team that applied for a team grant, at least 3 reviewers should show that they performed the following steps individually:

    • 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 31st.

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
  • Whether you apply for a “team grant”
  • 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!

30 Likes
2

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.

6 Likes
3

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
4

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

5

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
6

@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.

7

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 time, but hopefully I am wrong and we end up with many credible options.

If CodeGov doesn’t end up applying for one of these grants, the CodeGov known neuron will still be managed to follow people who develop credibility and are actively participating in reviews of these proposals. The default position will be to follow known neurons other than DFINITY to help advance decentralization of the NNS on technical topics, but only if that results in 100% voting participation and only if those votes are typically cast before DFINITY votes on these proposals. Perhaps in 6 months when the funding mechanism switches to the NNS instead of DFINITY developer grants, and especially if funding is related to voting power that is triggered by the votes of known neurons, then maybe it would make more sense to rebuild a CodeGov organization that is focused on technical proposal reviews. In the meantime, the CodeGov project will advocate for the community of developers who find it worthwhile to step up to perform this work to help decentralize the internet computer at the protocol level.

17 Likes
8

Hi Lara,

Thanks for putting this effort, it’s indeed a very hard and complex topic as you are starting to enter into management and politics.

We (codegov) had our regular bi-weekly call and it was clear that there wasn’t even a rough consensus on the current design.

For the reasons already mentioned by Wenzel, Nathan and I on separate replies, my first strong recommendation is that we halt the application deadline (19th of July) and allow for at least rough consensus to be reached.

I am worried that rushing this design will be unnecessarily sub optimal and the quality of the reviews hurt.

Recomendation 1:

  • Application process is halted for allowing more time for a better discussion of the proposed process / design.
6 Likes
9

Will try to separate recommendations so we can have focused discussion:

  • are concerns probable and relevant?
  • is the recommendation the best that mitigates it?

I, Wenzel, Nathan, Zane and a few others on the CodeGov team voiced their concern about the change from a cooperative model to a competitive model :disappointed:

Concern 1 - Shared Training & Tooling:
We are concerned that peer training, documentation (like review primers) and open source tools (like the review website, notification, tally bot, etc.) will cease to exist in this competitive model.

In a nutshell, we completely lose the economies of scale in shared services / needs.

Concern 2 - Unfair / Innefective Competition:
Furthermore, it seems we are heading towards a “bigger the Voting Power, bigger the reward” kind of mechanism.

We worry that reviewers will be judged by popularity / marketing effort / collusion with power, than by their technical quality.

Reviewers should be competing by nr of missed reviews, by nr of issues found or by
Dfinity devs satisfaction (NPS) score, not by individual/subteam popularity.

On another note, the reviewers also don’t want to do communication kind of tasks, they rather prefer to delegate into a marketing / project manager that can efficiently run those tasks.

Recommendation 2:
I believe these concerns can be mitigated by having a “core team” that is responsible for all the “shared” services and needs of all reviewers. The way to implement it can be deeper discussed but think of just another grant (same process of applying and being selected or maybe the reviewers can elect this core/supporting team).

The responsibilities of this core team are:

  • facilitate periodic calls between all reviewers.
  • With the reviewers define which benchmarks they agree to be tracked and compared about.
  • by the end of each month, release the latest results (that should be facts that a third party / anyone else could audit).
  • 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 / colaboration 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.

With this “core team” concept, think we are able to mitigate all concerns without adding significant new risks. Of course there is cost, but we should see it more as an investment, an investment on consistency, quality and sustainability of the whole system. This “axis” allows for economies of scale on the shared services, the qualified supervising of the reviewers and impartial communication with Dfinity and NNS token holders.

Looking forward to feedback on this recommendation, it’s by far the most important I have.

10 Likes
10

Come on man, 5k is a lot for that easy task. Don’t come and steal investors money. I would voye againts you

11

It would be a lot for one person but not for a full team. It’s a lot of work to do these reviews thoroughly and it certainly benefits from having reviewers who are doing development work or something similar at a professional level.

5 Likes
12

Hi everyone,

Thank you for the opportunity to participate in the grant program and for all the information provided. I appreciate the engagement from the community and DFINITY.

I wanted to update everyone on my current situation. At the moment, I am traveling back to my country to meet in person with a few potential team members. We are in the process of forming a dedicated team of 2-3 full-time ICP developers.

Our aim is to offer the creation of decentralized solutions for various ideas and businesses at affordable prices and within fast time-frames. We believe that this approach will help foster innovation and provide valuable services to the ICP community.

The grant would significantly help our team to engage more deeply with the ICP ecosystem by providing us with the resources to focus on governance participation and understanding the latest API changes and protocol developments. This will ensure that our solutions are robust, up-to-date, and aligned with the community’s needs.

Once we have established the team, we will be able to discuss this opportunity further and consider how we can contribute to the NNS governance process effectively.

10 Likes
13

Your team seems like an ideal fit for this new grant opportunity @b3hr4d. I have been very impressed with your showcase presentations for the B3Forge (Candid UI) project and for the @ic-reactor (React Library) project. Both have been well received and provide useful tooling for developers.

I love the idea that grants to participate in NNS technical proposal reviews are used for supplemental income for teams that are building full time on the internet computer. I’m very excited to see that you are interested in this grant program and hope that there are 10 more teams like yours that express an interest for each of the proposed topics. Then perhaps the community would have a strong reason to ask DFINITY to reconsider the scale of this new grant program.

We need a lot of qualified teams like yours that are willing to step up to perform these reviews in order to help decentralize the NNS on technical topics. They should be well funded in my opinion. Teams of 2-3 developers make a lot of sense for the grant sizes that are offered. I look forward to learning more about your application.

8 Likes
14

Hi Lara,

Thanks for this announcement. I’m excited to see how this pans out, but I also echo the concerns already raised on this topic. I’m interested to see who is prepared to step up to the challenge of reviewing IC-OS and Protocol Canister Management proposals under this new level of funding (an hourly rate that is less than one that I would find motivating, given time and freedom sacrifices that are incurred - others may have a different threshold). That being said, it’s great that DFINITY is willing to put funds towards governance decentralisation.

There are a few points that I think would be useful to clarify for anyone interested in applying for these grants. The announcement mentions:

Candidates can apply in this forum thread if they consider themselves as experts for a particular proposal topic

but it also mentions:

This intermediate short-term solution has the following advantages… become experts for a proposal topic

These two statements seem to be in conflict. Is DFINITY asking for teams only that already consider themselves experts at reviewing a specific type of proposal, or also teams that are hoping to become experts through the process of being funded to take part in reviews?

Aside from IC-OS and the other proposal topics, I’m interested to see the introduction of a grant for reviewing Subnet management proposals. Subnet management (and IC OS version deployment) is something that I find particularly interesting (evidenced in various comments I’ve left on IC-OS release threads in recent months):

e.g.

That being said - I wouldn’t call myself an expert, at least not yet (also, I’m aware that IC OS Version Deployments are no longer strictly considered part of the System management topic, they were separated out into their own topic a while back).

There are 7 different types of Subnet management proposals that have been executed this year, and numerous other types of Subnet management proposal that have been executed historically. I’ve pulled proposal history from the API and gathered some stats. The average length of time that the majority of these proposals were open for in 2024 is roughly 2.5 days (there are also exceptional circumstances where they’re only open for a few minutes e.g. subnet recovery). There are also occasions where the frequency of these proposals spikes significantly (e.g. 38 subnet config updates in March vs 1 in May - granted, these were simple changes, but it still indicates the potential for significant variability in workload). Given this, would you be able to clarify the following:

  • What timeframe is a reviewer of Subnet management proposals expected/required to cast a vote within? (note that these proposals can appear without warning on any day of the week)
  • Given that the level of work required to review these proposals can vary, are there any provisions for upping the funding during busy periods? (and what if a reviewer cannot keep up with a period of exceptionally high demand?)
  • In the event that a proposal may seem to require rejection, what channel should a reviewer use to voice their concerns. Will there be a dedicated forum topic, as there is for IC-OS releases?
  • What happens after the 6 months are up (would a reviewer reapply, or is the idea that other candidates would be given priority?)

Thanks in advance :pray:

4 Likes
15

Hi @wpb,

Thank you so much for your kind words and support! It means a lot to hear positive feedback about our projects, B3Forge and ic-reactor. We are passionate about creating useful tools for developers and contributing to the ICP ecosystem.

I completely agree that grants for participating in NNS technical proposal reviews can be a great supplemental income for teams like ours, allowing us to focus on building full-time on the Internet Computer. We are excited about this grant program and its potential to support dedicated teams in their efforts to help decentralize the NNS.

We are in the final stages of forming our team, and we will definitely consider applying for this grant once we are fully set up. I appreciate your encouragement and look forward to collaborating with other passionate teams in this space.

5 Likes
16

I hate to do a drive-by post, but I’ve expressed this opinion more than a few times, so I’ll repeat my 2 cents here.

I’m certainly not against grants as a short-term solution, but I think it is a bad precedent to set and not a long-term solution.

Reasoning:

  1. As soon as people are paid for voting they have a bias and reason to add rigidity to the system.(see almost any legislative body, but especially the US houses).
  2. The incentive to vote should come from the value of the vote. If the vote has no real value, that is why no voting community has started voting for it and no one will unless paid to do so until it has actual value.

How do you artificially put a value on the vote? Slashing.

The people allowing the results of these votes to be installed on their machines, who get paid the rewards for providing the network infrastructure should be the ones validating these proposals.

Inject purposely wrong Protocol Canister Code, ICOS Versions, Subnet configs, Participant management, and node admin items and slash Nodes if approved. Or slash NNS Neurons if they approve fraudulent proposals. Those with large stakes or expecting large network rewards will rapidly bootstrap the infrastructure needed to verify and validate proposals and the infrastructure to reach out and collect followers without the need to pay people directly for voting.

Slash their node reward. Slash our NNS rewards. Build a Moloch Chaos Monkey and force organization and infrastructure creation.

10 Likes
17

I like the idea of giving grants to voting neurons to get more people involved in NNS governance. It’s great that this could help decentralize things and motivate folks to participate. Having specialized and redundant voting can really boost the decision-making process.

But I’m worried about centralization. If most people delegate their votes to the big neurons to earn more rewards, it could lead to a concentration of power, which isn’t good for diversity in governance. This goes against the decentralization we’re aiming for.

Also, the funding seems too low for larger groups, which might stop them from getting involved effectively.

In short, while the proposal has its good points, these concerns need to be addressed to keep the governance fair and decentralized.

3 Likes
18

This is correct, it should only cover the canister upgrades that will be in the new topic Protocol Canister Management.
Of course some of the other canister are also very important, but we thought it makes sense to start with a few topics.

4 Likes
19

Thanks for the suggestion. IMH we don’t need to halt this altogether, as incoming applications might also add to the discussion (whether there is even interest and where the current proposal is maybe not the best fit).
If we need to further discuss and clarify things, I would propose to just increase the deadline if we feel like we need more time.

Let me bring this up internally and get back to you.

3 Likes
20

I agree; there’s nothing wrong with bootstrapping the process for a few months or maybe even a year, but it should not be a permanent.

1 Like