A forum discussion in January 2025 suggested reducing the standard voting period to 7 days.
Limitations
The expedited voting period must be less than the voting period.
There are no gov params to set a separate quorum for expedited proposals.
There is a gov param to set a separate threshold (% of YES votes out of total votes necessary to pass the proposal) for expedited proposals.
Only software upgrade and cancel upgrade proposals are eligible to be expedited on the Hub. This is Hub-specific and can be changed in the gaia code in a future upgrade if we want.
Proposal
Reduce the Hub’s standard voting_period to 7 days.
Reduce the Hub’s expedited_voting_period to 3 days.
Rationale
Reducing the standard voting period to 7 days
The Hub has had a 14 day voting period for years and has often struggled to reach 40% quorum on proposals without dedicated outreach from the proposal maker to validators via Telegram and other off-chain coordination platforms.
The norm for the Hub is to have at least 7 days of discussion on the forum, meaning that a proposal generally takes at least 3 weeks to progress from being posted to being passed (or rejected ).
Expedited proposals with a 7 day voting period have been used on the Hub for software upgrade proposals since July 2024, with dedicated outreach and reminders from the proposal makers to reach quorum.
As of prop 992 (March 2025), the Hub has proven itself capable of passing proposals in 7 days with only standard communications from the mainnet coordination team (one email, one Discord announcement).
Reducing the expedited voting period to 3 days
No one likes doing manual halt height upgrades - they’re stressful, risky, and painful to coordinate and execute.
Using governance to set the halt height is the simplest and fastest patch solution - it doesn’t require any code contributions or new features (though Hypha and ICL will also be pursuing other solutions - please stay tuned for our retrospective on the last emergency upgrade).
3 days is the fastest the Hub has ever been able to coordinate emergency action, so shifting that 3 days into an expedited proposal instead of communications makes sense and doesn’t represent a change in the actual time necessary for an emergency upgrade.
Governance votes
The following items summarize the voting options and what it means for this proposal:
YES - You support reducing the Hub’s voting period to 7 days and expedited voting period to 3 days.
NO - You do not support reducing the Hub’s voting period to 7 days and expedited voting period to 3 days.
NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned.
ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.
I also think all proposals should be eligible to be expedited. Things like client recovery and param change might also be used in an emergency. We can work with ICL to get that changed in the future but it’s a code change, not a param change.
As the OP for the initial draft to reduce voting periods for both expedited & normal proposals, Citadel One is in strong support of this.
For context, our proposal initially suggested 7 days for standard props and 4 days for expedited ones but we ended up not pushing on-chain upon feedback as the timing didn’t seem right.
it seems like since then the Hub set has proven capable of accommodating the proposed shorter dates, in which case it’s a Yes from us!
@lexa I just updated the other post to redirect people to this one. Also we’d be happy to contribute to the deposit amount if this goes onchain
Absolutely supporting this one, this should be a no-brainer. Manual upgrades are pure evil and should be avoided at all costs.
@lexa one thing, can you clarify whether regular upgrades (such as v22 → v23) are gonna be expedited or not? I suggest the following:
software upgrades fixing security vulnerabilities/exploits and also maybe IBC unfreezes - expedited proposals, 3 days voting
regular software upgrades - regular proposals, 7 days voting
other proposals - regular proposals, 7 days voting.
I suggest having 7 days for regular proposals (not involving fixing vulnerabilities etc.) as there might be some big changes in the codebase so it’d be nice for validators to have a bit more time to review and research and to make the informed decision about how to vote.
Fully agree with your suggestions for the norms of expedited proposals. I would like all proposals to be technically able to be expedited because we never know what will be useful in an emergency one day, but in practice expect that only emergency proposals would be able to pass on an expedited timeline.
Following our previous assessments in the linked discussion, we initially expressed a preference for extending the use of expedited proposals rather than reducing the standard voting periods. However, in light of the new arguments presented by the Hypha team, our position has evolved positively.
We recognize that this adjustment will require validators to exercise increased vigilance to prevent potential governance abuses. We trust that proposers will continue to respect pre-governance discussions and refrain from rushing proposals on-chain without sufficient community input. Should abuses occur frequently, it may eventually become necessary to implement a more stringent governance framework to mitigate such risks.
That being said, this remains speculative at this stage. If the core teams believe that faster governance execution can bring meaningful benefits to the chain, we are willing to support and explore this direction.
I think part of the problem with reducing the expedited voting period without also reducing the standard period is that our regular (planned) software proposals will end up taking 14 days OR will have to move just as fast as emergency operations.
Both seem like problems to me - I think it’s important than product gets to move faster than 14 days and that emergencies move faster than product. Ergo - reducing both voting periods. Having been on the proposing end of many proposals, I think it will be a challenge to proposal makers to get votes in 7 days but I also hope it will increase the importance of the off-chain discussion and coordination.
This is a very good emphasis on your prospective with this bid and was a key factor in our decision to support the proposal in its current form.
Historical voting patterns suggest that most proposals reach quorum well before the 7-day mark, giving us reasonable confidence to trial this adjustment. Should actual participation metrics decline significantly, corrective measures can still be proposed. For now, we prefer to remain optimistic and evaluate outcomes once the new framework is in place. We’ve also noted that raising the minDeposit threshold previously led to a reduction in spam proposals—this too will need to be monitored should this pattern re-emerge.
).