Dear all,
Please note that the proposal discussed in this thread (136454) does not change any NNS parameters, it merely exposes information that is already present in the NNS. As pointed out by @infu, exposing the parameter in the API is a prerequisite for potentially changing it. However, I recommend discussing changing the NNS parameter in question (neuron_minimum_dissolve_delay_to_vote_seconds) in API Change: Neuron Minimum Dissolve Delay Constraint Update (Release ETA March 17, 2025), while keeping this thread focused on the API extension. This includes, e.g., the following (absolutely valid) question:
Below, we explain why this conceptually uncontroversial change might have caused some confusion and the next steps to mitigate this confusion.
Background (exposing a new parameter in the NNS API)
The NNS involves an internal parameter that defines the minimum dissolve delay of a neuron required for it to be eligible to vote and propose. Recently, a new network economics field neuron_minimum_dissolve_delay_to_vote_seconds has been added, with the goal of exposing the parameter in question to the clients, so they no longer need to hard code its value. Relying on this API field would enable a smooth transition if the parameter will change in the future (please refer to API Change: Neuron Minimum Dissolve Delay Constraint Update (Release ETA March 17, 2025) discussing lowering the parameter from 6 to 3 months).
Proposal 136454 (initializing the new API field)
To enable the clients to start using the new API, the neuron_minimum_dissolve_delay_to_vote_seconds field needs to be initialized to the current value used for the corresponding parameter in the NNS (6 months). If adopted, 136454 will accomplish that goal (and nothing else).
Validating the proposal
Currently, proposal 136454’s payload is not correctly rendered by the NNS dapp (the new field neuron_minimum_dissolve_delay_to_vote_seconds is missing). The issue will be fixed with the upcoming NNS dapp upgrade (which was proposed earlier this week). Before this release, you may verify the proposal payload using the ICP Dashboard https://dashboard.internetcomputer.org/proposal/136454 or the following DFX command:
NNS_GOVERNANCE=rrkah-fqaaa-aaaaa-aaaaq-cai
dfx canister --ic \
call $NNS_GOVERNANCE get_proposal_info '(136_454 : nat64)' \
| idl2json | jq ".[0].proposal[0].action[0]"
which outputs
{
"ManageNetworkEconomics": {
"max_proposals_to_keep_per_topic": 100,
"maximum_node_provider_rewards_e8s": "10000000000000",
"minimum_icp_xdr_rate": "100",
"neuron_management_fee_per_proposal_e8s": "1000000",
"neuron_minimum_stake_e8s": "100000000",
"neuron_spawn_dissolve_delay_seconds": "604800",
"neurons_fund_economics": null,
"reject_cost_e8s": "2500000000",
"transaction_fee_e8s": "10000",
"voting_power_economics": [
{
"clear_following_after_seconds": null,
"neuron_minimum_dissolve_delay_to_vote_seconds": [
"15778800"
],
"start_reducing_voting_power_after_seconds": null
}
]
}
}
Notice that in the output, only neuron_minimum_dissolve_delay_to_vote_seconds is being assigned to a new value by this proposal. Other network economic parameters are null, which means they are not being changed, or set to the same values as now, which can be checked via the following command: dfx canister --ic call rrkah-fqaaa-aaaaa-aaaaq-cai get_network_economics_parameters | idl2json| jq).
Next steps
Due to the proposal rendering issue, DFINITY plans to vote on the NNS dapp upgrade proposal on Friday morning, wait for a few hours, and only then vote on 136454. This enables the community to validate this proposal also via the NNS dapp. Concretely, we aim at voting for the NNS dapp upgrade at 10:00, while proposal 136454 will be voted on at 17:00 CEST (UTC+2).
Ratio = 2:1 — an 8-year commitment gave 2x the influence of a short-term neuron.
