Remove cycle dao named neuron

Can we remove them is there a proposal we can do to remove a named neuron? They are not functioning anymore and their existence is misleading people.


Hi cryptoisgood. Just to clarify: does it mean that the cycledao neuron has been discontinued and I should not follow it if I want to?
Thank you.

Cycle DAO wrote a post recently outlining that it will no longer be a managed neuron, and they set their following to ICP Maximalist Network.

It would be better / cleaner for the NNS to remove those following Cycle DAO since it is now effectively defunct

The question is, what happens to all of Cycle DAO’s followees? Does it get reset or does it automatically get applied to ICP Maximalist Network?

Hi all,
I am a researcher in the NNS team.

Currently there is no proposal to remove known neurons. As this came up multiple times already I think it makes sense to suggest to add this to our backlog. Since the team is working on the final stretches for SNS and there are other governance feature requests, I guess we might not get around to do that right away.

The question is, what happens to all of Cycle DAO’s followees? Does it get reset or does it automatically get applied to ICP Maximalist Network?

That is an interesting question. When adding the removal of known neurons we would have to design what we mean by this in detail.
Intuitively, I would say that a known neuron is different from other neurons only in that it can be listed as a known neuron and thus also be displayed on frontends etc. With this interpretation “removing” a known neuron would probably just mean that we remove it from the list, but that the neuron would still exist. If we don’t define anything else, this would mean that current followers of this neuron would still follow it even thought the neuron is not known anymore (as one can always also follow a neuron that is not known).


I think simply removing a known neuron from the list (without changing the follower relationships) would be sufficient.


I agree with this - giving the NNS the ability to clear a specific neuron’s followees could be used to attack specific “minority” named neurons that the majority disagrees with and disrupt the balance of voting power on certain issues. It could also be used to temporarily boost voting rewards and reintroduce financial spam incentives into the system.

Therefore, simply removing the named neuron from the frontend UX should be sufficient.

@lara I would imagine a change like this would be a trivial frontend fix.


+1 to just removing it from the list, I really don’t think we should be changing neuron following relations.


Should we make a proposal to add it to back log or can you just do it?

I think this code change would need to come from a proposal that the community agrees on.

Maybe you can even get @Arthur Falls to fund it.

1 Like

I added it as a todo to the list of todos for the NNS team, so no further actions are needed to get it there. I think most people think this is a good idea.
Note that this does not mean that we will get around to this right away.
After finalising the SNS we will have to prioritise the different governance todos…

1 Like

Actually, the known neurons are stored in the NNS governance canister and the frontend pulls this list from the governance. This also allows others, including for example other frontends, to get the list.

A neuron can be added to the list by a proposal that, on adoption, adds a neuron to this list.
Note that this decision is automatically executed on chain and does not require manually adding the known neuron.
If we want to implement the removal of neurons, the required change is a new proposal in the NNS governance canister that, on adoption, removes a given neuron from the list.
Conversely, no frontend changes are required as the frontend just pulls the list.


Awesome, thanks for the correction @lara. I understand that you don’t want to context switch, but offf the top of your head do you have any idea how much work this (removal of a named neuron via an NNS proposal) would take to complete?

It might even be something (in terms of the governance canister change and proposal) that’s a light enough lift that the community could take on if you point us in the right direction.

On this point. Let’s just rename the to “Arthur’s Neuron”. I’m heavily involved in governance behind the scenes and have a large number of relationships with large holders who trust me in the named neuron role. Keeping the named neuron active will make it easier for me to onboard more investors when I begin activating them again. It also means we don’t lose follow options.


What happens if there is a second proposal to adopt a named neuron with a different name? I may try to look at the code later, but not at my computer . It should be in the governance section of the NNS code. (Great chance to poke around if you’ve never read the code.)


It looks like that would work.

1 Like

I wanted to add here that, while this is now on the team’s backlog, it might of course still be valuable to already make a motion proposal and ensure that the broader community is also in favour of this.
I don’t expect that people will be against this change, but if we want to follow normal patterns it might still be nice not to take the consent for granted?

Of course we can also do this later and, in any case, the community can also vote on the proposal that actually upgrades the governance canister with this change.

But I previously just answered the question in the sense of “we, the NNS team are now aware of this request” and wanted to clarify that additional communication might still be warranted for the larger community!

1 Like

Let me divide the “how much work”-question into two sub-questions:

  1. What are the required changes (from the top of my head)?
    a. Write a method that accesses the list of known neurons in the governance state and removes the given known neuron.
    b. Make sure this method can only be called by the governance canister
    c. Define a new proposal that calls this method. Consider what the properties of this new proposal should be (its type, topic, reward weight, etc). Add proposal verification etc.
    d. tests, code reviews
    e. Integration with the NNS frontend (is the new proposal type displayed correctly? Is the list of known neurons updated correctly?)
    f. security review
    g. Build the new governance wasm and test the upgrade in an environment that is as close to the production NNS as possible

  2. How long would it take? (Again, these are just some rough guesstimates from the top of my head)
    a.-e. I would say a few days for an NNS engineer, probably considerably longer for another engineer (as one has to find the relevant places in the code etc)
    f. a few hours, but some overhead as this includes another team
    g. another few hours for an NNS engineer. This relies on the right setup, so I think this would be a lot of effort for outsiders.

Regarding the question if this is something that could be done by the community, I don’t think I am the right person to answer this and I recommend that this is discussed in a more general conversation with others.
Some things that come to my mind:

  • We would then maybe first have to discuss how community contributions would best be organized in terms of tooling etc
  • We might want to discuss how we could slowly ramp up community contributions:
    • Maybe there are some parts of the code that are better suited to start with this and we could start there and widen the range. I personally think that it might make sense to start with a less security-critical canister than governance (note that if we break the governance canister, upgrades are not possible anymore and so recovery becomes very hard).
    • Maybe there are some tasks that are better suited to start with: As you see above, there are different parts to realising a feature. Maybe it makes sense that for some features the community contributes parts, but DFINITY still leads other parts (e.g., security reviews / the testing of the upgrades).
    • It might make sense to put this in perspective with other goals. Would it, for example, be more important for decentralization that more entities are able to verify proposals rather than contributing to changes themselves? Since community members cannot do everything, it might also make sense to discuss where to start here!

These are just some thoughts… As stated, I think this would require a more general conversation with other people :slight_smile: But I hope it was helpful that I shared some details about what tasks are included in this concrete example feature

1 Like

I just want to make sure that we consider this point by @Arthur (the person who controls the cycle_dao neuron).

if it’ renamed to “Arthur’s neuron,” do we need to do anything?

(I agree that it would be good to have the functionality for removing, but in this case, I think maybe a governance proposal to rename the neuron may be more helpful).

what do folks think @lara @cryptoisgood @skilesare @Arthur @justmythoughts @Manu ?

1 Like

from my point of view it would still make sense to have the functionality, but maybe if we don’t need it right now this just means that the feature is a bit less urgent?

Regarding having renaming instead of removing, I would say that removing is preferable: If we have adding and removing, I think a given neuron could be renamed by a proposal to remove it and another proposal to add it again (with a new name). The converse is not true: if we add just renaming, we still cannot remove neurons.
Also, I would expect that in the long term we would want to remove some neurons.
But happy to discuss!


@lara In simpler terms, this is what I was thinking as a process:

1. Add renaming functionality in short term
* Once it is done, submit NNS proposal to rename
* This keeps following relationships and neuron history and community

2. Add removing functionality after #1
* To be used in future cases

It seems you suggested we do #2 before #1 because we have to do that anyways. Did i understand correctly?