feat(governance): decouple minimum dissolve delay to vote from propose

[jasonz-dfinity]

Why

Under Mission 70, neuron_minimum_dissolve_delay_to_vote_seconds was lowered from 6 months
to 2 weeks. Since the same parameter also gated proposal submission, neurons with just 2 weeks
of dissolve delay can now submit proposals. This decouples the two thresholds so that proposal
submission retains the original 6-month requirement.

What

• Add a NEURON_MINIMUM_DISSOLVE_DELAY_TO_PROPOSE_SECONDS constant (6 months) and use it in
  make_proposal instead of the governable vote minimum.
• Add validation on neuron_minimum_dissolve_delay_to_vote_seconds ensuring it cannot exceed
  the propose constant. Every time a neuron submits a proposal it also votes on it, so the vote
  minimum must stay at or below the propose minimum.

Testing

• Updated test_neuron_minimum_dissolve_delay_to_vote_seconds_bounds for the new validation error

[github-actions]

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

1. Update unreleased_changelog.md (if there are behavior changes, even if they are
   non-breaking).

2. Are there BREAKING changes?

3. Is a data migration needed?

4. Security review?

How to Satisfy This Automatic Review

1. Go to the bottom of the pull request page.

2. Look for where it says this bot is requesting changes.

3. Click the three dots to the right.

4. Select "Dismiss review".

5. 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

[Copilot]

Pull request overview

This PR decouples the minimum dissolve delay required to submit proposals from the (recently lowered) minimum dissolve delay required to vote, ensuring proposal submission retains the original 6‑month requirement while voting eligibility can remain lower.

Changes:

• Introduce NEURON_MINIMUM_DISSOLVE_DELAY_TO_PROPOSE_SECONDS (6 months) and enforce it for non-ManageNeuron proposal submission in make_proposal.
• Add validation preventing neuron_minimum_dissolve_delay_to_vote_seconds from exceeding the proposal-submission minimum.
• Update network economics validation tests to expect the additional validation defect.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
rs/nns/governance/src/governance.rs	Adds the new 6‑month proposal-submission constant and applies it in make_proposal for non-ManageNeuron proposals.
rs/nns/governance/src/network_economics.rs	Adds an extra validation defect ensuring vote minimum does not exceed the proposal-submission minimum.
rs/nns/governance/src/network_economics_tests.rs	Updates expected validation errors to include the new “must not exceed propose minimum” defect.

Comments suppressed due to low confidence (1)

rs/nns/governance/src/governance.rs:5248

• make_proposal now enforces a new, hard 6‑month minimum dissolve delay for submitting non-ManageNeuron proposals. There doesn’t appear to be a unit/integration test covering this new behavior (e.g., a neuron with 2 weeks dissolve delay should still be able to vote but should be rejected when attempting to submit a Motion/ExecuteNnsFunction/etc. proposal). Please add a targeted test to lock in the new decoupled thresholds and prevent regressions.

        let min_dissolve_delay_seconds_to_propose = if action.manage_neuron().is_some() {
            0
        } else {
            NEURON_MINIMUM_DISSOLVE_DELAY_TO_PROPOSE_SECONDS
        };

        // The proposer must have sufficient dissolve delay to submit proposals.
        // This threshold is intentionally decoupled from the voting eligibility
        // threshold, which can be lower.
        if proposer_dissolve_delay_seconds < min_dissolve_delay_seconds_to_propose {
            return Err(GovernanceError::new_with_message(
                ErrorType::InsufficientFunds,
                "Neuron's dissolve delay is too short.",
            ));

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

1. Done. 2. Existing APIs behave as before. 3. No data migration needed. 4. No security-sensitive changes.