I would like to give an implementation update on the motion proposal compounding maturity which was approved in March’22.
Following an interactive implementation approach, the NNS team will be able to release the first part of this motion proposal covering maturity modulation this week. This means that whenever a new neuron is spawned, the ICP amount minted is modulated taking recent ICP price movements into account.
For further details on the modulation function please refer to this wiki article.
The remaining features of this motion proposal are being worked on.
Please don’t release this update without providing a way to move maturity between neurons. Some of us have many neurons with different lockups and merge all the maturity in a 8 year neuron. With this change it won’t be possible to do this without incurring in the modulation.
Have you thought about the addition of the possibility to convert maturity into staked ICP within the neuron whose it is the maturity ?
Currently, the proposal only plans to allow :
– the conversion of the LIQUID maturity into STAKED maturity
– the conversion of the LIQUID maturity into LIQUID ICP
But not the the conversion of the LIQUID maturity into staked ICP
@Manu (here) and I (here and here) talked about the importance of this feature (which is the current feature), because a lot of people will prefer staked ICP to staked maturity. Both stakers have the same purpose : stake, but we force people wanting to accumulate staked ICP rather than staked maturity to spawn ICP before restaking it within their neurons.
I know @jwiegley added this point in the system and gave us the possibility to discuss it further. How is your thinking about this ?
For neuron holders who take the conservative approach of treating daily maturity as a taxable event, it wouldn’t make much sense to convert LIQUID maturity into STAKED maturity. What would make sense is the current Merge Maturity functionality, the conversion of LIQUID maturity into staked ICP. It would be unfortunate if neuron holders who want to continue to Merge Maturity in this way have to jump through hoops and spawn/restake every time they want to Merge Maturity, and be subject to maturity modulation.
Put another way, it doesn’t make sense to penalize neuron holders (poor UX and possibly decreased rewards) who are just trying to follow the tax laws and guidance in their jurisdiction and aren’t even selling any ICP.
If neuron holders were able to opt in or out of this new system, I’d think that would also address this.
Pleased consider making this an opt-in feature. For me personally, I have been against the whole proposal and don’t feel it fits into the way I want to have my accounting set up. Others feel differently. This change is complicated in various ways and its effects on taxes will be different depending on jurisdiction.
To help each individual cope with their own situation, why not make this an opt-in feature? This allows both points of view to exist in parallel. It could be nice to test the system in this way as well, instead of going all-in and forcing the change across all users. If things go as planned and perhaps more legal clarity comes, maybe in the future the change can be completed whether or not people opted-in.
Hi all,
many thanks for your inputs! I am conscious of the fact that this motion proposal was subject to a long and intense discussion, shortly before I joined the Internet computer ship. So please bear with me in case that I do not capture all nuances of prior discussions in my answers, but I will try my best
Quoting from the initiating medium article
“There is a danger that a lack of understanding leads authorities to draw false links between the maturity of a neuron, ICP tokens, and realized income. Therefore, we must further harden the design of the framework to reduce this risk, by having maturity produce an indeterminate number of ICP (that is, so that given some amount of maturity, it cannot be predicted how much ICP it might eventually produce).”
it is my understanding that the proposal did not contain on purpose a way to convert liquid maturity to staked ICP (although I understand from where you are coming from).
In my personal opinion, I am less worried about the +/- 5% modulation factor (given the overall volatility in the crypto market) but rather increasing the system complexity by introducing a further term “staked maturity”. When this is implemented in the next step (as per the agreed motion proposal) we have to make sure that the NNS interface makes it as easy as possible to follow this process for normal users.
Again quoting from the medium article
“Neuron maturity is an attribute of neurons, which cannot exist independently, and cannot be separated from the neuron to which it belongs. This makes it impossible to sell, exchange or otherwise dispose of neuron maturity.”
moving around maturity from neuron to neuron does not seem to be aligned with intent of the motion proposal (although I understand why you are asking for that given the way you manage your neuron portfolio.)
If this feature is marked as opt-in, then to my understanding we would defeat the purpose of the motion proposal which has the very aim to ensure that it cannot be predicted how much ICP is produced from maturity.
I was only using the terms of the proposal itself as show the photo and overall the introduction of the proposal to the forum when we have been asked to give a feedback to Dfinity :
I disagree about such a description of the purpose of the motion proposal : it has the very aim to ensure that it cannot be predicted how much ICP is produced from maturity, yes, BUT ONLY TO avoid the tax burden for PRECISE people suffering of THEIR tax jurisdiction. I am in favor of relieving them of course, but we are not all in this case, and the disappearing of the tax suffering for this people is about to become an appearing of suffering for other ones. It is perfectly consistent to let predictability for those not suffering from it. We don’t need to go from an extremum to another one : by going to predictability for everyone TO unpredictability to everyone.
By setting this features an opt-in feature : the ones that this proposal was aiming to relieve are relieved, and the ones that have never been concerned by tax problematics keep going on without having to suffer anything.
It will not relief anyone from their tax obligation. This is the problem. For some reason, Dfinity did not wanted to seek a professional tax firm advice and it looks like their blockchain scientist became a tax expert on the fly. I think they will put many investors with serious tax problem, as I mentionned many time in the main thread.
If they leave the option for accurate calculation as of now, at least it would be optional for people who want take the chance thinking IRS will not tax them because the rewards are modulated. If they don’t, all investors where tax apply, will be forced to move in the grey zone (black TMO) of taxes.
The irony is that Dfinity acknoledge that the California tax accountant said thoses rewards were taxable.
Just cannot understand the whole situation why they do this.
Some people are critisizing Dfinity should focus on the layer 1 only of the blockchain. Programming for tax purposes, for some countries only, is mindblowing.
Why has Dfinity decided to prioritize this proposal over others much more important for the NNS to work properly such as 55651 and 38985?
In my opinion it shouldn’t have been a priority as it doesn’t provide significant benefits to the average stakers, if anything it makes the already complex system harder to understand and use.
We consider other features that are planned to have a lower priority and hence suggest tackling them after the SNS rollout. This includes for example the work on compounding maturity, the community fund and spam prevention.
It also seems to contradict what was previously stated, Dfinity didn’t have time to work on a true spam fix due to the SNS taking up all the resources, but somehow the least useful feature got prioritized and is about to be shipped. Do internal plans change that often in a matter of weeks? If so Dfinity should do a better job at communicating them.
It is not entirely clear why the developers should waste precious time on such an update. How does it improve the IC network? This will only complicate the understanding of staking for beginners, for whom these neurons with dissolve delay and maturity were already difficult to understand.
It sounds like the new system is not going to be opt-in and the +/- 5% modulation will be enforced for all minting of ICP rewards. It that’s the case, I would suggest that for the sake of the UX, Merge Maturity should still be supported. That is, there should be a Merge Maturity button (i.e., convert liquid maturity to staked ICP) that does something like this:
The merge maturity operation begins a 7-day clock that completes with a modulation of the amount to be merged. At the end of the 7 days, this final amount of newly minted ICP will be automatically added to the staked ICP of the neuron.
This would be a better UX than having to go through multiple steps to merge maturity (disburse maturity, then remember to increase stake 7 days later).
Yes, I understand the new stake_maturity functionality described in the proposal. I’m suggesting that the existing merge_maturity functionality could also be included, but in a modified form to fit in with the rules of the new system. This would be useful for neuron holders who stake their voting rewards and want to pay taxes for those rewards in the year the rewards are received, rather than waiting to pay taxes on those staked rewards until the neuron is dissolved.
Measures originating from the community are not treated the same as those originating from within Dfinity. Since governance proposals are not self-executing, we still depend on Dfinity, and it is no surprise that they prioritise their own priorities. In this case, the instructions came from the very top, too.
