Would point 4 be used to move maturity between neurons? Cause if the only way to do it implies being subject to modulation then I doubt it will be done that often and surely not automatically.
Moving maturity between neurons is usually done to optimize long term yield, APY for an 8 year lockup is already low considering the timeframe and the uncertainty, so if it’s 19%, I want 19%, but if modulation is applied in a downturn the APY won’t actually be 19% due to having lost a % of tokens due to modulation, so instead of auto compound disbursed maturity it’s better to wait for timeframes with positive modulation, so one can get the full APY + modulation bonus.
To my understanding, point 4 was mainly requested as a way to automate the workflow “spawn maturity to ICP” and “stake this ICP”. This was raised by several people in this thread and also in other forum entries.
John, I can not even express how much I agree with you! I have been 100% opposing this proposal from the very beginning and still think it is a very, very bad idea! See my original post for the reasons opposing here: Request for feedback: Compounding Maturity Proposal - #131 by khm I think those reasons still hold very true! Thank you for honestly expressing your view on this topic!
Here is a further implementation update on the work of the motion proposal for maturity enhancements.
As previously communicated, staking maturity was rolled out for NNS Internet Identity. As a next step, this is planned to be released also for NNS hardware wallet controlled neurons and NNS Quill. A wiki page giving an overview on neuron operations related to maturity which is here.
In order to reflect changes in functionality for NNS hardware wallet controlled neurons Zondax needs to update the Ledger app. Hence, we aligned a roll-out plan with Zondax as the provider of the app.
Planned next steps
Tuesday 20 Dec
Release update of the NNS Front-end app. This disables the “Merge maturity” button for the current Ledger app 2.0.6. It enables the button “Stake maturity” for the future version of the Ledger app 2.0.7.
Release update of the NNS back-end. This redirects calls from “Merge maturity to staking maturity.
Release an update of NNS Quill, replacing “Merge maturity” by “Stake maturity”. One can already now download the source code, compile it and stake maturity.
Wednesday 21 Dec:
Ledger releases Ledger app 2.0.7. Calls to the merge maturity (being now routed to stake maturity in the NNS back-end) will be displayed as stake maturity on the display of the Ledger device.
In a second phase, once a more comprehensive update of the Ledger app is available (which will also include auto-stake maturity), merge maturity will be disabled in the NNS back-end.
What do you need to know as a user of a Ledger device?
After Tuesday 20 Dec, users of Ledger app version 2.0.6 will be able to continue to the Ledger device, but will not be able to stake maturity (nor the former merge maturity). Users who update to the Ledger app version 2.0.7 on Wednesday 21 Dec, will be able to stake maturity.
What do you need to know as a user of NNS Quill?
Users are encouraged to update to the latest version of NNS Quill, which replaces the neuron manage command “–merge-maturity” by “–stake-maturity”. Users who continue to use prior versions of NNS Quill should be conscious of the fact that calling merge-maturity will result in staking maturity.
Yes @Roman, this is still the plan!
We have to build anyway build a disbursal operation for the NNS, and as per community input this should include the ability to automatically re-stake (e.g. via a flag).
Hi @dfisher, given that auto-stake for Ledger devices mainly requires updates in the Ledger app, we are in touch with with Zondax to define the plan (the timing is tbc in the moment). I will provide an update to this thread once I know more.
I can see why automatic staking would definitely be better than staking. However, what’s the difference between staked maturity vs. merged maturity for you, @dfisher? It must be significant if you are willing to incur the weekly effort of restaking maturity manually each week rather than using the automation of merged maturity. Is it because merged maturity can’t ever be reversed without dissolving a neuron, whereas staking allows you to move new maturity to a new neuron with a different dissolve delay? Or is it for tax reasons (or both)? Finally, doesn’t restaking cause spawning, which currently has a maturity modulation penalty of 4-5%? I’m still doing my due diligence, so sorry if these sound like basic questions.
Historically I merged maturity once a week. Now I will stake maturity once a week. I would prefer to auto compound staked maturity because it won’t require any effort on my part and I can just let it run. But I need to wait until that feature is made available on the Ledger HW.