Hi all,
As promised in a previous forum post, we are following up with a more concrete design for periodic confirmation.
TL;DR
- We follow up on the approved motion proposal on periodic confirmation and propose a design.
- A neuron has to regularly take one of the following actions: directly vote, set following, confirm following.
- If a neuron fails to do any of these actions for 5 months, the neurons’ voting power will be decreased until it reaches zero after 6 months of inactivity.
- The voting power of all other neurons is not affected.
Context / Motivation
The main idea of periodic confirmation is that in order to get rewards, governance participants have to remain active voters and regularly confirm their following settings. Neurons who set following once and then never interact with the NNS again get lower, adjusted voting rewards. In particular, neurons who were created with default following and never made an active decision who to follow, have to do so in order to keep getting voting rewards.
The original proposal was adopted by the NNS community in the NNS proposal 55651.
Today, the main motivations for periodic confirmation are
- In order to get voting rewards, every neuron has to make an active decision who to follow - default following is not enough.
- Followers are regularly incentivised to reconsider their following choice.
Design
On a high level, the proposed design suggests the following.
- In order to get voting rewards and have voting power, a neuron has to regularly vote directly, set following, or confirm the current following settings.
- If a neuron does not take any of the above actions, the neuron’s voting power is adjusted. After 5 months of no action, the neuron’ voting power is linearly decreased for one month until it reaches zero at the end of 6 months without any action.
To track this, each neuron has a new field indicating the last time when it took any of the above actions.
Relevant actions
Confirmation of following is the main action that was suggested in the motion proposal.
In addition, the design includes set following and direct voting. Setting following also reflects an explicit choice by the neuron who to follow. Direct voting is included because a neuron that always votes directly and does not rely on following is a very active governance participant and should not have adjusted voting power or adjusted voting rewards.
Details Adjustment
“Sleeper” neurons, who don’t take any of the above actions for more than 6 months, should not be automatically participating in voting and getting voting rewards. This design suggests to realize this by adjusting their voting power.
Proposal lifecycle
Let’s recall the proposal life cycle to understand the new design better.
-
When a proposal is submitted to the NNS, the NNS takes a snapshot of all neurons and
a. Establishes which neurons are eligible, meaning that they have a dissolve delay that is at least 6 months.
b. Stores an empty ballot for each eligible neuron with the neuron’s voting power.
c. The sum of all neurons’ voting power is the total voting power that is taken into account for the decision. -
Once a day voting rewards are computed for decided proposals by
a. Considering the reward pool for that day
b. Looking at all proposals and neurons and considering- i. The total voting power that could have been used if all neurons participated
- ii. In how much proposals and with how much voting power each neuron participated compared to this total
Voting power adjustment
This design proposes that
- For each proposal and neuron, in the ballot (Step 1.c.) consider the adjusted voting power. That is, record less voting power for neurons that have not taken any of the above actions for the last 5 months.
- For each proposal, distinguish
- the total (potential) voting power, which is the sum of all neurons’ voting power if they were fully participating and without the adjustment
- the total adjusted voting power, which is the sum of all neurons’ adjusted voting power that can contribute to the decision
- For each proposal,
- consider the total adjusted voting power for deciding proposals.
- consider the (potential) voting power when computing the rewards. This is similar to Step 2.b.i in that the rewards take into account the voting power “if all neurons participated”.
Effect of the voting power adjustment
Adjusting the voting power in this way has the following consequences.
- Sleeper-neurons are not considered in the decision making process. This means that proposals can still be decided quickly if the majority of the regularly active voters agree quickly. (Also see “Alternatives considered” below).
- A while ago, NNS governance was changed so that the reward pool is based on the available voting power rather than just on the voting power that was exercised. This was introduced to combat spam and also has the advantage that less rewards are produced in the case where there are a lot of sleeper neurons. Considering the total potential voting power in the new design follows the same ideas and preserves these advantages.
- If a neuron has been sleeping for more than 6 months, then the voting power recorded for the neuron in any open proposal is zero. This might be unexpected for a neuron that has been sleeping and comes back on some day to directly vote on a proposal - the direct vote would be recorded with zero voting power. However, this also has some advantages. First, to ensure this is not confusing, the behavior can be explained on frontends with a UI and can serve as an additional nudge for the neuron to reconsider and confirm the following. Second, if a neuron has not confirmed or set following or actively voted in more than 6 months, it can be an advantage for the governance process that this neuron cannot simply show up on one day and swing a proposal in an unexpected way.
Alternatives considered
Alternative 1. Reset of following: The original proposal suggested completely removing the following for neurons that don’t confirm following.
Compared to the current design, this has the disadvantage that sleepers would still be counted towards the total voting power for making decisions. As a consequence, if there are many sleepers, it would be hard or impossible to reach quick decisions for urgent proposals such as fixes to security bugs.
This is illustrated in the following graphs where the proposed design is compared with a reset of following. The lines depict voting power over time, where blue represents a sleeper neuron, pink a neuron that remains active, and purple the overall voting power. The solid lines show the voting power that can be used by the neurons and the total voting power that is considered for decisions. The dotted lines indicate the voting power that these neurons are exercising and the total voting power that can be exercised with the current level of activity. In the right graph you can see that when the total voting power for decisions includes the sleepers, the effectively used voting power cannot reach 50% of the voting power and fast decision are not possible.
When urgent proposals in the context of periodic confirmation were discussed in the past, some community members suggested taking into account the active voting power from the last few proposals. The current design follows a similar idea as it also does not account for the sleepers’ voting power in the decision making process.
Alternative 2. Adjustment of the voting rewards, but not the voting power: We also considered not adjusting the voting power and just adjusting the rewards of neurons who don’t confirm following.
This would have similar disadvantages as explained for Alternative 1. In addition, this would mean that sleeper neurons would still contribute to the decisions with their full voting power - even though they would not receive rewards for it, this still does not seem to be in line with the proposal’s intention.
Who can perform the relevant actions?
Already now, direct voting and setting of following can be done by a neuron’s controller or its hotkeys. The same permission should apply for confirmation of following.
This means that a neuron can take any of the relevant actions (which will also reset the timer) with its controller or hotkey, which is in line with the original proposal and ensures that the feature can be implemented in a user-friendly way.
NNS dapp
For the NNS dapp, the main functionality of the feature will be visible in the neuron overview page, where a user can see all their neurons. This page will include a warning if at least one of the user’s neurons has not confirmed following for the last 5 months and has adjusted voting power. It will also include a button that allows the user to confirm following for all their neurons.
In addition, the new neuron field is shown as a timer indicating how much time a neuron has left to take action before the voting power will be adjusted. Since this is a property of each individual neuron, this is shown in the neuron detail page. In the neuron detail page, in addition to a button to set following, there will also be an option to confirm following for this neuron.
In the voting view, there will be a new explanation in the case where a neuron’s voting does not have any effect due to voting power adjustment (the case discussed in Section “Effect of the voting power adjustment”). This will explain to the user why they observe the current behavior and encourage them to take action to reset their neuron’s timer.
The timer is reset if the neuron votes directly (manually using the “vote” buttons rather than by following), if the user sets following for a neuron, or if the user uses the confirm following button, either for this neuron or for all neurons on the overview page.
We are currently working on the design of this and are happy to share more information and graphics once we have them.
Next steps
If there are no concerns with the proposed design, we will start working on the implementation of the feature. One of the first steps will be to finalize the detailed APIs. For this, it is particularly important to reach as many frontend and custody providers as possible who will need to integrate with this feature.
In addition to reaching the integrating teams, this feature needs to be communicated widely to reach as many end-users as possible and ensure that they will not unexpectedly lose rewards.
We thank everyone for their feedback and look forward to taking this feature to the next step!
