GOR Governance Module Proposal #503
Comments
|
Hey @adr-sk, I like this proposal in general, seems well thought out. I have a few more specific observations I wanted to share.
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.
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. 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?
I disagree with this. It can be a source of controversy (and it has been).
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
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 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.
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.
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
The way prop 95 was made to pass was by achieving quorum through 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. |
|
Hey @giunatale, thank you for your insightful feedback!
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 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.
Self-delegation exists, as Delegates would have no choice but to delegate their own GNOT holdings to other Delegates otherwise.
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).
From my perspective, a
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 penalties should be applied to both
As we are planning to impose a non-voting penalty on Contributors, I believe the
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. |
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.
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.
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.
I think I agree with you. We can review this later.
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.
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 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. 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.
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.
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.
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. |
|
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? |
|
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? |
|
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 PowerGovernace TokenI 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 PowerHowever, 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. IncentiveI 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 Vote & TallySimilarly, 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. |
Gnoland Governance Module ProposalNote: 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. SummaryThe proposed module inherits the basic structures of the
Core Concepts
The Contributors DAOBackgroundStaking 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 Voting PowerTo 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.
ProposalsTypes
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.
Life Cycle1. Community Discussion
2. Submission
3. Deposit
4. Voting & Vote Tallying
Veto PenaltiesPenalties 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).
Non-Voting Penalties
Formatting
|
|
@Morpheus-AI Hey, thanks for the reply!
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. |
|
@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:
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 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. |
|
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! |
ajnavarro
added
🌱 feature
The Gnoland Governance Module ProposalNote: 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. SummaryThe proposed module inherits the basic architecture of
Core Concepts
The Contributors DAOThe 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. BackgroundStaking-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 Tiers and Voting PowersThe 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:
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
ProposalsTypes
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.
Life Cycle1. Community Discussion
2. Submission
3. Deposit
4. Voting & Vote Tallying
Veto PenaltiesPenalties 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).
Non-Voting Penalties
Formatting
|
dongwon8247
moved this from In Progress
to Blocked by / Wishlist / Issues
in 🤝🏻 Partner: Onbloc
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/govof the Cosmos-SDK with some notable changes:Contributors,Delegates, andValidatorsfor defining and managing members of the Proof of ContributionConstitutionthat stores a set of texts that serve as the Constitution of GnolandCore Concepts
VotingPoweron governance proposals.VotingPeriodas a protective measure against flash loan attacks (as suggested by @giunatale). Delegates are expected to exercise voting rights responsibly on behalf of delegators.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
VotingPowerof1.Validators.The Token House
VotingPowerfor each GNOT delegated.Proposals
Types
TextProposal: Proposals with no source code modifications such as opinion polls or roadmap proposals.ConstitutionAmendementProposal: Proposals that make changes to theConstitutionstruct.ParamChangeProposal: Proposals to be voted on by the Contributors' House that change parameters of the chain, excludingr/gov.GovParamChangeProposal: Proposals voted on by the Token House that change parameters of ther/gov.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.ValidatorUpdateProposal: Proposals that add or remove accounts from the validator set.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.
Yesvotes out of total exercised votes to pass.TestProposal,ParamChangeProposal,CommunityPoolSpendProposalYesvotes out of total exercised votes to pass.ConstitutionAmendementProposal,GovParamChangeProposal,ValidatorUpdateProposal,VetoProposalLife Cycle
1. Community Discussion
r/boards, Discord, forums, etc.) for a temperature check prior to their submission.2. Submission
0.3. Deposit
MinDeposituntil the deposit end time are considered expired, thus are removed from the state. This mechanism exists to prevent spam.4. Voting & Vote Tallying
MinDeposit.VotingPowerCalculation:VotingPowerof1.VotingPowerper 1 GNOT delegated at the subsequent block of which the proposal enters the voting period.VotingPowerVotingPowerYes: 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 votingNo. Not available for SuperMajority-typed proposals as a simpleNoof 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. AlthoughAbstainvotes are counted towards the quorum, they're excluded when calculating the ratio of other voting options above.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.Yesis greater than or equal to 1/2 of effective votes (total executed votes excludingAbstainvotes).Yesis less than 1/2 of effective votes.NoWithVetois greater than or equal to 1/3 of effective votes. This result overrides all others.Yesis greater than or equal to 2/3 of effective votes.Yesis 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
VetoProposalto put the proposal on aTrialstate, provided that the minimum deposit requirement has been met. TheTrialstate lasts until the conclusion of theVetoProposal.Veto Penalties
Veto-related penalties exist to punish malicious behaviors of governance participants.
Yesare penalized by being charged with a negative boost of x2/3 (Exact rate to be discussed) on theirVotingPower. The negative boost gets lifted over a period ofn(Exact rate to be discussed) weeks at a linear rate.Non-Voting Penalties
VotingPower, which can decrease to0, a point in which the Voter'sVotingPowerwill have no influence on the outcome.VotingPowerat a linear rate (Exact rate to be discussed) by re-participating in voting.Formatting
TextProposalTitle: The distinguishing name of the proposal.Description: The body of the proposal that further describes what is being proposed and details surrounding the proposal.Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.ConstitutionAmendmentProposalTitle: The distinguishing name of the proposal.Description: The body of the proposal that includes the reasoning behind the Constitution Amendment.UpdatedConstitution: The updated Constitution in the correct format.Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.ParamChangeProposalTitle: The distinguishing name of the proposal.Description: The body of the proposal that describes the reasoning behind the Parameter Change.Subspace: The realm with the parameter that is being changed. (cannot be set as r/gov)Key: The parameter that will be changed.Value: The value of the parameter that will be changed.Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.GovParamChangeComponents
Title: The distinguishing name of the proposal.Description: The body of the proposal that describes the reasoning behind the Parameter Change.Subspace: The realm with the parameter that is being changed. (fixed as r/gov)Key: The parameter that will be changed.Value: The value of the parameter that will be changed.Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.CommunityPoolSpendProposalTitle: The distinguishing name of the proposal.Description: The body of the proposal that describes the project and its team members that are requesting the funds.Type: The indication of whether the proposal is a regular funding request or a Milestone Funding request.Recipient: The account address that will receive funding from the Community Pool.Amount: The amount of funding that the recipient will receive in GNOTs.Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.ValidatorUpdateProposalTitle: The distinguishing name of the proposal.Description: The body of the proposal that includes the reasoning behind the validator update.Address: The account that will be affected by the proposal.State: Indicates if the target address will be added or removed from theValidatorsstruct.Deposit: The amount that will be contributed to the deposit from the account submitting the proposal.VetoProposalTitle: The distinguishing name of the proposal.Description: The body of the proposal that describes the reasoning behind the initiative to veto the passed proposal.ProposalID: TheIDof the proposal that the proposer is suggesting to veto. This value must match theIDof proposals in theTimelockqueue.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
The text was updated successfully, but these errors were encountered: