feat(nns): Add neuron_minimum_dissolve_delay_to_vote_seconds to VotingPowerEconomics
#4180
Conversation
aterga
added
the
CI_ALL_BAZEL_TARGETS
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
If this pull request affects the behavior of any canister owned by
the Governance team, remember to update the corresponding
unreleased_changes.md file(s).
To acknowldge this reminder (and unblock the PR), dismiss this
code review by going to the bottom of the pull request page, and
supply one of the following reasons:
-
Done.
-
No canister behavior changes.
| pub const MIN_DISSOLVE_DELAY_FOR_VOTE_ELIGIBILITY_SECONDS_BOUNDS: RangeInclusive<u64> = | ||
| (3 * ONE_MONTH_SECONDS)..=(6 * ONE_MONTH_SECONDS); | ||
|
|
||
| if !MIN_DISSOLVE_DELAY_FOR_VOTE_ELIGIBILITY_SECONDS_BOUNDS.contains(&delay) { |
There was a problem hiding this comment.
I'm confused by this - why not just do >= and <= instead of constructing a range and seeing if the value is inside of it?
| /// This value is an essential part of the staking mechanism, promoting | ||
| /// long-term alignment with the network's governance. | ||
| #[prost(uint64, optional, tag = "3")] | ||
| pub neuron_minimum_dissolve_delay_to_vote_seconds: ::core::option::Option<u64>, |
There was a problem hiding this comment.
So my main question is - if we're exposing this as an API parameter, does that mean that the value is actually being used to see if a neuron can vote? It looks like not yet. Is there a followup PR planned to actually use the value on VotingPowerEconomics to determine neuron voting eligibility?
This PR moves the inner code constant
neuron_minimum_dissolve_delay_to_vote_secondstoVotingPowerEconomics, exposing it as an API parameter. This helps the NNS clients to prepare for a potential change of this parameter.