Voting Neuron Grants – Season 2

Governance NNS Governance
, ,
1

TL;DR

  • Continuation of the pilot phase for incentivising voting neurons
  • 2 grants for each of the 7 most important proposal topics
  • Grants are disbursed to the selected recipients once a month as long as they provide monthly evidence for their work
    • Topics that require code reviews now include monthly calls where the grantees present proposal reviews and engage in discussions.
    • DFINITY would reserve the right to terminate the grant if the review is not satisfactory

Context & Motivation

The voting neuron grants were initially outlined in this forum post which provides additional context and outlines the motivation behind this initiative .
At this time, we want to expand the pilot phase of the Voting Neuron Grants (VNG) and also add additional topics (more info below). We currently plan this “season 2” to continue for at least six months or until an alternative solution has been implemented, whatever comes first.

Grants - high level

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

Season 1 topics (continued in Season 2)

  • Protocol Canister Management
  • 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 & API BN Management (we combine two topics here but refer both of them when we say “a topic to vote on” in the following)

Season 2 topics (new)

  • Application Canister Management
  • Service Nervous System Management
  • SNS & Neurons’ Fund

Season 2 Guidelines:

  • 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 and a satisfactory review by the DFINITY team (as applicable).
  • DFINITY reserves the right to terminate the grant at any time.
  • The terms and conditions outlined here apply to the voting neuron grants.

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: ~4h/week
    • Grant: $1500/month
  • Subnet management & API BN Management
    • Effort: ~4.25h/week
    • Grant: $1600/month
  • Application Canister Management
    • Effort: ~3.5h/week
    • Grant: $1500/month
  • Service Nervous System Management
    • Effort: ~1.5h/week
    • Grant: $600/month
  • SNS & Neurons’ Fund
    • Effort: ~0.75h/week
    • Grant: $250/month

Team grant: If you are a large team (e.g., 5+), and you have enough redundancy to be able to commit to 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 twice the size of the grant for individual reviewers. E.g. Protocol Canister Management would be rewarded with $10,000 instead of $5000.

What to do to get the grants

As a selected candidate, you are required to follow the steps outlined in this document to receive your grants.

More information about the application and selection process will be shared in a separate post once finalised. Thank you for your patience.

18 Likes
2

Thank you @cryptoschindler. I’m looking forward to submitting the CodeGov application for these grants.

5 Likes
3

These are great developments.

Good luck to all applicants.

8 Likes
4

This looks great @cryptoschindler, particularly the enhanced requirements for reviewers and the additional allocations for Application Canister Management, Service Nervous System Management, and SNS & Neurons’ Fund.

The CO.DELTA team are looking forward to engaging in the application process once it’s been finalised. Thanks again!

8 Likes
5

Much obliged @cryptoschindler. I would like to put more effort in contributing to the protocol. I am awaiting with high interest regarding the application and selection process.

2 Likes
6

I have a question regarding the monthly calls, it is stated each reviewer must present a proposal which hasn’t already been taken by someone else, but in the case of ICOS there are usually 4/5 proposals per review period which follow the required criteria. So how would this be handled if two teams are chosen to review the topic and the number of reviewers is therefore greater than the available proposals?

4 Likes
7

Hello!

Over the past year, several members of my team stepped away from this grant program - mostly due to the lack of funding and the repeatedly delayed election process. I ended up being the only one from our team who continued, spending part of my free time reviewing proposals, especially in the Participant Management & Node Admin topics.

For the upcoming season, I plan to apply under the ICP Hub Poland brand and also expand into the SNS & Neurons’ Fund topic. If funding is approved, I’d like to bring in a few more people, and eventually broaden the range of topics we review during future grant cycles.

Warmest regards,

Krzysztof Żelazko
Governance Lead, ICP Hub Poland

3 Likes
8

Thank you for this question! I think then we would need to cover the same proposal more than once.

2 Likes
9

Hey all,

I’m happy to be able to share more details with you regarding the application and voting process for season 2.

Application process

You can apply for a grant for one or multiple topics from the initial post.

To do so, present yourself in this forum discussion until Friday, August 15th.

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 perform the review tasks.

  • Your name
  • What topic(s) you apply for
  • The size of your team and whether you apply as an individual or a "team” grant
  • Introduce yourself, including links to LinkedIn, Github or other relevant social profiles. For team grants, please include brief bios for all reviewers.
    • Relevant experience (overall, in web3, on ICP)
    • Technical knowledge (can include links to projects, e.g., on github)
    • Current VNG participants should highlight the work delivered in the past
  • Why you want to be a voting neuron
  • Explain how you are contributing to the long-term success of ICP
  • Why you are interested in the topics you apply for
  • Why would 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 will vote for proposal review candidates who clearly demonstrate their ability to fulfill the responsibilities of the role. To ensure a transparent and consistent approach, we assess applications based on the following criteria:

  • Technical skillset: The candidate should have relevant technical expertise aligned with the types of proposals they intend to review.

  • Past contributions: Demonstrated involvement or meaningful contributions to the Internet Computer ecosystem are taken into account.

  • Clarity of application: Strong applications are clearly written, structured, and specific about how the candidate will approach review tasks.

  • Review track record: For candidates with prior participation, we consider how consistently they engaged in reviews, whether they followed review requirements, and whether they missed a significant number of proposals.

  • Avoiding concentration: We may deprioritize voting for the same entity across different topics to support a more distributed and representative reviewer set.

  • Fair decision making: As a neutral party focused on the long-term success of the NNS, we aim to make decisions that are objective, fair, and grounded in the rules. We would vote for each application based solely on its merits without any bias or speculative thinking.

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

11 Likes
10

Voting Neuron Grant Application - CodeGov

This is our formal application for the Grants for Voting Neurons program Season 2 offered by DFINITY.

We are applying for team grants for the following proposal topics:

  • IC-OS Version Election
  • Protocol Canister Management
  • Subnet Management & API Boundary Node Management
  • Participant Management & Node Admin

The CodeGov team has been reviewing and voting independently on these NNS proposal topics for almost a year as a grant recipient for these topics during Season 1, and we would be honored if the NNS would award us with the opportunity to continue in the grant program during Season 2. We have been successful at helping advance decentralization of NNS governance through funding from this grant program. We are a larger team of developers from the ICP community who have the skills to provide an educated evaluation of proposal details, document their findings, and a willingness to vote reliably on every proposal.

CodeGov

Details about the CodeGov organization including our manifesto, team members, and known neuron configuration can always be found on our website at codegov.org. The configuration of the CodeGov known neuron is actively managed to ensure that Followees selected for each proposal topic are fully committed and available to perform detailed reviews with a target timeline of 48 hours after proposal creation. The CodeGov known neuron vote is cast automatically by consensus among the selected Followees for each topic in which they specialize. In the rare event that we cannot reach consensus automatically due to unforeseen circumstances, then the vote for the CodeGov neuron is cast manually based on feedback from the reviewers who have been able to complete their proposal review within the established timeframe. Hence, we always strive to complete our reviews as soon as possible and well before DFINITY votes.

The CodeGov neuron owns the minimal amount of voting power required to participate in NNS governance, but we trigger 5-6% total voting power for the topics that we cover. Hence, the voting power that we trigger is 100% provided by other neurons who have chosen to follow us on these topics. This is a great honor and a heavy responsibility that we take very seriously. It inspires us to perform our due diligence on every proposal and reminds us that our work has been making a difference to the NNS governance community.

In addition to participation in NNS voting, we also have a CodeGov WTN neuron that votes on WaterNeuron proposals. WaterNeuron is a liquid staking protocol built on ICP that owns very large 6 month and 8 year neurons and enables WTN token owners to cast the votes for these large NNS neurons. CodeGov is involved in WaterNeuron to help provide a credible and reliable option for the WTN community to follow on NNS proposals. We built a vote relay canister that automatically casts the same vote on WTN NNS proposals that CodeGov already casts on NNS proposals. This canister has provided reliable replication of the Codegov vote between the NNS and the WTN SNS for over a year. Several months ago, DFINITY created a WTN neuron and forked our vote relay app in order to replicate their own vote. After over a year of active engagement in the WTN community, CodeGov has developed a strong reputation as evidenced by the high number of people who have chosen to follow us. This demonstrates an additional way that CodeGov is contributing to the long term success of ICP.

IC-OS Version Election

Team members reviewing this topic include @hpeebles @timk11 and @cyberowl. Demonstrations of our reviews can be found by searching the forum for the IC-OS-election tag and scrolling through the posts for easily identifiable CodeGov reviews. Select examples are also provided (137578, 136664, 136223). Even though only 3 reviewers are required for the grants program, we will often have 4-5 reviewers covering this topic to give more developers experience with the codebase.

Protocol Canister Management

Team members who intend to continue reviewing this topic include @cyberowl @timk11 and @LaCosta. Demonstrations of our reviews can be found by searching the forum for the Protocol-Canister-Management tag and scrolling through the posts for easily identifiable CodeGov reviews. Select examples are also provided (137582-83, 135286, 137499-500, 137262-67). Even though only 3 reviewers are required for the grants program, we will often have 4-5 reviewers covering this topic to give more developers experience with the codebase.

Participant Management & Node Admin

Team members who intend to continue reviewing this topic include @timk11 @LaCosta @Cris.MntYetti and @ZoLee. Demonstrations of our reviews can be found by searching the forum for the New Node Provider Proposals thread and scrolling through the posts for easily identifiable CodeGov reviews. Select examples are also provided (134664, 137071, 137077-78). Even though only 3 reviewers are required for the grants program, we will often have 4 reviewers covering this topic to provide a more diverse decision.

Subnet Management & API Boundary Node Management

Team members who intend to continue reviewing this topic include @timk11 @LaCosta @Cris.MntYetti and @ZoLee. Demonstrations of our reviews can be found by searching the forum for the Subnet-Management and API-Boundary-Node-Management tag and scrolling through the posts for easily identifiable CodeGov reviews. Select examples are also provided (137229-34, 135664-66, 137338-42, 137170). Even though only 3 reviewers are required for the grants program, we will often have 4 reviewers covering this topic to provide a more diverse range of perspectives.

Team Member Bios

Hamish Peebles (@hpeebles)

Co-founder and developer of OpenChat. Hamish graduated with a degree in mathematics from the University of Cambridge then leapt into the world of software engineering and has loved it there ever since. He enjoys finding simple solutions to complex problems with a focus on performance and scalability.

Tim Kirchler (@timk11)

Tim has designed or contributed to a number of projects on the Internet Computer. These include a multi-sig wallet built for the BUIDL Bitcoin Hackathon, an app for encrypting and sharing content using an early version of the vetKeys feature, an oracle to show estimated liquidity position returns, a Motoko-based Ethereum virtual machine and a machine learning model trainer using zero-knowledge proofs (in progress). Having originally come from a health science background, Tim holds a Master of Digital Health and Data Science from the University of Sydney and has a special interest in the application of blockchain technology and artificial intelligence to the health domain.

Jefri (@cyberowl)

Jefri, known in the ecosystem as cyberowl, is a seasoned software developer with a strong focus on the IC. He has extensive experience in blockchain development, particularly with Motoko and JavaScript, drawing from prior work with concurrent languages like Elixir and Erlang that follow the Actor model. Jefri has contributed to diverse projects, including a file uploader pattern for JS, Rust, and Motoko as part of an ICDevs.org bounty, a GitHub-like platform for designers, and a time capsule app that won the VetKeys hackathon. His code has been adopted by other developers.

As a key participant in CodeGov, Jefri reviews NNS proposals, verifies canister upgrades, and ensures the security, transparency, and integrity of decentralized applications. He actively engages in forum discussions on governance, SNS decentralization sales (e.g., Modclub, Seers DAO), and critiques failed projects like BOOM DAO to promote better practices.

Passionate about building products people :heart:, privacy, and true decentralization.

Henrique LaCosta (@LaCosta)

Henrique has developed and contributed to several projects on different blockchains, mostly on Ethereum and on the Internet Computer. Some of the projects include a lending protocol on CoreDAO for the ETH Lisbon 2023 Hackathon, a card game on the Internet Computer for the Build on ICP Portugal Hackathon, and contributions to the Obsidian Tears project, a blockchain-based 2D RPG with NFT integration. Currently Henrique is also working on a project for the World Computer Hacker League.

Cris MntYetti (@cris.mntyetti)

Cris has been active in the blockchain space since 2020, and aligned with the Internet Computer’s vision shortly after its May 2021 launch. He has a growing 8-year neuron since July 2021 and has spent the last four years deep in the IC trenches on a daily basis.

Chris’s background blends a technical foundation with hands-on work in retail, designing physical stores, mapping customer flows, and managing B2B sales. That experience taught him how people actually interact with systems, and how even the best strategy collapses when it’s disconnected from execution.

Today, Cris works at the intersection of Web2 and Web3, helping teams translate complex ideas into usable systems, structure projects to avoid chaos, and grow without losing direction. He has a strong passion for data analysis, spotting patterns, uncovering inefficiencies, and building strategies that solve problems at the root. Whether it’s fixing communication gaps in DAOs, tightening user flows, or aligning incentives across stakeholders, his focus is always on making things work in practice, not just on paper.

Zack (@ZoLee)

CodeGov team member for over 2 years reviewing all proposal types at one time or another.

Wenzel Bartlett (@wpb)

Founder and manager for the CodeGov.org known neuron. Founding member and manager for the Synapse.vote known neuron. Active participant in NNS governance for over 4 years.

Voting Principles

CodeGov team members vote independently based on their individual opinions but there are some commonly held principles. We aim to apply the same standards in our reviews no matter whom it might affect. We believe it’s important for reviewers to be as impartial as possible and to provide the reviews as information without veering into unrelated points or agendas.

We generally strive to reflect the wishes of the NNS community as expressed through community-approved Governance proposals, as these are a reference on what the current standards should be. Although there may be some cases where the standards can be counterproductive, most of the time they should be followed and we would prefer to see them being discussed and changed rather than simply being overridden.

We support the development of a well-functioning, safe and decentralized network. We encourage a high standard of proposals, whereby all the necessary information to enable any community member to plan their vote can be found in the proposal itself or by following links given within it.

Team Processes

While the teams listed above reflect our current plan to staff these reviews for any proposal topic where we are awarded a grant, we reserve the right to change these teams and our known neuron Followee configuration as needed. We will actively manage our team membership in a way that ensures we have skilled reviewers dedicated to each topic who can make the time and resource commitment to these reviews for the duration of the grant program. Hence, if anyone needs to drop out for personal reasons or because they are not in compliance with the grant requirements or our CodeGov team standards, then we will recruit and train others to fill their spots. We may also add additional team members as needed to ensure that we are able to fulfill our commitment to these proposal topics in the most reliable way possible. Performing technical reviews of NNS proposals is real work that requires skilled developers who are dedicated to the task every week. It can only be accomplished reliably with adequate funding that developers are willing to accept. Our reviewers are asked to review each proposal for technical correctness and compliance with established work processes defined by the NNS community and/or DFINITY and to vote on each proposal with their own convictions. They are expected to explain and defend their vote, but to always remain diplomatic and civilized in how they make their case. The fact that we have a larger team provides a safety in numbers where individual reviewers can have an opinion that differs from the rest of the reviewers, which provides an opportunity to raise awareness of differing points of view. Having a larger team enables us to be flexible in our organizational structure and work processes to ensure we are a reliable known neuron to follow on any proposal topic. We have spent a lot of time trying to gain experience and credibility as reviewers of technical NNS proposals and one of our goals is continuous improvement.

Final Remarks

Thank you for the opportunity to apply for these grants. Whether or not we get some or all the grants, CodeGov will remain committed to supporting decentralization of the NNS through active participation in governance. Our neuron will always be configured to follow people and organizations in the ICP community who have publicly announced that they are committed to being reliable and educated Followees on any proposal topic. We will not follow anyone who pencil whips their vote or casts automatic yes or no votes without first making a concerted effort to review technical details and vote with an educated opinion. If we cannot find suitable Followees for a specific topic, then of course we will follow DFINITY on that topic. DFINITY is an appropriate Followee for any topic because they offer an educated and active voice on all NNS changes. However, if decentralization is our goal, then CodeGov is here as an option to help enable the ICP community to move in that direction.

10 Likes
12

:glowing_star: Voting Grant Application: ICP Hub Poland

Hello ICP Community!

We’re excited to share our formal application for the Voting Neuron Grants: Season 2, kindly offered by the DFINITY Foundation.

TL;DR

ICP Hub Poland is applying for two grant topics:

  • Participant Management & Node Admin
  • SNS & Neurons’ Fund

This submission is made by an individual reviewer operating under the ICP Hub Poland banner. Our Governance Lead, active in NNS governance since genesis, was grant applicant of the Season 1 grant elections via proposals 131777 and 131776.

Our goal is simple: strengthen the decentralization of the NNS by growing the voice of Polish contributors, offering thoughtful reviews, and voting with transparency and care.

:office_building: About ICP Hub Poland

ICP Hub Poland is a growing community in the Internet Computer ecosystem. We focus on onboarding developers, organizing IRL meetups, and fostering local awareness of Web3 and decentralized governance.

  • X/Twitter: @ICPHUB_PL
  • LinkedIn: ICP HUB Poland
  • Team: Core contributors with regional dev outreach
  • Grant Type: Individual reviewer, aligned with a long-term vision of forming a team grant cohort in future seasons

We believe that empowering local voices is crucial to decentralized governance and want to accelerate Polish participation in this process.

:bust_in_silhouette: Our Reviewer Profile

:bullseye: Topic Focus Areas

:envelope: Participant Management & Node Admin

We have hands-on experience from Season 1 in reviewing node provider proposals. This includes:

  • Verifying hardware specs and region compliance
  • Catching anomalies in configuration, metadata, or reward schemes
  • Publishing clear and actionable feedback
  • Asking tough but constructive questions

This work is ongoing, and we aim to keep improving the quality and consistency of reviews.

:wrench: SNS & Neurons’ Fund

We care deeply about how decentralization through SNS launches is executed.

  • We’ve observed numerous SNS launches and participated in several as early community members or investors.
  • Too often, SNS proposals prioritize fundraising over working products.

Our approach is different:

  • SNS is not a pitch deck. It’s a moment of decentralization.
  • We look at team track record, MVP maturity, fair distribution models, and community readiness.
  • Tokenomics and voting structure matter. We analyze both critically.

You may not always agree with our reviews, but you’ll always know where we stand.

:white_check_mark: Voting Principles

  • We vote with conviction, not convenience
  • We document our decisions and explain our reasoning
  • We say “no” when a proposal raises serious concerns, but always respectfully
  • Our neuron is locked for 8 years, showing our long-term alignment with ICP
  • We advocate for regional voices, not out of favoritism, but to strengthen decentralized diversity

:locked_with_key: Long-Term Commitment

Whether this proposal is accepted or not, our efforts continue:

  • Publishing honest, detailed reviews
  • Contributing to forum and OpenChat discussions
  • Promoting governance literacy in Poland
  • Locking 100% of any reward back into our neuron to support the network
  • Recruiting and mentoring other Polish reviewers to form a future team grant cohort

:red_triangle_pointed_up: Final Thoughts

Thanks to DFINITY and the broader community for continuing to push NNS governance toward transparency, diversity, and resilience. We’re proud to play a role in this process and will continue to show up week after week.

We’re not just here to vote. We’re here to help build a better NNS.

7 Likes
13

I’ve tried expressing this a few different ways. Lane does a much better job of it.

3 Likes
14

Why not just do TL;DR here ? At this point we all know who we are ! never the less it is at least some sort of feedback regarding " Theater ". If you know you know.

1 Like
15

Core lesson is that startups like Urbit need a focused, visionary founding team to drive product development and achieve traction (product-market fit and revenue) before getting bogged down in decentralized governance.

16

I think your concerns are valid (if I understand them correctly). I skimmed that article and there’s a lot in there that I agree with and that also frustrates me.

The thing that’s needed in the context of Web3 governance is competition, and we should not be afraid to point out when we see others doing a bad or half-assed job. I think this is how you help to ensure selection pressure weeds out the unprofessional/unqualified and ensure those who are best suited to performing strong due diligence are given a platform and incentive to do so.

4 Likes
17

Voting Neuron Grant Application - Aviate Labs

Topic(s): Participant Management & Node Admin

Type: Individual

Reviewer: Louise Velayo (@louisevelayo)

Hi community,

Here is my forum post to officially apply for the Voting Neuron Grants, specifically for reviewing Participant Management & Node Admin proposals. My name is Louise Velayo, and I represent Aviate Labs. For these proposal reviews, I will be the only reviewer on behalf of Aviate Labs. But, as the team expands, this can change. I will make sure to update the community in such a scenario.

About Aviate Labs & Myself

Relevant Experience

Aviate Labs has been an active contributor to the IC ecosystem since genesis, with active involvement in node operations and Node Provider community coordination. We have served as a long-term infrastructure partner for one of the largest node providers, supporting everything from initial onboarding to maintaining operations. Our experience goes beyond managing nodes. We’ve developed tooling, led community efforts, and on some occasions, have provided feedback to DFINITY to test, refine, and improve node-related processes.

Operational Expertise

  • 4+ years of node operations for Allusion across three data centers in Belgium (recently scaled down to two: BR1 and BR2).

  • Direct, hands-on experience with the IC-OS installation process and lifecycle of nodes, from setup to maintenance and upgrades.

  • Very familiar with the node provider documentation, including how it has evolved over time and where friction points exist for new entrants.

Tooling for the Community

  • Built and open-sourced a node alerting service in October 2023 that notifies node providers when their nodes go offline. This service is fully hosted and maintained by Aviate Labs.

  • Currently developing the Node Monitor Platform, a comprehensive tool suite for node providers offering trustworthy metrics, alerting, and proposal generation to support performance-based rewards. This project is also a grant recipient.

Ecosystem Leadership

  • Organized the first-ever Node Provider ICP Lab, bringing together over 20 node providers for peer exchange and alignment.

  • Serving as the Community Lead of the Node Provider Working Group, facilitating regular dialogue and collaboration between node providers and DFINITY.

Technical Knowledge

Aviate Labs’ technical knowledge related to these voting topics is best demonstrated to our active projects related to Node Providers:

  • Node Monitor: Used by ~30 out of 94 node providers to monitor node health and receive actionable alerts.

  • Public Node Metrics: Creating tooling and documentation to enable Node Providers to more easily set up Public Node Metrics (hardware-level) metrics to be exposed to the community (work in progress).

  • Rewards Dashboard: Live dashboard showing how the performance of a node, based on its success in proposing blocks, translates into node rewards data.

  • Registry Explorer: A new tool to simplify navigation and inspection of the NNS registry, useful for proposal reviewers (work in progress).

Notable Reviews

A complete list of my reviews is available in this spreadsheet, but here are a few highlights that demonstrate our contextual and technical understanding:

  • Proposal 136699: We identified that a cleanup proposal was set to incorrectly remove pending node operators due to a misinterpretation of the “rewardable” status. While all other reviewers voted to adopt, we voted to reject due to our awareness and understanding of the full context timeline. The broader community ultimately voted the same way. This illustrates the importance of historical awareness when reviewing proposals.

  • Proposal 137203: Spotted an incorrect assumption in a proposal’s explanation of the IC’s target topology. While we still voted to adopt, the correction demonstrates our ability to balance accuracy and attention to detail with governance pragmatism.

  • Proposal 137343 & 137412: We flagged incorrect documentation that most reviewers overlooked. Despite recent changes to the model, we stayed up to date and delivered a thorough review. While nearly all other reviewers voted to adopt, and the proposals ultimately passed, this instance highlights our commitment to upholding the standards set by the NNS and the broader community. We’re not afraid to vote differently from the majority when the facts warrant it.

Motivation for Becoming a Voting Neuron

We believe that governance, especially around node onboarding and administrative processes, must be grounded in real operational insight and lived experience. That’s why we feel it’s critical that at least one voting neuron comes from a team with direct hands-on experience like Aviate Labs.

Among all the reviewers from Season 1, Aviate Labs was the only team bringing that operational perspective to the table. Our goal is to ensure governance decisions related to participant management are informed, accurate, and ultimately strengthen the resilience of the network’s infrastructure.

Contribution to the Long-Term Success of ICP

We are building the tools and services that enable others to join the network more easily. By creating tools and documentation that simplify the experience for node providers, we reduce the friction for onboarding and scaling.

In the long term, as the network expands beyond the current target topology, these tools will play a key role in accelerating node onboarding and operational excellence. Our work is aimed at making the ICP infrastructure more robust and scalable.

Interest in Participant Management & Node Admin

Our interest in these topics comes directly from hands-on experience in node operations and involvement in initiatives like the Node Provider Working Group. At Aviate Labs, everything we do is centered around supporting node providers, so naturally, we’re interested in understanding who these entities/individuals are, where they’re setting up nodes, and what their experience is like navigating the governance processes.

Reviewing proposals gives us valuable insight into the evolving state of the network and helps us stay closely connected to the individuals and companies behind the infrastructure. It’s one of the best ways for us to stay aligned with the ecosystem’s needs and continue building relevant tools and support systems.

Long-Term Commitment

We are committed to voting beyond the grant period. Our roadmap, especially around tool development, relies on an informed, well-managed governance process. By staying involved, we ensure that our tools remain aligned with governance developments and serve the ecosystem effectively.

Voting Principles

Our foundational belief is that the NNS is the source of truth. Accordingly:

  • We base evaluations primarily on the proposal text and forum posts that are directly linked in the proposal.

  • Where the NNS provides no clear precedent, we look to:

    • Previous proposals of a similar type that can serve as precedent.

    • Community discussion on the forum

    • Discussion with other connections in the ecosystem

    • Judgement informed by our experience, long-term context and input from the points above.

We are excited about the opportunity to continue to contribute to the governance process and to continue supporting the NNS governance structure through clear, technically informed, and operationally grounded proposal reviews. Thank you for your time and consideration :folded_hands: .

7 Likes
18

Proposal 137683 Observations | Lorimer :infinity: :dog_face: - CO.DELTA △

VOTE: YES

TLDR: Proposes to create a known neuron called Gwojda. This neuron belongs to Gautier Wojda, and the proposal was submitted by him. Based on discussion with Gautier, my understanding is that he plans to submit an application for season 2 of the Grants for Voting Neurons initiative, covering Protocol Canister Management as an individual reviewer.

CO.DELTA has also recently onboarded Gautier as a co-owner and reviewer (all team members are co-owners in CO.DELTA). We currently have a surplus of reviewers who are ready to cover the Protocol Canister Management topic, and instead I’m delighted that Gautier will be covering IC OS Elections, Application Canister Management, and Service Nervous System Management as part of a decentralised team in CO.DELTA.

Please support his known neuron proposal to help advance decentralisation of the NNS. Please also note that there is no rule requiring a known neuron proposal to be announced in advance (more info).

You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.

CO.DELTA △

We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:

  • Look: We observe the details and context of NNS proposals
  • Test: We test and verify the claims made by those proposals
  • Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.

Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.

2 Likes
19

Proposal 137683 Observations - Wenzel | CodeGov

VOTE: YES

TLDR: I am voting to ADOPT this known neuron proposal because I have direct experience working with @Gwojda in the capacity of reviewing technical proposals and I believe he will be a strong contributor to the Internet Computer as a known neuron.

Background: The CodeGov team has been searching for additional developers to add to our team and one of our team members (@ZoLee) recommended @Gwojda. Hence, I reached out to him about a month ago and asked if he would be interested in reviewing Subnet Management, Node Admin, and Participant Management since I was aware that he maintains nodes for Etragone and Decentralized Entities Foundation. During those initial discussions, I learned that he is a developer and auditor for Origyn and GoldDAO and has released public projects (here and here) recently. He expressed an interest in getting involved in other proposals that are covered by CodeGov including IC-OS Version Election and Protocol Canister Management. I was quite excited about this opportunity because @Gwojda sounded like the perfect candidate to become a team member for CodeGov. He is heavily involved in ICP projects and is willing to supplement his income by performing NNS proposal reviews for the most important technical topics. I offered to let him perform reviews on a trial basis so we could verify that his skills were a match, but also so he could verify that performing these reviews is something that he wanted to commit to longer term. Below are links to all the reviews that he performed over the last 3 weeks for CodeGov and for which he will be paid equivalent to all our other reviewers for his work as per my commitment to him.

IC-OS Version Election

Proposal 137578 and 137579
Proposal 137497 and 137498
Proposal 137345 and 137350

Protocol Canister Management

Proposal 137582 and 137583
Proposal 137499 and 137500
Proposal 137346, 137347, and 137348

Unfortunately, I learned on Monday of this week that @Gwojda had been approached by @Lorimer (and others) about joining co.delta instead of CodeGov for the purpose of reviewing IC-OS Version Election (IC-OS VE), Application Canister Management (ACM), and Service Nervous System Management (SNSM). Of course, he would have been paid more by CodeGov since I had already offered the opportunity for him to cover Protocol Canister Management (PCM) in addition to IC-OS VE, ACM, and SNSM, which are all topics he expressed an interest in reviewing. Nevertheless, I can respect his decision to join co.delta instead of CodeGov.

Since he was not offered the opportunity to review PCM, I offered to let him join CodeGov specifically for that topic. There is already precedent for participating in proposal reviews with 2 separate entities, which is not an issue in my opinion.

I also offered to pay him to continue to review IC-OS VE and PCM for the remainder of Season 1 knowing that he would be switching to co.delta if they are awarded grants in Season 2. This is in keeping with my policy with every reviewer that has left CodeGov including @lorimer and @Zane . My goal is to always keep developers incentivized to perform the work of NNS proposal reviews any time I have the funds to do so.

@Gwojda indicated an interest in both of these offers (PCM Season 2 with CodeGov and IC-OS VE and PCM for the remainder of Season 1). However, yesterday (Friday) I learned that @Gwojda had been persuaded to take a different approach again. He is not going to perform IC-OS VE and PCM reviews for CodeGov for the remainder of Season 1, but he is going to do them pro-bono. He is also going to apply for the PCM grant as an individual. Of course, this sounds like some higher level politics at play here ( @Gian @Dustin @borovan @Thyassa do any of you happen to have any insight? ), but we didn’t really discuss it further. He has repeatedly pointed out that he prefers to remain in the shadows focused solely on the technical stuff, which I fully understand.

While I am disappointed that he has been persuaded to not join CodeGov, I am very happy that there is a path forward for @Gwojda to get involved in technical NNS proposal reviews. His skills and experience are a perfect match. In the event that co.delta and/or @Gwojda do not win the respective grants for Season 2 and CodeGov does, the opportunity will still exist for @Gwojda to join CodeGov whenever we need additional reviewers. Any time I can provide an opportunity for skilled developers like him to get involved, I will at least make the offer.

This experience has made me wonder if there are other developers who work for Origyn, GoldDAO, Decentralized Entities Foundation, Cecil DAO, Bity, and other related entities who would also be of great benefit to the internet computer ecosystem if they were to engage in NNS proposal reviews. What do you think @Gian @Dustin ? Have you ever considered offering grants to any of the skilled developers that work for you (or to others in the ICP ecosystem) to get involved in NNS proposal reviews? It really shouldn’t be just DFINITY that offers these grants. ICP is a governance token at it’s foundation and the original intent of the tokenomics was to incentivize people and organizations to roll up their sleeves and actively engage in the proposal review process. The logic was that larger participants would find it important to use a portion of their maturity to pay for resources that help protect their interests in the protocol. Of course, this isn’t out of distrust for DFINITY. It’s simply about having a vested interest in making sure that the changes that are made to the protocol are consistent with your own expectations and doing your part to ensure that real work is being done to justify earning your investment returns (since ICP is not intended to be a security). Ideally, you would be putting people into a position to evaluate all NNS technical proposals and you would be following their vote on those proposals that they review instead of following DFINITY on everything. Otherwise, I would argue that we don’t have true decentralization. We need more technically skilled people performing this role. More importantly, we need more whales, founders, and larger organizations in the ICP ecosystem playing a bigger role in NNS governance. It would be awesome if you would consider using a portion of your maturity in your investments to offer grants to the community for this purpose (similar to what DFINITY is doing) or, even better, hire people to to work directly for one of your organizations who are responsible for NNS proposal reviews that are disclosed publicly. Perhaps you could reach out to @cryptoschindler @Lomesh-dfn1 and/or @Jan to learn more about how you could contribute in this way. Maybe you could sponsor some additional grants for Season 2 and an easy way to get involved.

About CodeGov
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron's Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.
3 Likes
20

Hi Moritz, CO.DELTA held a meeting on Friday with all co-owners, including our newest member Gautier, and we have subdivided ourselves into reviewer sub-teams that will specialise on the various topics. We’re also in the process of onboarding another co-owner/reviewer.

Given that collectively we’re a large decentralised team (9 or 10 members), and given that we plan to apply to cover all topics (but as specialised sub-teams), our expectation is that it would be best to create separate application posts for each topic, given that these are the posts that become the proposal summary (on each topic-specific motion proposal). Each post would focus just on the members who will be covering that topic. This means there may be a little bit of duplication between some posts, but also each of the team member personal statements will contain topic-specific info. The expectation is that this will make it easier for voters to grasp each of the proposals, making sure the motion text is focused on what that specific motion proposal is about.

Do you have an thoughts or recommendations about our suggested approach? Would DFINITY prefer to see a single post that covers all topics and team members? The latter approach would mean a less focused post that I expected would then be duplicated across the various proposals.

I’d also like to reiterate that our entire setup is decentralised (neuron, fund disperal canister, and all other aspects). We’ll be formalising the newest members in the next few days. Each sub-team within CO.DELTA thereby acts as a distinct entity covering their respective topic, thereby ‘avoiding concentration’. There’s no hierarchy or central element to the CO.DELTA collective, and all funds are 100% directed to the reviewers involved in each topic.

Please let us know if you have any concerns about this aspect.

Thanks

3 Likes