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 proposals where Hypha, in our best judgment, feels validators chose not to reject via failure to meet quorum)
Proposal
Notes
1005 Bridging Worlds: Empowering Cosmos with an Ethereum NFT Bridge
1006 Connecting Businesses: Empowering Stack Adoption with a Data Bridge (using NFTs)
Same proposal as 1005, in spirit, with updates based on conversation with Cosmos Labs
Later re-proposed in 1015, which reached quorum and passed with some validator outreach from Hypha.
Proposal
Increase the Hub’s standard voting_period for all proposal types to 14 days.
Increase the Hub’s expedited_voting_period for all proposal types to 7 days.
Governance votes
The following items summarize the voting options and what it means for this proposal:
YES - You support increasing the Hub’s voting period to 14 days and expedited voting period to 7 days.
NO - You do not support increasing the Hub’s voting period to 14 days and expedited voting period to 7 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 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 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.
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!
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.
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.
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.
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.
I don’t really think a different, temporary solution is needed here.