Hi all, thanks for all the feedback and questions.
Let me address some of the main points that were raised - phrased and summarised in my words:
- Why does the voting power start decreasing after 5 months rather than 6 months, which would be nice as it is a biannual confirmation? Why is it not 3 months?
The idea was to pick a period that is short enough to have some effect but long enough so that it is realistic for most neurons to perform one of the actions without being a major hurdle. I think the originally proposed 6 months is a good sweet spot for this.
There is no major difference whether we start the voting power decrease at 6 months or arrive at zero voting power at 6 months. If the community prefers the former to make this a biannual confirmation, we can adjust the design accordingly.
We think that 3 months is a bit too often. We could consider having a shorter period in the beginning to see the first effects earlier - e.g., set the timer to 3 months ago so that the first neurons have to confirm within this time.
We think however that we should not go below 3 months because all integrations need enough time to prioritize and implement support for this and the communication has to reach all neuron owners so that they know they have to do this.
- Why have a decline at all and not just go from full to zero voting power?
We agree that this might not make a huge difference for NNS dapp users and similar frontends, as a warning can already be shown earlier and basically serve as a “grace period”. However, this is not true for users who interact with the NNS through a command line tool - they only learn about the neuron upon sending requests. Therefore, we still propose the decline.
Note that we don’t think this will be substantially more engineering work and, as was noted, for most users it should not complicate things as they would be prompted to take action already before the decline.
- What is the definition of “directly vote?”
This is a vote that is directly cast by a neuron’s controller or hotkey, no matter which frontend is used. But it does not include votes that are automatically registered by the governance canister due to following. Technically, any call to the neuron management function register_vote is considered a direct vote.
- Is this feature useful if one can circumvent it?
It is known that this is the case and generally it is very hard to prevent automation. The idea is that this feature likely captures a substantial portion of the voters and therefore still has a positive effect.
- Why does the design not actually reset the following? Why is there no complete reset?
We agree that there is some benefit to a full reset as it forces neurons who come back after a long time to make an active decision rather than just reactivate their account.
We can adjust the design and governance could fully remove the following settings for neurons who reached zero voting power due to the adjustment.
This will increase the code complexity slightly as it requires a new regular job on the governance, but we can also implement this while the rest of the feature is already released (as this case is only relevant after a few months).
- Why is direct voting one of the actions considered?
This was briefly explained in the original post, but let me try to explain this better.
The design with the voting power adjustment has advantages over the alternatives as explained in “Alternatives considered”. Consider a neuron that has no following set at all and directly votes every day. In this design, the neuron would have adjusted voting power after a while, because it does not confirm following which is just not relevant for the neuron. Adjusting the voting power of this neuron does not seem to be fair as this is a neuron that is the most active governance participant that can exist.
I think on a more practical level, neurons that directly vote on a regular basis are likely neurons that are interested and engaged and already make conscious decisions on who to follow. Also, they are likely regularly visiting the NNS dapp and would also see the prompt to confirm following.
- What is the notification campaign associated with this feature?
We plan to reach out to all the projects that we know of that integrate with the NNS and widely inform users on the channels that we have, e.g., on the forum, X, information about new feature in the NNS dapp, etc.
- Will manually vote with any one of my neurons reset the timer for all my neurons?
No, this is not the case. If a neuron votes, this will only reset the timer of this one neuron.
Note however, that if you cast a direct vote on the NNS dapp, you can select multiple or all of your neurons. If you select multiple ones, a direct vote will be cast for each of those neurons. For this feature that means that all selected neurons’ timer would be reset. This is likely how most users vote, but I wanted to clarify that it is not enough to vote e.g., with only one neuron using a command line tool.
