Allow only the controller of a neuron to register it as a known neuron


Currently NNS users can submit RegisterKnownNeuron proposals for neurons they do not control. Malicious actors may abuse this to wrongfully “claim” ownership of neurons or “dox” actual owners.

This proposal offers a conceptual solution, which is to only allow the controller of a neuron to register it as a known neuron. If accepted, the expectation is that a technical solution be implemented by DFINITY.


Only allow RegisterKnownNeuron proposals where the proposer matches the ID field.

For example, the following would be valid and the invariants would be enforced on a technical level.


The proposed solution would prevent people acting in good faith from registering known neurons on behalf of others. This presents a trade-off regarding the convenience of being able to delegate the submission of a proposal.

Further Work

This proposal only aims to address the case where someone registers a neuron that they do not control in their own name.

Due to increased motivation for doing so, such as gaining followers and voting power, the inverse may be more of a concern; someone registering a neuron that they do control in someone else’s name.

1 Like

Why is there an issue with the proposal for Register Known Neuron coming from a neuron ID that is different than the neuron being registered? I thought you were interested in making sure the organization being registered controls the neuron ID being registered. I don’t see how this proposal confirms this identity.

A nefarious actor can still create a neuron and submit a Register Known Neuron proposal with that neuron and still misrepresent the name that is submitted.

This proposal would prevent anyone from registering a public neuron that is created using the NNS dApp since proposals cannot be submitted by neurons created using the NNS dApp at this time.

What am I missing? Why is this important?

I agree it is important to somehow verify that the public organization or person is not being misrepresented. Isn’t that done by asking that person or organization if they submitted the proposal and if the registered neuron is their neuron? I think there is a way to unregister known neurons too, so that would be a reasonable cure if a nefarious actor was found to have misrepresented a person or organization.

I believe this is the only way to guarantee that a neuron can’t be “claimed” (in name only) by someone who doesn’t control it.

How would you feel if someone submitted a known neuron proposal using your neuron ID and their name?

Whether it turns out to be a nuisance or something worse I think it’s worth discussing whether we want to disallow it altogether.

Right now this is preventable with some manual checks but it doesn’t scale. We can automate all of that away.

I agree with all of your other points which is why I included the “further work” section. I think that’s a separate problem which will probably take longer to figure out, and I don’t think it should hold up this proposal which has a clearer path to resolution.

…but the proposal doesn’t accomplish that goal. Don’t get me wrong, I do agree with the goal.

If you want to present a proposal that is actionable toward that goal, then I think you need to remove the language that emphasizes the idea that the proposal has to be submitted by the neuron that is trying to be registered. What you are looking for is a way to verify that the person or organization being named is in control of the neuron being registered.

Requiring that the proposal is submitted by the neuron being registered does not accomplish that goal. I can create a neuron myself and submit a proposal with that neuron to register that neuron and say that it is Paul Young’s neuron. This passes the litmus test of your proposal as it stands now, but it is not a valid claim. What you are looking for is a way to verify that Paul Young controls the neuron being registered instead of Wenzel Bartlett. It makes no difference who submits the proposal. It only matters that Paul Young controls the registered neuron.

No I’m not :slightly_smiling_face:

What I’m proposing is to make a change so that my neuron (or someone else’s neuron) can’t be registered as a known neuron by anyone other than the person in control of it.

Maybe someone wants to provide their name for someone else’s neuron for some unknown reason, or maybe they want to dox people by associating the actual controller’s name with their neurons without permission.

We can prevent that.

I think your example above is the other way around and what I wrote at the end of my original post.

I think this proposal would be a nice to have, but i think we can accomplish pretty much the same by just looking at whether the neuron id in question actually voted yes on the proposal. If you would try to register my neuron id under your own name, I would not vote in favor of that.

I like this idea but it seems less robust.

The controller of the neuron being targeted may not see the proposal and end up voting yes because some well-meaning person they follow votes yes (perhaps because they incorrectly assumed it was initiated by the controller)

1 Like

OK, I stand corrected on the goal.

As indicated in another forum topic, this proposal would mean that registered known neurons could not be created and managed with the NNS dApp because neurons created in the NNS dApp cannot submit proposals. ICP Maximalist Network and would not be registered known neurons if this was a requirement. When that problem is solved, then I can support this proposal. Otherwise, I think registered known neurons would be limited to people and organizations who are comfortable with DFX command lines, which is a much smaller subset of the IC community. It’s a significant filter on who would be capable of registering a neuron at this time.


I didn’t know that. Thanks for bringing it up, and thank you for your other input as well.

1 Like

Regarding the other side of this problem, once canisters can make HTTP requests we could employ some identity verification mechanisms similar to what Keybase offers.