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

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

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

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

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

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.

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.

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

we 100% support this

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.

lexa:

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.

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.

lexa:

I think it will be a challenge to proposal makers to get votes in 7 days

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.

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

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.

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.

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

Govmos:

Historical voting patterns suggest that most proposals reach quorum well before the 7-day mark

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.

Govmos:

reasonable confidence to trial this adjustment.

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.

lexa:

The best time for a prop to sit in one phase of the process is discussion, imo.

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.

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…

Excerpt (1197 of 2526 characters). Read the whole post on the forum ↗

lexa: 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. 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…

Excerpt (1194 of 2064 characters). Read the whole post on the forum ↗

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: • 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. • 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…

Excerpt (1195 of 3312 characters). Read the whole post on the forum ↗

The proposal to shorten Cosmos Hub’s governance voting periods, from 14 to 7 days for standard votes and from 7 to 3 days for expedited ones. is a practical step toward making the governance effective and agile. At GATA HUB, we support this change. We’ve seen the community handle shorter timelines successfully in the past, and we believe these adjustments can improve decision-making without compromising participation, so long as communication remains strong. Shorter voting periods mean quicker reactions to important issues, which is essential as the ecosystem grows. That said, it’ll be important to monitor the impact over time and adjust if needed. Overall, it’s a smart move that balances efficiency with the reality of how active this community already is.

Heavily support this - this will let us do upgrades faster and better!

Can we get rid of the “abstain” voting nonsense while we’re at it? I don’t see the benefit of people showing up to say “no opinion”. Either lower required quorum or make vals actually vote.

Can we get rid of the “abstain” voting nonsense while we’re at it?

That is well beyond the scope of this proposal, but everyone is welcome to make their own proposals (signal or otherwise) to request changes to governance.

Yeah, I’m not getting into the whole process again for no validators to participate in the discussion and then vote no. Concur it’s outside of scope, wanted to put the idea on magmar’s radar, sorry for the poor wording.

Seen sir - abstain has caused much pain

Can’t we create something dynamic based on the quorum ?

Not without changes to the gov module, which is beyond the scope of this proposal. That would be a longer term solution and it’s on the list of things my team and the ICL team is looking into.

Yeah, 100% supportive of this prop. The manual upgrades are painful and this is really going to save time for the validators, ICL & Hypha. They’re also just taking away time for our team to be able to ship, so it’s really going to help us move faster.

If it turns out props are not meeting quorum, we can always revert back. But Osmosis has been doing this for a while now and there are no major problems there, even though there’s a large validator overlap.

Feeling the urgency to put this to a vote so that (if it passes), we will be able to use expedited proposals for patches in June. I’ve moved this into [LAST CALL] and intend to put it on-chain tomorrow.

I’ve added the details of the experiment into the prop text. In essence:

• This is a trial for up to 6 months
• If a better longterm solution arises in 6 months, Hypha will put up a prop to revert the params and work to make sure it hits quorum
• If >10% of reasonable proposals fail to hit quorum in 6 months, Hypha will put up a prop to revert the params and work to make sure it hits quorum
• Hypha is not responsible for passing the reversion proposal, just for putting it up and getting it to quorum

This is incredibly important for enabling the Hub to benefit from rapidly increasing Cosmos development pace and future developer platform we want to build on top of the hub.

Since we’ve become responsible for hub and broader stack development, we’ve been focused on rapidly accelerating product development everywhere. In 3 months, we’ve shipped:

• A new version of IBC with a connection to Ethereum
• A new version of the Cosmos SDK
• A massively improved version of EVMOS’s EVM
• A new liquid staking module that doesn’t require forking the SDK

We’ve also triaged a ton of security issues across the stack and the hub, and we’re really just getting started. With all of this development (espeically the emergency development), we’re constantly bottlenecked on hub upgrade times.

As a result, the Hypha team has had to coordinate multiple unusual non-gov upgrades to patch issues or get the latest and greatest in time for product releases

If we’re going to make the Hub great, we need to be able to move faster as a community and this proposal takes us in that direction

We’re in voting: Mintscan

This closes on May 23rd. Please cast your vote!

Vote YES easily. Great proposal to make Cosmos more agile and faster in decision-making

Hi, how you will make it dynamic? Like some props only or…?

Cosmos_Nanny: Really? Mind sharing your data for this? As someone who closely follows governance action, I’ve observed the opposite pattern for non-upgrade proposals. We’d actually be very interested in seeing your data — because on-chain evidence suggests quite the opposite . Selecting the last 50 proposals (discounting updates and spams) and analyzing the vote trends definitely supports our conclusion. This information is publicly available and verifiable by anyone. For reference, voting trends can be easily tracked via the Mintscan dashboard by navigating to the “Vote” tab, as illustrated here: image 2792×990 139 KB Source: Mintscan This tool allows any community member to see that, aside from a few outliers like the AADAO oversight election (which you rightly pointed out), most proposals reach quorum well before the 7-day mark , and in many cases, the voting outcome is already settled by then . If any doubts remain regarding the proposed reduction of the voting period to 7 days, we believe that implementing the change would offer the perfect opportunity to analyze fresh data and compare voting behaviors with those observed under the current 14-day…

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

It has been six months and three legitimate proposals have failed to meet quorum, triggering Hypha’s responsibility to put up a proposal to revert this change. I’ve begun the thread here: Increase voting period to 14 days and expedited voting period to 7 days