Objective
Help neuron owners make informed decisions regarding which known neurons to delegate their voting power to.
More concretely, there are 2 main areas to improve:
-
The known neuron information can be outdated as it’s difficult to update and impossible to remove.
-
There is not enough information about the known neurons based on which the neuron owners can decide who to delegate their voting power to.
Background
In the NNS, neurons can vote directly on proposals or delegate their voting power to other neurons, which is also called following other neurons.
In the NNS, “known neurons” can be registered in governance through NNS proposals. While those known neurons don’t hold special power, they are featured in the NNS Dapp page where users can delegate their voting power. Therefore, they are more likely to be followed by other neurons and hence more likely to wield more voting power because of their followers. The known neuron feature is an important way to achieve voting power decentralization without every neuron owner having to be an expert in every proposal topic, as the voting power can be delegated to different experts on certain topics.
More details on known neurons and how they are registered can be found here.
Overview
We will first discuss 4 proposed changes to be implemented in the short-term, and then 2 changes that we consider as follow-up.
Proposed Changes
New Proposal Type: Deregister Known Neuron
To help users best make good vote delegation choices, the list of known neurons should be curated and include neurons that actually vote. If a known neuron decides not to participate in voting anymore, or the community believes a certain known neuron is no longer providing valuable input, there should be a way for the known neuron to be deregistered. One known neuron already declared itself to be inactive through a proposal.
Therefore, we propose to add a new proposal type that removes it from the registered list on governance given a known neuron’s id.
type DeregisterKnownNeuron = record {
id : opt NeuronId;
}
Note that anyone can submit such a proposal, not just the known neuron itself.
Links in Known Neuron Data
To make it easier for the known neurons to engage with their followers, as well as letting potential followers learn more about them, we propose to add a list of URLs to the known neuron:
type KnownNeuronData = record {
name : text;
description : opt text;
# Can be links to social URLs (OpenChat, X, etc.), or a homepage.
links : opt vec text;
};
Voting Participation and History
To help a (potential) follower to decide whether to delegate or keep delegating their voting power to a known neuron, we propose to record a known neuron’s voting history and expose a voting participation rate as well as voting history. More specifically:
-
In the KnownNeuronData, we add a `committed_topics` field (which then can be added through proposals) as a list of topics
-
Record voting history of all known neurons
-
When listing known neurons, additional information can be exposed:
-
Voting participation rate of committed topics (up to the last 100 proposals per topic)
-
Votes on the last 200 proposals (limit is subject to change during implementation) of committed topics
-
Stop Including Known Neuron Data through list_neurons
The list_neurons API can return a large number of neurons. There is pagination (500) to ensure that its results don’t exceed the message limit. However, as we add more information into known neuron data, the current page limit will no longer keep the message size within the limit. Given that we already have the list_known_neurons API, there is not much added value by exposing known neuron data through list_neurons. Therefore we propose to no longer include the known neuron data when listing neurons.
Future Improvements
Update Known Neuron
Currently, the RegisterKnownNeuron proposal type can already update an existing known neuron (the proposal execution adds a known neuron if it does not exist, and updates if it does), so there is not that much value to provide a new UpdateKnownNeuron proposal type, other than having a better name for the proposal type. If we do introduce this proposal type, the existing RegisterKnownNeuron proposal type should no longer be able to update an existing known neuron.
Full Voting History API
Given that we only expose the votes on the last 200 proposals in list_known_neurons (mostly to guarantee the results always stay within the message size limit), it might be helpful to expose the full voting history of a given known neuron by a new API get_known_neuron_voting_history.
Next Steps
Feedbacks are welcome from all community members, and especially people who own or operate known neurons. If there are no major concerns, we plan to start the implementation and include it in the normal governance release process.