We’re announcing an upcoming API change ETA March 17, 2025, that may affect your neuron-related functionality. Specifically, this update pertains to the constraint on the minimum dissolve delay required for neurons to propose or vote.
Action Required
All NNS downstream clients who have any neuron-related functionality should:
check if they rely on the minimum delay constant (neurons’ min dissolve delay to propose / vote),
This change is a first step towards reducing the minimum dissolve delay to 3 months. If you have questions, feedback, or need assistance with the transition, feel free to reply here.
could you please clarify the following:
1/ will the minimum_dissolve_delay_to_vote be part of response from the get_network_economics_parameters query call, or it will be separate one?
2/ what about maximum_dissolve_delay? still hardcoded to 8 years?
1/ Indeed it’s going to be part of the voting_power_economics field of get_network_economics_parameters query call.
2/ There’s no plan AFAIK to change the maximum delay, so no point in fetching it dynamically.
1/ got it, thanks
2/ still nice to have everything consistent and achievable from the get_network_economics_parameters call. in the same way as for SNS projects from the get_nervous_system_parameters call.
Thanks for the explanation! I’m looking forward to learning about the transition from 6-month to 3-month staking.
Should interest rates be reduced when we transition, or should everyone just receive a 3-month reduction in their dissolve time (no change to interest)?
@EpicICP, the percentage allocation of rewards from the lowest to the highest staking period will remain the same, and the dissolve delay of currently locked neurons won’t be changed. So, if you’re currently staking for 6 months, that same reward tier will be available for neurons with a 3-month dissolve delay after the transition. This means your rewards could actually increase if new neurons with shorter durations start being created - as long as you don’t dissolve your neuron.
Based on the payload of the prior proposal of this sort that executed, the settings being applied in this proposal are the same as the current settings (except for a minor difference in how the default votingPowerEconomics value is specified, illustrated below).
I’m curious why the neuron_minimum_dissolve_delay_to_vote_seconds field has been omitted from votingPowerEconomics. It was added to this type recently in this commit →
The proposal claims to be setting it to 6 months (the current default), but the payload says otherwise.
Hi @1eo, could you clarify why this code path needs executing (given that it’s using the existing settings, rather than changing them)?
Update: I’ve just queried the IC API and can see that the raw payload does in fact contain the missing information that the NNS dapp hides!
15778800 seconds (6 months), as described in the proposal summary All makes sense now. This field needs initialising as it was only recently added. Evidently the NNS dapp is using an outdated version of this type so is not aware of the new field.
I think this highlights a governance attack vector. The NNS dapp should absolutely not be hiding information in the payload. I don’t think it should be making any assumptions about the shape of the data, and it should show exactly what the payload contains. What do you think @jasonzhu?
With https://dashboard.internetcomputer.org/proposal/136454 being adopted, the field neuron_minimum_dissolve_delay_to_vote_seconds is now initialized, so it’s a good idea for frontends to adopt the value from this field (and no longer used hard coded values for this parameter).
We will soon work on making the proposals more readable in the nns-dapp, starting with the SNS parameter changes.
On the other hand, backend changes are not a priority at the moment, but we are aware of it.
All makes sense now. This field needs initialising as it was only recently added. Evidently the NNS dapp is using an outdated version of this type so is not aware of the new field.
