Periodic confirmation of following is released!

The main idea of periodic confirmation of following 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 or were created with default following and then never interact with the NNS again get lower, adjusted voting rewards. To find more information about the feature and community discussions about it, please see the previous blog post, this forum discussion, and the adopted motion proposal.

With the adoption of proposal 134777 and proposal 134787, the periodic confirmation feature was released in the NNS.

In the following we recap what this means for NNS users and tools that integrate with the NNS. If you use the NNS dapp, you can also refer to this tutorial how to confirm following.

How this affects NNS users

To keep their voting power and thus to keep getting voting rewards, NNS users are required to take at least one of the following three actions once every half year for each of their neurons:

  1. Vote directly
  2. Set following
  3. Confirm the current following settings

In particular, according to how the feature initialized the neurons’ settings, in order to keep getting rewards all users must take one of the above actions before March 2nd 2025.

If you are already an active governance participant who manually votes on NNS proposals or regularly revises and changes following, you will not be required to take extra actions. Voting and setting following remain working exactly like before. To ensure that your followees vote according to your preference, and they don’t miss proposals, you can for example take a look at vpGeek’s known neuron list.

In addition to these actions that were already available before, you can now confirm your current followers if you would like to keep them in order to keep getting rewards.

Let’s go in a bit more detail about what to do to keep getting rewards depending on what dapp you use to interact with the NNS.

NNS dapp users

If you are an NNS dapp user, you can vote directly by referring to the instructions here and modify following using the tutorial here.

In order to learn how much time a neuron has left before it starts losing rewards, you can go to the neuron detail page and find the following information:

You can also use the button "Confirm Following” in order to confirm the current following choices for this given neuron.

Once a neuron has less than one month left before it gets adjusted voting power and rewards, the NNS dapp would also show the following warning messages to the user in the neuron detail page.

For users who don’t take any actions until then, this will happen for the first time in February 2025.

If a user has at least one neuron for which this is the case, the NNS dapp would additionally show a warning on top of the neuron overview table together with a button to confirm following for all neurons in the table, as shown in this picture:

Quill users

If you are a user that holds neurons with `quill’, you can vote directly and set following as before and as described in quill neuron-manage.

If you would like to keep your following settings as they are and just confirm them to ensure that your neuron will not start losing voting power and rewards, you can now use the same neuron-manage command with the new flag --refresh-followers.

For example, for a a hypothetical neuron 2313380519530470538 you can use the following command:

quill neuron-manage 2313380519530470538 --refresh-followers

This will produce a response like:

(
     record {
          command = opt variant {
               RefreshVotingPower = record {}
          };
     }
)

Ledger Hardware wallet (HW)

If you are using the Ledger HW to control your neurons, one of the easiest ways to take the required actions is to add your NNS dapp principal as a hotkey to your neuron (see how you can do this in this video).

Because a neuron’s hotkey can vote, set following, and confirm following for a neuron, this allows you to take all the relevant actions by simply following the guidelines above.

For this reason, if you have a Ledger HW connected to your NNS dapp, the NNS dapp will also recommend that you add your neurons to the NNS dapp (i.e., add your NNS dapp principal as a hotkey to the Ledger HW controlled neurons). If you don’t do this, the NNS dapp will have no way of knowing whether the linked HW has any associated neurons.

This recommendation is shown when you create a neuron and as a general note on the Token account page (as the NNS dapp does not know whether you already have neurons with this account).

If you control your neurons with a Ledger HW but use the Ledger HW CLI, you can vote and set following as before (see README).

The option to just confirm following is planned to be added soon, so for now if you want to be sure that your neuron keeps its voting power and keeps getting rewards, it is recommended that you take one of the previous two actions with it.

How this affects tools that integrate with NNS

If you are building a tool that integrates with NNS governance and provides staking to users, then your users will also be affected by this change. Therefore, if you haven’t done so you might want to notify your users about the upcoming change. You could also update the application to warn users if they approach the deadline when their neurons’ voting power will be adjusted and to provide them with a very simple flow to set or confirm following.

In the following, we provide some additional remarks that might be useful depending on how you integrate with NNS governance.

Rosetta staking

If you have a tool that offers NNS staking using Rosetta, it is recommended that you update to the latest version of Rosetta and your backend to be able to use the feature.

Self-custody through direct NNS integration

If you have a tool that provides self-custody by directly integrating with the NNS governance, you can make use of the NNS governance’s new API. The new API was shared in this blog post and is now reflected in this .did file. The new manage-neuron command to confirm following is called RefreshVotingPower because the endpoint refreshes the neuron’s timer denoting when the neuron last took one of the relevant actions to now.

Conclusion

We hope these tips are useful!

Tell your friends to regularly check their neurons to make sure that they are keeping their voting power and rewards – a great opportunity to discuss ongoing proposals or which neurons are great to follow!

14 Likes

Hey @lara. I just wanted to say that you and the DFINITY team did an outstanding job implementing periodic confirmation. Thank you so much for driving this to completion. I think it will help improve our governance system.

6 Likes

In the context of a system where users are required to confirm their activity every six months to maintain voting rewards, it is essential to consider the diverse needs and circumstances of different user groups. Some users may prefer or need to go offline for extended periods, such as those from remote regions in Africa or affluent individuals traveling in isolated areas like the Savanna or Sahara desert. This counter approach argues that it is acceptable for these users to have lower voting rewards rather than being completely excluded from the system.

Understanding User Diversity

1. User Circumstances: Users come from various backgrounds and situations that influence their online activity. For instance, individuals living in rural parts of Africa may face connectivity issues or choose to limit their online presence due to personal preferences or cultural reasons. Similarly, wealthy travelers might intentionally disconnect from digital platforms while enjoying nature.

2. Value of Offline Time: The choice to remain offline can be a conscious decision for many users who prioritize experiences over digital engagement. Recognizing this preference is crucial for creating an inclusive platform that respects individual choices.

Impact of Mandatory Confirmation on Users

1. Exclusion vs. Reduced Rewards: The proposed feature mandates confirmation every six months, which could lead to complete exclusion from rewards for those who do not comply. However, this raises questions about fairness and inclusivity for users who may not be able or willing to confirm their activity regularly.

2. Potential Solutions:
Instead of outright removal from the rewards system, a more equitable approach could involve tiered rewards based on user activity levels:
* Users who confirm their activity could receive full rewards.
* Users who fail to confirm but have been inactive for an extended period could receive reduced rewards.
* This structure would allow users who prefer longer offline periods to still benefit from participation without penalizing them harshly.

Addressing Concerns with New Features

Clarification on Reward Structure:
It is vital for the platform administrators to clarify how the new feature will affect users who do not confirm their activity:
* Will they be completely removed from receiving any rewards?
* Or will they simply receive a diminished reward based on their inactivity?

Clear communication regarding how these decisions impact user experience is essential. Providing detailed information about reward adjustments can help manage expectations and encourage continued engagement even among less active users.

Conclusion
In summary, while ensuring active participation through regular confirmations is important for maintaining an engaged community, it is equally crucial to accommodate users who may prefer longer offline periods due to various reasons such as geographical location or lifestyle choices. A balanced approach that allows reduced rewards rather than complete exclusion would foster inclusivity and respect individual preferences within the IC ecosystem. Thank you!

1 Like

Hello,

It is vital for the platform administrators to clarify how the new feature will affect users who do not confirm their activity

Note that there is no platform administrator. The ICP is managed by a decentralized DAO whose voters first agreed in the mentioned motion proposal that this feature should be done and adopted its implementation in the proposals this week (also linked above).

The high level design was discussed extensively with the community and approved by the NNS in this motion proposal that is also linked above.
Indeed it was discussed that allowing for offline time is also important and it was agreed that 6m is a good tradeoff. Note that there is a time within the reward is only adjusted, but this reaches 0 afer 7m of inactivity.

6 Likes

Hi @lara :wave:

Out of curiosity, when did the initial periodic confirmation timer start, and when will the first 6 month period be up for people that haven’t logged in for some time (1+ years)?

I have a few family members that follow my neuron, so I need to set a reminder timer for them :slightly_smiling_face:

1 Like

For all neurons created before the feature was added the starting date for the timer is September 1st: ic/rs/nns/governance/src/lib.rs at ac71086bf4d6854e8612d21f8104ba839283dc48 · dfinity/ic · GitHub

3 Likes

So then assuming 180 days is used in the 6 months calculation,

Inactives should see a refresh notice starting Wednesday, January 29th
And would need to reconfirm following before Friday, February 28th

Is this correct?

1 Like

Due to how the code defines a month (just a 12th of a year), one must take action before March 2nd 2025. At some time during the this day the deadline is hit, so I recommend to just do it at latest a few days before.
The NNS dapp should then show the warning roughly 1month before that (I don’t know by heart if it just shows it 30days before or also 1/12th of a year or on the same date one month before)

2 Likes