GOR — Governance Module

Note: this issue will be updated to keep track of changes in rules.

Challenge Description

Define and Implement a Governance smart-contract suite capable of competing with existing chains’ governance modules. If you think you can improve the governance system of Cosmos Hub, this is your chance to show us how!

What we look for in the submissions / suggestion on what could work for addressing the challenge

retrospectives and investigations into case studies (#540)
- I.e., https://docs.cosmos.network/v0.45/modules/gov/
- Recent exchanges on social media, especially around Cosmos prop82
human specs — definitions, rules, examples (#540)
technical specs and interfaces
implementation
documentation
bootstrapping plan

What wins points

notable contributions
code modularity
collaborative mindset

I am not sure wether I'll actually try giving a crack at this, but I was pondering about it and I wanted to share a few questions and observations I had, as I think they might help in scoping out the task.

Voting power determination

In the Cosmos Hub governance voting power is determined from the amount of bonded ATOMs. The relation is 1 token 1 vote.

@moul: How does Gno.land modified version of Proof of Stake (Proof of Contribution) works in practice? I am asking because I am trying to understand whether the system can be used to also determine somehow the voting power for governance. From what I can see Tendermint voting power is currently statically defined as there is no module to handle dynamic voting power based on bonded tokens (i.e. no x/staking module or equivalent), so I think some more clarity around the mechanics of Proof of Contribution for Gno.land would be helpful.

However, for both systems I would argue that having delegators inherit the validator's vote if they don't vote themselves is not the right path. I argue validators should not be politicians, unless they deserve also that role due to their track record and reputation. Validators should be chosen because of their technical excellency, and their ability to efficiently serve the blockchain to maintain high levels of availability and security. Tendermint consensus power distribution should not be strictly tied to governance voting power distribution, the two should be treated somewhat independently.

This - I argue - will provide a platform for more politically-aligned governance delegations to exist, but mitigate the influence that this can have on the validator set (which should be chosen using different criteria).

Not every network participant is always able to dedicate the necessary time to engage in governance, or the knowledge or expertise to judge fairly on every matter. I believe in this sense some form of (always overridable) delegation is beneficial. But users should be allowed to delegate governance voting power independently from how they delegate Tendermint voting power.

To this end, the GOR governance smart-contract suite should allow for delegations that are independent from the underlying security mechanism.

Users that have governance voting power (how this is determined is to be specified) should be able to delegate it to elegible entities, i.e. delegates. This is similar to how, for instance, Optimism works (interestingly enough, Optimism also has a constitution).

Anyone can permissionlessly propose themselves as a delegate to be elegible to receive governance delegations. Delegates are supposed to be public (but not necessarily doxed) figures, in a similar way to validators, and should engage actively in public discussions and debates.

Users should always be able to override their delegate(s) vote, as well as re-delegate their governance voting power. As this system is not tied with the blockchain security model, re-delegations and un-delegations should always be possible and instant. Un-delegations do not necessarily "unbond" tokens (with a specific reference to the Cosmos Hub, since it is not completely clear to me how Proof of Contribution works) but simply remove the existing governance delegation(s).

On the Cosmos Hub, this feature might be achievable without modifications to x/gov and instead relying on x/authz. However, I am not sure whether this is the right path, but it's the one with the least friction. With this approach delegators would still inherit the validator's vote by default.

Votes and Vote Tallying

The protection of minority interest remains a foundational aspect for any truly equitable, fair and abuse-resistant governance system. It's important that the network possesses the correct mechanisms to protect every current participant. This is especially true as sub-communities have always the right to fork the original network should they feel the need, and leave the current network if it's not going in the direction they agree with. But the other way around - i.e. "coercion" of a relevant minority - is inadmissible.

For this reason, the no with veto vote option currently present in the x/gov Cosmos Hub module is important, and the intended functionality - which is not punishing spam proposals, as erroneously understood by many - has to stay, one way or another. In fact, the original Cosmsos Whitepaper when providing specifications for governance does not even tie spam prevention and burning of deposit to no with veto votes. It indeed states:

Each proposal requires a deposit of MinimumProposalDeposit tokens, which may be a combination of one or more tokens including atoms. For each proposal, the voters may vote to take the deposit. If more than half of the voters choose to take the deposit (e.g. because the proposal was spam), the deposit goes to the reserve pool, except any atoms which are burned.

Moreover, in my opinion the controversy regarding how currently no with veto votes are counted on the Cosmos Hub (stemmed out of Cosmos Hub's prop82 discussions) is to be brought up, and addressed. A Twitter thread that succintly and properly summarize the issue is this one, while Jae here expanded further.

In general, abstain votes should never be counted when tallying. The intent of an abstain vote, as stated in the x/gov documentation, is to allow <<voters to signal that they do not intend to vote in favor or against the proposal but accept the result of the vote>>, which means that they should not influence the result, but only contribute to the quorum.

No and No With Veto

The original Cosmsos Whitepaper presents a different specifications than what has been ultimately implemented in x/gov. The whitepaper allows 1/3+ minorities to force decisions in both directions (yes and no) by voting “with force”, but proposes some penalties in case a decision is vetoed. There should be indeed a weight to chosing the "with force"/"with veto" option. It's an extreme measure that should not be taken lightly.

A few considerations:

I believe the removal of YeaWithForce as an option in the final x/gov design was the correct choice. While it makes sense to have a mechanism to stop a proposal, I don't think it makes sense to allow a minority to force a proposal. This is ripe for abuse, as it could allow for a minority to force harmful changes.
As I said, no with veto votes should have a weight to them. The social stigma around voting no with veto originates from the fact that there is no inherent disincentive to use no with veto instead of no, and therefore voting no with veto can be seen as an offense mechanism rather than a defense mechanism. While the option should exist, there should be an inherent "cost" for taking this action, so that only truly motivated voters would resort to this option. I argue that - similarly to the specification of the Comsos Whitepaper - no with veto voters should be punished by losing a percentage VetoPenalty of their stake if the proposal is ultimately rejected.
No with veto votes could simply count as 1.5 no votes when votes are tallied. They are not considered separately. This still allows for 1/3+ of no with veto votes to stop a proposal only by themselves if needed (i.e. in absence of no votes). And with this equivalence, voting just no would not hurt the veto effort.

Two-thirds supermajority

Some types of proposals (e.g. constitution amendments) should also only pass if a strict supermajority of yes is achieved (as also mentioned in the Atom One constitution). This is to remove both the social pressure that minorities might subject themselves to for openly challenging these proposals with no with veto votes (as it arguably happened [1, 2] during Cosmos Hub's prop82), as well as the need to incur in penalties by using no with veto in these cases. For these proposals, the no with veto option would be absent.

These proposals should also have a longer voting period. If - for example - deliberation for a "normal" proposal is 2 weeks, for these proposals the voting period should be 3 or 4 weeks.

However, having this mechanism does not preclude the need to preserve no with veto as an option for other proposals. Signaling proposals (i.e text proposals) might not include a supermajority threshold for passing, but they might be equally risky. We have had multiple examples of this happening on the Cosmos Hub.

Depoist refund and burn

I don't see as correct the automatic burning of the deposit that happens currently in Cosmos Hub's x/gov when a proposal is vetoed. The option of vetoing a proposal is not - and should not be - a spam prevention mechanism. If we assume that using no with veto incurs in a potential penalty if used (as discussed above), it implies that whether the deposit is burned or not should be determined separately.

I argue that in the case when either no or no with veto are selected as vote, the voter should also specify (as a corollary preference) whether he considers necessary to punish the proposal by burning the deposit, in a binary way (yes or no). At vote tallying, deposits for rejected proposals are burned if and only if a majority of no votes opted for burning the deposit (assuming again no with veto are aggregated to no votes with a 1.5x weight). This would still mitigate spam, but prevent unduly punishing of controversial but clearly not spam proposals.

In general, when a proposal is deemed to be spam, no with veto votes are usually well above the 1/3+ threshold. Examples: https://www.mintscan.io/cosmos/proposals/73 https://www.mintscan.io/osmosis/proposals/277 https://www.mintscan.io/evmos/proposals/38 This shows that just voting no + burn deposit is in general sufficient to punish spam proposals, and no with veto can remain a last resort defense mechanism.

Deposit period, UX and `memo` field

In my opinion, on-chain deliberation should be made more interactive, using the memo field. For delegates (and validators), at the very least, the memo field when they vote should be used to provide reasoning/explanations for their choices, and displayed through the UI. Bringing some of the discussion on-chain I argue would be beneficial for improving the voting process.

Moreover, I think the flow around the deposit period can be equally improved. Since anyone can permissionlessly contribute to the deposit, it would be interesting to explore ways to double down on this aspect. Deposits for proposals can be crowdsourced, so that MinDeposit can stay relatively high, but multiple endorsments from network participants can bring a worthy proposal to the voting period. More visibility/emphasis for the deposit period could - in my opinion - improve the governance process by allowing also discourse/interactions to happen on-chain but before the proposal is up for voting for everyone. Also in this case, the memo field for depositors (aka "endorsers") should be displayed, so that reasoning behind the choice of supporting the proposal can be displayed and shared.

Hey, thank you @giunatale 🙏

FYI: This kind of public retrospective is very helpful and can count as a contribution when being reviewed.

I'll take the time to make a longer answer soon. To unlock you, the TL;DR; will be:

PoC is more similar to PoA than to PoS; but it's managed by a DAO.
The target of this challenge is to build a governance module as smart contract libraries and realms, not as a cosmos-sdk module.
The module won't be necessarily linked with the underlying PoS, PoC, PoA. But it's an option. -> Use interfaces to get voting power.

Thank you for your reply! Looking forward for a more in depth answer. Feel free also to comment on everything I wrote.

The target of this challenge is to build a governance module as smart contract libraries and realms, not as a cosmos-sdk module.

I understood this, I made some comments that could also translate to the Cosmos Hub due to it being referred to in the description of this issue. The primary goal is the GOR smart-contract suite, but I found interesting to envision how this could also translate for changes/improvements for the broader Cosmos governance

The module won't be necessarily linked with the underlying PoS, PoC, PoA. But it's an option. -> Use interfaces to get voting power.

Sounds reasonable. But with the system I had in mind, the veto option should have some sort of associated cost, so that's also why I was interested in understanding. Yet I agree it's not necessarily a blocker. The governance suite should be high-level enough to support different mechanisms for voting power determination.

Hey Gnomes!

We would like to share our ideas at Onbloc so far in regards to this challenge. Your feedback is much appreciated to refine and complete our initiative through the power of collective intelligence. We look forward to seeing discussions & debates around this draft as an effort to design the most effective governance module in the space!

A TL;DR of our ideation

A fork of the gov module of the Cosmos hub with the following changes:

An on-chain-managed membership system for Proof of Contribution
Removal of delegation-based VotingPower and validator set inclusion
A bicameral governance structure which consists of the Contributors’ House and the Token House
Changes to Vote Tallying & Implementation of Supermajority Votes
Penalty for Non-Voters
An alternative Community Pool funding mechanism

On-chain Managed Membership System for Proof of Contribution

Gnoland Team, as previously discussed, is proposing the creation of a PoA-based consensus mechanism for Governance and Chain Validation. To achieve this, we need an on-chain managed tiered membership system for Contributors. It makes sense to issue these memberships as NFTs, specifically SBTs or other non-transferable token specifications, to prevent selling and maintain the spirit of Proof of Contribution. All Contributors would have equal voting rights, but differentiating them by tiers is necessary.

One important consideration is the ability to "slash" memberships if necessary. A potential solution is to add a proposal function that can modify the NFT's metadata to mark it as invalid.

Removal of delegation-based `VotingPower` and Validator Set Inclusion

Gnoland is taking a unique approach where the security of the chain isn't tied to the economic guarantees backed by the staking of tokens. Naturally, the part where VotingPower and inclusion of Validators are determined by token staking should be removed. As per the announcements from the blog posts & AMAs from the Gnoland team, all members will have equal voting rights, and Validators will be selected through a vote among Core Contributors who are evaluated to have sufficient technical expertise and highly-available infrastructure.

A Bicameral Governance Structure

To be inclusive of the GNOT Token holder’s voice, and to prevent a corrupt cartelization of a small group of Contributors, a bicameral governance structure which consists of the Contributors’ House and the Token House, each with specific responsibilities should be implemented for adequate decentralization and accountability.

The Contributors’ House
- Members: Core Contributors
- Responsibilities: Administration & operations in regards to the chain such as development, validation, PR, etc.
- Voting on General Proposals (Network param changes, protocol updates, community funding proposals)
- Electing Validators
The Token House
- Members: GNOT Token Holders
- Responsibilities: Overseeing the Contributors and aligning the interests of token holders to the chain’s direction.
- Proposing and voting on dismissal a “corrupt” contributor
- Proposing and voting on amendments to the Gnoland Constitution

This particular section was inspired by the Optimism Collective mentioned in the comment above from @giunatale . Although the Optimism Collective was mentioned to reference delegates from the comment, we've decided that the bicameral structure of Optimism was also an interesting approach worth exploring. Would love your take on this @giunatale !

Changes to Vote Tallying & Supermajority Votes

There are currently 1 type of proposal and 3 types of votes: A simple majority vote with voting options of Yes, No, and NoWithVeto.

From what we’ve seen on Proposal 69 & 82 & 83 of the Cosmos Hub, proposals that make significant changes to the chain/tokenomics reasonably require stronger agreement from voting parties. Also, No votes are counted against ‘NoWithVeto’, which is illogical considering that both voting options represent opposition towards the proposal.

A simple way to prevent this would be to add another proposal type as suggested by the ATOM ONE Constitution: A Super Majority Vote.

A supermajority vote should require ⅔+ of total voting power (excluding abstain) to vote on Yes to pass, while removing the NoWithVeto from the voting option. (NWV is redundant as a ⅓+ on No would result in the same outcome)

Proposal types that fall under the category below should automatically be processed as a supermajority vote:

The proposal makes changes in the tokenomics (in terms of utility or roles) to native tokens of the chain.
The proposal results in an additional minting of native tokens of the chain.
The proposal modifies the parameters of governance realm of the chain.
The proposal makes amendments to the Gnoland Constitution.

(Also inspired by the comment above from @giunatale )

Penalty for Non-voters

As a chain that would highly rely on active contributions from the Contributors’ House, it would be logical to implement a penalty for non-voters to prevent inactive voters from receiving rewards or maintaining their VotingPower without making any meaningful contributions. For each proposal that a voter is absent from, a linearly-increasing negative boost should be applied to the voter's VotingPower. Once the negative boost crosses a threshold, their membership should be slashed for inactivity. Prior to the slash, the voter should regain VotingPower at a linear rate by participating in future proposal votes.

Example: Assuming a negative boost of 10% and a threshold of 50%, voting power of Contributor "A" falls by 0.1 for each proposal "A" does not vote on. If "A" does not vote on 3 consecutive votes, the voting power of "A" falls from 1 to 0.7. "A" loses membership by being absent on 5 consecutive votes.

An Alternative Community Pool Funding Mechanism

The existing community pool funding mechanism where the grant is received upfront in a single batch has several drawbacks:

The absence of a secure method to provide large funding (most governance participants are cautious/resistant to large funding requests with extensive scope)
No guarantee of completion of deliverables
No mechanism for grant supporters to get rewards

Our proposed solution to this is what we call the Options Funding. Options Funding is a novel funding mechanism that leverage OPTION tokens. Once passed, granted GNOTs are locked up in a contract with a preset expiry date, and the same quantity of OPTION tokens are issued. OPTION tokens are fungible tokens that each represent 1 GNOT locked in the contract. OPTION tokens are tradable for locked GNOTs upon reaching an objective that is provable on-chain (or by submitting a proof to be reviewed by the Contributors' House). If the submitter fails to complete the objective by the expiry date, the locked GNOTs are returned to the community pool, resulting in the OPTION tokens to lose value.

Options funding can be an effective public funding tool, as it will allow the developers of the project secure upfront capital while protecting the community pool from a project failure. This unique structure prevents developers from "robbing" the Community Pool by receiving a huge grant with a seemingly feasible plan and giving up on the development while keeping the grant. OPTION tokens can be sold in secondary markets (e.g., DEXs, OTC platforms) at a discount (less than redeemable quantity of GNOTs) to supporters who believe in the builder to complete the project.

This creates an opportunity for each funding proposal to function as a "native-token-less" ICO that rewards both builders and speculators upon success, while protecting the Community Pool.

We’re exploring ways to make this implementable, and would appreciate some input from you guys from the community.

Plans

This sums up our ideas so far! Please note this is just a preliminary draft of our proposal, which we plan to update and share with the community by the end of the week. While we work on the proposal, we're looking for members from the community who are interested in collaborating with us to help bring it to completion.

We're open to discussions and will provide more reasoning behind these ideas in the comments to assist you in deciding if our direction aligns with your interests. If you have any questions or need clarification regarding our work, feel free to leave a comment below and let us know!

Thanks for sharing your thoughts openly @adr-sk. I am definitely interested in collaborating on converging on a common design if this sounds interesting for you too.

I'll try to comment on a few things.

It's important to remark - as also done by Manfred earlier - that the result of this challenge should be a suite of smart-contracts. We can't resort to forking x/gov, but we can reuse design elements and code where it makes sense.

On the bicameral governance structure

I always thought this was an interest idea to explore, and that's also why I am fascinated by the Optimism governance experiment. After also reading Moving beyond coin voting governance by Vitalik I am very much of the idea this is the correct path forward.

PoC is more akin to PoA than PoS, but I believe it's not through NFTs or SBTs (seen as non transferrable NFTs) that membership is acquired, but by through $GNOSH (if I recall correctly), and $GNOSH are fungible (you can have more $GNOSH based on how much you contribute) but you can't transfer them. I believe this is how you achieve the tiered system (more $GNOSH = higher tier). But I am just trying to reconcile info from scattered discussions with Manfred and stuff I've heard or read online so I might be wrong.

In any case, it still makes sense that 1 account (i.e. 1 member) = 1 vote for the Contributors' House. And to that extent, that some mutable metadata about contributors is kept (akin to storing metadata in their "soulbound token") But, I am still interested in understanding more concretely how PoC works. Do we have issues with sybil resistance and how are these mitigated? Can I contribute under another pseudonym and gain another seat at the DAO and vote in the Contributors' House?

All Contributors would have equal voting rights, but differentiating them by tiers is necessary.

So here 1 member = 1 vote (almost). However with an associated actual "weight" in [1, 0] that accounts for slashing (for penalties due to absenteism as you mention).

One important consideration is the ability to "slash" memberships if necessary. A potential solution is to add a proposal function that can modify the NFT's metadata to mark it as invalid.

The penalization mechanism you propose later in your document makes sense for the Contributors House, and I agree this functionality should be implemented. Slashing should be up to having your VP go to 0 and stay at 0, but I am not sure what you meant by marking it as "invalid" here ($GNOSH should still entitle you for rewards for your previous contributions, you just can't vote anymore)

For the Token House, a delegates system still makes sense to exist. It's a bit more tricky for the Token House to properly establish rules around slashing for absenteism or usage of NWV (should voting power slashes affect the underlying tokens? I argue they should not, but how this can be done efficiently - also from an actual implementation point-of-view ?).

While I agree that separation of powers (and competences) for the 2 houses is ultimately what makes this system powerful (and I like the one you propose), I also think there should be a way for more direct interaction of these two houses, and in particular the ability for the Token House to veto the Contributors' House on a specific proposal (while I don't think the other way around makes as much sense given the separation you propose).

On Supermajority Votes and No With Veto

As we also discussed on Discord, I very much agree and am in support of having 2/3+ supermajority for certain proposals, however this does not completely mitigate the issue. While I think we will get rid of most points of friction from the re-envision of the governance system with a bicameral setup (so situations like prop82 will be next to impossible to happen), the issue with the no with veto option still remains. We should keep this in mind as progress is made on this task

On options

Options could be a very interesting incentivization mechanism, they are used pretty regularly in traditional corporations. I've been tinkering with options as well as an idea and I find interesting you mentioned them too. It's a powerful derivative that can offer many benefits.

However, it can't really be used for funding the way you propose, since the contract you have in mind is not exactly an option (which is price-based). Your "option" is a derivative that is not tied to price, but to the performance of the grantee. Once the grantee has sold the option, they have no incentive to perform anymore as they have no exposure to the upside (they capitalized already, before delivering). Who would buy an option from a grantee knowing the risk of this option becoming worthless is tied to the performance of who just sold you the option, and that this person does not have any incentive to perform anymore?

But keep pushing on the idea cause it's worth exploring. In some way or another, alternative incentivization schemes and funding mechanisms are required in my opinion.

Hey @giunatale, thanks for your reply! I’ll try to address your questions/concerns below:

PoC is more akin to PoA than PoS, but I believe it's not through NFTs or SBTs (seen as non transferrable NFTs) that membership is acquired, but by through $GNOSH (if I recall correctly), and $GNOSH are fungible (you can have more $GNOSH based on how much you contribute) but you can't transfer them.

I first want to clarify here that “the NFTs/SBTs as memberships” is a new idea, partially inspired by POAP. This is not something that was officially announced or suggested by the Gnoland team (unless I missed something). There are two reasons why I believe this approach could work well:

NFTs would greatly simplify the differentiation between contributors and non-contributors for both individuals and platforms. For instance, creating a Contributor-only proposal or setting up a Contributor-only forum on r/boards, and much more can be simply implemented via token-gated access if memberships were minted as NFTs.
Implementing membership as NFTs would simplify the process of changing the tier of a Contributor, removing them from the membership group, or applying a negative voting power boost. This can be achieved by modifying the metadata of the NFTs through governance proposals, rather than relying on more complex methods such as blacklists of certain addresses. For example, defining "Contributors" as those with a GNOSH balance of 1 or more, removing them from the membership would be difficult as GNOSH ownership is permanent.

Can I contribute under another pseudonym and gain another seat at the DAO and vote in the Contributors' House?

I believe this is a challenge faced by Proof-of-Authority consensus mechanisms in general. A potential solution would be to introduce some form of identity verification for Contributors, similar to what Optimism has implemented with their delegate profile verification using Twitter/Tally, but with no external dependencies (in terms of outsourcing something outside of Gnoland).

To ensure authenticity of addresses, I suggest we incorporate a relatively high requirement for GNOSH holdings to prevent the creation of pseudonymous profiles by spreading Contributions across multiple wallets.

For the Token House, a delegates system still makes sense to exist. It's a bit more tricky for the Token House to properly establish rules around slashing for absenteism or usage of NWV (should voting power slashes affect the underlying tokens? I argue they should not, but how this can be done efficiently - also from an actual implementation point-of-view ?).

As discussed on Discord, I agree that implementing a delegate system, similar to Optimism or Uniswap, for the Token House would be a viable solution and deserves further exploration.

Regarding the voting weight (NWV) and slashing for the Token House, it makes sense to have a supermajority requirement for all proposals put to a vote. This reflects the higher level of coordination and commitment required from the community for significant decisions such as dismissing Contributors, amending the Constitution, or vetoing proposals from the Contributors' House (as suggested in your comment).

However, it can't really be used for funding the way you propose, since the contract you have in mind is not exactly an option (which is price-based).

The term “option” is simply a placeholder for a name of the proposed mechanism – it can be replaced with a more appropriate name. The temporary name “OPTION” was chosen, as by purchasing OPTIONs, supporters are basically speculating on the completion of the project which is similar to a “call option”. If anyone has a better name for this, we’re open to suggestions.

Who would buy an option from a grantee knowing the risk of this option becoming worthless is tied to the performance of who just sold you the option, and that this person does not have any incentive to perform anymore?

The proposed system is where speculators or supporters of grantees purchase OPTION tokens, akin to an angel investment. For instance, if a grantee proposes a community pool funding request for developing a frontend for r/boards and the community deems the grantee to be capable, the price per OPTION in GNOT would be relatively higher (as it's likely that the deliverables would be completed before the deadline).

Conversely, if the grantee has a low track record and proposes a complex project like a rollup chain in Gnolang (or whatever else that could be complicated) the price per OPTION would be lower due to the uncertainty of completion. In the event that the grantee completes the task, the supporters who bought the OPTION at a low price could potentially see a high return (high risk / high return). This mechanism aims to facilitate more daring proposals while safeguarding the community pool funds from being spent on incomplete projects.

The only risk would be if the Contributors refuse to vote the deliverables as complete, which I guess could be perceived as an "oracle issue". However, this is unlikely as the Gnoland ecosystem would not attract contributors or new projects if grantees are not fairly rewarded.

I'll try to explain more on this on the formal proposal that we plan to release by the end of this week.

As we've both agreeed that the bicameral system is worth further developing, the next step for us could be to specify the responsibilites of each House. I think the fundamentals should be defined as the Contributors' House having the "power to execute" and the Token House having the "power to veto". From the implementation point-of-view, we could incorporate a timelock that allows the Token House to run a veto proposal, which can be seen as something similar to the concept of challenge periods in rollups. What are your thoughts?

I think we are converging to some common design :) cool @adr-sk

I first want to clarify here that “the NFTs/SBTs as memberships” is a new idea, partially inspired by POAP. This is not something that was officially announced or suggested by the Gnoland team (unless I missed something).

What I was arguing is that a Voter data structure (or some different name) that holds all the metadata is equivalent to an NFT/SBT so I didn't see the need to "overarchitect" by creating the explicit on-chain token(s). (akin to a Validator object for x/staking). The data structure associated to an account (a $GNOSH holder) is created the first time the account votes on a proposal (unless it is created by a pre-emptive ban on the account from the Token House). Perhaps the first time a new account votes (entering the HoC) it should be with a lower than 1 voting power (linearly increasing as more participation is achieved).

NFTs would greatly simplify the differentiation between contributors and non-contributors for both individuals and platforms. For instance, creating a Contributor-only proposal or setting up a Contributor-only forum on r/boards, and much more can be simply implemented via token-gated access if memberships were minted as NFTs.

Contributors are $GNOSH holders, tier is determined by amount of $GNOSH. I think this is irrespective of governance participation and more related to the underlying PoC.

Implementing membership as NFTs would simplify the process of changing the tier of a Contributor, removing them from the membership group, or applying a negative voting power boost. This can be achieved by modifying the metadata of the NFTs through governance proposals, rather than relying on more complex methods such as blacklists of certain addresses.

Updating entries in the Voter data structure would allow the same results (if you want this to be an explicit on-chain token, I am not against it, I just don't see the explicit need).

For example, defining "Contributors" as those with a GNOSH balance of 1 or more, removing them from the membership would be difficult as GNOSH ownership is permanent.

The Voter data structure would have the VP multiplier set to 0 and another field to indicate this change is permament (so can't linearly increase anymore). This would effectively indicate that this $GNOSH holder (effectively a "contributor") does not have anymore voting power in governance (for whatever reason).

To ensure authenticity of addresses, I suggest we incorporate a relatively high requirement for GNOSH holdings to prevent the creation of pseudonymous profiles by spreading Contributions across multiple wallets.

Access to the House of Contributors should not be gated, or at the very least this should be configurable. The issue with sybil resistance is out of scope for this task and I was more asking to @moul. We should have this in the back of our minds but should not be our focus here.

Regarding the voting weight (NWV) and slashing for the Token House, it makes sense to have a supermajority requirement for all proposals put to a vote. This reflects the higher level of coordination and commitment required from the community for significant decisions such as dismissing Contributors, amending the Constitution, or vetoing proposals from the Contributors' House (as suggested in your comment).

Giving the proposed separation of competences, I was actually thinking the same. This might be an easy "fix" and makes a lot of sense for the Token House.

Regarding options, I would leave this on the side for now as it is relatively out of scope (at least to get to an initial design). However, I still am doubtful that the type of derivative you propose fully makes sense on its own. If rewards are provided in tranches for example using an instantiation of the #407 , then funds would be released gradually and the problem of funding projects that underdeliver would already be mitigated. The derivative you propose has a substantial risk that would translate in a high discount on the market. I doubt that strictly as a funding mechanism it would be attractive for grantees.

I am in favor of the proposed separation of powers. I also like how you defined them (power to execute, and power to veto). The Token House would exist primarily for three reasons (taking inspiration from input from @adr-sk and the discussion we had. I argue btw that additional minting of tokens in an unscheduled way should never be allowed)

manage the Constitution
manage parameters of governance realm of the chain (including banning/reinstating members from the HoC)
veto House of Contributors

Anyone, however, should be able to submit proposals, irrespectively of which House would be responsible to vote them. Proposals explicitly designed to be addressed by the Token House would require a 2/3+ supermajority and a relatively high quorum (above 50%?). Delegates for the Token House should exist to achieve better participation from the Token House. What we are desiging vaguely reminds me of the Roman Senate and how only Tribunes of the People were able to veto the Senate. Interesting to keep this parallel in mind IMHO.

From the implementation point-of-view, we could incorporate a timelock that allows the Token House to run a veto proposal, which can be seen as something similar to the concept of challenge periods in rollups.

So, in essence any proposal up for vote for the House of Contributors can be challenged by a sufficient number of votes from the Token House. During the voting period Token House voters can actually cast votes, but the only voting option for them is "veto". They can only decide either to veto or not vote at all. If a set threshold is reached when votes are tallied the proposal is vetoed.

I've gathered our discussions so far and uploaded a proposal in a separate issue. I'm looking for members from the community who can help complete/implement the proposal. If our ideas sound interesting to you and you'd like to contribute by providing insight, please leave a comment on the issue so we can discuss further!

To make the challenge more manageable, we've isolated a simpler part that's maybe more appropriate to get started. Please check out #728. However, working on the complete task is still worthwhile.

Hey everyone :). Thanks for inspiring me to finally start writing and capturing some thoughts for a project I've been prodding forward largely in stealth mode until the past few days linking to it from Gno.land related posts.

My project has no relationship to the Cosmos world/governance system, but I wanted to capture my thoughts even if only in rough draft before diving into x/gov. I've aimed to highlight some of the concepts, principles and constructs I see needing consideration with my own project, which may be relevant to a DAO-of-DAOs model more generally. I'll aim to dig through the Cosmos governance model to see where there's overlap/conflicts/divergent conceptual approaches to try to refine some feedback more relevant to this issue if I can think of any suggestions after a deeper dive.

In the meantime, the initial draft is captured at Proof-Of-Reciprocity: Social Capital Derived Governance. It represents an incomplete, largely top of mind brain dump of the loose model I've had in mind for my project that seems most applicable to the problem being solved for here. Would love any feedback on any of the thoughts found there :)

Adding to my last post, I didn't exactly intend to start playing with code for the still super loosely defined model I'm chasing, but as it turns out... Gno is too fun so I ended up starting to pick at it lol. Another blog post covering the escapade so far, and I've tossed the WIP at GH in a commune branch. It's made up of a commune realm leaning on a dao package, with an undercooked citizen realm leaning on an equally undercooked identity package that I'll likely aim to better hack together next to make it organizationally aware and lean into Federation as early as possible into the toy-ing.

Definitely 100% a toy still, but I want to say thanks to this project for finally inspiring me to both write more, and to finally put some code to the part of my project I hadn't started coding. Guess I was just waiting for the right layer1 project to come along :P lol

I haven't quite gotten around to pulling the changes up into the Realms so I don't have a wrap up of this written, but I've just pushed some updates to a commune-identities branch on my fork that now captures a functioning dao-of-daos prototype :)

I've better fleshed out the imagined identity package, and pulled it into the previously defined dao package with dao_test walking through identity/dao creation, federation and voting.

The identity package defines IIdentity, Organic, Organizer and Organized interfaces, which breaks down the roles needed for orgs-of-orgs at the identity level. This is then leveraged/extended by the dao package to add proposals/voting and soon reputation/social-capital oriented constructs, and supports Federate and FederatedVote hooks to vote on behalf of the DAO (currently just locked to admin). Both packages have a registry construct as well, though I suspect a lot of this will end up refactored at some point so the implementation of that will likely change.

Next up I think I'm going to dive into expanding on the Proposal to support types, with Federate and FederatedVote being the first executable proposal types.

Any feedback welcome. It's been fun massaging this out :)

Edit: Editing rather than spamming more. The commune-proposals branch now has improved proposals, which are now sessioned (undecided results increments Proposal nonce and creates a new session, along with per-user vote counts to track proposal engagement). Proposals also auto-execute using ProposalDelta to define the change request. That branch also contains an untested Submission system that's similar to the un-sessioned Proposals, and tracks MemberMeta stats (submission/proposal count, vote counts, etc) at the DAO level. dao_test now includes a proposal to federate a DAO with another, which then is auto-executed on successful yay vote resolution, outputting the Proposal Nonce, MemberMeta, and member count of the target DAO for each step (including an undecided vote resolution/second session). Still super rough around the edges, but I have nearly enough to start toying with the real fun: Reputation/Social-Capital!

gnolang / gno