[VOTING] Decrease voting period to 7 days and expedited voting period to 3 days

Hub Proposals Parameter Change
1

Changelog

  • 2025-May-08: defined conditions under which Hypha would put up a proposal to return to previous params
  • 2025-Apr-28: posted first draft

Context

The current relevant governance parameters on the Hub are:

expedited_voting_period: 168h0m0s //7 days
voting_period: 336h0m0s //14 days
  • Prop 926 (passed on June 17, 2024) signalled overwhelming support for the use of 7-day-voting expedited proposals for software upgrades.
  • Conversation around prop 926 suggested support for an even shorter voting period.
  • 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 :upside_down_face:).
  • 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.

Responsibility to revert back to old params

Hypha will take responsibility for monitoring Hub governance and putting up a param change proposal to revert back to 7-day expedited and 14-day standard voting period if either of the following conditions are met in the 6 months after this proposal passes:

  1. A different solution is deployed which allows for a 3 day emergency upgrades and 7 day planned upgrades, and 14 day non-upgrade governance OR

  2. More than 10% of “real” non-software proposals fail to meet quorum (e.g., not spam, not proposals where validators mindfully chose not to vote).

Hypha’s commitment is to solely to put up the proposal and work to bring it to quorum. We make no commitment to campaign either for a YES or NO vote, but will exercise our best judgement at the time of the proposal.

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.
7 Likes
2

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.

1 Like
3

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 :saluting_face:

1 Like
4

Strong yes from us too. I’m losing several months of life expectancy with each manual upgrade.

6 Likes
5

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.

2 Likes
6

Regular upgrades would not be expedited.

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.

2 Likes
7

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.

Thank you for reading,
Govmos

2 Likes
8

we 100% support this

1 Like
9

Thanks for the perspective, Govmos!

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.

2 Likes
10

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.

2 Likes
11

Strong yes for me, i will vote in favour.
Keep building faster mates :heart:

12

Personally support building fast, but “build fast/break things” concept, I do not. The responses so far can make sense in supporting this proposal, however.

Cannot support rushing proposals. If anything, decreasing voting period for expedited proposals makes sense. Will vote no for now.

1 Like
13

Curious to understand this better, FHZ!

14 days is by far the longest voting period time in the interchain afaik, and anecdotally, I find that it means we see wild swings in public opinion while the prop is in voting. That’s the worst time for there to be debate and discussion because the prop can’t be changed, and it just slows down governance and increases drama because both sides calcify in their position instead of being able to work together to edit something that’s still in draft.

The best time for a prop to sit in one phase of the process is discussion, imo. The speed at which we vote should be a function of validator responsiveness, not people needing time to think about a prop if it’s already been public knowledge for at least a week on the forum.

1 Like
14

For sure – ideally, proposals would/should undergo thorough community discussion during the pre on-chain phase. However, that’s the ideal. And that’s not what happens.

Forum engagement is deeply wanting. And unfortunately, meaningful participation rarely occurs until a proposal is live.

The reality of our governance process: attention and scrutiny are disproportionately triggered by on-chain visibility. That’s the reality.

Any adjustments to the voting period should be based on how governance actually functions today, not on aspirational assumptions about how we want it to work.

While there may be a compelling case for reducing the vote period in specific contexts, such as software upgrades where validators must act quickly…applying this to regular governance proposals would be problematic imo. Most proposals require more deliberation time, not less.

In fact, I support the opposite in some cases. Specifically, extending the vote period when quorum is only reached near the end of the voting window.

This pattern can be symptomatic of governance manipulation, as outlined here:
Proposal: Extend Voting Period When Quorum Reached Too Close to Proposal End

15

Really? Mind sharing your data for this?

As someone who closely follows governance action, I’ve observed the opposite pattern for non-upgrade proposals. Take the AADAO oversight elections, for example, voter turnout was among the highest we’ve ever seen, yet the top two candidates’ proposals didn’t reach quorum until around day 12 iirc.

16

Depends on how “reasonable” said confidence is. I don’t believe in optimism driven parameter changes. Should be predicated on observable trends and data. On facts. Not hope.

17

Agreed.

The logic behind keeping the 14 day voting period, versus 7 days, is wanting to give ample time. An extreme, but necessary arguement, is remembering a few years back when the world was, unforunately, experiencing the various natural disasters.

18

The reality of our governance process: attention and scrutiny are disproportionately triggered by on-chain visibility. That’s the reality.

100% agree with this. It’s very frustrating. I speculate that people don’t vote until day 12 (in the case of the AADAO elections )because the deadline is day 14. Deadlines change people’s behaviour and from many proposals where I’ve done get-out-the-vote campaigns, it’s rare for people to be willing to commit to voting until time is almost over. How can we gather observable data about how people behave with a 7 day deadline without actually creating a 7 day deadline? I don’t think it’s possible to get the whole chain to pretend there’s a 7 day deadline.

We have a philosophical difference on optimistic param changes though, and that’s fine. I think the impact of the change is humble enough that it’s worth giving it a shot and seeing concrete results. It’s easy to change a parameter back, and I am very confident that it’s possible to get validators voting in 7 days with a little bit of extra outreach if people want to change it back.

All of that being said, my priority here is to get the expedited voting period down so we can use it for emergency upgrades and that (imo) necessarily impacts the standard voting period.

From my perspective, the constraints of the problem are:

  1. Use only the currently available tools (i.e. do no dev or integration work)
  2. Cause as little churn in the software pipeline as possible

Reducing expedited voting to 3 days is an obvious choice and I think very few people would disagree with it. Gov upgrades are lower risk, easier to work with, and universally preferred over manual upgrades.

If we reduce expedited voting and leave standard voting at 14 days, then our standard planned software releases need to go through 14 day voting as well, because there will be no more 7 day voting on the Hub. Coming up on three years of coordinating Hub upgrades in collaboration with three different software teams, my expert opinion is that this lead time is not possible without frequent binary swaps and emergency upgrades to include new patches, which throws the upgrade de-risking process into jeopardy as well (we put a lot of resources into testing the Hub’s transition from one version to the next).

I don’t want to jeopardize governance discussions! But I really do need help figuring out what the solution is, then, given the constraints that I see on the problem. @Cosmos_Nanny what do you think? Any suggestions?

4 Likes
19

First, Lexa - thank you for all the work you do.

If this is to be framed as a controlled experiment, then we need to define what the actual controls are, no? Saying “we can change it back” minimizes the coordination cost of submitting and passing another proposal; and more importantly, on what basis would we make the case to revert, clear?

Rn, there’s no defined rollback criteria. At minimum, can we explore this more?

If we’re serious about treating this as an honest experiment, we should establish what metrics we’ll be observing e.g., voter/validator turnout, quorum timing, or proposal pass/fail rates. And who will monitor this?

Without that, we risk making changes wo a structured way to assess the impact of changes made.
The change isn’t “humble” when it potentially redefines the governance tempo across the board.

In a cost-benefit analysis, the potential cost is too high wrt the downstream effects. To reiterate, some high-stakes proposals could be rushed through with inadequate deliberation or pass/fail simply due to compressed timelines, not based on merit. I agree with your observation that human-behavior is deadline driven. But deadlines don’t beget better decision-making outcomes.

I legit feel your pain.
I’ve been directly involved w six proposals on the hub, and each time it’s felt like I’ve been in active labor for 14 days!

But because of the 14-day voting period (combined with 2 to 3 weeks of pre-prop deliberation), I’m more confident that these proposals achieved social consensus, which is the imperative and objective of gov.

I respect the effort to solve coordination constraints wo new development. But the solution should be a long-term fix, maybe extend x/gov to support dynamic voting periods, determined by proposal metadata or type, especially for upgrade-related proposals.

3 Likes
20

That’s a great point, let’s define an experiment.

Hypha’s putting this prop up, and we can commit to monitoring its impact on the pace of governance. We can also commit to submitting the proposal to roll it back - submitting props and getting them up to quorum are both well within our wheelhouse. However - obviously no one here can commit to that rollback proposal passing, just that we would take on the labour of bringing it to vote and getting it to quorum.

I suggest the following criteria for putting up a rollback proposal in the 6 months following this proposal passing:

  1. A different solution is deployed which allows for a 3 day emergency upgrades and 7 day planned upgrades, and 14 day non-upgrade governance.
    • This solution may yet be undefined, though promising options include updating the gov module to allow for dynamic voting periods or shifting the entire upgrade process out of on-chain gov (like Celestia). My team is investigating some of these options, so it’s a real possibility that one will manifest.
  2. More than 10% of “real” non-software proposals fail to meet quorum.
    • This doesn’t include spam props, or props where validators choose not to vote because they deem it not worthwhile.
    • In the last 6 months, there have been 13 non-software proposals, all of which (I think) hit quorum in the 14 day voting period. Prop 989, I’m not certain about based on how Mintscan displays the data.
    • I’m cool with a vibes-based policy - if someone posts and says “this prop really should have met quorum and it didn’t”, I’d want to see a couple other respected community figures agreeing but that’s proof enough for me.

To me, whether or not a prop has hit quorum is the only meaningful metric here. We cannot measure the reasons for how many props get put up, or for a proposal failing or passing aside from meeting quorum, and the timing of when the voter turnout hits quorum is a fun fact but ultimately secondary to whether it hit quorum at all.

In a cost-benefit analysis, the potential cost is too high wrt the downstream effects.

I don’t begrudge this difference of opinion in the costs vs benefits, but I do want to be really clear about where my sense of priority comes from as both an active governance participant and the team that coordinates the Hub’s upgrades.

I truly believe that it if it means getting to use governance to patch software instead of doing it manually, it’s worth the risk of negatively impacting governance.

Manual upgrades are extremely costly to the Hub’s dev team, coordination team, and validators. If normal governance is like 14 days of active labour, then performing a manual upgrade feels like we have ignored all medical advice and made an otherwise routine gestation into something high-risk and dangerous.

Governance provides a clear, safe(r), easy way to repair our chain when it’s broken. Manual upgrades repeatedly risk chain halts, which are bad for the Hub’s reputation; relationship with partner orgs, chains, and validators; and longevity as a leader in the interchain.

Our ability to participate in governance depends on having a functional chain at all, and any time we halt, there is a chance (however small) that it doesn’t come back or that our partners deem the Hub unreliable and walk away.

3 Likes