# Universal governance module proposal

**URL:** https://forum.hypercore.one/t/universal-governance-module-proposal/544
**Category:** Development
**Created:** [November 5, 2024, 11:39am UTC](https://forum.hypercore.one/t/universal-governance-module-proposal/544 "2024-11-05T11:39:55Z")
**Posts on this page:** 1
**Showing post:** 15

<div class="post-metadata">

### Author: ![coinselor](https://forum.hypercore.one/letter_avatar_proxy/v4/letter/c/41988e/32.png) [@coinselor](https://forum.hypercore.one/u/coinselor)
#### Post date: [November 13, 2024, 11:29am UTC](https://forum.hypercore.one/t/universal-governance-module-proposal/544/15 "2024-11-13T11:29:07Z")

</div>

First, I want to thank @sumoshi21 for taking the initiative to draft an implementation for the governance module. This has been long overdue and is a crucial step for the future of our network.

I appreciate how quickly Sumoshi integrated feedback and made changes. However, George’s insights present a compelling argument against the current approach, which we should carefully consider.

> [@WP1 Governance Spec](https://forum.hypercore.one/t/wp1-governance-spec/545/5):
>
> The suggestion for dynamic quorum would be for robustness. It’s very likely that over the years pillars will stop functioning but not deconstruct (if people die without succession plans). Likely we will need a consistent mechanism to take them out of the pillar pool for both momentum creation and voting quorums, with a way to get back in (e.g. a signature of liveliness).
> 
> Consider the following:
> 
> Let’s say we get a bunch of pillars in China. 40%. But then China decides to completely cut off outside internet access. We can’t reach 66% + 1 for an upgrade. We can’t spork to lower the threshold since that would require the same threshold. Without a dynamic quorum, a hardfork would be required. And that could be acceptable given the circumstances. I am providing a possible solution for network survivability without hardforks.
> 
> Dynamic quorum also means people need to either vote NO for changes or get out of the way for progress. Someone who can’t be bothered to vote may be bothered to upgrade if they see everyone else is. Greater momentum. Enough time would need to be given however.

It’s encouraging to see @aliencoder and @georgezgeorgez, along with other network developers, joining the discussion. I’d love to hear from even more voices, as this change deserves thorough review and due process.

While I recognize different preferences for pace, I tend to favor caution with significant changes like this. If speed had been a priority, I would have recommended drafting the implementation a year ago, during the initial discussions. We had the time, so there’s no need to rush now.

At this point, I support testing the governance module in a live production environment, such as hyperqube\_z. It seems it will be live soon, and I can’t think of a better way to stress-test it.

On this note, I’d also like to see other developers receive compensation for their work on the Governance Module AZ—especially contributors like George, who have invested substantial time and thought and will be involved in testing the module. It would reflect well on our network if this effort is a collective achievement by a majority of our developers.

---

_[View the full topic](https://forum.hypercore.one/t/universal-governance-module-proposal/544)._