feat(nns): Reduce neuron_minimum_dissolve_delay_to_vote_seconds to 2 weeks#9689
feat(nns): Reduce neuron_minimum_dissolve_delay_to_vote_seconds to 2 weeks#9689jasonz-dfinity wants to merge 4 commits intomasterfrom
Conversation
…weeks Per the mission70 whitepaper, reduce the minimum dissolve delay to vote from 6 months to 2 weeks. - Lower the validation bound from 3 months to 2 weeks - Migrate the value to 2 weeks during post_upgrade if it is currently higher, so the change takes effect immediately upon canister upgrade
There was a problem hiding this comment.
Pull request overview
Updates NNS governance economics to reduce the minimum dissolve delay required for neurons to vote, aligning the configurable bounds and performing a state migration on canister upgrade so the new minimum takes effect immediately.
Changes:
- Lowered the validation lower-bound for
neuron_minimum_dissolve_delay_to_vote_secondsfrom ~3 months to 2 weeks. - Added a
post_upgrade-time migration (viaGovernance::new_restored) that reduces the stored value down to 2 weeks when it is higher. - Updated/added unit tests covering the new bounds and migration behavior.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| rs/nns/governance/src/network_economics.rs | Lowers the allowed minimum dissolve delay-to-vote bounds to 2 weeks. |
| rs/nns/governance/src/network_economics_tests.rs | Adjusts bounds test to use the new 2-week lower bound. |
| rs/nns/governance/src/governance.rs | Runs a post-upgrade migration that reduces the stored minimum dissolve delay-to-vote to 2 weeks when higher. |
| rs/nns/governance/src/governance/tests/mod.rs | Adds migration unit tests for reducing 6 months to 2 weeks and preserving already-lower values. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…nic guard - Change DEFAULT_NEURON_MINIMUM_DISSOLVE_DELAY_TO_VOTE_SECONDS to 2 weeks - Update validation error message from "three and six months" to "two weeks and six months" - Add panic if neuron_minimum_dissolve_delay_to_vote_seconds is unexpectedly below 2 weeks - Update test expectations for new default value
There was a problem hiding this comment.
This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):
-
Update
unreleased_changelog.md(if there are behavior changes, even if they are
non-breaking). -
Are there BREAKING changes?
-
Is a data migration needed?
-
Security review?
How to Satisfy This Automatic Review
-
Go to the bottom of the pull request page.
-
Look for where it says this bot is requesting changes.
-
Click the three dots to the right.
-
Select "Dismiss review".
-
In the text entry box, respond to each of the numbered items in the previous
section, declare one of the following:
-
Done.
-
$REASON_WHY_NO_NEED. E.g. for
unreleased_changelog.md, "No
canister behavior changes.", or for item 2, "Existing APIs
behave as before.".
Brief Guide to "Externally Visible" Changes
"Externally visible behavior change" is very often due to some NEW canister API.
Changes to EXISTING APIs are more likely to be "breaking".
If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.
If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.
Reference(s)
For a more comprehensive checklist, see here.
GOVERNANCE_CHECKLIST_REMINDER_DEDUP
293e992 to
8f01582
Compare
Revert DEFAULT_NEURON_MINIMUM_DISSOLVE_DELAY_TO_VOTE_SECONDS to 6 months and gate the 2-week value behind is_mission_70_voting_rewards_enabled(). This avoids breaking tests that depend on the constant for neuron setup while still applying the new default when the flag is enabled. - Gate neuron_minimum_dissolve_delay_to_vote_seconds() fallback - Gate maybe_reduce_neuron_minimum_dissolve_delay_to_vote_seconds migration - Gate voting_power.rs min dissolve delay fallback - Migration tests explicitly enable the flag
8f01582 to
52aabd4
Compare
# Conflicts: # rs/nns/governance/src/governance.rs
N/A behind feature flag
Why
Per the mission70 whitepaper, we want to reduce the minimum dissolve delay to vote from 6 months to 2 weeks.
https://dfinity.atlassian.net/browse/NNS1-4315
What
neuron_minimum_dissolve_delay_to_vote_secondsfrom 3 months to 2 weekspost_upgrademigration behindis_mission_70_voting_rewards_enabled()so they only take effect when the mission70 flag is enabledneuron_minimum_dissolve_delay_to_vote_secondsis unexpectedly below 2 weeks during migrationTesting
Unit tests added for the migration (with the flag explicitly enabled): verifies 6 months is reduced to 2 weeks, and that a sub-2-week value triggers a panic. Bounds validation test updated.