Increasing Decentralization & Reducing ICP Inflation with a Single Proposal

Note: I especially encourage team members of DFINITY to articulate their positions, solutions, and feedback on Periodic Confirmation of Neuron Followees proposal. Feedback from all angles is welcome (tokenomics, security, technical implementation, and NNS governance).


  • Reduce voting rewards inflation by ~40%
  • Spark network decentralization

Do this by implementing a single proposal that has already passed the NNS, Periodic Confirmation of Neuron Followees.

Original Forum Post
NNS Governance Proposal from April 2022 (passed)

Background on Inflation

Recently, @dominicwilliams posted some ideas around optimizing network tokenomics. The goal of the first idea was to reduce inflation that comes from NNS staked voting rewards.

Voting rewards are by far the greatest contributor to network inflation, 15x that of node provider rewards. Therefore, in order to make a dent in network inflation, voting rewards are the first reasonable place to make changes.

Screenshot 2024-05-19 at 21.18.18

@bjoernek published an inflation analysis report a few days later, showing the effect of variants of Dominic’s tokenomics ideas if they were implemented.

Bjoern determined that the impact on voting rewards inflation (not including node provider rewards) would be:

The most upvoted comment in Dominic’s Tokenomics post came from @Manu, who suggested

Background on Decentralization

One of the major criticisms that people outside the Internet Computer ecosystem have about ICP is just how decentralized the network is.

While the hardware is decentralized amongst node providers, when DFINITY votes on a change to the network on:

(Active voting power refers to counted voting power that actually votes on the proposal, while)

So DFINITY instantly passes code updates, but not governance or SNS code updates. Why is this the case?

At Genesis, DFINITY and the Internet Computer Association were the default, and only named neurons in the NNS. Around the end of 2021, the DFINITY foundation passed a change removing itself and the ICA as a default followee for the governance topic. Additionally, the new SNS proposal topic (initiated in late 2022 for the SNS-1) does not include DFINITY or the ICA as a default followee.

DFINITY has not yet removed itself or the ICA as a default followee for all non-SNS and non-governance proposals.

Learnings from removing the default followee

  • Decentralization takes a combination of action & time
    • 2.5 years after the changes to governance default following, roughly 50% of voting power is not triggered by DFINITY
    • The newly introduced SNS topic in 2022 has a similar voting power to that of the governance topic
    • During the same time period, there have been no changes to voting power triggered by DFINITY on non-SNS and non-governance proposals, and DFINITY is still the default followee on these topics

Is Decentralization of Updating the Internet Computer Network Important?

  1. It’s listed as one of the major roadmap categories on the new Internet Computer Roadmap

  2. Members from DFINITY have acknowledged the “current level of decentralization” as a fair criticism of the Internet Computer.
    Increasing Decentralization on the Internet Computer

  3. It’s one of the major selling points DFINITY makes for choosing ICP over other blockchains or centralized solutions

Screenshot 2024-05-19 at 20.41.52

  1. The Internet Computer’s Bitcoin Integration is backed and secured by the current level of decentralization of the network.

Screenshot 2024-05-19 at 20.47.55

  1. The Periodic Confirmation of Neuron Followees proposal was spearheaded and passed by the ICP community over two years ago. This proposal was important enough to be passed by the decentralized ICP community, but it has yet to be implemented. It is also listed as a “future feature” (not immediately important) roadmap item under Governance and Tokenomics category.

Screenshot 2024-05-19 at 21.07.29

What are the exact implementation details of Periodic Confirmation of Neuron Followees?

There are various implementation options for periodic confirmation of followees, which I encourage others to discuss.

In short, the details can be worked out, but voting power isn’t changing drastically anytime soon. The original Periodic Confirmation of Neuron Followees proposal was intentionally vague in order to provide leeway in the solution.

So let’s all try to find a solution that works for both the ICP community and DFINITY.


I wonder why @dominicwilliams and Dfinity shelved this for so long after it passed a vote in which they also voted for? Seems like a simple adjustment to make that would eliminate dormant accounts from printing rewards without actually participating in the Dao.

Our main problem is not inflation, but the sale of ICP from wallets with over 1 million ICP. These sell continuously… BR Thomas


In my opinion, a professional consultancy should be paid for, involving a renowned economist from the Austrian school. This economist would provide annotations on the proposals in this thread and offer suggestions.

Definitely Keynesian models are not desired for healthy tokenomics.


Isn’t this just asking the tokenomics question differently?
I thought we were finished with discussions of tokenomics?
Dfinity said they weren’t pursuing tokenomics anymore??

But for un used neurons or dominant ones, I agree. But it would need to require confirmation.

Hi @justmythoughts thank you for sharing your thoughts. I plan to provide some feedback next week.


Context on Periodic Confirmation

  • The idea of periodic confirmation of followees was initially proposed as a spam prevention measure. However, this issue has been addressed through an adjustment in the reward distribution.
  • At ICP genesis, all neurons were configured to follow DFINITY by default. Consequently, the suggestion for periodic confirmation has remained popular within the community as a method to trigger neurons to reaffirm or modify their choices.
  • While there seems to be broad community support for this proposal, concerns exist regarding its impact on user experience, particularly for those users who use the Network Nervous System (NNS) infrequently.

Suggested Alternative: Soft Reset

@diegop recently suggested a simpler alternative that aims to achieve similar outcomes with less effort. Here is how the soft reset would work:

  1. DFINITY would establish a new known neuron for other neurons to follow.
  2. During a transitional period, DFINITY would vote with both the old and new known neurons. After the transitional period DFINITY would stop voting with its old known neuron. This period could be managed differently across various proposal topics, allowing us to throttle the process to effectively test and measure the impact.
  3. Concurrently, a user information campaign would be launched to ensure everyone is aware of the change. Furthermore the migration of voting power to the new DFINITY neuron and other known neurons could be monitored.

This approach would have the following benefits:

  • Minimal implementation effort.
  • Addresses the main concern of resetting followees without affecting user experience on a periodic basis.
  • No modifications required to the existing NNS rules. This suggestion aligns with the expected protocol for following; if a neuron that someone follows stops voting, it does not lead to any unexpected disadvantages. It is the responsibility of the follower to ensure they are following neurons that align with their interests.

Additional Considerations

It is worth noting, mirroring comments from the thread above, that a soft reset or periodic confirmation of followees could lead to a at least temporary reduction in inflation. We view this more as a potential side effect rather than the primary goal of the proposal.


The proposed soft reset approach offers a pragmatic solution to the main issue driving the need for periodic confirmation—a reset of default following—without introducing drawbacks related to implementation complexity or user experience deterioration. We encourage the community to share their feedback on this approach. Specifically, we would like to hear whether community members believe this approach effectively addresses the main issue underlying the proposal for periodic confirmation.


Even if you (Dfinity) transition to a new neuron, we need periodic follow up. If you can’t be bothered to check your investment on the NNS every six months, you aren’t contributing to the ecosystem in any meaningful way. Keep hotkeys so that you can vote from platforms like OC and vpgeek but the aggregate voting power from known neurons is an absurd concept to me. Giving up your voting power to blindly follow anyone, even the developers, shouldn’t allowed or rewarded.

Also, I don’t agree that periodic follow was addressed adequately through an adjustment in the reward distribution if we are still having conversations about it. Dfinity (and their cumulative voting power) was in favor of it prior, so it should really be implemented or at a minimum a revote of the community. Do we plan to do a soft reset every 3 years when this continues to be an issue?

I personally think everyone should be required to manually vote. This is especially true in order to receive rewards. The disallowing of following votes would also keep SNS projects from executing middle of the night treasury drains that automatically pass because everyone follows the developer neuron. Example from last year…


There are a few nuanced details that are important to this conversation that I think are easily lost in the discussion of resetting default following. They really should be part of this conversation.

  1. There is no neuron in the NNS that follows DFINITY by default on the Governance proposal topic or the SNS & Neurons Fund proposal topic. The only default following that exists is on technical topics, which are all the topics that fall under the “All Topics Except Governance and SNS & Neurons Fund” catch-all category. Anyone who is following DFINITY on Governance and SNS & Neurons Fund is doing so by active choice whereby they manually chose to follow DFINITY at some point in time after their neuron was created.
  2. At this time, is the only public known neuron (ID 2649066124191664356) besides DFINITY that is intentionally reviewing, making educated decisions, and voting independently on the IC-OS Version Election proposal topic and the System Canister Management proposal topic. Our work is documented throughout the forum and in our CodeGov community on OpenChat.
  3. There is no funding mechanism built into NNS governance rewards, or any other mechanism, that incentivizes people or organizations to contribute to the decentralization of the NNS on technical topics. The only reason CodeGov can exist to perform our work is because the funding comes from developer grants, which is not guaranteed and arguably not sustainable.
  4. If we want known neurons that provide an option for people to follow to advance decentralization of the NNS on technical topics, then we need those known neurons to be skilled developers and/or people/organizations who specialize in specific proposal topics. They must be committed to reviewing and voting independently on every proposal for that proposal topic. This is real work that nobody will do for free. It does no good for decentralization and is unhealthy for the internet computer if those votes are cast by some default NO or default YES mechanism. Our goal should be to have educated voting on technical topics.
  5. If the primary goal behind a default following reset is to advance decentralization of the NNS, then I don’t see how we can achieve that goal unless people and organizations are incentivized to perform the work of reviewing technical proposals and offering a reliable option for people to follow besides DFINITY. DFINITY is a reliable option for following on technical topics, so any kind of reset to default following will likely result in people choosing to follow DFINITY. While that makes it an intentional choice for each neuron owner, I’m not sure we can argue that it achieves decentralization. Implementing a reset today might be premature.
  6. If decentralization is not the primary goal for people who support the reset of default following today, then I’d be interested in learning more about why resetting default following is so important at this time. It’s definitely not to resolve the spam issue that once plagued the NNS since that was solved in a different way.
  7. The advantage of default following today is that it enables DFINITY to execute proposals immediately if there is a critical update. This happens according to the definition of Immediate Majority Decision (the definition can be found on the dashboard by looking at the fine print of the Voting Results section of any proposal) and is enabled because of default following. DFINITY does not directly control enough voting power to trigger this type of decision by themselves and if voting on Governance proposal topics is any indication, it is not likely that they will achieve this ability if default following is reset. Without default following, proposals will likely take days. For the Governance topic, DFINITY triggers 27.3% of total voting power in the NNS when they vote, but they only directly control (own) 19.65%. Hence, a lot of voting power in the NNS that is cast on Governance proposals is triggered by neurons other than DFINITY and it takes time for those votes to be cast. This could have a negative effect on voting for technical topics if there are not other organizations that are also committed to reviewing and voting expeditiously. However, an advantage to the soft reset being proposed is that DFINITY can choose to hold off on the transition for the proposal topics that are typical candidates for critical updates (e.g. IC-OS Version Election). It will be important for the community that wants a default following reset to be cognizant of the need for DFINITY to implement critical updates, which means it may not be a full reset any time soon.

I believe it is important to advance decentralization of the internet computer because of the power it can have to protect the protocol, but to me this is a transition that should occur over 10-20 years. It seems to me that a higher priority than resetting default following should be to find a way to incentivize people and organizations to contribute to the decentralization of the NNS on technical topics. We need those people and organizations to develop expertise and track record as a reliable known neuron option on technical topics, which I don’t think will happen without incentives and will not happen over night.


I agree with most of @wpb’s points. I think doing this one-off change where DFINITY switches to a different neuron makes sense and is easy to do, but i don’t see it as a full alternative to periodic confirmation, because currently nobody is incentivized to actively vote, so most neurons will likely follow dfinity again.

The best path i see towards more decentralization is

  1. incentivize voting & being followed, for example by giving a share of the voting rewards of a following neuron to the neuron that is being followed. This means that an entity such as codegov would be financially rewarded for the work they do.
  2. have periodic confirmation, such that neuron holders regularly reassess whom they follow, and that new neurons have a chance of collecting a significant following if they convince the community that they are carefully voting.

I think just doing one of the two will mean that voting power stays where it is, so i believe we need both.


I agree that this sounds quite important. Is there a forum thread or working group ready to put forth concrete proposals? I’m interested to discuss.


Beautiful I love these two points. I wonder if the incentive should work something like this:

  1. Individual voting rewards are highest when voting manually
  2. If voting through following, a portion of rewards are docked from the follower and given to the follower

So then we incentivize manual voting and followed voting, with what I hope is a bit of a check or balance.


I think I just repeated point 1 @Manu , so maybe just take it as emphasis.

Where should we discuss this kind of incentive mechanism? It’s long been floating around, for years, let’s actually try and get broad consensus on this to implement it.


I agree with this idea to offer higher rewards for manual voting, but I hope that can be scoped where the manual voting that is rewarded is an educated vote that is cast with the intent of offering protection to the protocol instead of a sole intention to harvest rewards (without caring about protecting the protocol). People may try to game the system by automatic voting and/or pencil whipping their votes without understanding or thinking about what they are voting on. Reviewers for CodeGov write public reports on their observations and conclusions when they perform a review of proposals, which serves as a type of proof of work that they actually reviewed the proposal. Anyone is able to read their reviews and decide for themselves if the CodeGov team or the individual reviewer is actually performing the work. While I created this policy when CodeGov initially launched over a year ago, we have discussed these reports several times as a team and continue to believe that these reports are an important product of our work. I’m not sure exactly what that proof of work needs to look like if manual voting is incentivized across all of the NNS, but hopefully there is some way to identify and prioritize educated voting if these types of incentives are implemented.

I’m not aware of any at this time, but I agree it would be interesting to discuss.


Many thanks for the great feedback received so far!

I understand the connection being made regarding incentives for known neurons and resetting of following.

I would like to understand more what people think regarding the frequency of a potential resetting of following: Assuming we already had effective incentives for known neurons in place, would we need a periodic reset, or would a one-off reset be sufficient?

1 Like

I think the key criteria should be that people make their own decision about who they follow and they actively manage the neuron. The former could be addressed by a one-off reset some day. The latter could be handled in various ways, one of which is a periodic Followee reset. An alternative is to simply monitor for liveness of the neuron owner. Any action taken on the neuron that can only be performed by the controller of the neuron could count as liveness. That could include manual voting, hotkey voting, configuring Followees, changing the dissolve delay or dissolve state, successfully logging into the NNS dApp using the II anchor that controls the neuron, sending a successful DFX command such as get_full_neuron, etc. Hence, it doesn’t necessarily have to be a periodic followee reset that demonstrates that the neuron owner is alive and actively controlling the neuron. I think it is important to eventually stop paying governance rewards to neuron owners who have lost control of their neuron, even if that means simply triggering a dissolve on any neuron whose owner hasn’t been active in any way over a specified period of time. It’s reasonable to assume that anyone who exercises any type of control of their neuron is intentional about who they follow, so I don’t think the Followee configuration needs to be reset if we can assure liveness in other ways.


Great ideas here around neuron liveness and incentivizing becoming a followee.

However, any sort of liveness measure or check can be automated or botted around say, via a hotkey. It’s also less predictable to say “be active once every 6 months”, because that timeline is different for different people.

The simplest solution would be to require the user to log in once within July 1 - December 31 each year (6 months ahead of time) to confirm new followees. Any followees not reconfirmed are reset (cleared) on January 1st (UTC time) every year. You essentially log into the NNS, there’s a banner saying you have X days to reconfirm, and you press a “YES” button to reconfirm your followees.

Most countries require you to get a new identification card every couple of years or file taxes once a year. I don’t think it’s an outrageous idea to require logging in and reconfirming settings to continue earning rewards, but some at the foundation may want to speak to legal counsel about this before moving forwards, as some litigious people will undoubtedly miss out on rewards if this change is passed.

Regarding incentivizing followees, it’s quite clear after turning 3 years old that an independent contributor to the protocol (other than DFINITY) won’t spring up on its own unless there is a financial incentive. I’m a huge supporter of the foundation’s funding of the CodeGov project, but this also drives the point home that working to govern the protocol isn’t free, nor should it be free.

I think this will actually take care of itself, just as it has with governance. People will follow the neurons that put in the work. At first, this will probably just be DFINITY (and maybe CodeGov for some).

But that’s ok. Because the $$ will be there to drive recruiting efforts to expand CodeGov, as well as other organizations and individuals.

@Manu does DFINITY have any programs or plans to reward not just followees, but those that submit code-related proposals that get passed and adopted into the protocol?


I would strongly caution against paying people to become experts from the NNS rewards. This leads to professionalization for the sake of, which can be initially good but leads to fragility and lock-in of whatever system emerges. As soon as the dominant group is getting paid they won’t change a damn thing even if it needs to be changed. (See the US house of representatives and Senate).

If you want to pay them, then make the review and configuration of the network worth something. I guarantee you that if you put node providers on the hook for validating their replica and had multiple replicas with real slashing if the code doesn’t work then they’d all become massive experts on replica reviewing. Hide traps in each build that can only be avoided by adding magic strings to the config and you’ll have people looking really hard at the code base.

I’m not sure how to incentivize mundane things like subnet assignments and things like that, but also not EVERYTING needs an on chain vote. It does need financial accountability for those making the choices.

Maybe if every time a subnet went down we all had our rewards reduced we’d collectively hire someone(or more likely the whales) would hire someone to make sure that doesn’t f-ing happen.

The people with the most on the line are the likely the ones you can trust with your vote the most.


Can we do away with following all together? You shouldn’t be rewarded for following someone and giving away your vote / voting power. Manually voting ensures you at least have a chance to look at what you are agreeing to. This would also solve rewarding dead / inactive neurons.