SNS Generic Nervous System Function Restrictions

[Lorimer]

Hey @daniel-wong, @DanielThurau, @msumme,

I have a problem. I’ve checked the IC repository and noticed that you guys have been involved in the relevant area of the codebase - I’m hoping you can help me…

Context

I’d like to be able to raise an SNS proposal to register a generic nervous system function for calling the manage_neuron function on that SNS’ governance cansiter (thereby allowing the SNS DAO to vote on proposals to manage neurons that are controlled by that SNS’ governance cansiter).

At the moment I’m focusing on WaterNeuron, but I’d like encourage the same sort of neuron (and neuron management) to be established on other SNSs. I’ll also aim to move on to the NNS soon (but that’s a separate topic).

Further reasoning for this is explained in the D-QUORUM OC channel for WaterNeuron. Essentially it allows for a decentralised neuron for which the DAO is responsible for electing followees (acting as elections for trusted ‘council members’, making the neuron a highly reliably option for following on more or less every topic). The important thing is that the neuron cannot be controlled by any individual (only the governance canister holds permissions for the neuron).

Problem

I had a go at raising a proposal to register a Manage Neuron generic nervous system function (using @rem.codes’ awesome Toolkit ) and I ran into an issue regarding generic nervous system restrictions →

The important part is at the bottom of the screenshot. Function targets a reserved canister.

The relevant part of the IC codebase is here →

dfinity/ic/blob/master/rs/sns/governance/src/governance.rs#L3036

It appears that SNS’ are currently not allowed to have generic nervous system proposals that execute functions on the SNS’ governance canister itself (in this case the manage_neuron function).

Request

Would you be able to shed some light on why this restriction is necessary? Can it be lifted? Presumably it’s easily circumvented by registering a method on another canister that simply calls the desired method on the governance canister. Your insight and help would be much appreciated.

Please take a moment to see what I’m trying to achieve with the D-QUORUM neuron. I think this is an important use case, and it would be great if the SNS framework could be adjusted to make this feasible without undue heavy lifting.

Thanks in advance

[daniel-wong]

I think @lara would probably be the best person to answer this, but I’m pretty sure that the short answer is, “security.”.

In general, a widely recognized security principal is, “lock down ALL the things”. It is also widely recognized that in practice, this often ends up blocking legitimate actions.

Since this is a security issue, we would have to consider it carefully.

[daniel-wong]

To further elaborate, for example, we have a proposal type that transfers tokens from the SNS’s treasury. This type or proposal requires a 2/3 super majority to approve (and higher participation, plus restrictions on the amount). If we did not restrict target canisters, you wouldn’t need a super majority anymore to transfer tokens from the treasury.

The restrictions on treasury proposals were added after a large amount was transferred out of an SNS treasury. That SNS’s community was unpleasantly surprised by the transfer. In response, we added restrictions to increase people’s confidence in SNSs.

I’m not saying that these rules are written in stone. Just trying to add motivation/rationale.

[daniel-wong]

I think the original use case that these generic proposals were designed to target was performing administrative actions on canisters that the SNS controls (we call these “dapp” canisters). It was not envisioned that these would be used to target SNS framework canisters themselves.

Again, this does not mean SNS must work this way forever. Just trying to explain the thought process that went into the original design.

[Lorimer]

Thanks @daniel-wong, this makes sense and I expected this to be the reason (lock-down everything by default unless there’s an obvious use case). Presumably the transfer function doesn’t validate that the call is being made by the governance canister? This would provide the same level of security for all relevant functions, but without undue restrictions.

Alternatively, given that the manage_neuron topic is the clear exception to the rule (it has a robust permissions system that’s enforced, which is tied to how SNS neurons have been designed), another solution would be to add an exception for the manage_neuron function.

There’s lots of precedent for treating the manage_neuron function differently on the NNS. I understand that this could be a bit of added SNS complexity, but it should be simple enough and the use case is there.

What do you think @lara

[lara]

Hi Lorimer,

indeed as mentioned by Daniel the reason why generic functions cannot target SNS canisters is that this might allow to escape security rules (changing things about the SNS DAO itself without e.g., complying with some restrictions that should be followed). Therefore, if other kinds of proposals targeting the SNS canisters themselves are needed, 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.

DAO is responsible for electing followees

That sounds like an interesting idea. Is it needed for this that the full neuron is managed through proposals?
I wonder if your mentioned alterantive isn’t maybe even better: one could have a canister control the neuron and the canister in turn be DAO controlled. With this, one could have very targeted methods to register new followers, which might be easier for DAO voters to understand what they are voting on.

There’s lots of precedent for treating the manage_neuron function differently on the NNS. I understand that this could be a bit of added SNS complexity, but it should be simple enough and the use case is there.

Note that on the NNS this is a very special case and these proposals are also treated differently as other proposals (e.g., they have different fees and no rewards). When we designed the SNS we made a conscious decision not the have manage_neuron proposals as they add quite some complexity to the code due to adding special cases in the proposal lifecycle. Moreover for a lot of voters the concept is quite complex to grasp.
But if we just allowed to call mange_neuron as a proposal on the SNS, this would be a bit a different concept - so I am not sure how well these two are comparable.

[lara]

I also want to add that we have a project on the SNS roadmap that aims to add a concept like known neurons or named neurons to the SNSs. Just mentioning this because, depending on how we decide as a community to realize this, this might also add to your goal.

[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)

[lara]

@Lorimer

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

You are right this is possible.
What I meant is that if we remove the restriction altogether it might be possible that we allow for generic proposals to do other things that we don’t want. For example, only SNS governance can upgrade SNS root as it is its controller. Currently this can only happen through the predefined upgrade path - which is by design. If it were now possible to register any generic method then a proposal could maybe be sent to upgrade the SNS root to something else: as the proposal is sent by the SNS governance this might be possible. This would however never be possible over another (proxy) dapp canister that can be built by someone.
I haven’t thought it through in detail if this would break somewhere else in this specific example, but my main point is that if we allow for that it would be harder to exclude that there are any such cases, also for example with the SNS governance’s priviledge to call the SNS governance owned accounts on the ledger etc.

Another aspect, where I am sure that different people have different opinions, is separation of concerns: some might say that the core functionality should be in the SNS canisters, ensuring that it has everything that the SNSs need but also avoiding things that make it complex. For things that are just used in some SNSs and can be built on top, I think it is also great if custom canisters, libraries, etc are build that can be shared among SNSs but might not be needed everywhere.

Hope that helps explain my point better.

[Lorimer]

@lara

This would however never be possible over another (proxy) dapp canister that can be built by someone.

Thanks Lara. I neglected to account for the call context not being propagated between canisters (which was silly of me). Therefore if only the SNS governance canister has permissions for the neuron, this proxy approach wouldn’t work unless the principal for the proxy canister had permission for the neuron.

I also understand the points about making it easier to reason about the different scenarios that can occur (and their security guarantees).

---

Nevertheless, it’s reasonable for an SNS to be able to control a neuron that is owned by that SNS’ governance canister. We can rule out undesirable scenarios here given that neurons have a robust permissions system.

There are numerous scenarios where this functionality is already needed and used, where one SNS governance canister (A) owns neurons for another SNS (B). For example, it’s not unheard of for one SNS to participate in the initial token sale of another SNS (e.g. @GOLDDAO with @WaterNeuron). There are also other ways in which an SNS can acquire neurons. The way to allow SNS A to control their neuron for SNS B is to register a generic nervous system function on SNS A for calling the manage_neuron function on the SNS B governance canister (again, @rem.codes has done some great work on this). Here’s an example proposal. This doesn’t currently work when the SNS neurons owned by the governance canister are of their own token, which is a restriction that doesn’t make sense.

Given that there’s now a use case, and it’s easy to reason about the consequences, and this should be very simple to address, would DFINITY consider removing the restriction that an SNS DAO cannot execute manage_neuron on their own governance canister (even though they can execute it on the governance canister of other SNSs)?

[Lorimer]

Hey @lara, perhaps a more succinct way for me to have put what I wrote above would have been, if an SNS finds itself in possession of a neuron of its own token type (possessed by the governance canister), what options does the SNS DAO have for controlling and managing it?

[lara]

Hi @Lorimer thanks for breaking it down again.

if an SNS finds itself in possession of a neuron of its own token type (possessed by the governance canister), what options does the SNS DAO have for controlling and managing it?

These are the best two options that I see:

1. Extend the SNS governance canister to have a built-in proposal to do this.
2. Have a new canister control the neuron which is in turn controlled by SNS governance. The neuron can then also only be modified and managed by DAO proposals, possibly applying extra rules in the canister

Note that we will not have capacities to work on the first solution in the near future. So if you are looking for a faster solution, I would encourage you to consider the second option.

[Lorimer]

@lara

Have a new canister control the neuron which is in turn controlled by SNS governance. The neuron can then also only be modified and managed by DAO proposals, possibly applying extra rules in the canister

But how would the neuron be assigned to another principal, if the governance canister is the only principal that currently has control over the neuron?

@lara

Extend the SNS governance canister to have a built-in proposal to do this

Okay, sounds good. This should also be extremely simple to do. I’d expect this to be no more than a few lines of code here and there.

@lara

Note that we will not have capacities to work on the first solution in the near future

Would you expect this to be a big piece of work? I think it would be trivial. Would you accept a pull request from me?

[lara]

But how would the neuron be assigned to another principal, if the governance canister is the only principal that currently has control over the neuron?

Ah, you already have a neuron where governance is the only controller? Then indeed to do something with this neuron (including transfering it to another controller) you would need a proposal.
You could of course also create an (additional) new neuron with a different controller and just use that one for your plan. Then you could still later disburse the old neuron when the functionality is there.

Would you expect this to be a big piece of work? I think it would be trivial. Would you accept a pull request from me?

I don’t necessarily think this will be very big, no. But we still have to prioritise the work (even just a day of work means pausing some larger project or not doing another small improvement). Often it can also take a bit longer including all required testing and security reviews.

Unfortunately, we don’t have an established process yet to accept external contributions. Therefore, I think it is unlikely that we could facilitate this…

[Lorimer]

@lara

Unfortunately, we don’t have an established process yet to accept external contributions

That’s a shame, but I understand.

@lara

disburse the old neuron when the functionality is there

Okay, thanks @lara. What part of the roadmap would you expect a Manage_SNS_Controlled_Neuron to fall under? I’m hoping to get a feel for how long it might take to get support for this.

[wpb]

Hey @lara @daniel-wong @DanielThurau @msumme. I want to go on record indicating that I think that the Manage_SNS_Controlled_Neuron method that is being discussed here is a bad idea for decentralized governance. I know it may be a while before you really pick it up and focus on whether of not it is a feature that you want to build, but I really hope you think about the potential consequences.

I believe all SNS known neurons should be one contributing known neuron among many other known neurons that have equal opportunities. It should not be controlled by the NNS or by an entire SNS. Both the NNS and the SNS pay people to vote on proposals. If a specific known neuron is controlled by the NNS or an SNS, then the NNS or the SNS is defacto placing higher priority and importance on that neuron. Every decision that is made on the configuration of the neuron comes before the entire DAO and they are paid to cast a vote. Some will vote nefariously. Some will pencil whip a vote. Some will lobby for specific changes. It would be placing decisions on how a neuron operates in the hands of many people who don’t care or don’t believe they should be making those decisions because they own their own neurons or they are part of a competing organization. Having neurons that are controlled by the entire DAO removes the free market nature of known neuron contributions and the governance framework that is build around liquid democracy. Known neurons should always be controlled by individuals or smaller organizations within a DAO that come together to fight for a specific cause so that when all neurons in the DAO vote on proposals the decisions that are made represent the aggregate will of the DAO. This is undermined if the DAO is controlling a specific known neuron.

Alex Lorimer and I have gone round and round about this in regards to the D-QUORUM neuron that he has proposed for WaterNeuron and future SNS and NNS projects. You are welcome to read though the discussions to get further clarification of his position and my position, but we have been unable to convince each other (which happens a lot lately). Here is an invite to the channel where the discussions have been occurring. I encourage you to read through it before you embark on creating this method that Alex has requested. I trust your judgement on whether or not Manage_SNS_Controlled_Neuron should exist, but thought this discussion could add some community based viewpoints on the subject.

@Lorimer

[Lorimer]

Just to clarify @wpb, you’re asking DFINITY to not implement a very basic function that allows the DAO to call their manage_neuron method on their own governance canister? You want the DAO to be denied this freedom, because you think it would be bad for them?

Note that there are scenarios (other than the D-QUORUM use case) where the ability for the DAO to call manage_neuron on their own governance canister would be useful. Also, the DAO could very well decide to dissolve the neuron if they so wish, and move the proceeds into the treasury. It’s up to the DAO what they do with their own neuron.

Regarding the free market that you described, a DAO-controlled neuron would do nothing to reduce that. You’re basing your opinion on nothing substantiated. The opposite is true. A power-law distribution is the natural state of follower-VP distribution across neurons, and it’s the one that will tend to (network effects and positive feedback loops are well documented and studied in these types of scenarios). A DAO-controlled neuron means that the neuron that is inclined to have the most followers is not controlled by an individual (a single point of failure), or small group.

Note that the NNS has already set a precedent for having the DAO vote on a select few neurons that they consider the best fit for the job of reviewing certain proposals. Anyone could then create a neuron that represents a round-up of the votes of those neurons. This is what a DAO-controlled neuron would be (except that it has no single-point-of failure i.e. it doesn’t depend on some individual faithfully mirroring the will of the DAO - that requires trust, which can be abused).

There are many opportunities that open up from having a DAO-controlled neuron (such as D-QUORUM). At some point I’ll get around to proposing this for the NNS. Note that the NNS could use that power to dissolve the neuron and acquire the ICP if that’s the overall preference. The current ‘grants for voting neurons’ methodology is clunky, and would benefit greatly from being moved on-chain, where followees of a DAO-controlled neuron receive disbursements or ICP rewards (perhaps like node providers). … anyway that’s just one potential scenario.

Asking for the freedom for this type of functionality to be denied to all and any SNS is strange.

[wpb]

@Lorimer

Just to clarify @wpb, you’re asking DFINITY to not implement a very basic function that allows the DAO to call their manage_neuron method on their own governance canister? You want the DAO to be denied this freedom, because you think it would be bad for them?

I think I clearly explained my position on this new method that you have suggested, which doesn’t exist today because the SNS team hasn’t so far believed that it is needed. This has been extensively discussed in the D-QUORUM channel on OpenChat, which I invited everyone to read if they would like to see more background information. You did a great job of outlining your vision there @Lorimer . Myself and others have also did a great job of responding there as well. As stated, I trust the judgement of the DFINITY SNS team to evaluate your suggestion further and decide for themselves what new methods may be needed.

[Cris.MntYetti]

Hello everyone,

I’ve been following the discussion around the proposal for a DAO-controlled neuron, which, as I understand, is being considered across the entire SNS network, starting with WaterNeuron. Given that this could have implications for all SNS and even NNS, I wanted to seek the broader community’s insights and understand if other DAOs have been part of this conversation. If feedback from other DAOs exists, it would be helpful to see where I can find it.

My points of uncertainty:

The proposal is intended to add security, unify community voice, support smaller neurons, streamline reward distribution, and balance the free market of neuron influence. But I’m struggling to see the added value of a DAO-controlled neuron, especially given the overlap with what DAOs already control directly. Here are specific points where I feel the benefits may be redundant:

1. Reduced Single-Point Vulnerability

   • As proposed, a DAO-controlled neuron is meant to avoid single points of failure by being collectively managed by the entire DAO rather than an individual or small group. The goal is to enhance security and resilience by making sure decisions don’t rest with any one person.
   • Since the DAO already governs the SNS, any decisions the DAO makes already reflect the collective will. I understand the benefit of having an independent neuron controlled by a DAO, but what is the need for duplicating the control in a separate entity controlled by the same DAO it contributes to?

2. Unified Representation of Community Will

   • As I interpreted the proposal, a DAO-controlled neuron could act as a unified, representative voice that reflects the overall “average” stance of the DAO. Instead of each member choosing separate followees, the neuron would consolidate and amplify the DAO’s general perspective.
   • Where I see redundancy: The DAO already functions as a unified decision-making body for the project. Members who want to follow the majority can do so by voting directly or following prominent neurons that represent their own and the DAO’s interests. This redundancy raises questions about why we need a separate neuron to repackage the DAO’s will. It seems to me more about how individuals manage their neurons rather than about reducing risks.

3. Platform for Smaller Voices

   • As suggested, a DAO neuron could promote lesser-known or smaller neurons by selecting them as followees, thereby providing visibility and helping them grow followership.
   • Why It Might Feel Redundant: Supporting smaller voices is a valuable goal, but the DAO can already promote these neurons directly by encouraging members to explore diverse options. Additionally, members can independently advocate for valuable neurons without needing a central DAO neuron to direct this process. This approach seems simpler and preserves the flexibility of decentralized choice.

4. Streamlined Reward Distribution

   • An on-chain, DAO-controlled neuron could distribute rewards efficiently. For instance, followees of this neuron could receive rewards as an acknowledgment of their valuable contributions, and I agree with this claim.
   • Where I fail to understand the benefits: The DAO’s existing treasury and governance mechanisms can already reward contributions directly. Adding a neuron to handle rewards may complicate what could be managed through simpler proposals and existing structures. There is certainly great value in an independent DAO controlled neuron like this, but where’s the benefit if it’s the same DAO controlling it? Couldn’t it be more direct?

5. Free-Market Alignment and Network Effects

   • The argument is that a DAO-controlled neuron could provide a balanced and fair option in the free market of neurons, consolidating community influence and countering private or centralized neurons that might dominate followership.
   • Yes, in theory, a DAO-controlled neuron might offer a collective community choice, but in practice, it risks becoming a “default” followee if it’s the same DAO that controls it, discouraging members from exploring diverse neurons. Members in a free-market DAO already have the option to follow popular or prominent neurons aligned with the community’s values. This makes an “official” neuron unnecessary for maintaining free-market balance and risks reducing followership diversity. A decentralized governed neuron can easily be created independent from any specific DAO and promoted if the objective is to reduce VP in centralized managed ones.

I feel like the main issue addressed here is that some neurons have more influence in the ecosystem, and since those neurons are managed independently and with a more centralized structure, the willingness is to replace them with decentralized ones. Isn’t the whole point of liquid democracy for everyone to chose freely how to manage their neurons and delegations? Why introduce a function where DAO members need to consistently vote for a council and insure that it doesn’t gain overall control over the DAO? There are many benefits in having both centralized and decentralized managed neurons that contribute to the ecosystem, favouring one of them isn’t a good idea IMO. For example, Dfinity is a major contributor to ICP, it’s an independent organization that is managed internally in a centralized manner, and has a lot of influence overall. The goal shouldn’t be turning Dfinity into a NNS managed entity, rather than finding ways to incentivise more organizations like Dfinity to step up.

In conclusion, my overall questions are:

Have other DAOs been part of this discussion? Are they aligned with this direction, or are there varying views across projects? Any existing feedback would be helpful to understand if this proposal fits the wider IC ecosystem.

For those who support the DAO-controlled neuron, are there specific benefits here that I’m missing and the DAO couldn’t accomplish just as effectively through its existing governance tools?

Is the added layer of a DAO-controlled neuron consistent with our goal of encouraging decentralized governance? Does this extra complexity truly foster a diverse, free-market ecosystem, or does it risk creating a central “default” choice that could stifle that diversity?

I’d genuinely appreciate the community’s insights to better understand if the benefits of this proposal genuinely enhance SNS governance or if they risk creating unnecessary overlap and complexity.

Thanks for any thoughts you might share!

[Lorimer]

Cris, your arguments have been LLM-generated. Please understand that it’s unreasonable to debate by clicking a button while demanding a significantly larger time investment from the reader/responder (unless they’re to resort to the same approach - which gets old fast). This isn’t how reasonable debates are conducted.

100% fake

This AI detection certificate is valid for 3 days, for anyone who would like to inspect. Alternatively you can perform the analysis yourself, using this tool or a number of others.

Having been a member, I’m aware that CodeGov makes excessive use of LLMs in marketing content (and evidently elsewhere). I know that you represent the marketing arm of CodeGov, but when it comes to debating on important topics, I find this approach counter-productive to reasonable debate. It’s ridiculously easy to spam a topic with AI fluff. If you’re going to insist on doing this, can I ask that you label your content as such? It’s largely the same on OC.

Users place trust in CodeGov, and I think they deserve a higher standard of practise (in more ways than one). I don’t mean this to offend. It’s a polite request.

---

I’ll pick apart and address each of those LLM-generated points when I get a chance later. Many of them are founded on misconceptions, and a lack of understanding (which is fair, it a complicated topic, and LLMs are great at providing shallow but convincing sounding arguments in your favour, if you ask them to).

In the meantime I’ve prepared an infographic that I hope makes things clearer.

As a side note, while you’ve mentioned you’re keen to distance yourself from your position in CodeGov for the sake of this debate, I think it’s very important to acknowledge. Both you and @wpb are the only individuals who have objected to this idea. As it happens CodeGov represents Neuron A in the infographic above. Your arguments have been that you want to see VP decentralised and shared among many. You clearly do not realise what the reality of the situation is. Would you like me to show you some real data?

In terms of seeking feedback from others, I’ve only very recently broached this topic, and I decided to start with WaterNeuron given it’s governance importance for the NNS. I think it would be useful to get input from individuals and organisation that put themselves forward for the NNS grants for voting neurons elections (of which CodeGov grabbed every single possible grant).

cc @WaterNeuron, @zenithcode, @louisevelayo, @quint, @krzysztofzelazko, @Jesse, @jaesharma, @zohaib29, there are many more…

I would add...

I would add that it’s worth remembering that the first question that practically every new member asks when joining the NNS, or an SNS DAO is, ‘what’s the dev neuron’? or ‘what’s a quick an easy neuron I can follow for everything?’. A DAO-controlled neuron allows them to say ‘hey, I’ve not got time to go in-depth on this, I hereby donate my VP to the DAO (for as long as I decide to follow the DAO-controlled neuron) so that the active and diligent members can distribute that VP with careful intent’