Hi all,
we had some discussions in DFINITY regarding whether NNS neurons should be controllable by canisters.
Our current take is that we should not allow canisters to control NNS neurons as we should not risk the creation of neuron markets. One main concern about having services that offer “staked tokens” and hold huge NNS neurons is that these services would have a very large, aggregated voting power in the NNS which may thus centralize the voting power.
Some more detailed concerns / answers to some questions in this thread:
- “The Same is already possible with ECDSA / http”: This is true. But rather than making neuron markets even simpler, we currently think that we should rather try to prevent these cases as well by adding additional authentication means to a neuron. One idea would be to add to a neuron not only a controller but also an additional key or means of authentication that could not easily be done with ECDSA.
- “Couldn’t we just allow some canisters to control neurons, e.g., DAOs”. First it is not straightforward how an “allowed” canister would be defined. As some of you mentioned it is conceivable to work with whitelists etc. However, what should be allowed wasms? For example, it might first seem that it is valid to allow SNSs to control NNS neurons, as SNSs use code that has been approved by the NNS. However, an SNS could easily be used to actually create a neuron market, e.g., by the SNS token basically working as “wrapped NNS neurons”.
Next steps:
- As mentioned, rather than allowing all kinds of canister controllers, we plan to further look into how to prevent canister controllers by ECDSA + http. Initial ideas are discussed that include an additional key/protocol to access neuron functionality that could not be easily provided by a canister.
- We think that a lot of use cases why community members asked for this feature might also be solvable by other means. Notably, for implementing “known neurons” that can be registered in NNS governance for others to follow them on proposal decisions are often realized by a group of people managing this one known neuron. Instead of implementing this in a canister, this can already be realized by a special type of proposal type “manage neuron” that allows a selected group of neurons to manipulate one neuron. Moreover, more elaborate following-functions implemented in a canister can be achieved by adding a canister as a neuron’s hot key rather than the controller.
To enable the community to effectively use these existing tools, we plan to work on documentation on how these can be set up.
We will follow up once we have this additional documentation or more insights on the design of the new additions!