SNS Generic Nervous System Function Restrictions

[Lorimer]

Thanks for your detailed response @lara, I really appreciate it.

@lara

the preferred solution would be to add this proposal to the core SNS canisters - this ensures that it is easier to reason about the restrictions and that they are the same on all SNSs

I’d love to see a built in manage_neuron SNS function. That being said, I think it’s a shame that some awesome work has already gone into Toolkit to make this sort of thing practical using generic nervous system functions. I’m sure @rem.codes could say more about that. Making this a native nervous system function would sort of make that element of the Toolkit redundant (and maybe isn’t the best way of encouraging the community to help improve IC functionality).

In terms of the utility of these restrictions, I still don’t quite understand what they’re achieving. My apologies if I’ve misunderstood. What’s to stop the SNS from adding a function to one of the dapp canisters, and then doing a cross-canister call to the desired function on the governance canister, and then registering the new dapp canister function as the target of a generic nervous system function? Doesn’t this get around the restriction (at the expense of unnecessary added complexity and indirection)?

@lara

That sounds like an interesting idea. Is it needed for this that the full neuron is managed through proposals?

Thanks Indeed, I’m planning to establish a set of standardised criteria for the D-QUORUM neuron, and encourage others to set up the same sort of neuron on other SNSs. The idea so far is that:

• The neuron is controlled by no other principal except the SNS governance canister.
• The SNS governance canister has every permission except for the following (ensuring that the neuron is permanently tied to the governance canister)
  • NEURON_PERMISSION_TYPE_MANAGE_PRINCIPALS (2),
  • NEURON_PERMISSION_TYPE_MANAGE_VOTING_PERMISSION (10)
• The SNS registers a generic nervous system function (if it’s not going to be made native) to manage the neuron (given that this can now only be done exclusively by the governance canister, triggered by DAO consensus)
• The neuron is called D-QUORUM for consistency across SNSs

The idea is that D-QUORUM is a highly decentralised neuron and a very effective option for people looking for a good neuron to follow (one that can be adapted by the DAO over time). It’s crucial that no individual can trigger a vote on this neuron or set the followees (to significantly reduce any chance of governance attacks, mistakes, or centralised biases). Eventually I’ll get around to proposing the same sort of thing for the NNS (but that’s a topic for down the road).

@lara

one could have a canister control the neuron and the canister in turn be DAO controlled

This is what I’m suggesting. The canister in question is the SNS governance canister

I think another canister would be added complexity which doesn’t sound justified. It would effectively be doing the job of the governance canister (executing the will of the DAO). Great tooling is already being developed to help manage this workflow via a UI (Toolkit ) to simplify the neuron management process.

@lara

SNS roadmap that aims to add a concept like known neurons or named neurons to the SNSs

This would be fantastic, and would very much aid one of the objectives of D-QUORUM.

---

CCing @sat, as we happened to discuss D-QUORUM this morning on Zoom (just in case you want to add some points to this discusson)