The voting members of the Synapse named neuron would like to ask the NNS voting body to approve two Register Known Neuron proposals. One will publish a new neuron name with a new neuron ID and the other will revise the name of our existing neuron. Anyone who is interested in knowing our manifesto, voting members, neuron configuration, or policies can find up to date information at our website synapse.vote.
Management of the new synapse neuron is controlled by a decentralized group of Followees for the Neuron Management proposal topic. The new neuron does not have a known private key or seed phrase. Management of the original synapse neuron cannot be decentralized since it was created using the NNS dApp and an internet identity. The configuration of both neurons is posted on our website (synapse.vote) like we have always done with our existing named neuron. We recommend that anyone who chooses to follow the Synapse neuron should follow our new neuron ID since it has a higher degree of decentralization.
These two Register Known Neuron proposals will be submitted in the near future by Wenzel Bartlett (forum: @wpb and Twitter: @sayitkind) using neuron ID 12008772471346176261.
Great question. I documented the process in detail and would be happy to share, but I need time to clean it up by removing personal information that might be present. I’ll share a google doc link soon. The basics can be found in this post by @bjoern here on the forum. He was gracious enough to help me learn the ic-repl commands and explain the steps.
You need a parent neuron that is capable of spawning a child neuron who can be assigned a principle that has no known private key or seed phrase. This means the parent neuron needs to have sufficient maturity to spawn a neuron and it must have a private key that enables you to operate on it using command line tools such as ic-repl. When the spawn command is executed, the child neuron inherits the Followee and hotkey configuration of the parent neuron. Since the goal is to end up with a decentralized neuron, the principal you assign should be one that is verifiably without a known private key and seed phrase. Bjoern described how that can be accomplished in that post linked above. Before the child neuron is spawned, it is critical that you ensure that the parent neuron has a Followee configured for the Manage Neuron proposal topic ( which is topic 1). The parent neuron can follow itself on this Manage Neuron proposal topic. You want the child neuron to inherit this Followee because there will be no other way to control the neuron since you won’t know the private key. Once spawned, the only way to control the child neuron is via Neuron Management proposals. You can configure up to 15 Followees to manage the neuron, which means they can all create proposals, they all have full access to view the neuron configuration, and they must all vote to execute the configuration proposals.
As mentioned, I will provide example commands for creating the decentralized neuron and for configuring the decentralized neuron. If you want, I can also create a decentralized neuron for you and assign you as Followee for the Manage Neuron proposal topic for that neuron. Then you can configure it however you want. I have a parent neuron with sufficient maturity to be used for this purpose. That way you don’t have to wait to accumulate sufficient maturity to perform this task from another neuron.
It is currently not possible to submit proposals or manage a neuron using the Manage Neuron topic with the NNS dApp. This means you will need to submit Manage Neuron proposals using command line. However, if you have a neuron that is configured as a Followee on the Neuron Management proposal topic, then these proposals will show up in the NNS dApp and you can vote using the NNS dApp. This was the key recent development that made it practical to create this new decentralized neuron for Synapse. We have quite a few voting members with know how to submit these proposals, but everyone can vote using the NNS dApp. Nobody can change anything about the new synapse neuron unless it passes a vote from all our voting members.
Much appreciated to your answer. I’d like to have a decentralized neuron. I will go through the guide firstly, any unclear i will post here. thanks again
In my opinion, it would be better to leave the old neuron with the name ‘(formerly ICP Maximalist Network)’ which in itself already means that it is the ‘original’ nueron. Just name the new one simply ‘Synapse.vote’ for general order.
However, I think that you will correct this name without ‘NEW’ marker in the other time
Thanks for your feedback. It certainly makes sense. There are two primary reasons for wanting to rename the original neuron:
It was a promise we made when we changed to Synapse that we would fully separate the Synapse neuron name from the ICP Maximalist brand. There was a long transition to give people time to recognize the new name.
It seemed we needed a way to clearly and easily distinguish between the new and the old neuron since they are different neuron IDs and the transition by followers requires active, manual change of neuron configuration. If we didn’t use new and original in the names then we would need to be very explicit when describing the two neurons. If people do transition, then in the future it could enable us to deprecate the old neuron and rename the new neuron to just synapse.vote as you mentioned. That would be the ideal outcome, but we will make that decision over the longer term based on response from our Followees.
