GOR Governance Module Proposal

[adr-sk]

Gnoland Governance Module Proposal

Note: This document is a work in progress. I'm in search of collaborators to help define and implement the Governance Module for Gnoland.

This document is a formal proposal following our initial ideas at Onbloc shared in the comments of the issue featuring the challenge. I converged our ideas into a single proposal for deeper discussions with the community.

Summary

The proposed module inherits the basic structures of the x/gov of the Cosmos-SDK with some notable changes:

• Adding Contributors, Delegates, and Validators for defining and managing members of the Proof of Contribution
• Removal of the delegation-based validator set inclusion
• A bicameral governance structure that consists of the Contributors’ House and the Token House
• Updates to vote tallying & supermajority votes
• Penalties for non-voters
• Adding Constitution that stores a set of texts that serve as the Constitution of Gnoland

Core Concepts

• GNOT: The non-inflationary native gas token of Gnoland. GNOT tokens are used for paying transaction fees and funding proposal deposits.
• GNOSH: The inflationary native share token of Gnoland. Owners of GNOSH tokens are considered "Contributors", and receive a portion of the chain's revenue.
• The Gnoland Congress: The governance body of Gnoland which consists of two different houses - the Contributors' House and the Token House. Each house is given distinct responsibilities.
• Core Contributors: Members of the Contributors' House. Core Contributors are the Top 334 (exact number to be defined) Contributors in terms of GNOSH holdings. The inflationary nature of GNOSH ensures that Core Contributors who make inconsistent contributions are diluted away. All of the top 334 Core Contributors have equal VotingPower on governance proposals.
• Delegates: Members of the Token House. One must receive a delegation of GNOTs to become a Delegate. The voting power of Delegates for each proposal will be calculated based on a snapshot of GNOT holdings on the block following the one on which the proposal enters VotingPeriod as a protective measure against flash loan attacks (as suggested by @giunatale). Delegates are expected to exercise voting rights responsibly on behalf of delegators.
• Delegation: The act of granting the underlying voting rights of GNOT tokens to a Delegate. As GNOT tokens are not used to secure the network, no bonding periods are involved in delegations. Self-delegation is allowed for individuals who deem themselves competent. (This delegation system is inspired by the governance structures of Uniswap and Optimism which achieve a similar objective - giving the ultimate discretion to token holders.)
• Validators: Nodes that participate in tx validation and block production to upkeep the blockchain. Validators are elected by the Contributors' House.

More to be added

The Gnoland Congress

Background

Gnoland adopts Proof-of-Contribution (PoC), a consensus mechanism akin to Proof-of-Authority (PoA), which relies on a small group of philosophically-aligned individuals, who have made significant contributions to the chain, to make core decisions and perform administrative operations. Although this novel consensus allows for a scalable and streamlined governance system, it lacks a way to be inclusive of the sentiment of the main users of the chain: GNOT holders.

As a solution, this proposal suggests the implementation of a bicameral governance system for Gnoland where its governing entity is made up of two separate houses: the Contributors' House and the Token House. The bicameral system allows a group of experts (the Contributors) to efficiently govern and run the chain while keeping them in check by giving the Token House the right to Veto their decisions.

The Contributors' House

• Given "the Power to Execute", the Contributors' House is responsible for the operations and management of the Gnoland blockchain.
• Representatives of the Contributors' House are Core Contributors.
• All Core Contributors receive a VotingPower of 1.
• A non-exhaustive list of roles assigned to the Contributors' House:
  • Voting on network-related governance proposals such as protocol updates, param changes, or emergency matters.
  • Review and select Validators.
  • Partnering with other entities or organizations for ecosystem expansion.

The Token House

• Given "the Power to Veto", the Token House is responsible for voting on proposals that reasonably require a higher degree of consensus from community members and overseeing the Contributors' House to veto proposals that could potentially harm GNOT owners.
• Representatives of the Token House are Delegates.
• Delegates receive 1 VotingPower for each GNOT delegated.
• A non-exhaustive list of roles assigned to the Token House:
  • General governance proposals with texts.
  • Make amendments to the Constitution.
  • Review and approve requests to receive funding from the Community Pool.
  • Veto proposals passed by the Contributors' House that could have a negative impact on the interests of GNOT holders.
    • Examples: Increasing the base transaction fees of the network for higher Contributor rewards, or adopting a new token other than GNOT as a fee payment method.

Proposals

Types

1. TextProposal: Proposals with no source code modifications such as opinion polls or roadmap proposals.
2. ConstitutionAmendementProposal: Proposals that make changes to the Constitution struct.
3. ParamChangeProposal: Proposals to be voted on by the Contributors' House that change parameters of the chain, excluding r/gov.
4. GovParamChangeProposal: Proposals voted on by the Token House that change parameters of the r/gov.
5. CommunityPoolSpendProposal: Proposals that request funding from the Gnoland Community Pool. Some examples of categories that are eligible to receive funding are as follows: Censorship resistant social applications, DAO tooling, developer tooling, infrastructure services, education, payment applications, financial inclusion, climate change, and academic research.
6. ValidatorUpdateProposal: Proposals that add or remove accounts from the validator set.
7. VetoProposal: Proposals that can be initiated by the Token House during the timelock to veto a proposal passed by the Contributors' House.

The type of vote to be held for a proposal is determined based on the extent of its effect on the chain and may be conducted as either a Simple Majority vote or a Super Majority vote.

• Simple Majority: Proposals that require 1/2 or more Yes votes out of total exercised votes to pass.
  • Applied Types: TestProposal, ParamChangeProposal, CommunityPoolSpendProposal
• Super Majority: Proposals that require 2/3 or more Yes votes out of total exercised votes to pass.
  • Applied Types: ConstitutionAmendementProposal, GovParamChangeProposal, ValidatorUpdateProposal, VetoProposal

Life Cycle

1. Community Discussion

• Proposals must be drafted and thoroughly discussed on community boards (r/boards, Discord, forums, etc.) for a temperature check prior to their submission.
• It is advised that the proposer only proceeds upon receiving positive sentiment from the community.

2. Submission

• Proposals can be submitted by anyone.
• Proposals are identified by IDs that increase by 1 in sequential order, with an initial ID of 0.

3. Deposit

• A proposal enters a deposit period of 43,200 blocks (≈3 days considering a block time of 6 seconds) after the transaction that contains the proposal is confirmed on the chain.
• Anyone can contribute to the deposit during the deposit period, meaning that the proposal submitter does not have to solely fund the deposit.
• Proposals that fail to reach a deposit of the value set as the MinDeposit until the deposit end time are considered expired, thus are removed from the state. This mechanism exists to prevent spam.

  NOTE: A higher MinDeposit must be set for the VetoProposal type, as it would extend the implementation of the proposal.

• At the end of a proposal, deposits are handled as the following:
  • Returned: If a proposal passes or fails after reaching the quorum, its deposits are returned to each depositor.
  • Confiscated: If a proposal expires, fails to reach the quorum, or is vetoed, it is considered as having malicious intent. Hence, the depositors are penalized by having the deposits confiscated, which are sent to the community pool to be used to fund public goods.

4. Voting & Vote Tallying

• A proposal enters a voting period of 201,600 blocks (≈14 days considering a block time of 6 seconds) starting from the block following the one in which the proposal reaches the MinDeposit.
• VotingPower Calculation:
  • The Contributors' House: Each Core Contributor is given an equal VotingPower of 1.
  • The Token House: Each Delegate is given 1 VotingPower per 1 GNOT delegated at the subsequent block of which the proposal enters the voting period.
• Quorum: For the outcome of a proposal vote to be considered valid, a threshold of executed votes must be reached. Proposals that fail to reach a quorum by the end of the voting period are considered invalid, and thus have no effect on the chain.
  • The Contributors' House: 2/3 out of total VotingPower
  • The Token House: 1/2 out of total VotingPower
• Voting options:
  1. General Proposals
     • Yes: Indicates approval of the proposal in its current form.
     • No: Indicates disapproval of the proposal in its current form.
     • NoWithVeto: Indicates stronger opposition to the proposal than simply voting No. Not available for SuperMajority-typed proposals as a simple No of 1/3 out of total votes would result in the same outcome.
     • Abstain: Indicates that the voter is impartial to the outcome of the proposal. Although Abstain votes are counted towards the quorum, they're excluded when calculating the ratio of other voting options above.
  2. Veto Proposals
     • Veto: The only voting option to be exercised by Delegates if they believe the proposal passed by the Contributors' House could have a negative impact on the ecosystem or if it does not align with their principles.
• Votes of Delegators override those of Delegates, and there are no redelegation penalties or restrictions.
• Assuming that a proposal reaches the quorum by the end of the voting period, its result is decided as the following:
  • Simple Majority Proposals
    • Passed: Yes is greater than or equal to 1/2 of effective votes (total executed votes excluding Abstain votes).
    • Rejected: Yes is less than 1/2 of effective votes.
    • Vetoed: NoWithVeto is greater than or equal to 1/3 of effective votes. This result overrides all others.
  • Super Majority Proposals
    • Passed: Yes is greater than or equal to 2/3 of effective votes.
    • Rejected: Yes is less than 2/3 of effective votes.

5. Timelock & Veto

A proposal passed by the Contributors' House is subject to a timelock of 7 days prior to its implementation. During the timelock, anyone may submit a VetoProposal to put the proposal on a Trial state, provided that the minimum deposit requirement has been met. The Trial state lasts until the conclusion of the VetoProposal.

Veto Penalties

Veto-related penalties exist to punish malicious behaviors of governance participants.

• For proposals that are vetoed by the Contributors' House:
  • This is a case where the Contributors' House has control over the "malicious" voters. Core Contributors who have voted Yes are penalized by being charged with a negative boost of x2/3 (Exact rate to be discussed) on their VotingPower. The negative boost gets lifted over a period of n (Exact rate to be discussed) weeks at a linear rate.
• For proposals that are vetoed by the Token House:
  • No penalties are applied in this case, as this should be seen as a "conflict of interest" between Contributors and Delegates.

Non-Voting Penalties

• A non-voting penalty exists for Contributors and Delegates. This method ensures that all eligible voters actively contribute to the governance of the chain while diluting the power of inactive voters.
• For each proposal that a voter un-participates in, a linearly-increasing negative boost is applied to the voter's VotingPower, which can decrease to 0, a point in which the Voter's VotingPower will have no influence on the outcome.
• The voter can regain VotingPower at a linear rate (Exact rate to be discussed) by re-participating in voting.

Formatting

TextProposal

• Components
  1. Title: The distinguishing name of the proposal.
  2. Description: The body of the proposal that further describes what is being proposed and details surrounding the proposal.
  3. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

ConstitutionAmendmentProposal

• Components
  1. Title: The distinguishing name of the proposal.
  2. Description: The body of the proposal that includes the reasoning behind the Constitution Amendment.
  3. UpdatedConstitution: The updated Constitution in the correct format.
  4. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

ParamChangeProposal

• Components
  1. Title: The distinguishing name of the proposal.
  2. Description: The body of the proposal that describes the reasoning behind the Parameter Change.
  3. Subspace: The realm with the parameter that is being changed. (cannot be set as r/gov)
  4. Key: The parameter that will be changed.
  5. Value: The value of the parameter that will be changed.
  6. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

GovParamChange

• Components

  1. Title: The distinguishing name of the proposal.
  2. Description: The body of the proposal that describes the reasoning behind the Parameter Change.
  3. Subspace: The realm with the parameter that is being changed. (fixed as r/gov)
  4. Key: The parameter that will be changed.
  5. Value: The value of the parameter that will be changed.
  6. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

CommunityPoolSpendProposal

• 2 types of community pool spending proposals exist.
  1. Regular Funding: A regular funding type to be used for short-term offline projects that require upfront capital. The funding is provided as soon as the proposal passes the governance vote.
  2. Milestone Funding: A funding mechanism that allows for the division of grant distributions. GNOT grants are divided into multiple tranches with each to be released after a milestone is reached. This provides "salary-like" funding for developers to keep them incentivized to complete the project.
• Components
  1. Title: The distinguishing name of the proposal.
  2. Description: The body of the proposal that describes the project and its team members that are requesting the funds.
  3. Type: The indication of whether the proposal is a regular funding request or a Milestone Funding request.
  4. Recipient: The account address that will receive funding from the Community Pool.
  5. Amount: The amount of funding that the recipient will receive in GNOTs.
  6. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

ValidatorUpdateProposal

• Components
  1. Title: The distinguishing name of the proposal.
  2. Description: The body of the proposal that includes the reasoning behind the validator update.
  3. Address: The account that will be affected by the proposal.
  4. State: Indicates if the target address will be added or removed from the Validators struct.
  5. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

VetoProposal

• Components
  1. Title: The distinguishing name of the proposal.
  2. Description: The body of the proposal that describes the reasoning behind the initiative to veto the passed proposal.
  3. ProposalID: The ID of the proposal that the proposer is suggesting to veto. This value must match the ID of proposals in the Timelock queue.
  4. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

Remarks

Below are ideas that need to be further explored (and hopefully implemented).

• Incentives for the Token House: While we can anticipate a high level of participation from the Contributors' House, the only form of incentives of the Token House is the ability to govern the Community Pool and guard against proposals that may conflict with their interests. As GNOT is a non-inflationary token, it is likely that a significant portion of the supply will be utilized in DeFi for increased capital efficiency. Ensuring high engagement from the Token House is crucial for the efficacy of the bicameral system. I am seeking ways to economically incentivize individuals to delegate their tokens and become more involved in the governance system. The concept of community Delegates (as suggested by @giunatale) serves as a means to stimulate greater voting rates and participation.

• Chain Halt: Reflecting from the collapse of LUNA/UST, it is worth exploring around the idea of having a mechanism that can temporarily halt the blockchain in emergency situations. New technologies are prone to critical problems and the irreversible nature of blockchain makes it difficult to recover from catastrophic events. Implementing such a feature could grant the community a period of respite, thereby enabling them to take measures that would mitigate further harm.

As mentioned in the beginning, I am seeking participation of individuals who can contribute to the completion and implementation of this proposal with their valuable insights. If you have any suggestions or ideas, please share them in the comments section and I will promptly follow up.

Contributors & Notable Contributions

*In alphabetical order of Github handles

• @adr-sk: Main author
• @dongwon8247: Review and feedback
• @giunatale: Ideas on supermajority votes, Token House Delegates, improvement suggestions

[giunatale]

Hey @adr-sk, I like this proposal in general, seems well thought out. I have a few more specific observations I wanted to share.

Core Contributors: Members of the Contributors' House. Core Contributors are the Top 334 (exact number to be defined) Contributors in terms of GNOSH holdings. The inflationary nature of GNOSH ensures that Core Contributors who make inconsistent contributions are diluted away. All of the top 334 Core Contributors have equal VotingPower on governance proposals.

I like this idea. So participation is kind of tier-based, but still inclusive. I am of course assuming that the number of slots will be a parameter changeable through governance, and initially set to 334. Implementation-wise, a lot of the logic for determining active validators in the valset of a classical dPoS cosmos-sdk chain can be reused here, as the mechanics is not that different.

Delegation: The act of granting the underlying voting rights of GNOT tokens to a Delegate. As GNOT tokens are not used to secure the network, no bonding periods are involved in delegations. Self-delegation is allowed for individuals who deem themselves competent. (This delegation system is inspired by the governance structures of Uniswap and Optimism which achieve a similar objective - giving the ultimate discretion to token holders.)

I am curious to understand here how do we plan on dealing with delegations when GNOT are transfered away. Are underlying delegations voided? transfered? I would probably go about voiding them. So that delegations are tied to an account and not the actual tokens. To allow multiple delegations for a single account and deal with the GNOT fungibility, we remove GNOTs from each existing delegation proportionally when GNOTs are transfered away without resizing the delegations first.

The existence of self-delegations as you envisioned seem to imply to me that delegations are giving away the voting rights entirely, meaning that once I delegated voting power with my GNOT I cannot override my delegates vote if I want. Not sure this is right. As we are snapshotting voting power (rightfully so) as the proposal enters voting, we need to allow single holders to react to abuse attempts by delegates. The ability of holders to ultimately vote themselves if they feel the need is the ultimate defense mechanism, we need to be careful with removing it IMHO. Can you clarify this point?

Confiscated: If a proposal expires, fails to reach the quorum, or is vetoed, it is considered as having malicious intent. Hence, the depositors are penalized by having the deposits confiscated, which are sent to the community pool to be used to fund public goods.

I disagree with this. It can be a source of controversy (and it has been). I don't think that deposits for proposals that do not reach quorum should be confiscated. The proposal simply do not enter voting (and is deleted so it does not occupy permanent blolckchain space) so it cannot create harm. The deposit threshold worked as intended. A proposal might not reach threshold but because it's not well structured or there was a mistake, not just cause it's spam. Funds should not be confiscated imho, but simply returned (similar to the Cosmos Hub), and data about the proposal pruned from the blockchain. Seemingly, a proposal if vetoed is not automatically spam (e.g. prop 69, prop 82 on the Cosmos Hub). In my opinion, No and NoWithVeto voters should also be asked to additionally indicate whether they think the deposit should be confiscated, and only if a strict majority agrees the proposal is punished by confiscating the deposit. This is also in line with what is discussed in the original Cosmos Whitepaper (where the burn of the deposit is a considered a separate choice).

VetoProposal: Proposals that can be initiated by the Token House during the timelock to veto a proposal passed by the Contributors' House.

I would propose a change in the way this is handled. Instead of adding an additional timelock after a proposal is passed, so it can be vetoed by the Token House, the option to veto a proposal from the Token House could be open as soon as the proposal enters the voting period. Token House members would only be able to cast a Veto vote.

This is a case where the Contributors' House has control over the "malicious" voters. Core Contributors who have voted Yes are penalized by being charged with a negative boost of x2/3 (Exact rate to be discussed) on their VotingPower. The negative boost gets lifted over a period of n (Exact rate to be discussed) weeks at a linear rate.

I think this is done in the "opposite" way of wat I was thinking. The penalization should be done to veto voters, so they use the veto vote only when truly necessary. Giving no weight to the veto option for veto voters makes it no different than No (but with more power) and this is not correct. Let's never forget that whomever vetos a proposal is not necessarily on the right side, there should be checks and balances on both ends (the veto effort could be the malicious act). Exclusively punishing Yes voters is also in my opinion not fair. In the Cosmos whitepaper, veto voters ("with force") are punished so the choice has some weight wrt to a simple No, and in addition to that everyone is punished to reflect the fact that an onchain proposal was vetoed. There is no further exclusive punishment for Yes voters, and there shouldn't be.

Again, we can't be sure that the veto effort is right and the yes voters are malicious, I see it as kind of survivor bias. We have to assume anyone from any side could be malicious, and avoid creating systems that polarize. We should focus on creating systems that are simply game-theoretically sound and incentivize honest behavior.

A non-voting penalty exists for Contributors and Delegates. This method ensures that all eligible voters actively contribute to the governance of the chain while diluting the power of inactive voters.

I would refrain from penalizing delegates (and in general the Token House). It's not only complicated from an implementation point of view (keeping consistency between token holders, delegations and corresponding voting powers would be non trivial if VP slashing is added) but it's also conceptually not necessary given the responsibilities of the Token House. Delegates should exist only to facilitate participation from the Token House, but remember that the Token House should focus on the "power to veto". Penalties should only exist for Contributors' House members, where active participation is more of a requirement.

NoWithVeto: Indicates stronger opposition to the proposal than simply voting No. Not available for SuperMajority-typed proposals as a simple No of 1/3 out of total votes would result in the same outcome.

As I mentioned, I would provide a VP slashing (a extension of the penalty system you suggest, but applied here) for veto users, so there is an actual weight on the veto, and is not used lightly. But this is only for this vote option on simple majority proposals, and only for members of the Contributors' House (in my opinion there shouldn't be any simple majority proposal types for the token house, so they never have to decide between a No and a NoWithVeto)

Abstain: Indicates that the voter is impartial to the outcome of the proposal. Although Abstain votes are counted towards the quorum, they're excluded when calculating the ratio of other voting options above.

The way prop 95 was made to pass was by achieving quorum through Abstain votes by involved validators, which have large voting power on the Hub. I think this shows the presence of the Abstain option should actually be removed. We don't want - in reality - entities to force an outcome where they have a conflict of interest by abstaining due to their high voting power. I am wary about Abstain, it seems a good idea in principle, but it shows more and more that opens up more issues than opportunities.

Finally, Community Pool spending could be incorporated into the duties of the Contributor's House, as remember the Token House can always veto. This also avoids the need for having proposals with simple majority at all for the Token House. To this end, I would also add that we should strive for not having simple majority proposal at all for the Token House. Any proposal that goes on the Token House should be a supermajority vote. This in my opinion mititagates a lot of potential issues.

[adr-sk]

Hey @giunatale, thank you for your insightful feedback!

I am of course assuming that the number of slots will be a parameter changeable through governance, and initially set to 334.

Yes, that’s the idea! The number 334 was taken from one of Jae’s interviews from last year. From my understanding, it’s supposed to cap at 334, so the initial number would actually be smaller and gradually increase as we onboard more Contributors.

I am curious to understand here how do we plan on dealing with delegations when GNOT are transferred away. Are underlying delegations voided? transferred? I would probably go about voiding them. So that delegations are tied to an account and not the actual tokens.

I agree that it would make more sense to void them. Otherwise, recipients of GNOTs would have to verify manually whether their newly received tokens are delegated to someone. In some cases, GNOTs held in cold wallets of exchanges could sit there in delegated status, which wouldn’t make sense.

The existence of self-delegations as you envisioned seem to imply to me that delegations are giving away the voting rights entirely, meaning that once I delegated voting power with my GNOT I cannot override my delegates vote if I want. Not sure this is right. As we are snapshotting voting power (rightfully so) as the proposal enters voting, we need to allow single holders to react to abuse attempts by delegates. The ability of holders to ultimately vote themselves if they feel the need is the ultimate defense mechanism, we need to be careful with removing it IMHO. Can you clarify this point?

Self-delegation exists, as Delegates would have no choice but to delegate their own GNOT holdings to other Delegates otherwise.

I don't think that deposits for proposals that do not reach quorum should be confiscated. The proposal simply do not enter voting (and is deleted so it does not occupy permanent blolckchain space) so it cannot create harm. The deposit threshold worked as intended. A proposal might not reach threshold but because it's not well structured or there was a mistake, not just cause it's spam. Funds should not be confiscated imho, but simply returned (similar to the Cosmos Hub), and data about the proposal pruned from the blockchain.

I don't believe this would be a major problem, as the Contributors' House is likely to have a high voting participation rate anyway, given the non-voting penalties. I suggest revisiting this matter later, once we have decided whether to retain the Abstain option or eliminate it, as you suggested (more on this below).

Seemingly, a proposal if vetoed is not automatically spam (e.g. prop 69, prop 82 on the Cosmos Hub). In my opinion, No and NoWithVeto voters should also be asked to additionally indicate whether they think the deposit should be confiscated, and only if a strict majority agrees the proposal is punished by confiscating the deposit.

From my perspective, a NoWithVeto vote implies that the voter perceives the proposal as harmful to the chain, and has been proposed with harmful intentions. Given this, it's difficult for me to imagine a case where the Voters would NOT want to confiscate the deposit.

I would propose a change in the way this is handled. Instead of adding an additional timelock after a proposal is passed, so it can be vetoed by the Token House, the option to veto a proposal from the Token House could be open as soon as the proposal enters the voting period. Token House members would only be able to cast a Veto vote.

The purpose of the Timelock was to provide the Token House with adequate time to consider both sides of the proposal after the completion of the Contributors' House voting round. In addition, it would decrease the number of proposals that the Token House would actually vote on, since they would not have to consider those that were rejected or vetoed by the Contributors' House.

However, if we can find a way to achieve a high participation rate from the Token House, your proposed approach would likely be more efficient, as proposals would not have to wait for the full 7 days before implementation. Let's discuss this further once we have agreed on the roles and powers of both houses.

I think this is done in the "opposite" way of wat I was thinking. The penalization should be done to veto voters, so they use the veto vote only when truly necessary. Giving no weight to the veto option for veto voters makes it no different than No (but with more power) and this is not correct. Let's never forget that whomever vetos a proposal is not necessarily on the right side, there should be checks and balances on both ends (the veto effort could be the malicious act). Exclusively punishing Yes voters is also in my opinion not fair. In the Cosmos whitepaper, veto voters ("with force") are punished so the choice has some weight wrt to a simple No, and in addition to that everyone is punished to reflect the fact that an onchain proposal was vetoed. There is no further exclusive punishment for Yes voters, and there shouldn't be.

I think penalties should be applied to both Yes voters of a vetoed proposal and NoWithVeto voters of a passed proposal. The latter for the reason you’ve provided, and the former for the reason being that they should be considered as those who tried to pass a harmful proposal, which should be a reasonable case to penalize.

The way prop 95 was made to pass was by achieving quorum through Abstain votes by involved validators, which have large voting power on the Hub. I think this shows the presence of the Abstain option should actually be removed. We don't want - in reality - entities to force an outcome where they have a conflict of interest by abstaining due to their high voting power. I am wary about Abstain, it seems a good idea in principle, but it shows more and more that opens up more issues than opportunities.

As we are planning to impose a non-voting penalty on Contributors, I believe the Abstain option should be retained. Forcing all Contributors to vote either Yes or No could create a predicament for those with a conflict of interest.

Finally, Community Pool spending could be incorporated into the duties of the Contributor's House, as remember the Token House can always veto. This also avoids the need for having proposals with simple majority at all for the Token House.

IMO, the primary challenge we face with the Token House currently is the absence of direct incentives for laypeople to delegate GNOTs, whereas Contributors have all the reasons to do so.

If we are unable to motivate the laypeople to actively delegate GNOTs, I am unsure if the concept of "Power to Veto" will function as we intend it to. To address this issue, we could consider offering rewards to delegators, or providing additional reasons to delegate, such as the ability to vote on community pool spending proposals, which may be of interest to many token holders.

I think our next task should be to clarify the definition of each voting option so that we have a shared understanding, and to develop strategies that would motivate participation from Token House even in the absence of direct incentives.

[giunatale]

Yes, that’s the idea! The number 334 was taken from one of Jae’s interviews from last year. From my understanding, it’s supposed to cap at 334, so the initial number would actually be smaller and gradually increase as we onboard more Contributors.

I remember him mentioning that. Again I like this approach. Basically you don't have to be admitted to the Contributors' House. If you contribute enough to attain the threshold GNOSH, you are granted a seat. I think dis is da wey.

In some cases, GNOTs held in cold wallets of exchanges could sit there in delegated status, which wouldn’t make sense.

Indeed. And exchanges would never delegate themselves as they can't act on behalf of users without their consent (this is also why they do not vote on governance). Making them inherit delegations from received GNOTs poses issues. And in any case, going this route also immensely simplifies the code IMHO.

Self-delegation exists, as Delegates would have no choice but to delegate their own GNOT holdings to other Delegates otherwise.

The way I see it, since the design is slightly different than Optimism for example (as delegators can always override their vote), having no delegations for an account is ok. They have chosen to retain the voting power and not let someone else use it on their behalf. They would only be able to vote themselves. But if they delegate, they can always override the vote. In this sense, while self-delegation can make sense in this system, I kind of see it as redundant. But perhaps I have in mind a different system than what you have yourself.

I don't believe this would be a major problem, as the Contributors' House is likely to have a high voting participation rate anyway, given the non-voting penalties. I suggest revisiting this matter later, once we have decided whether to retain the Abstain option or eliminate it, as you suggested (more on this below).

I think I agree with you. We can review this later.

From my perspective, a NoWithVeto vote implies that the voter perceives the proposal as harmful to the chain, and has been proposed with harmful intentions.

I happen to disagree. Prop 69 and 82 on the Hub are clear examples of proposals that could be seen as harmful but did not deserve the deposit burn IMHO. In my first reply in #409, I talk extensively about why mixing spam prevention (the only true purpose of the deposit and the burn) and punishing "politically" harmful proposals is a form of polarization. If a proposal is politically contentious it does not automatically make it worth of punishing.

Given this, it's difficult for me to imagine a case where the Voters would NOT want to confiscate the deposit.

I - and many others - would have felt much better voting NWV on 69 and 82 on the Hub without punishing the proposers with a burn of their deposit. I recall explicitly depositors of prop 82 complaining that the NWV vote was a "f you" because they were also burning ATOMs of a non-spam proposal, confiscating funds illegitimately.

I would like to see these sources of controversy removed in our system. Ultimately, governance is made by people. These people will be there even after proposals end their voting period. If we have systems that polarize we open up to the same issues as we see happening on the Hub.

The purpose of the Timelock was to provide the Token House with adequate time to consider both sides of the proposal after the completion of the Contributors' House voting round. In addition, it would decrease the number of proposals that the Token House would actually vote on, since they would not have to consider those that were rejected or vetoed by the Contributors' House. However, if we can find a way to achieve a high participation rate from the Token House, your proposed approach would likely be more efficient, as proposals would not have to wait for the full 7 days before implementation. Let's discuss this further once we have agreed on the roles and powers of both houses.

The existence of Delegations is precisely to enable achieving high participation rate. This is why they exist on Optimism for example, and this is also discussed by Vitalik in his article I linked in our discussion in #409. We can't expect laypeople to participate actively (except in special circumstances, and in that case they would override their delegates and vote themselves), but we can expect them to find more influential entities they are politically aligned with to delegate to. The existence of delegations is exaclty how we achieve high participation.

However I still see your point. Perhaps voting period for the TH should be always a little bigger than the CH, so voting proposals should still have a tail period (i.e. a timelock) during which TH members can still cast their Veto. But IMHO they should be able to do it already when the proposal is up. I.e. voting period for both houses starts at the same time but ends later for TH.

I think penalties should be applied to both Yes voters of a vetoed proposal and NoWithVeto voters of a passed proposal. The latter for the reason you’ve provided, and the former for the reason being that they should be considered as those who tried to pass a harmful proposal, which should be a reasonable case to penalize.

Again, this is basically doubling down on the governance outcome which results in polarization, it does not really represent an incentivization/disentivization mechanism, but simply a political decision. The reason why I disagree with you is because I instead approach it from the perspective of game theory. I am thinking this: "I want to achieve a non-biased system, that does not make assumptions on which part is right. The NWV vote as it is today does not hold any weight. I can always vote NWV instead of NO with no repercussions. This can (and will) be abused from malicious actors as there is no penalty for not dong so. I need to provide a weight to NWV votes so that voters do not abuse its usage, and at the same time make it impossible for yes voters to criticize nwv voters as they are paying the price for their choice" Your penalizations (for yes voters on vetoed and nwv voters on passed proposals) seem to me to have the effect of trying to incentivize losing sides to switch so they are not penalized. I am not sure this is what we want. I just see instead penalization for NWV voters for vetoed proposals: they used NWV to stop a proposal knowing they would be penalized. They made a choice with weight, and they are willing to pay the price, but their vote counts more than a simple NO. This - to me - disincentivize use of NWV that is not truly motivated, and this is desireable behavior.

As we are planning to impose a non-voting penalty on Contributors, I believe the Abstain option should be retained. Forcing all Contributors to vote either Yes or No could create a predicament for those with a conflict of interest.

I get your point. As non voting in our system for CH is penalized as absenteism, we can't rely on it as a form of abstain. But perhaps I got ahead of myself here. I actually see the "abstain issue" as a bigger problem for the Hub, where the governance voting power is a function of staking. Probably situations like prop 95 will be less of a problem on Gnoland and this bicameral design.

IMO, the primary challenge we face with the Token House currently is the absence of direct incentives for laypeople to delegate GNOTs, whereas Contributors have all the reasons to do so. If we are unable to motivate the laypeople to actively delegate GNOTs, I am unsure if the concept of "Power to Veto" will function as we intend it to. To address this issue, we could consider offering rewards to delegators, or providing additional reasons to delegate, such as the ability to vote on community pool spending proposals, which may be of interest to many token holders. I think our next task should be to clarify the definition of each voting option so that we have a shared understanding, and to develop strategies that would motivate participation from Token House even in the absence of direct incentives.

We can't expect the laypeople to be active. We can expect them to be selfishly motivated and wanting the best for themselves, which will mean most of them will actually delegate though. This is I think also the assumption made for other delegation-based systems (not on Cosmos I mean).

But I see your point here too. Perhaps we should think of some form of incentive for holders to delegate. I would not provide rewards, but we should perhaps think of something.

[Morpheus-AI]

Hello digging into the project and have some questions, who is measuring contributions to the project and who decides as to who qualifies for the 334 places? How about contributors that are non technical and people who may write articles, engage in social media, forums, groups and spread the idea or contribute in ways other than Github or development? How are these people's contributions measured?

[ltzmaxwell]

Hi, I'm very interested in bicameral house designs, but I still have some doubts. Below are some excerpts and references from the "Working Constitution of the Optimism" that caught my attention:

"The Collective must balance short-term incentives with its long-term vision."

"Influence in governance must extend beyond financial stake to value humanhood and intelligent life."

"OP Holders have the right to remove a director of the Optimism Foundation and veto changes to the founding documents that would materially reduce their rights."

However, one question remains: how can the Contribute House balance Token House's veto power? can Contribute House also veto Token House? If not, will this lead the community(potentially) to focus solely on financial interests, which would be inconsistent with the initial ideas of community contributors - a group of people with similar philosophical views - to value humanhood and intelligent life?

[ltzmaxwell]

I have some initial ideas for the design of the Gor module，which can be divided into several parts: Distribution, Stake, Governance, Slash, etc. However, there are several mechanisms to be considered:

Voting Power

Governace Token

I propose creating a GovToken interface that any token implementing it can use as a GovToken, whether it is a Native Coin, Grc20, or Grc721.

Calculation of Voting Power

However, in our design, the calculation of voting power needs to be considered separately to accommodate the differences between the Token House and Contribute House implementations.

In Token House, GovToken can be delegated (to self or others) to correspond with voting power and staking rewards, which is a common feature in many systems like cosmos-sdk.

In the Contribute House, if voting power is equal for everyone(say 1), their voting power will be represented by badges of different levels.

Incentive

I remember in Jae's presentation, he mentioned "remove financial incentives", but I'm not sure about the exact design.

So if the usual reward mechanism is still retained, should we support a duration-based stake mechanism where the delegator's reward is calculated based on both the amount and duration of their stake? this is some ideas borrowed from Origin Dollor.

Vote & Tally

Similarly, we can define an interface, say VoteCounter, to support different voting and tallying strategies to meet different governance requirements, like different voting types, supermajority votes, deposit refund, and penalties for non-voters.

[adr-sk]

Gnoland Governance Module Proposal

Note: This document is a work in progress. I'm in search of collaborators to help define and implement the Governance Module for Gnoland.

This is the latest version of the issue updated on March 10th following the discussions from the Office Hour Call.

This document is a formal proposal following our initial ideas at Onbloc shared in the comments of the issue featuring the challenge, and discussions from the Game of Realms Office Hours. I converged the proposed ideas in a single issue for more extensive discussions.

Summary

The proposed module inherits the basic structures of the x/gov of the Cosmos-SDK with some notable changes:

• Added Contributors and Contributor Tiers for defining and managing tiered members of the Contributors DAO

• Added penalties for non-voters

• Added Constitution which stores a set of texts that serve as the Constitution of Gnoland

• Removed delegation-based validator set inclusion

• Updated vote tallying & supermajority votes

Core Concepts

• GNOT: The non-inflationary native gas token of Gnoland. GNOT tokens are used for paying transaction fees and funding proposal deposits.

• GNOSH: The inflationary native share token of Gnoland. Owners of GNOSH tokens receive a portion of the chain's revenue, and each earns a spot in the Contributors DAO.

• Contributors DAO: As the Governance body of Gnoland, the Contributors DAO is responsible for voting on proposals put forth by Gnomes. Members of the DAO are Contributors, individuals have been transparently acknowledged, reviewed, and rewarded for providing meaning work to the network.

• Tiers: The hierarchical structure of the Contributors DAO consists of 5 levels (or 7). Contributors are placed in different tiers based on the relative GNOSH holdings.

NOTE: Making each tier criteria relative to individuals' GNOSH holdings is more reasonable compared to having an absolute-number criteria, as it would always ensure that none of the tiers remain vacant while preventing a situation where voting power of a member of a lower tier surpasses that of a member of a higher tier due to having less members.

The Contributors DAO

Background

Staking token-based governance systems often gurantee strong decentralization and an additional layer of utility to native tokens. However, they're faced with drawbacks such as inefficiency from excruciatingly slow decision-making processes and the "low cost of attack" vulnerability during a price crash of the underlying asset (an example of this during Terra's collapse). With the launch of Interchain Security (ICS) on the Cosmos Hub, consumer chains are now given an option to delegate validation to the Hub, which opens up opportunities to include a wider range of contributors to the governance system.

Gnoland's novel approach to governance move beyond granting voting powers to the staking of native tokens. Instead, members of a permissionless, contribution-gated DAO are entrusted with the reponsibility to participate in the governance based on their expertise and comprehension of initiatives and objectives of Gnoland. This allows for a scalable governance system driven by a professional, agile working group of individuals with various skill sets.

To become a member of the Contributors DAO, one must earn GNOSH by submitting a transparent, meaningful contribution to Gnoland which is reviewed by the Evaluation DAO, a group accountable for the work of evaluating and rewarding Contributors.

Akin to the x/gov being widely adopted as the de-facto governance framework for chains across the Cosmos Ecosystem, our objective is to design a customizable, modular stack implementable by any GnoVM chain with minimal changes, with the only restriction being detaching governance powers from tokens fueling the chain.

Voting Power

To achieve decentralization while preserving security, the Contributors DAO is structured into several tiers, with all members in the same tier possessing equal voting power. The system naturally places those with a proven track record of contributions with more skin-in-the-game in a higher tier, while ensuring inclusivity of newly joined members while limiting their influence.

The allocation of voting power in each tier decreases by 2/3 (inheritance from Tendermint) in a recursive manner, with the topmost tier holding ≈38.39% of the total voting power.

NOTE: Voting Power of Tier 1 = N → N+N(2/3)+N(2/3)^2+N(2/3)^3+N(2/3)^4=100 N ≈ 38.39

• Tier 1: Top 0~5% in GNOSH holdings (≈38.39% total voting power)
• Tier 2: Top 5~15% in GNOSH holdings (≈25.59% total voting power)
• Tier 3: Top 15~35% in GNOSH holdings (≈17.06% total voting power)
• Tier 4: Top 35~60% in GNOSH holdings (≈11.37% total voting power)
• Tier 5: Top 60~100% in GNOSH holdings (≈7.58% total voting power)

NOTE: What was proposed in the Office Hour Discussion was to have topmost tier hold 50% of total voting power and decrease it by 1/2 recursively. However, that would result in the highest tier having the power to pass/fail any simple majority proposal. Having it decrease by 2/3 would allow for inclusivity of lower tiers in all cases.

Pct. criterias for tiers are set as arbitrary values as of now. More discussions should be made to find reasonable numbers. Would also love to hear @giunatale 's take on this for a suggestion of maybe a simpler or a more efficient way to implement this!

Proposals

Types

1. TextProposal: Proposals with no source code modifications such as opinion polls or roadmap proposals.

2. ConstitutionAmendementProposal: Proposals that make changes to the Constitution.

3. ParamChangeProposal: Proposals that change one or more parameters of the chain, excluding r/gov.

4. GovParamChangeProposal: Proposals that change parameters of the r/gov.

5. CommunityPoolSpendProposal: Proposals that request funding from the Gnoland Community Pool. Some examples of categories that are eligible to receive funding are as follows: Censorship resistant social applications, DAO tooling, developer tooling, infrastructure services, education, payment applications, financial inclusion, climate change, and academic research.

6. ValidatorUpdateProposal: Proposals that add or remove accounts from the validator set. (subject to removal upon ICS implementation)

The type of vote to be held for a proposal is determined based on the extent of its effect on the chain and may be conducted as either a Simple Majority vote or a Super Majority vote.

• Simple Majority: Proposals that require 1/2 or more Yes votes out of total exercised votes to pass.

  • Applied Types: TestProposal, ParamChangeProposal, CommunityPoolSpendProposal

• Super Majority: Proposals that require 2/3 or more Yes votes out of total exercised votes to pass.

  • Applied Types: ConstitutionAmendementProposal, GovParamChangeProposal, ValidatorUpdateProposal

Life Cycle

1. Community Discussion

• Proposals must be drafted and thoroughly discussed on community boards (r/boards, Discord, forums, etc.) for a temperature check prior to their submission.

• It is advised that the proposer only proceeds upon receiving positive sentiment from the community.

2. Submission

• Proposals can be submitted by anyone.

• Proposals are identified by IDs that increase by 1 in sequential order, with an initial ID of 0.

3. Deposit

• A proposal enters a deposit period of 43,200 blocks (≈3 days considering a block time of 6 seconds) after the transaction that contains the proposal is confirmed on the chain.

• Anyone can contribute to the deposit during the deposit period, meaning that the proposal submitter does not have to solely fund the deposit. However, a minimum initial deposit exists to prevent spam proposals from flooding the proposal queue.

• Proposals that fail to reach a deposit of the value set as the MinDeposit until the deposit end time are considered expired, thus are removed from the state. This mechanism also exists to prevent spam.

• At the end of a proposal, deposits are handled as the following:

  • Returned: If a proposal passes or fails after reaching the quorum, its deposits are returned to each depositor.

  • Confiscated: If a proposal expires, fails to reach the quorum, or is vetoed, it is considered as having malicious intent. Hence, the depositors are penalized by having the deposits confiscated, which are sent to the community pool to be used to fund public goods.

4. Voting & Vote Tallying

• A proposal enters a voting period of 201,600 blocks (≈14 days considering a block time of 6 seconds) starting from the block following the one in which the proposal reaches the MinDeposit.

NOTE: It seems reasonable to reduce the voting period (maybe somewhere around 7 days) to promote an agile governance environment, given that our system now has a seemingly less number of total voters, all of whom are expected to stay actively engaged.

• VotingPower of an individual = [Total Voting Power of the Tier]/[Total Members in a Tier]

  • Example
    • Let's assume that there are 500 Contributors in total. Alice is ranked 10th in GNOSH holdings, placed in Tier 1, while Bob is ranked 250th, placed in Tier 4.
    • Total Members in Tier 1 = 5% of 500 = 25 Members
    • Total Members in Tier 4 = 25% of 500 = 125 Members
    • Alice's VotingPower = 38.39%/25 = 1.5356%
    • Bob's VotingPower = 11.37%/125 = 0.09096%

• Quorum: For the outcome of a proposal vote to be considered valid, a threshold of two-thirds in executed votes out of total voting power must be reached. Proposals that fail to reach a quorum by the end of the voting period are considered invalid, and thus have no effect on the chain.

• Voting options:

  • Yes: Indicates approval of the proposal in its current form.

  • No: Indicates disapproval of the proposal in its current form.

  • NoWithVeto: Indicates stronger opposition to the proposal than simply voting No. Not available for SuperMajority-typed proposals as a simple No of 1/3 out of total votes would result in the same outcome.

  • Abstain: Indicates that the voter is impartial to the outcome of the proposal. Although Abstain votes are counted towards the quorum, they're excluded when calculating the ratio of other voting options above.

• Assuming that a proposal reaches the quorum by the end of the voting period, its result is decided as the following:

  • Simple Majority Proposals

    • Passed: Yes is greater than or equal to 1/2 of effective votes (total executed votes excluding Abstain votes).

    • Rejected: Yes is less than 1/2 of effective votes.

    • Vetoed: NoWithVeto is greater than or equal to 1/3 of effective votes. This result overrides all others.

  • Super Majority Proposals

    • Passed: Yes is greater than or equal to 2/3 of effective votes.

    • Rejected: Yes is less than 2/3 of effective votes.

Veto Penalties

Penalties related to veto exist to discourage malicious behaviors of rogue Contributors. Individuals who meet the following two conditions are subject to a penalty of -50% (subject to change) to their current voting power, which recovers at a linear rate over a quarter (subject to change).

1. A member has voted NoWithVeto on a passed proposal: A NoWithVeto vote indicates that the voter views the proposal as plainly harmful and malicious and is making a public gesture to shut it down. Because this option carries such strong underlying sentiment, it should not be abused by voters who simply disagree with a proposal or who find it conflicting with their interests.

2. A member has voted Yes on a vetoed proposal: Here, we imply that the voter has tried to pass a malicious proposal, which is a reasonable case for punishment.

Non-Voting Penalties

• A non-voting penalty exists for Contributors. This method ensures that all eligible Contributors actively contribute to the governance of the chain while diluting the power of inactive ones.

• For each proposal that a voter fails to participate, a linearly-increasing negative boost is applied to the voter's VotingPower, which can decrease to 0, a point in which the Voter's VotingPower will have no influence on the outcome.

• The voter regains VotingPower at a linear rate (subject to change) by re-engaging in voting.

Formatting

TextProposal

• Components

1. Title: The distinguishing name of the proposal.

2. Description: The body of the proposal that further describes what is being proposed and details surrounding the proposal.

3. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

ConstitutionAmendmentProposal

• Components

1. Title: The distinguishing name of the proposal.

2. Description: The body of the proposal that includes the reasoning behind the Constitution Amendment.

3. UpdatedConstitution: The updated Constitution in the correct format.

4. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

ParamChangeProposal

• Components

1. Title: The distinguishing name of the proposal.

2. Description: The body of the proposal that describes the reasoning behind the Parameter Change.

3. Subspace: The realm with the parameter that is being changed. (cannot be set as r/gov)

4. Key: The parameter that will be changed.

5. Value: The value of the parameter that will be changed.

6. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

GovParamChange

• Components

1. Title: The distinguishing name of the proposal.

2. Description: The body of the proposal that describes the reasoning behind the Parameter Change.

3. Subspace: The realm with the parameter that is being changed. (fixed as r/gov)

4. Key: The parameter that will be changed.

5. Value: The value of the parameter that will be changed.

6. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

CommunityPoolSpendProposal

• 2 types of community pool spending proposals exist.

1. Regular Funding: A regular funding type to be used for short-term offline projects that require upfront capital. The funding is provided as soon as the proposal passes the governance vote.

2. Milestone Funding: A funding mechanism that allows for the division of grant distributions. GNOT grants are divided into multiple tranches with each to be released after a milestone is reached. This provides "salary-like" funding for developers to keep them incentivized to complete the project.

• Components

1. Title: The distinguishing name of the proposal.

2. Description: The body of the proposal that describes the project and its team members that are requesting the funds.

3. Type: The indication of whether the proposal is a regular funding request or a Milestone Funding request.

4. Recipient: The account address that will receive funding from the Community Pool.

5. Amount: The amount of funding that the recipient will receive in GNOTs.

6. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

ValidatorUpdateProposal

• Components

1. Title: The distinguishing name of the proposal.

2. Description: The body of the proposal that includes the reasoning behind the validator update.

3. Address: The account that will be affected by the proposal.

4. State: Indicates if the target address will be added or removed from the Validators struct.

5. Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

Remarks

Below are ideas that need to be noted or further explored.

• Bicameral Governance System: This proposal originally involved an idea on a bicameral system where the governance body is divided into 2 groups - the Contributors' House and the Token House. However, this idea has been deprecated as we're exploring ways to entirely detach the governance power from tokens to move beyond a economically-driven governance system.

• Chain Halt: Reflecting from the collapse of LUNA/UST, it is worth exploring around the idea of having a mechanism that can temporarily halt the blockchain in emergency situations without applying any penalties to validators. New techs are prone to critical problems and the irreversible nature of blockchain makes it difficult to recover from catastrophic events. Implementing such a feature could grant the community a period of respite, thereby enabling them to take measures that would mitigate further harm.

As mentioned in the beginning, I am seeking participation of individuals who can contribute to the completion and implementation of this proposal with their valuable insights. If you have any suggestions or ideas, please share them in the comments section and I will promptly follow up.

Contributors & Notable Contributions

*In alphabetical order of Github handles

• @adr-sk: Main author

• @dongwon8247: Review and feedback

• @giunatale: Ideas on supermajority votes, Token House Delegates, improvement suggestions

[adr-sk]

@Morpheus-AI Hey, thanks for the reply!

who is measuring contributions to the project and who decides as to who qualifies for the 334 places?

This has yet to be decided. In fact, a part of GOR Phase 1 specifically addresses this challenge. If you have an idea of how this should be handled/implemented, you should take a look.

Also, to clarify, what I'm referring to in this proposal in regards to submitting/evaluating contributions involves an assumption that we have a functional Evaluation DAO up and running.

[adr-sk]

@ltzmaxwell Hey, glad to hear that you're interested in the bicameral design. Unfortunately, this concept was removed from the latest draft with 2 biggest reasons being:

1. The potential hostile governance takeover issue resulting from equal voting power across all Contributors has been addressed with the tiered-membership structure.
2. With GNOT being a non-inflationary token without native staking rewards, it's reasonable to expect a majority of its supply to be locked in AMMs or lending platforms for capital efficiency. With this in mind, it's unlikely for GNOT holders to find governance delegation attractive, which will result in a low governance participation rate.

Something else that was proposed during the last office hour call that's worth noting was to let GNOT holders only vote on GNOT-related governance proposals. However, since it's likely that the mint function will be removed from the GNOT contract and the community pool management will be handled by the Contributors DAO, there wouldn't be much left for the token holders to vote on even if they had access to governance.

Still, if you have ideas that can justify giving governance powers to GNOT holders, I'd love to hear about them, as I'm open to bringing back the bicameral design if we can make it work.

[MichaelFrazzy]

Just confirming this is still the most up-to-date issue/documentation covering governance and related tokenomics. Contributor DAO voting power is still tentatively based on that geometric series equation, with Contributor DAO now completely replacing the concept of having x top Core Contributors holding their house's VotingPower? Going to be digging into everything more over the next few days, I love the current foundation!

[adr-sk]

The Gnoland Governance Module Proposal

Note: This document is a work in progress. I'm in search of collaborators to help define and implement the Governance Module for Gnoland.

This is the latest version of the issue updated on August 31th, reflecting the most recent presentations from Manfred, an interview with Jae, and a review from Michael on a comment on Issue #319

This document is a formal proposal following our initial ideas at Onbloc shared in the comments of the issue featuring the challenge, and discussions from the Game of Realms Office Hours. I converged the proposed ideas in a single issue to drive extensive discussions.

Summary

The proposed module inherits the basic architecture of x/gov of the Cosmos-SDK with the following changes:

• Added membership tiers for defining and configuring a hierarchical structure within a DAO.

• Added penalties for non-voters.

• Added the supermajority voting type.

• Added constitution which stores a set of texts that establish the fundamental principles and philosophy of the DAO.

• Removed the validator set inclusion mechanism based on delegations of the native staking token.

• Updated the vote tallying method.

Core Concepts

• GNOT: The non-inflationary native gas token of Gnoland. GNOT tokens are used for paying transaction fees and funding proposal deposits.

• WORX: The inflationary native share token of Gnoland. Owners of WORX tokens receive a portion of the chain's revenue, and each earns a spot in the Contributors DAO. WORX tokens are non-transferable, meaning none can be purchased or sold.

• Contributors DAO: As the governing body of the chain, the Contributors DAO is responsible for voting on submitted proposals. Members of the DAO are called Contributors, who consist of individuals who have been transparently acknowledged, reviewed, and rewarded with WORX for providing meaningful work to the project.

• Tiers: The hierarchical structure of the Contributors DAO consists of 7 tiers. Contributors start at the lowest tier, moving up by fulfilling the requirements.

The Contributors DAO

The following specification uses GNOT as the gas token and WORX as the share token. The module can be adapted to any Proof-Of-Contribution blockchain by replacing GNOT and WORX with the native tokens of the chain.

Background

Staking-token-gated governance systems often guarantee strong decentralization and an additional layer of utility to its native tokens. However, they're faced with drawbacks such as inefficiencies resulting from painfully slow decision-making processes and the "low cost of attack" vulnerability during a sharp price crash of the staking token (an example seen in the course of Terra's collapse). With the launch of Interchain Security (ICS) on the Cosmos Hub, chains are now given an option to delegate validation to the Hub, which opens up opportunities to include a wider range of contributors to the governance system.

The module's novel approach to governance deviates from traditional systems where voting powers are proportional to the amount of staked tokens, entirely relying on the game theory economics for the security of the chain. Instead, members of a contribution-based DAO are entrusted with the responsibility to participate in the governance to pioneer the initiatives and objectives of Gnoland based on their expertise. This allows for a scalable governance system driven by a professional, agile working group of individuals with various skill sets.

Members of the Contributors DAO consist of Contributors who have earned WORX by submitting transparent, meaningful contributions to the project which is reviewed by the Evaluation DAO, an independent group accountable for evaluating and rewarding Contributors with newly minted WORX.

Akin to the x/gov being widely adopted as the de-facto governance framework for chains across the Cosmos Ecosystem, our objective is to design a modular stack implementable by any GnoVM chain with high customizability.

Tiers and Voting Powers

The Contributors DAO is structured into multiple tiers, with all members within the same tier possessing equal voting power. The system is designed to place those with a proven track record of contributions with more skin-in-the-game in a higher tier while ensuring the inclusivity of newly joined members, yet limiting their influence to prevent a hostile takeover.

There are three different types of requirements:

1. tokenGated: Automatically updated based on the WORX balance of an account.
2. timeGated: Automatically updated based on the time spent by the account in the lower tier.
3. governanceGated: Manually updated through a governance vote. This type should be used when reviewing off-chain requirements such as KYC or approval from high-tier members.

The allocation of voting power is fixed at 51% for Tier 1. The remaining 49% is distributed across the lower tiers, with each successive tier receiving an allocation that recursively decreases by 0.49.

NOTE: Voting Power of Tier 2 = N N+N(0.51)+N(0.51)^2+N(0.51)^3+N(0.51)^4+N(0.51)^5=49 N ≈ 24.44

• Tier 7
  • Requirement: tokenGated by a positive WORX balance. Accounts that make their first valid Contribution are automatically added to this tier.
  • Total Voting Power: ≈ 0.84%
• Tier 6
  • Requirement: tokenGated to the top 50% of all members in terms of WORX holdings.
  • Total Voting Power: ≈1.65%
• Tier 5
  • Requirement: tokenGated by the top 25% of all members in terms of WORX holdings.
  • Total Voting Power: ≈ 3.24%
• Tier 4
  • Requirement: governanceGated by a Super Majority governance vote from Tier 1~4 members. KYC submissions are mandatory to prevent Sybil accounts.
  • Total Voting Power: ≈ 6.36%
• Tier 3
  • Requirement: timeGated by 1 year as a Tier 4 member.
  • Total Voting Power: ≈ 12.46%
• Tier 2
  • Requirement: governanceGated by a Super Majority governance vote from Tier 1 & 2 members. Only elected leads in at least one domain/area may apply.
  • Total Voting Power: ≈ 24.44%
• Tier 1
  • Requirement: governanceGated by a Super Majority governance vote from Tier 1 members for approval.
  • Total Voting Power: 51.00%

NOTE: Requirements for tiers were inspired by concepts from Slide 7 of Manfreds' recent presentation at BUIDL Asia. Further discussions are needed to improve/refine these requirements.

Proposals

Types

1. textProposal: Proposals with no source code modifications such as opinion polls or roadmap proposals.

2. constitutionAmendementProposal: Proposals that make changes to the constitution.

3. paramChangeProposal: Proposals that change one or more parameters of the chain, excluding r/gov.

4. govParamChangeProposal: Proposals that change parameters of the r/gov.

5. communityPoolSpendProposal: Proposals that request funding from the Gnoland Community Pool. Some examples of categories that are eligible to receive funding are as follows: Censorship-resistant social applications, DAO tooling, developer tooling, infrastructure services, education, payment applications, financial inclusion, climate change, and academic research.

6. memberPromotionProposal: Proposals that request approval from eligible voters to promote an account to a higher tier.

7. validatorUpdateProposal: Proposals that add or remove accounts from the validator set. (must be removed or disabled for ICS consumer chains)

The type of vote to be held for a proposal is determined based on the extent of its effect on the chain and may be conducted as either a Simple Majority vote or a Super Majority vote.

• Simple Majority: Proposals that require 1/2 or more yes votes out of total exercised votes to pass.

  • Applied Types: textProposal, paramChangeProposal, communityPoolSpendProposal

• Super Majority: Proposals that require 2/3 or more yes votes out of total exercised votes to pass.

  • Applied Types: constitutionAmendementProposal, govParamChangeProposal, memberPromotionProposal, validatorUpdateProposal

Life Cycle

1. Community Discussion

• Proposals must be drafted and thoroughly discussed on community boards (r/boards, Discord, forums, etc.) for a temperature check prior to their submission.

• It is advised that the proposer only proceeds upon receiving a positive sentiment from the community.

2. Submission

• Proposals can be submitted by anyone.

• Proposals are identified by IDs that increase by 1 in sequential order, with an initial ID of 0.

3. Deposit

• A proposal enters a deposit period of 43,200 blocks (≈3 days considering a block time of 6 seconds) after the transaction that contains the proposal is confirmed on the chain.

• Anyone can contribute to the deposit during the deposit period, meaning that the proposal submitter does not have to solely fund the deposit. However, a minimum initial deposit exists to prevent spam proposals from flooding the proposal queue.

• Proposals that fail to reach a deposit of the value set as the minDeposit until the deposit end time are considered expired and, thus are removed from the state. This mechanism also exists to prevent spam.

• At the end of a proposal, deposits are handled as the following:

  • Returned: If a proposal passes or fails after reaching the quorum, its deposits are returned to each depositor.

  • Confiscated: If a proposal expires, fails to reach the quorum, or is vetoed, it is considered as having malicious intent. Hence, the depositors are penalized by having the deposits confiscated, which are sent to the community pool to be used to fund public goods.

4. Voting & Vote Tallying

• A proposal enters a voting period of 201,600 blocks (≈14 days considering a block time of 6 seconds) starting from the block following the one in which the proposal reaches the minDeposit.

NOTE: It seems reasonable to reduce the voting period (maybe somewhere around 7 days) to promote an agile governance environment, given that our system now has a seemingly smaller number of total voters, all of whom are expected to stay actively engaged.

• votingPower of an individual = [Total Voting Power of the Tier]/[Total Members in the Tier]

  • Example
    • Let's assume that Alice is placed in Tier 2 with 3 other members, while Bob is placed in Tier 5 with 199 other members.
    • Alice's votingPower ≈ 24.44%/4 ≈ 9.76%
    • Bob's votingPower ≈ 3.24%/200 ≈ 0.0162%

• Quorum: For the outcome of a proposal vote to be considered valid, a threshold of two-thirds in executed votes out of total voting power must be reached. Proposals that fail to reach a quorum by the end of the voting period are considered invalid and thus have no effect on the chain.

• Voting options:

  • yes: Indicates approval of the proposal in its current form.

  • no: Indicates disapproval of the proposal in its current form.

  • noWithVeto: Indicates stronger opposition to the proposal than simply voting no. Not available for SuperMajority-typed proposals as a simple no of 1/3 out of total votes would result in the same outcome.

  • abstain: Indicates that the voter is impartial to the outcome of the proposal. Although abstain votes are counted towards the quorum, they're excluded when calculating the ratio of other voting options above.

• Assuming that a proposal reaches the quorum by the end of the voting period, its result is decided as the following:

  • Simple Majority Proposals

    • Passed: yes is greater than or equal to 1/2 of effective votes (total executed votes excluding abstain votes).

    • Rejected: yes is less than 1/2 of effective votes.

    • Vetoed: noWithVeto is greater than or equal to 1/3 of effective votes. This result overrides all others.

  • Super Majority Proposals

    • Passed: yes is greater than or equal to 2/3 of effective votes.

    • Rejected: yes is less than 2/3 of effective votes.

Veto Penalties

Penalties are applied to vetoers of passed proposals and supporters of vetoed proposals to discourage malicious behaviors of rogue members. Both groups are subject to a penalty of 50% (subject to change) to their current voting power, which recovers at a linear rate over a quarter (subject to change).

1. Member who voted noWithVeto on a passed proposal: A noWithVeto vote indicates that the voter views the proposal as intentionally harmful and is making a public gesture to shut it down. Because this option carries such strong underlying sentiment, it should not be abused by voters who simply disagree with a proposal or who find it conflicting with their interests, in which cases their votes should instead be a no.

2. Member who voted yes on a vetoed proposal: Here, we imply that the voter has tried to pass a malicious proposal, which is a reasonable case for punishment.

Non-Voting Penalties

• A non-voting penalty exists for members. This method ensures that all eligible members actively contribute to the governance of the chain while diluting the power of inactive members.

• For each proposal that a member fails to participate, a linearly-increasing negative boost is applied to his/her votingPower, which can decrease to 0, a point in which the member will have no influence on the outcome of proposals.

• The member regains votingPower at a linear rate (subject to change) by re-engaging in voting.

Formatting

textProposal

• Components

1. title: The distinguishing name of the proposal.

2. description: The body of the proposal that further describes what is being proposed and details surrounding the proposal.

3. deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

constitutionAmendmentProposal

• Components

1. title: The distinguishing name of the proposal.

2. description: The body of the proposal that includes the reasoning behind the Constitution Amendment.

3. updatedConstitution: The updated Constitution.

4. deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

paramChangeProposal

• Components

1. title: The distinguishing name of the proposal.

2. description: The body of the proposal that describes the reasoning behind the Parameter Change.

3. subspace: The realm with the parameter that is being changed. (cannot be set as r/gov)

4. key: The parameter that will be changed.

5. value: The value of the parameter that will be changed.

6. deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

govParamChange

• Components

1. title: The distinguishing name of the proposal.

2. description: The body of the proposal that describes the reasoning behind the Parameter Change.

3. subspace: The realm with the parameter that is being changed. (fixed as r/gov)

4. key: The parameter that will be changed.

5. value: The value of the parameter that will be changed.

6. deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

communityPoolSpendProposal

• 2 types of community pool spending proposals exist.

1. Regular Funding: A regular funding type to be used for short-term offline projects that require upfront capital. The funding is provided as soon as the proposal passes the governance vote.

2. Milestone Funding: A funding mechanism that allows for the division of grant distributions. GNOT grants are divided into multiple tranches with each to be released after a milestone is reached. This provides "salary-like" funding for developers to keep them incentivized to complete the project.

• Components

1. title: The distinguishing name of the proposal.

2. description: The body of the proposal that describes the project and its team members that are requesting the funds.

3. type: The indication of whether the proposal is a regular funding request or a Milestone Funding request.

4. recipient: The account address that will receive funding from the Community Pool.

5. amount: The amount of funding that the recipient will receive in GNOTs.

6. deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

memberPromotionProposal

• Components

1. title: The distinguishing name of the proposal.

2. description: The body of the proposal that includes the rationale behind the member promotion. Must also include supplementary documents if required (e.g., KYC materials)

3. address: The account that is subject to the promotion review. A logic for checking if this value matches the submitter's actual address should be implemented.

4. newTier: Indicates the tier that the account will be placed in if passed. A logic for checking if the current tier of the address is the preceding tier of this value should be implemented.

5. deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

validatorUpdateProposal

• Components

1. title: The distinguishing name of the proposal.

2. description: The body of the proposal that includes the reasoning behind the validator update.

3. address: The account that will be affected by the proposal.

4. state: Indicates if the target address will be added or removed from the validators struct.

5. deposit: The amount that will be contributed to the deposit from the account submitting the proposal.

Remarks

Below are ideas that need to be noted or further explored.

• Bicameral Governance System: This proposal originally involved the idea of a bicameral system where the governance body is divided into 2 groups - the Contributors' House and the Token House. However, this idea has been deprecated as we're exploring ways to entirely detach the governance power from tokens to move beyond an economically driven governance system.

• Chain Halt: Reflecting on the collapse of LUNA/UST, it is worth exploring the idea of having a mechanism that can temporarily halt the blockchain in emergency situations without applying any penalties to validators. New techs are prone to critical problems and the irreversible nature of blockchain makes it difficult to recover from catastrophic events. Implementing such a feature could grant the community a period of respite, thereby enabling them to take measures that would mitigate further harm.

As mentioned in the beginning, I am seeking the participation of individuals who can contribute to the completion and implementation of this proposal with their valuable insights. If you have any suggestions or ideas, please share them in the comments section and I will promptly follow up.

Contributors & Notable Contributions

*In alphabetical order of Github handles

• @adr-sk: Documentation authoring

• @dongwon8247: Review and feedback

• @giunatale: Suggestions and improvements

• @ltzmaxwell: Module development

• @MichaelFrazzy : Review and Feedback