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 mitigate this. If passed, I’d be happy to contribute to this during the adjustment period.
Additional Considerations
The forum discussion period, while not an on-chain parameter, should align with these changes:
Reduce standard discussion period to 7 days
Maintain extended discussion periods for:
Major network upgrades
CHIPS proposals
Other fundamental protocol changes
To maintain consistency and avoid any potential uncertainties around governance participation patterns, the Expedited Period will remain unchanged. Making it equivalent to the Standard Period, if this proposal passes.
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.
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?
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?
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.
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.
I’m not sure either, would love to hear the input of others on how to best do this.
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. Retaining the 14-day voting period for critical proposals ensures that all community members have adequate time to review, deliberate, and participate meaningfully in these decisions.
At Govmos, we strongly encourage the community to extend the use of expedited votes, which we believe could accommodate approximately 80% of governance proposals. By leveraging this framework more frequently, we can achieve the desired agility without compromising the integrity of the governance process. Should the expedited framework prove insufficient over time, we would then consider supporting a reduction in the standard governance voting period to 7 days.
For now, we firmly believe that a broader adoption of the expedited framework represents the most prudent and moderate path forward.
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.
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:
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.
Reducing the on-chain governance duration should only be considered if it offers a clear advantage. At the moment, we see no compelling evidence to support this idea. It seems that the expedited framework is currently underutilized, which is why we recommend increasing its use as a first step. If it becomes evident that speeding up governance beyond the 7-day expedited timeline would be beneficial, we could then support a proposal to reduce the general voting period to 7 days and the expedited period to 3 days. We hope this clarifies our position on the matter.
