[PROPOSAL] [DRAFT] Decrease Standard Voting Period on the Cosmos Hub

Changelog • 2025-Jan-07: Posted initial draft • 2025-Jan-08: Edited draft to apply the change only to Standard Voting Period. Summary This proposal seeks community feedback on reducing voting periods on the Hub: • Standard Voting Period: Reduce from 14 days to 7 days Motivation The Hub’s current governance timeline spans 28 days (14 days for forum discussions plus 14 days for voting). While this timeline served the Hub’s minimalist origins well, the ecosystem has evolved significantly with the addition of: • Permissioned CosmWasm • Interchain Security • Hydro • [REDACTED] from the Skip team The above, along with the upcoming changes to the Hub in 2025, could benefit from more responsive governance. And a minimum of four-week process to effectively implement any changes could potentially get in the way of moving faster. Potential risks Achieving Quorum The Hub has maintained a 14-day voting period since genesis. Halving the voting period could initially challenge reaching Quorum initially, as past governance participation patterns may need time to adjust. Mitigation : Targeted communication to Validators during in the voting period could well…

Excerpt (1198 of 1817 characters). Read the whole post on the forum ↗

Targeted communication to Validators during in the voting period could well mitigate this.

Especially with Interchain Labs taking over full development for the Hub, I don’t think we should be tweaking things that require more and better communication. I have great confidence in this new team but why introduce more risk factors into the transition period when they’re still onboarding to all the existing processes?

Expedited proposals with 7 day voting were introduced in v18 in July 2024. Since then, we have had only three expedited proposals (v19, v20, 21) and each time, 7 days of voting has been doable but still required additional comms on the final day to make sure the proposals pass.

I don’t support anything faster than 7 days on the Hub. I’d want us to hit a point where 7 day voting doesn’t require last-minute comms before considering anything faster.

7 days for standard governance is fine by me

I am all in for that, I also opened another thread on it in the past, glad to see it’s not only me.
Decreasing voting periods should make it more agile and would allow pushing changes to the Hub more quickly.

For timings:

• for standard governance, 7 days I think is quite okay
• for expedited governance, 4 days indeed might be too small, so I am unsure about that.

I also think that it kinda makes sense to split regular upgrades (and leave them at 7 days, so not expedited, that way tech-savvy people would have more time to review the code and stuff) and vulnerabilities fixes upgrades (these would be more crucial to deploy ASAP and it kinda makes sense to make them emergency ones and have even shorter voting period on these).

Not sure whether this is technically possible as of now, but sounds like a nice idea, what do you think?

lexa:

I don’t support anything faster than 7 days on the Hub. I’d want us to hit a point where 7 day voting doesn’t require last-minute comms before considering anything faster.

That’s a good point. My rationale behind decreasing the expedited voting period was that we need a shorter one than the standard but I don’t see specific needs for it other than that.

Would it be possible to have a standard Voting Period equal to Expedited Voting Period, parameter-wise?

Good idea.

We could do a 7 day standard period and then software proposals are standard, not expedited.

And something super super fast for vulnerabilities where the expectation is that we are using voting period to coordinate on an upgrade height and the patch is released once the proposal passes and the upgrade is imminent so that the vulnerability isn’t exposed until the upgrade is about to happen? I’m not as clear on what’s feasible for this.

I don’t think there’s a technical need for the expedited param to be shorter than standard…but it could be shorter by like, 1 minute or something trivial.

lexa:

We could do a 7 day standard period and then software proposals are standard, not expedited.

Is it technically possible to have software proposals as both standard and expedited? (as in, can one submit a software upgrade proposal as both standard and expedited?)

Why am I asking, both regular upgrades and the vulnerability fixes ones are technically a SoftwareUpgradeProposals, and ideally I don’t think it’s a good idea of having a new major release (let’s say upgrading cosmos-sdk from 0.50 to 0.52 or something else that’s relatively big) going via a shorter voting period (not because it won’t meet the quorum, but because people won’t have enough time to review it), and also it doesn’t seem a good idea of using a longer voting period for a vulnerability fix.

This is on my December 2025 wish list, I am delighted to see things moving faster and will vote for a reduction of this magnitude in the on-chain voting time. We need to move faster to our goals.

lexa:

I’m not as clear on what’s feasible for this.

I’m not sure either, would love to hear the input of others on how to best do this.

lexa:

I don’t think there’s a technical need for the expedited param to be shorter than standard…but it could be shorter by like, 1 minute or something trivial.

There’s a check in the code that fails if expeditedMinDeposit is not greater than minDeposit. In case the same applies to the periods ( Standard > Expedited), I’ll shorten the Expedited by 60s. That way it stays 7 days.

We acknowledge the need for more agile governance processes on the Cosmos Hub, particularly as the network continues to grow and evolve. However, as highlighted by other community members, certain critical proposals—such as software upgrades and blockchain parameter changes—require extended deliberation to ensure thorough community review and input. The introduction of expedited proposals with a 7-day voting period has significantly improved governance composability for general matters. This expedited framework, with its higher passing threshold of 66.7% (a two-thirds majority), offers a balanced mechanism to address time-sensitive issues without compromising on decision quality. Rather than reducing the standard governance voting period to 7 days, we advocate for maximizing the use of the expedited framework while retaining the standard 14-day voting period for fundamental changes . This approach strikes a balance between the need for efficiency and the importance of careful evaluation for pivotal decisions. Historical voting patterns have demonstrated that vote outcomes can shift significantly over time, highlighting the value of allowing sufficient discussion periods.…

Excerpt (1199 of 2025 characters). Read the whole post on the forum ↗

Hey Phil, thanks for chiming in. Those are some good points. Here are my thoughts: While expedited props can indeed be leveraged for standard props ( especially now that they both have the same MinDeposit amount ) it’s worth considering that the threshold (66.7%) for expedited proposals can create an unnecessary burden for straightforward changes that don’t warrant a higher threshold. Many standard proposals, while not time-sensitive, would benefit from faster execution without needing the higher threshold. Govmos: without compromising the integrity of the governance process. Could you elaborate in this? What type of proposal would benefit from a 14-day voting period, especially if we’re maintaining the regular period for forum discussions. v19, v20 and v21 ( all of which I consider critical proposals) have all been expedited proposals and there didn’t seem to be any issues. It’s also worth noting that, even with a period of 7 days, the Hub still lags behind compared to other chains. I do, however, agree completely that certain proposals require extended deliberation. Hence the suggestion of maintaining longer discussion periods for: • Major network…

Excerpt (1196 of 1256 characters). Read the whole post on the forum ↗

JohnMontagu: it’s worth considering that the threshold (66.7%) for expedited proposals can create an unnecessary burden for straightforward changes that don’t warrant a higher threshold We find this perspective somewhat puzzling. As you mentioned, “straightforward” proposals should reasonably achieve a two-thirds majority without significant difficulty. Furthermore, since the deposit requirements for expedited proposals are nearly identical to those for standard 14-day proposals, aligning the voting thresholds wouldn’t be logical. In our view, the current framework strikes a fair balance. If we were to observe misuse of the expedited system to the detriment of the chain’s integrity, we would consider proposing an increase in the deposit requirements for expedited proposals to address the issue. However, there is no indication of such abuse at present. JohnMontagu: Could you elaborate in this? What type of proposal would benefit from a 14-day voting period, especially if we’re maintaining the regular period for forum discussions. Reducing the on-chain governance duration should only be considered if it offers a clear advantage. At the moment, we see no…

Excerpt (1198 of 1641 characters). Read the whole post on the forum ↗

Update: conversation around this topic is being continued on this post by the Hypha team.

Fully against reducing voting times at this stage