[PROPOSAL] Extend Voting Period When Quorum Reached Too Close To Proposal End

[PROPOSAL] Extend Voting Period When Quorum Reached Too Close To Proposal End


We propose a modification to the Cosmos Hub’s governance module to potentially extend the voting period for active governance proposals. This extension will be triggered if a proposal achieves quorum too close to the end of its voting period. The aim is to ensure that there is sufficient time for discussion and to mitigate potential governance manipulation.


The Cosmos Hub – and for what matters, any other Cosmos blockchain using the default x/governance module of the Cosmos SDK – is subject to a potential issue that arises when proposals achieve quorum towards the end of their voting period.

The operational principle of the code is that a proposal takes effect – meaning the outcome of the proposal is valid and it is not automatically rejected – only when it reaches quorum. When this happens too close to the end of the voting period, it might be hard for all stakeholders to react accordingly and in time, potentially compromising the governance process.

For instance, a voter might have chosen to not cast their vote when going over a proposal, since the proposal did not seem to get the involvement required to reach quorum and become effective. The proposal might then suddenly reach quorum only a few days before ending, with the voter being unaware and therefore unable to react.

In general, we deem necessary to provide sufficient time for thorough discussion and deliberation among stakeholders, and avoid situations where the voting process might be hindered in any way.

Through this new implementation system, we aim to encourage holders to cast their vote sooner, ensuring the quorum is achieved more swiftly.

Proposed solution

To ensure that stakeholders have ample time for discussion and deliberation, we’re introducing a mechanism to extend the voting period under specific conditions. Here is how it works:

  • Quorum Timeout: Think of this as a “warning timer”. If a proposal achieves quorum after this timer has expired but before the voting period ends, it triggers an extension. If quorum is reached within this time window, it potentially means the proposal might need more time for discussion. Given the 14-day voting period on the Cosmos Hub, we propose a quorum timeout of at least 7 days (or in any case a fixed value between 7-11 days).
  • Max Voting Period Extension: This is the maximum amount of extra time a proposal’s voting period can be extended. A possible value could be 7 days, half of the voting period.
  • Quorum Check Count: This determines how many times we check if a proposal has achieved quorum after the “warning timer” has expired. It is like checking in periodically to see if more time is needed for discussion. This number should be low enough - say 2 or 3 - so that quorum checks are sufficiently distanced between each other. We don’t need to check too frequently and we want to minimize the impact on network performance. Note that setting this parameter to 0 effectively disables the mechanism presented here entirely. Therefore, governance always has the freedom to disable quorum-based vote period extensions if desired or necessary.

In Practice

  • When a proposal is initiated, it enters a queue where it waits for its turn to be checked for quorum.
  • If the proposal achieves quorum before the “warning timer” expires, it continues as usual, and the voting period ends as scheduled.
  • If the proposal achieves quorum after the “warning timer” but before the voting period ends, the voting period gets extended by a predefined amount (but not more than the maximum allowed extension).

Why This Approach?

This mechanism ensures that proposals that reach quorum - thus implying its outcome will come into effect - late in their lifecycle get the time they deserve for thorough discussion. It strikes a balance between giving stakeholders enough time to deliberate and ensuring the governance process remains efficient.

For those interested in a more technical and detailed explanation, please refer to the associated Architecture Decision Record (ADR) available here. If this proposal gets approved, we will submit a pull request to the Cosmos SDK for inclusion.


We are excited to share that this functionality has already been implemented. For those interested in diving deep into the code, we are providing the GitHub link for a thorough examination, and we encourage everyone to take a look and provide feedback or raise issues. However, it is essential to note that the current implementation is compatible with the main branch of the Cosmos SDK. Additionally, it should be noted that expedited proposals (not yet available on the Cosmos Hub, but introduced in later Cosmos SDK versions) are intended to be exempt from the mechanism proposed here. However, if an expedited proposal fails and is converted to a regular proposal, it will then become subject to this mechanism, just like any other regular proposal.

Given that the Cosmos Hub currently operates on an earlier SDK version (v0.45), there might be a need for backporting to ensure compatibility. We’re confident that this backporting process should be straightforward, and we are prepared to undertake it ourselves if necessary.

Performance implications

The computational complexity of checking for quorum is by all means equivalent to the tallying process. This stems out from the necessity to iterate over all votes. Any potential slowdown during quorum checks would be confined to the specific block when the check occurs, in a similar fashion to a proposal tally.

By spacing out quorum checks appropriately (e.g., once every few days or even weekly), the overall performance impact on the network should be contained.


The proposed enhancement to the governance module is a proactive measure to ensure that all governance proposals receive the attention, discussion, and deliberation they deserve. By extending the voting period under specific conditions, we can foster a more informed and engaged community, reduce the potential for manipulation, and ensure that decisions are made with ample consideration. We believe this change will significantly benefit the Cosmos Hub and its stakeholders.

We thank the community for reading through this proposal and for getting involved and providing their feedback. This work is part of the Decentralists initiative on Cosmos Hub governance pioneered by All in Bits Inc.



in a world where large orgs (like yours, owning 10% of Atom genesis tokens) are not allowed to use their Atoms to manipulate vote outcomes by massively delegating/redelegating during the last days of a proposal lifecycle, this idea would be nice.

in our world, i’m not sure it is.


I have been advocating extending the voting period for a while now. I am a firm believer in open markets and building from logic. Consensus computing, at this stage, which is “managed” manually by operators, simply doesn’t make sense with these tiny voting windows. Consensus is about communication, which is about time and patience. A network such as Cosmos is a baby and needs more time to make decisions, like all babies (metaphorically) do.

Easy yes from Citizen Cosmos / Web3

1 Like