[REJECTED] Increase voting period to 14 days and expedited voting period to 7 days

Changelog • 2025-Nov-27: Added language to clarify that this voting period applies universally to ALL proposal types • 2025-Nov-26: Created first draft Context Proposal 998 passed in May 2025, reducing the Hub’s voting periods from 14 days standard / 7 days expedited to 7 days standard / 3 days expedited. As part of this proposal, Hypha agreed to monitor the Hub’s governance progress and put up a proposal to revert this change (restoring the 14 day standard voting and 7 day expedited voting) if either of the following conditions were met: • 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 • 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). Conditions for reverting • No alternative solution for 3 day emergency upgrades, 7 day planned upgrades, and 14 day non-upgrade governance has been developed. • The following proposals have failed to meet quorum despite being legitimate proposals from known entities (i.e., not spam, not proposals that ignored governance norms, not…

Excerpt (1192 of 2820 characters). Read the whole post on the forum ↗

I feel that the decreased voting period has been a huge success, with faster governance and our first governance-approved 3-day emergency upgrade landing on the chain before a security advisory had even been published. I think the Hub can handle the 7/3 voting period, and we should not revert.

We are generally favorable to restoring the previous standard. That said, it may be prudent to delay the final decision until the new Foundation delegation program is released. This program is expected to place meaningful weight on governance participation as a criterion for validator eligibility, which could naturally improve quorum formation without requiring immediate changes to the voting period.

Waiting for its publication would give the community a clearer view of its practical effects and help determine whether further adjustments are truly needed. Still, we would also support reducing the voting period at this stage, with the option to revisit and reduce it again later once the impact of the delegation program on governance participation becomes measurable.

I’m really surprised to hear that support from you, Govmos! What makes you supportive of reverting to the 14/7 voting periods?

I think it’s good tension for our governance to have some proposals struggle to meet quorum with zero outreach. People running proposals (especially community spend proposals) should be doing community outreach throughout the process to gauge sentiment and make sure the community is engaged with what’s being proposed.

Aligned with Lexa’s view here that we should not revert the change to the voting period and that the 7 and 3 day voting structure has been successful at getting the Hub to move more quickly on important proposals.

Re: the quorum, agree with @Govmos that the upcoming delegation program should help encourage more active governance participation. Even since the initial discussions I’ve been having with validators about governance participation and its involvement in quorum we’ve already anecdotally seen an uptick in voter participation. I expect this will only increase when the program launches.

we think we should keep 7/3 voting period, faster governance is nice, especially for emergency upgrades

lexa:

I’m really surprised to hear that support from you, Govmos!

We believe there may have been a misunderstanding. To clarify, we are not advocating for reverting software upgrade proposals to a seven day voting period, nor do we wish to modify expedited proposals, whose faster execution remains beneficial for the chain. Our point concerns non-software proposals, for which extending the period to fourteen days could be appropriate if there is clear evidence of quorum degradation.

More specifically, we were expressing support for your suggestion to restore the standard governance period to fourteen days, provided the governance module can be updated to distinguish between proposal types. This would be our preferred outcome.

Regarding overall governance participation and recent difficulties in meeting quorums, we continue to believe that the forthcoming delegation policy should address these issues by encouraging more consistent validator involvement.

I have the same opinion here. If the quorum is not reached, we can conclude that the proposition lacks of precision, which is of no interest to anyone in the proposed form. Vote NO for me.

Ah, understood!

Nothing technical has changed since the last proposal, so it is not possible to set different voting periods for different kinds of proposals. This proposal is explicitly to set ALL voting periods to 14 days standard and 7 days expedited.

And I continue to argue that there is not clear evidence of quorum degradation. 3/18 props failing to meet quorum (one of which passed on its second try) is not a strong enough evidence to me, especially given that I don’t think the proposal teams did any outreach at all on them. Feel free to correct me if any validators were actually approached by those teams and asked to vote!

I also though initially this is proposed for all proposals. Do I get it right that the following is being proposed?

• for software upgrades proposals: 7 days regular voting/3 days expedited voting
• for other proposals: 14 days regular voting/7 days voting

@lexa can you clarify this a bit, I think I am confused.

This is proposed for all proposals.

There is no existing way to set different voting periods for different proposal types. I’m not sure where that idea came from, since it wasn’t possible when I made the first prop (998) and it still is not possible.

I will amend the top-level post to make that extra clear.

Hello!
We support the idea of fast proposal, fast proposals = fast decision making - this is exactly what we need to make Cosmos better!

I don’t think this is always the case. The third proposal example was pretty precise. It simply wasn’t “exciting”

According to my quick calculations approximately 40% of the voting power belongs to centralised exchanges or other entities that never participate in the governance. I expect precise calculation to show a number even higher than that

Don’t think the incentivization program will affect the validators mentioned above but it will definitely help to make sure that the remaining 60% does participate. The problem is that validators that making up the dormant part have higher staking positions in the top and the ratio is shifting towards them. The share of the active voters is slowly shrinking

Unless the problem get resolved (e.g. through Nakamoto Coefficient proposal) the issue with the quorum will only pop up again as more critical later

A temporary solution could be to reduce the quorum from 40% to 30%/20% that way proposals will always pass either via a no or a yes vote. Instead of failing because of the quorum. As an example the Recover Expired IBC Client to XPLA Chain that got rejected had a quorum if 39.14% even though it had a yes vote of approx 87%.

I think this is a dangerous idea on its own - reducing quorum without changing the pass threshold would just make it easier to pass proposals as well as hit quorum. If one were to reduce quorum, I’d also want to raise the pass threshold.

Presently, we require 40% quorum and 50% YES votes (0.4*0.5 = 0.2) so 20% of the voting power can pass a proposal.

If we were to reduce quorum to 30%, I think the pass threshold should then be 66.67% so that the voting power required to pass a proposal is the same 20% (0.3*0.6667 = 0.2).

However! That’s beyond the scope of this proposal I don’t really think a different, temporary solution is needed here.

Why not increasing the hub’s gov periode to like 10days and keep expedited to 3 ?

Perhaps We can find an agreement on a middle

There might be an argument to be made for that, I suppose. I am against it. I think 7 days has worked fine, and I’m not interested in slowing down our governance again.

But that, too, would be for a different proposal. The details of this proposal are firm, since it is what I committed to putting up for a vote under certain conditions when Prop 998 went on-chain.

I share the same opinion, I really dont know why a prop for reversal would be needed . But if it is needed, mayne we could find a consensus on a middle. That was what I think

Planning on putting this on-chain today. I should have last-called it but I’m not modifying this prop in any way from its original intent so I don’t think last-call is super important.

I really should check the forum more often. Just completely overwhelmed these days with administrative stuff + starting the SOC2 process.

So, personally not favorable to this proposal, like most of the participants to this discussion.

It is true that a longer voting period for non emergency / non technical proposals could be positive as a lot of voters probably hear about it only after it makes it on-chain, and some actually need thought and analysis to make up one’s mind; but until it is technically possible it’s a moot point.

The upcoming delegation program for Cosmos will have the governance participation as a criteria if I’m correct, so it might actually help shuffle the active set enough that quorum is reached on every proposal.

I would keep the decreased expedited_voting_period at 3 days.

For the standard_voting_period, I would love to see some analytics about the change in participition rates of frequent voters. If the participition rate of frequent voters decreased drastically because of the decreased voting period than we should argue if speed outweights governance participation.
@lexa Would you be able to supply metrics about this?

Sorry, Flo, I don’t have those metrics.

I won’t be putting up any more props to adjust the voting periods unless something dramatic changes. I’m really happy with 7 days standard and 3 days expedited, and that set of params has now effectively passed governance twice (once for the initial prop, and once when this prop was rejected).

No worries. I somehow missed that this was already in voting when i wrote my comment.