Allowing neurons to add a controller (without being able to remove previous controllers)

Governance
1

There has been a healthy amount of deliberation around the idea of making all neurons transferable. The biggest concern in doing so it that it would allow bad actors to buy up voting power, vote to adopt destructive proposals and then sell their stake before adverse consequences can materialize.

Many of the proponents of neuron transferability were motivated by the intention of creating some sort of business model around the transfer of neurons. With the passing of This motion and subsequent proposal (which allows canisters to control neurons, but doesn’t allow a neuron’s controlling principal to be transferred) such business models are easily permitted.

However, there are others such as @dfisher (and myself) who have legitimate need for the ability to associate a neuron with another principal.

I’m writing this post to open the discussion on the idea of allowing neurons to have multiple controllers (rather than just a single controller) with the added restriction that controllers may Not be removed, only added.

This would allow neuron holders to access their neurons via several different principals, while simultaneously addressing the security concerns that stem from the idea of neurons being too liquid to foster a governing body that prioritizes longterm outcomes.

By restricting principals from being removable from the list of a neuron’s controllers, you ensure that neuron controllership is only ever shared amongst trusted parties and never transferred from one actor to another, thereby preventing any marketplace from sprouting as a result of this change.

This would allow stakers with neurons that are controlled by principals associated with hardware devices to be able to add other devices from which they can access the neurons.

This would also permit the continued monitoring of neurons that are transferable as any neuron that doesn’t have a self-authenticating principal as a listed controller can be concluded as being a canister-controlled neuron.

@bjoernek @diegop @skilesare @Ajki @lara

1 Like
2

The frustrating thing is that this was in the NNS since the very beginning with the TOPIC_NEURON_MANAGEMENT topic that was removed from the NNS in the initial weeks because people were unknowingly giving COMPLETE control(except for final dissolve) of their neuron to DFINITY and ICA(the only known neurons at the time). This was a UI issue and we could have kept it with just an explanatory sentence of what the topic did in the UI, but for some reason, it never came back. ICDevs had plans to use this topic extensively for fundraising, but once it was removed, it never returned.

You can still use this topic but you have to do so programmatically and hack the NNS interface javascript to get it to work. For canister controlled neruons I’m sure it is trivial.

If you follow a neuron on this topic, that neuron can make proposals and, if the only one followed then instant decisions on your neuron. It isn’t exactly a controller, but has all the same rights to split, vote, and even disperse maturity. Perhaps it can’t do the final dissolve…only the original controller can do that, but especially in scenarios where you have no intention of ever dissolving the core principle of the neuron it is basically a controller.

Unless you need the right to dissolve and won’t be able to ever do that from the original controller it may meet your needs.

Once set up you can spawn maturity with a command like:


dfx canister --network=ic  call rrkah-fqaaa-aaaaa-aaaaq-cai manage_neuron \
"(record \
{\
    id=opt (record {id={ControlingNeuron}:nat64}); \
    neuron_id_or_subaccount = null; \
    command=opt (\
      variant {MakeProposal=(\
        record {\
          action=opt (variant {\
            ManageNeuron=record {\
              id=opt (record {id ={TargetNeuron}:nat64}); \
              neuron_id_or_subaccount = null; \
              command =  opt( variant {\
                Spawn = record{\
                  new_controller= opt(principal \"{Desired New Controller of Maturity Neuron\")\
                }\
              })\
            }});\
          url = \"https://forum.dfinity.org/icdevs.org\";\
          title = opt(\"donation\");\
          summary = \"donation\";\
        })\
      })\
  })";

You can see the contrived instructions in the archive of our site here: Icdevs_mainsite/content_donations.md at bootcamp · icdevs/Icdevs_mainsite · GitHub

2 Likes
3

This looks like the exact functionality that I need, except for the fact that it has to be performed via a proposal to the NNS.

For my use case, I’d need to employ this functionality on a regular basis without the latency introduced by having to undergo an NNS proposal.

1 Like
4

It is a different kind of NNS proposal and only the followed neurons vote…so if you only follow one neuron on the topic it executes as soon as you make the proposal.

2 Likes
5

This is perfect. I think I’ll be able to work with this. Thanks Austin

1 Like
6

When a neuron submits a proposal, does it automatically vote in favor of adopting that proposal? Or does a neuron have to submit a proposal, and then explicitly vote to adopt the proposal after it has submitted the proposal

7

Whichever neuron you propose with will auto-vote yes. So if you need to have others vote you can create a controlling neuron with a very small total amount…but I don’t think that is what you’re looking for.

I think this will get you mostly what you want.

I do think that I misspoke that this allows splitting neurons. You’d have to achieve that over time with maturity going to a different place.

8

I will add that multiple controllers that can’t be removed would be VERY interesting and much simpler. :slight_smile: