# WP1 Governance Spec Feature Vote **URL:** https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554 **Category:** HyperQube **Created:** [November 14, 2024, 8:06am UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554 "2024-11-14T08:06:13Z") **Posts on this page:** 1 **Showing post:** 1
### Author: ![georgezgeorgez](https://forum.hypercore.one/letter_avatar_proxy/v4/letter/g/eada6e/32.png) [@georgezgeorgez](https://forum.hypercore.one/u/georgezgeorgez) #### Post date: [November 14, 2024, 8:06am UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/1 "2024-11-14T08:06:13Z")
Developers should serve the requirements of the community. We cannot accept contributions to the codebase just because they exist or how much effort was spent. There’s been some ongoing discussion and debate regarding Governance: > [@WP1 Governance Spec](https://forum.hypercore.one/t/wp1-governance-spec/545): > > Starting this early to respond to everyone pinging me about This is good Similar to my draft code but we can use his as the starting point for the governance embedded, and of course reward with incentivizes. Based on the work items, we can see that a spec and the implementation are only part of what’s needed for the work to be useful. A systematic way for testing, consensus, and acceptance is crucial, and that’s something missing that hopefully we can solve here. Anything touching sporks es… > [@Universal governance module proposal](https://forum.hypercore.one/t/universal-governance-module-proposal/544): > > Hello! I’m proposing a flexible governance embedded that will fulfill all of our current necessities and even beyond. The governance embedded contract will be able to: Create sporks to upgrade the network codebase Change network parameters that were previously only accessible to admins We are basically solving 2 problems at once with my proposed architecture for the embedded contract. The process goes as follows: One must spend 1 ZNN in order to make a governance proposal. This anti-spam … Technical mechanisms must be comprehensible in the language of its users. In the case of governance, the users will be Pillars. The role of a protocol designer is to take the desires of the community, analyze them for cryptoeconomic security, and translate them into implementation-neutral instructions. The role of a protocol developer will be to take a specification and implement it for a given platform. Currently we only have go-zenon, but in the future we may have rusty-zenon, so a clear spec will be required so that both implements perform the exact behavior. **The following vote will serve as a guideline for spec definition. It is non-binding. The scope will be limited to what gets deployed onto hyperqube\_z.** Factors such as deployment feasibility will impact what is actually delivered to hyperqube\_z. Future work packages will include the deployment of governance onto mainnet with any lessons learned from testing on hyperqube\_z. For multiselect questions, choose as many options, including none, as desired. In general, the options will go from more conservative to less conservative in terms of changes made. Depending on scope, we may have additional follow-up questions in the future. * * * For the governance embedded contract on the hyperqube\_z extension chain: Q1: Should different voting requirements and thresholds apply to different types of governance actions? Specifically, should we classify different actions into [Type 1 and Type 2](https://www.theuncertaintyproject.org/tools/decision-types) decisions? Options: - A: No - B: Yes - C: Other (with explanation) Q2: What should the default voting requirements be? If applicable: for Type 1 decisions, and starting requirements for dynamic quorums. Options: - A: Greater than 2/3 of all voting eligible pillars - B: Greater than 1/2 of all voting eligible pillars - C: Greater than 1/2 of votes with a 1/3 voting eligible pillar quorum (Same as AZ) - D: Other (with explanation) Q3: What should the default voting duration be? If applicable: for Type 1 decisions, and starting requirements for dynamic quorums. Options: - A: 15 Days - B: 30 Days - C: 45 Days - D: 60 Days - E: Unlimited - F: Other (with explanation) Q4: If applicable, what should the voting requirements be for Type 2 decisions? Options: - A: Greater than 2/3 of all voting eligible pillars - B: Greater than 1/2 of all voting eligible pillars - C: Greater than 1/2 of votes with a 1/3 voting eligible pillar quorum (Same as AZ) - D: Other or N/A (with explanation) Q5:If applicable, what should the voting duration be for Type 2 decisions? Options: - A: 15 Days - B: 30 Days - C: 45 Days - D: 60 Days - E: Unlimited - F: Other or N/A (with explanation) Q6: What should the requirement be for submitting governance proposal? MULTISELECT: Options: - A: ZNN Burn - B: ZNN Deposit (returned upon passing vote) - C: Must be Pillar - D: Limited to 1 proposal per Epoch - E: Other or N/A (with explanation) Q7: Should removing pillars from voting eligibility (caging) based on momentum production activity be part of scope for this work package? MULTISELECT: Options: - A: For Governance - B: For Accelerator-Z - C: For Momentum Production - D: Other (with explanation) Q8: Should we implement dynamic quorum requirements to eventually resolve votes that fail to get enough YES or NO votes? - A: No - B: Yes - C: Other (with explanation) --- _[View the full topic](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554)._