# 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:** 14
**Page:** 1
### Author:  [@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)
---
### Author:  [@georgezgeorgez](https://forum.hypercore.one/u/georgezgeorgez)
#### Post date: [November 14, 2024, 8:28am UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/2 "2024-11-14T08:28:04Z")
| Question | Answer | Notes |
| --- | --- | --- |
| Q1 | B | Yes to type1/type2 decisions |
| Q2 | A | \>2/3 should be required for sporks |
| Q3 | E | For sporks creation, I would want to give either 45 or 60 days for pillars to decide. For spork activation however, I could see the merits of shortcutting the time once a certain amount of votes are achieved. For example, if \>2/3 pillars (and likely other participants) signal they already have the new spork code running, then a speedy activation could be warranted with some possible buffer time. Getting READY signals from Sentinels is something we will have to tackle later if not now. |
| Q4 | B | \>1/2. Although I would be fine with what AZ has as well |
| Q5 | B | 30 days |
| Q6 | BCD | 1 ZNN deposit, returned after passing a vote, limited to 1 proposal per pillar a day |
| Q7 | A | Caging governance voting pillars based on momentum production. Long term it should apply to AZ and momentum election too, so I’m ok adding the others into scope if it’s easy. But it shouldn’t be something that holds us up. |
| Q8 | C | Dynamic Quorum is a potentially useful and potentially dangerous idea. It provides a disaster recovery mechanism that doesn’t require hardforks. It would be interesting to test it on hyperqube\_z but I don’t think we should let it be something that delays us. I think we can probably suffice with high level pillar caging based on momentums. I would possibly want to revisit if we ever do hard fork or two on hyperqube\_z or mainnet. |
---
### Author:  [@SultanOfStaking](https://forum.hypercore.one/u/SultanOfStaking)
#### Post date: [November 15, 2024, 2:03am UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/3 "2024-11-15T02:03:46Z")
MVP we can submit governance proposal to change later 🙂
1 B
2 A
3 B
4 BC IDK…
5 A
6 ABD
7 ABC
8 A
---
### Author:  [@nexuspillar](https://forum.hypercore.one/u/nexuspillar)
#### Post date: [November 15, 2024, 6:59am UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/4 "2024-11-15T06:59:28Z")
Q1 B
Q2 A
Q3 C
Q4 B
Q5 B
Q6 BCD
Q7 ABC
Q8 C (not at this stage)
---
### Author:  [@vilkris](https://forum.hypercore.one/u/vilkris)
#### Post date: [November 15, 2024, 3:14pm UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/5 "2024-11-15T15:14:47Z")
| Question | Answer | Notes |
| --- | --- | --- |
| Q1 | B | Yes to type1/type2 decisions |
| Q2 | A | |
| Q3 | C | |
| Q4 | C | AZ style for familiarity |
| Q5 | A | Same length as AZ for familiarity |
| Q6 | BCD | 1 ZNN deposit, returned after passing a vote, limited to 1 proposal per pillar a day |
| Q7 | A/D | I would prefer keeping the scope on the governance contract in this WP. A caging mechanism could possibly be a completely separate WP, so that no caging mechanism is included in this governance WP. |
| Q8 | C | We could explore this idea later. |
---
### Author:  [@SultanOfStaking](https://forum.hypercore.one/u/SultanOfStaking)
#### Post date: [November 16, 2024, 12:46am UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/6 "2024-11-16T00:46:01Z")
Context - Thinking burn 1 minimum then deposit ~4 you get back if you get approved
Also 30 days is more than enough IMO even for level 1. I think 15 days is a long time if you’re engaged. A lot can happen in 15 days
---
### Author:  [@SultanOfStaking](https://forum.hypercore.one/u/SultanOfStaking)
#### Post date: [November 16, 2024, 12:51am UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/7 "2024-11-16T00:51:57Z")
If I’m honest 30 days feels obscene
---
### Author:  [@sugoibtc](https://forum.hypercore.one/u/sugoibtc)
#### Post date: [November 16, 2024, 2:02am UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/8 "2024-11-16T02:02:43Z")
Q1: B
Q2: A
Q3: C
Q4: C
Q5: B
Q6: BCD
Q7: ABC - Priority to A
Q8: C - currently N/A
---
### Author:  [@coinselor](https://forum.hypercore.one/u/coinselor)
#### Post date: [November 16, 2024, 1:06pm UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/9 "2024-11-16T13:06:56Z")
| Question | Answer | Notes |
| --- | --- | --- |
| Q1 | B | |
| Q2 | A | |
| Q3 | D | I’m going with 15 days for hyperqube\_z. Probably 60 for Alphanet. |
| Q4 | B | |
| Q5 | A | |
| Q6 | BC | |
| Q7 | ABCD | Given this is a resource intensive task it probably should be researched, developed, and tested in isolation |
| Q8 | C | We could fake black swan events on hyperqube\_z and consider the implications/improvements this feature might bring |
---
### Author:  [@Stark](https://forum.hypercore.one/u/Stark)
#### Post date: [November 16, 2024, 4:31pm UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/10 "2024-11-16T16:31:47Z")
@georgezgeorgez can you clarify:
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
• 😧 Other (with explanation)
=================
…it looks like we’re supposed vote on which activities a non-momentum-producing pillar would get prohibited/caged from.
In other words, a caged pillar would not be able to:
A. Vote for Governance
B. Vote for AZ
C. **Produce Momentums?**
This looks to me like voting pillars out of the network. Is that correct? I want to make sure we are all understanding this in the same way.
---
### Author:  [@digitalSloth](https://forum.hypercore.one/u/digitalSloth)
#### Post date: [November 17, 2024, 9:08am UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/11 "2024-11-17T09:08:10Z")
| Question | Answer | Notes |
| --- | --- | --- |
| Q1 | B | |
| Q2 | A | |
| Q3 | B | Lower on HyperQube for testing |
| Q4 | C | |
| Q5 | A | |
| Q6 | BCD | 1 ZNN deposit, returned after passing a vote, limited to 1 proposal per pillar a day |
| Q7 | AD | Focus should initially be for governance but with a mind to apply it to AZ & Momentum production. How would uncaging work? There needs to be a way for a pillar to signal they want to play an active role in the network again, maybe an uncage function on the pillar contract requiring a 1 ZNN burn for example |
| Q8 | C | |
---
### Author:  [@Bzed](https://forum.hypercore.one/u/Bzed)
#### Post date: [November 17, 2024, 3:06pm UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/12 "2024-11-17T15:06:26Z")
| Question | Answer | Notes |
| --- | --- | --- |
| Q1 | B | |
| Q2 | A | |
| Q3 | D | With voting to end once super majority is met. Activation based on signaling |
| Q4 | B | |
| Q5 | B | |
| Q6 | D | Limited to 1 proposal per epoch, pillars only |
| Q7 | D | No, QSR burn equals one vote |
| Q8 | C | Might be an important idea. Needs testing |
---
### Author:  [@Stark](https://forum.hypercore.one/u/Stark)
#### Post date: [November 17, 2024, 10:20pm UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/13 "2024-11-17T22:20:08Z")
Q1: B
Q2: A
Q3: B
Q4: C
Q5: A
Q6: B, C, D
Q7: A, B, C (provided that there is a permissionless way to uncage oneself)
Q8: A
---
### Author:  [@georgezgeorgez](https://forum.hypercore.one/u/georgezgeorgez)
#### Post date: [November 18, 2024, 2:41pm UTC](https://forum.hypercore.one/t/wp1-governance-spec-feature-vote/554/14 "2024-11-18T14:41:12Z")
If we actually implement caging, we will refine the details as a community.
But the way I would spec it out would be like:
If you don’t produce any momentums for say a 3 days. Then you are caged.
You are token out of the eligible pillar set for governance, az, and pillar election for momentums.
After a period of 2 weeks, you can sign a message to uncage yourself.
The two weeks is the penalty, but a pillar can uncage itself anytime after it.
That’s how I would approach it.