Neurons will have a new field voting_power_refreshed_timestamp_seconds indicating when the neuron last voted directly, set following, or confirm following (called “refreshed their voting power” in the API).
Neuron holders: By the end of November, users can reset their neuron’s timer by performing any of these actions. Neurons who are not performing any of them will have adjusted voting power in March 2025 and their followees reset in April 2025.
Integrators: All API changes shared today will be released by the end of November. The adjusted voting power will be developed behind a feature flag and be turned on at the beginning of the new year.
Intro
Hi all,
As we are making some progress on the periodic confirmation feature, we would like to share the detailed API changes and the release plan. This is particularly important for frontends and products that integrate with governance, so that they can implement the required changes on their end.
Each neuron has a new field voting_power_refreshed_timestamp_seconds that records when the neuron last took any of the actions of voting, set following, or confirm following.
If a neuron performs any of these actions, the timestamp is set to the current time now.
The field is initialized with the timestamp representing midnight Sep 1st 2024 UTC.
New neurons have this field set to the same value as created_timestamp_seconds.
For each neuron, there are two new fields indicating the neuron’s voting power. deciding_voting_power indicates the voting power that a neuron exercises on proposals. This voting power is adjusted in the case where the neuron hasn’t voted directly, set following, or confirmed following for more than 6 months. potential_voting_power indicates the voting power that the neuron had if it regularly confirmed following (or voted directly or set following).
Unlike the current field voting_power, both deciding_voting_power and potential_voting_power will be shown as zero for neurons that are not eligible for voting (have less than 6 months dissolve delay).
The existing field voting_power is deprecated. For backwards compatibility it will for now remain existent and will newly also show zero for neurons that are not eligible.
Neuron actions
There is a new manage neuron command RefreshVotingPower to confirm the following on a neuron. It is called “refresh voting power” because calling this refreshes the new neuron field voting_power_refreshed_timestamp_seconds to now.
Remark: Note that even without this new action (and before it is implemented) the same can be achieved by reading a neuron’s followees and setting the neuron’s followers to the same selection or by voting directly.
Proposal attributes
Each proposal has a new field total_potential_voting_power that denotes the sum of the potential voting powers for all eligible neurons. This is used as a basis for distributing rewards as laid out in the design.
Nervous system parameters
There are two new nervous system parameters: start_reducing_voting_power_after_seconds defines the time period after a neuron’s timer has been refreshed when the neurons’ voting power is adjusted and clear_following_after_seconds determines the time period from when the voting power adjustment kicked in to when the neuron’s voting power will reach zero and the neuron’s followees are reset.
start_reducing_voting_power_after_seconds will be initialized with 0.5 years and clear_following_after_seconds with 1/12 year (which is how one month is defined in the governance code).
Release plan
This is the release plan we aim at.
Next week (until Nov 18 2024)
Each neuron has a new timestamp voting_power_refreshed_timestamp_seconds that is set to Sep 1st 2024
New nervous system parameters
Second half of November 2024
Refreshing of the neuron’s voting_power_refreshed_timestamp_seconds when the neuron votes directly, sets following, or confirms following => Users: at this time, users can already take any of these actions to refresh the timer of their neurons. When they do, they have again 6 months until the neuron would have adjusted voting power.
New APIs (as above) => Integrators: those who want to integrate with this feature or build a frontend for it have all APIs needed to do so.
December 2024
Behind a feature flag, implement the effect of the feature on voting power in the neurons and the proposals. Note that this has no effect yet. This is to give all integrators time to implement the feature on their end.
January 2025
Turn on the feature flag so that the feature takes effect.
March 2025
=> The neurons who haven’t taken any action until now, start having adjusted voting power
April 2025
=> The neurons who haven’t taken any action until now, will have their followees reset
Next steps / updates
We are actively working on the above changes and will post important updates in this thread.
Wow @lara! DFINITY is making amazing progress on implementation of this feature. I can’t believe this change is finally upon us. All the details sound consistent with what I recall from prior discussions about periodic confirmation.
How exactly do you think DFINITY’s voting rewards will be optimized? Their voting power will not change, therefore their rewards will not change. Same goes for every neuron that actively votes. There is no special optimization for DFINITY over anyone else. There is only the creation of an incentive for people to pay attention and to actively participate in governance. There is no free lunch. Vote = rewards. No vote = no rewards. Like it or not, set and forget is not an option and has never been an option that guarantees optimal rewards.
First, if some people lose their rewards, others will inevitably gain their share.
Second, I fully support active neuron participation.
However, Dfinity controls thousands of neurons—do you honestly believe they’ll manage them manually? This creates a clear disparity between what they can achieve and what regular retail participants can realistically do. **
Such a system feels inherently biased, driven by vested interests and, ultimately, money.
**
I personally manage several neurons, and it’s already a huge hassle to update them regularly. Is the goal of this protocol to make the process unnecessarily painful for users?
This is false. That changed almost 2 years ago (proposal 80970). It was the solution to the spam problem. Nobody gets more rewards when fewer people vote.
They don’t manage thousands of neurons, but they do manage close to a hundred neurons. Click on any one of them and you can see how they manage them. Here is an example below for neuron 4025. Look at the Proposals to Manage Neuron section and click on any one of the proposals. You will see that it takes 2 out of 3 votes to pass, which means that the neuron is 100% controlled manually by 3 people. They are all managed through the Neuron Management proposal topic.
Hey @chepreghy and @lara this reminds me of a question that I meant to ask you. In the Medium article I didn’t see any reference to hotkey controlled neurons. If you have hotkeys set up where one of your neurons has hotkey control of the rest of your neurons, then will this enable you to verify following one time instead of having to verify for all of them? Or does voting manually with a neuron that has hotkey control of other neurons qualify as voting manually with those hotkey controlled neurons? If neither of these options satisfy the requirements of periodic confirmation, then will the NNS dApp have a future feature where you can confirm following of many neurons in bulk? Basically, what is the easiest way to satisfy periodic confirmation when you own many neurons?
Yes, I noticed that you did listen to one detail. I think there is a solution for people with many neurons related to hotkeys, but I don’t recall exactly in what context. I hope it is helpful to you when periodic confirmation is finally implemented.
Edit: It appears that hotkey voting will satisfy periodic confirmation…
So setting up following between your neurons will not satisfy periodic confirmation, but hotkey control will.
There is nothing to burn. Rewards are distributed as maturity, which is an IOU, not ICP. Abandoned rewards are not distributed as maturity. They are not accumulated anywhere. They don’t exist. You can’t burn something that doesn’t exist.
I routinely use the Neuron Management proposal topic for CodeGov. It’s the only way I can control setup of the the neuron in the same way that DFINITY has to control their neurons. These proposals can only be submitted and actioned by neurons that are Followees for the Neuron Management proposal topic. In order to submit the proposal or vote on the proposal, you have to prove that you are the controller of that neuron with every call you make. This cannot be done by a canister to my knowledge. Hence, my comments on this come from experience. I could care less if you believe me or if you think I’m intentionally misleading.
To be honest, I’m growing bored of your nonsense. You clearly have much less understanding of how NNS governance and how neurons work than what you want people to believe. I’ve tried to help, but it’s a lost cause. Good luck staying up to date on the rules and getting answers from others. Maybe they will have more patience with you.
Is it currently not possible to call the #RefreshVotingPower command? I tried and it seems to trap? I take it that this will be activated when the feature is activated in January?
It seems that the default voting power refreshed timestamp is set to Sep 1. That doesn’t seem right since the feature is only activated in January? Neurons will have aged 4 months already by the time users can call the refresh voting power command?
@daniel-wong (sorry for cold tagging, but I know you are probably best to answer this)
40 days later and this is not implemented yet ? Is it the simply the periodic reset that takes time ?
Note that we usually discuss features with the community before we have time to work on them - especially for complex features such as periodic confirmation there needs to be enough time for discussion and depending on the discussion adjustments and/or motion proposals.
So first for most of the time between the initial design discussion and this new post here, we finished other work.
If you have hotkeys set up where one of your neurons has hotkey control of the rest of your neurons, then will this enable you to verify following one time instead of having to verify for all of them?
Yes, the current idea for the frontend is that you can verify following for all the neurons that you see (and thus have at least hotkey priviledge) at once.
It seems that the default voting power refreshed timestamp is set to Sep 1. That doesn’t seem right since the feature is only activated in January? Neurons will have aged 4 months already by the time users can call the refresh voting power command?
Yes, this is correct. As indicated by the release plan “Each neuron has a new timestamp voting_power_refreshed_timestamp_seconds that is set to Sep 1st 2024”. As also described in the plan, this means that the first effect on fully sleeping neurons will be visible in March and the first resets of following would happen in April. Note however that if you directly vote or change following for your neurons today, this should already reset the timer.
So this time is a middle ground between giving users enough time to take action but also seeing some effect of the periodic confirmation within the next quarter.
Is it currently not possible to call the #RefreshVotingPower command? I tried and it seems to trap? I take it that this will be activated when the feature is activated in January?
Could you maybe share the error text that you saw? We detected a bug late last week which should be fixed in this proposal. So hopefully it covers your problem too. Otherwise, please let us know again!
