Disburse Maturity in NNS

[jasonzhu]

TL;DR

DFINITY proposes to support disbursing maturity in NNS similar to SNS, as well as deprecating spawning neurons in favor of disbursing maturity.

Context

In both NNS and SNS, neurons accumulate maturity as voting rewards, and they can be converted to ICPs (with maturity modulation). Below is how the process looks like for NNS/SNS:

Disburse Maturity in SNS

In SNS, converting maturity to ICP is done through disbursing maturity: 7 days after the user “disburses maturity”, new ICPs are minted and sent to the account chosen by the user. The DisburseMaturity command has been supported from the very beginning of SNS as the only option for converting maturity to ICP.

Spawn Neurons in NNS

In NNS, the only way to convert maturity to ICP is through spawning new neurons: 7 days after the user “spawns” a new neuron, the ICP within the spawned neuron becomes available and can be disbursed to any account.

In a typical week, there are about 2400 new neurons created, and among them about 1800 (75%) are spawned neurons. Most of the time, such neurons just become empty after the spawn is finalized (and dissolved) and the user gets the fund out. Therefore, switching from spawning to disbursing maturity will satisfy the use case most of the time, while avoiding leaving behind empty neurons. If the user indeed wants a new neuron, they can still create a new neuron by staking the disbursed ICPs. For those reasons, we believe that disbursing maturity should replace spawning.

Proposed Changes

There are mainly 2 changes in the API in terms of disbursing maturity, similar to SNS:

• A new manage neuron command will be added, given a percentage and an ICRC1 address, the portion of the maturity (specified by percentage) will be disbursed to the given address after 7 days (subject to maturity modulation, similar to spawning)

  • In the NNS Dapp, the command will be available through a “Disburse” button in the “Maturity” section of the neuron page, similar to SNS.

• When querying full neurons, the client will also get a list of ongoing maturity disbursements.

  • In the NNS Dapp, active disbursements of NNS neurons will be viewed through the neuron page in the “Maturity” section of the neuron page, similar to SNS.

Deprecation of Spawning

In order to make sure no clients are broken by this change, we will propose changes in a few areas:

NNS Dapp Controlled Neurons

Soon after the NNS Governance supports disbursing maturity, we will propose changes in the NNS Dapp to replace the “Spawn Neuron” button with “Disburse Maturity”. Note that this does not include hardware-wallet-controlled neurons.

Hardware Wallet Controlled Neurons (Connected to NNS Dapp)

After a new hardware wallet app supports disburse maturity, we will propose some changes in the NNS Dapp to add the disburse maturity button alongside the spawn button. At that time, spawn will always work, while disburse maturity will only work for newer hardware wallet versions. 3 months after that, we will propose to remove the spawn button, and the user would have to upgrade their hardware wallet app in order to disburse maturity.

Hardware Wallet CLI

DFINITY maintains a CLI library for advanced users. Disburse maturity will be added soon after it’s supported by NNS Governance

Other Use Cases

For all other use cases, we plan to allow 4 months of migration time (after NNS Governance fully supports disburse maturity) before removing the spawn command.

Next Steps

Further updates regarding the implementation of disburse maturity will be posted in this thread. As always, feedback is welcome, especially regarding the deprecation timeline of the spawning.

[Lorimer]

Thanks @jasonzhu, could you confirm who will have permission to disburse maturity from an NNS neuron? Will it continue to be limited to the neuron controller (and not permitted for hotkeys, or Neuron Management followees)? I assume this is the case, but just want to make sure.

[wpb]

There is a utility for spawning neurons that inherit the same configuration as the parent neuron, but where you can assign a controlling principal. It’s how the Synapse and CodeGov neurons were both created. Both were assigned a controller that are verifiably without a known private key. Both had Followees configured for the Neuron Management proposal topic on the parent neuron so that the child would inherit the same Followee configuration. I’m not sure if this feature is available via the NNS dApp, but it is available via command line. Will this feature be preserved?

How to create a decentralized community neuron

NOTE: Since the latest governance upgrade, the method described below does not work anymore since disburse_to_neuron does not copy the followees anymore. I will update this tutorial shortly to use spawn instead, where the same strategy still works. How to create a decentralized community neuron Recent months have brought amazing progress toward the decentralization of the IC governance system, the NNS. Several named neurons have been created and accumulated significant following, including ICP…

[Lorimer]

You can achieve the same thing with canister-controlled neurons. If you don’t need the canister you can let the canister be deleted (verifiably removing the controller).

Note that the CO.DELTA neuron is a canister-controlled neuron that was instantiated by the canister.

[bjoern]

While not ideal, at least one could still use split to create more decentralized neurons from a single initial one. So maybe create one more before the feature is disabled and then you can create as many as you want in the future.

[jasonzhu]

could you confirm who will have permission to disburse maturity from an NNS neuron? Will it continue to be limited to the neuron controller (and not permitted for hotkeys, or Neuron Management followees)?

Good question. If we go with the same behavior as Spawn, hotkeys should not be able to spawn, but neuron management proposals should be able to. I’m not seeing a strong reason to deviate from that behavior. Please let me know if you disagree.

[Lorimer]

I think it would be good to keep the rule that only the controller can disburse maturity (excluding Neuron Management followees). Otherwise this would be a change that would break some behaviour assumptions/understandings relating to the security of funds.

[jasonzhu]

Do you see any concrete examples where this would be problematic, and do you think it applies to spawning too (there were indeed neuron management proposals for spawning in the past)

I understand the general concern and will discuss within our team, but also wanted to understand your concern a bit better.

[jasonzhu]

Interesting case. I was not aware of it.

Do you think the approaches suggested by @Lorimer and @bjoern are satisfactory?

[Lorimer]

@jasonzhu

there were indeed neuron management proposals for spawning in the past

I guess it’s the disbursement that’s restricted, and/or its possible that some genesis neurons behaved differently

Could you confirm that there’s not currently a way for a non-controller principal to access the maturity of a neuron?

@jasonzhu

Do you see any concrete examples where this would be problematic

D-QUORUM is a use case that would be complicated by altering the security arrangements of neuron maturity.

@Lorimer

Note: The formal neuron controller for D-QUORUM is the NNS itself, and the only principal with the power to disburse voting rewards is the neuron controller

---

Update: This misunderstanding above has now been corrected. Thank you @jasonzhu

@Lorimer

Note: The formal neuron controller for D-QUORUM is the NNS itself. This is the permanent controller that can never be changed, meaning that the NNS has the power to remove all followees on the Neuron Management topic if they ever abuse their position (such as by attempting to withhold or wrongfully obtain maturity). See founding committee commitment.

[wpb]

Yes, if there is a split method that will inherit the Followee configuration of the original neuron, then it should be ok. I guess the functionality that would be lost is having the ability to assign a different controller, which I think could be useful. However, I recognize the use case is extremely small. Right now I’m not seeing a need for any more neurons like this for any use cases where I would be involved. Perhaps it’s best to not let this niche influence the changes you are making at this time.

[msumme]

@Lorimer

I think it would be good to keep the rule that only the controller can disburse maturity (excluding Neuron Management followees). Otherwise this would be a change that would break some behaviour assumptions/understandings relating to the security of funds.

Controllers would be able to disburse, not hotkeys. But are you also thinking that it shouldn’t be possible via ManageNeuron proposals?

[Lorimer]

Thanks @msumme. Indeed, given that Neuron Management followees are not the formal controller of the neuron (i.e. the permanent one that can’t be changed). I’m sure I’ve read this restriction, either in the code or in documentation somewhere. Do I have this wrong?

[jasonzhu]

I believe neuron management proposals are always able to spawn neurons, i.e. the neuron management followees as a group have access to the maturity of the managed neuron. To be sure, I just successfully reproduced in a local environment (the neuron with maturity follows another neuron at topic 1, and the owner of the followee is able to spawn a neuron from the maturity assigning the controller to its own principal).

Therefore, allowing disburse maturity to do the same thing doesn’t seem to alter any security arrangements.

[Lorimer]

Cool, thanks for clarifying @jasonzhu (I had the wrong end of the stick). I’ll update my post on that D-QUORUM thread

[tiago89]

Only saw this topic today.

I really like the experience on SNS Neurons, agree that it should be the same on NNS and how ICP is disbursed

Also it should make it easier for Neurons that are canister controlled.

Looking forward for developments.