Evaluation DAO, Decentralist DAO, and GNO chain Governance

A simplified and evolving approach.

Part 1/3

Summary:

The proposal is to help clarify the requirement and use cases for the Evaluation of DAO, the Gno Governance process. The more solid use cases we have, the easier we can abstract the requirement and make the trade-off in the software design and implementation. Even though it proposed a solution in the end, the primary purpose of this proposal is to clarify problems to solve, bring up open options and invite discussions. We break it down into three parts.

1) intro, use cases, high-level voting system 2) challenges, incentives, and skin in the game 3) technical solution and trade-off

Decentralized Autonomous Organization（DAO）and Governance.

A DAO is an abstraction of the decentralized organization entity on the chain. As an organizational entity, the members of the entity need to work together and make decisions on policies, organization structure, resource allocation, feature development, fund distribution, etc. As it is a decentralized entity, members need a governance structure and process to help them resolve conflicts and reach a consensus on these decisions.

Let’s look at a few examples from the purpose, member structure, decision points, conflicts, and challenges. After that, we abstract entity and process, list design trade-off options, and layout road maps.

DAO and Community

Evaluation DAO

https://github.com/gnolang/gno/issues/407

Evaluation DAO manages the Game of Realm and bootstrapping community participation in the governance.

There are three groups of people involved in DAO activities. They are the New Tendermint core team, community contributors, and other participants. The main areas in that we will need to resolve the conflicts are as follow

Categorize the work
Quantify the work
Qualify submissions
Decide the winning submissions
Size the rewards to the contributors
Change the above rules

The Decentralists DAO

https://github.com/decentralists/DAO

Decentralist DAO provides funding and governance of all aspects of the cosmos hub improvement proposals. It encourages competition among groups that implement the proposal. The members involved were top-level DAO members or community members and permission-less sub-DAO entities, which manage budget and improvement proposals in each category. The group concept is yet to be defined; for now, to simplify the modeling, we define a sub-DAO representing a group on-chain

The main areas that The Decentralists DAO will need to resolve the conflicts and reach a consensus are as follow

Approve improvement initiatives ( request for proposal)
Approve budget for improvement
Qualify implementation prosal
Decide the winning delivery
Size the distribution among the contributor groups.
Approve fund distribution
Change the above rules

GNO chain Governance

It overlaps with both Evaluation DAO and The Decentralists DAO plus

Approve chain parameter changes
Approve chain upgrades.
Change rules that define the DAO

We can borrow some of the concepts from existing cosmos-hub governance. However, depending on if the GNO chain adopts Interchain Security (ICS) or POS to secure the chain, the delegation, bonding, and bonding period in governance could have different meanings. With ICS, it removes the incentive and skin in the game of token delegation and bonding from the POS token. Therefore, we should introduce new incentives and skin in the game for those governance tokens.

Candidate selection and ballot proposition.

As we see in the above examples, we need to make two types of decisions. We can adopt two different voting systems for each and apply the voting power using governance tokens.

For approval activities, the ballot proposition, we vote yes or no
For selection activities, we can borrow score-voting and rank ranking; we rank or give the score for each option

Voting power and distribution.

After we decide on a voting system we use, we need to figure out how the vote is weighted, distributed, and tallied.

If we adopt one vote per person, it is relatively simple. But people can attack with fake accounts.
Suppose each vote has weights represented in tokens. We need to define the token distribution for each person.
If the voting weights are based on privilege, we need to define who gets wants privilege and how to quantify it as voting tokens.

Voting power determination should be flexible in my opinion (through interfaces). The way a sub-dao distributes VP should depend on the specific sub-DAO, its duties and its members. The "simplest" one account one vote will work in most cases, as DAO members should be known individuals with track records, therefore the probability they use sybil identities is low (they would have to actively work on building up two separate identities with sufficiently high public recognition).

Also, I believe you are mixing up scope and duties of this task with #409 (#503).

From what I understand, the evaluation DAO should be a hierarchical structure, where proposals within a sub-DAO are first approved within the sub-DAO itself and then promoted for revision to the parent DAO, whose responsibility is to compare and select proposals from peer sub-DAOs which are in competition with each other.

Proposals, in the context of the evaluation DAO, should be limited in scope and not necessarily result in actual changes to on-chain parameters. The evaluation DAO should be used to organically promote the best solutions that can be then submitted for approval to on-chain governance, through the Governance Realm #409. Proposals within the context of the evaluation DAO might be arbitrary blobs of data, or simple text proposals. But the evaluation DAO IMHO should be scoped in some sense to R&D, where there is scientific discussion and technological development.

I see the following activities/functionalities as needed (the list is not comprehensive nor necessarily accurate):

A way for a DAO to self-regulate and add new members
A way for a sub-DAO to permissionlessly create and candidate themselves as sub-DAO. Members need not be also members of the parent DAO.
A way fo the parent DAO to also have (limited) control on the sub-DAOs (e.g. members?)
A clear cathegorization/labeling system that allows identification of competing sub-DAOs (working on the same topic).
A system to comprehensively manage funds within a DAO (for rewards to individual members) as well as funding of sub-DAOs
A voting system for approval of a proposal within a DAO for promotion to evaluation to the parent DAO
A voting system for a parent DAO that allows for asynchronous scoring of competing solutions of different sub-DAOs within the same cathegory/label. Once a solution is selected and the label/cathegory is cleared, the sub-DAOs (and even the parent-DAO if it was scoped to simply select a winner in that cathegory) are potentially disbanded and any remaining funds returned
A way for a DAO to create governance proposals to interact with #409 and potentially implement the best solutions selected from competing sub-DAOs

I also suggest you take a look at: https://github.com/DA0-DA0/dao-contracts

@giunatale appreciate your comments. Those are great use cases. and https://github.com/DA0-DA0/dao-contracts is awesome.

The approach I take is to review the problems we must solve through governance first; then, we figure out the trade-offs we need to make, and finally a solution as a starting point on a road map. We'd like to explore before converging. #409 is only one of the choices we have for governance.

Here is why

For examples:

Both evaluation DAO and Decentralist DAO need to evaluate and pick the solution and contributors that compete to provide the result. For those use cases, Score-voting and Rank-voting are better voting systems than x/gov #409, which models ballot propositions, a yes / no voting on a proposal.
x/gov is built on top of token staking; the essential underline logic such as token distribution, skin-in-the-game, and Sybil attacks are already addressed by the staking, delegation, bonding period, and slashing. However, GNO and GOR might not have or have yet to figure out the token staking. Without staking we will need to find other ways to solve those problems fundamental to governance, and x/gov #409 does not address these.

I am not sure I understand why you want to mix in the governance system with the evaluation DAO, which - as the name suggests - is scoped towards evaluation of solutions. The evaluation DAO purpose is defined in the rules of the GOR challenge, and in its description. If you want to propose alternative governance systems to, for example, the design we are defining in #503, you are free to do it but that is for addressing #409. Issue #409 is a generic issue for defining the governance system, it is not a solution and hence I don't understand your statement "#409 is only one of the choices we have for governance". Issue #409 would actually be a perfect example for something the evaluation DAO would be used to select the best among the competing solutions. But the scope of the evaluation DAO is not to implement governance.

Your first point is what I more or less see the evaluation DAO needed for.

The second point you make, I am not sure I follow. Also there is no staking in GNO, technically, and there will never be, as it uses a different security mechanism. #409 is a generic task, the task dedicated to developing a governance system, so it cannot explicitly address the issues you listed (solutions for it should). But for example #503, which is a proposal for a design, actually addresses many of the aspects you listed.

If you want to mix #407 and #409, ultimately you are free to pursue this attempt. But I would advise caution as mixing the two things together might result in an overly complex system.

@giunatale Thank you so much for your feedback!

DAO needs a gov system to resolve conflicts. I explained in the 2nd paragraph of part 1/3.

The end goal of GOR is to build a framework or working system that we can leverage to launch and operate the GNO chain. That is why converting the x/gov module to contracts is one of the choices to meet the end goal.

I will explain more about challenges and skin-in-the-game in my parts 2/3. The simplified answer is

the incentive of delegation is staking rewards, not the governance voting
the skin in the game of governance is in the staking token economy, not in the governance itself.

Whether we introduce staking is our design choice. However, we must consider the above to gain ground for governance design.

A deeper and broader exploration of the fundamental issues does not lead to a more complex system. The simple or complex solution is a design choice. We must understand and identify the problems, trade-offs, and assumptions when we make these choices.

Parts 2/3 and 3/3 will address the above topics in detail.

DAO needs a gov system to resolve conflicts. I explained in the 2nd paragraph of part 1/3.

I understand what you mean. But while I agree, I argue that conflicts in the evaluation DAO are only for the matter of:

scoring solutions from subdaos
dao and subdaos management (including funds)

It's pretty scoped out in this sense, and I am not sure if we need more complex governance capabilities as I see anything related to this to fall under #409.

Anyhow, let me tell you my initial thoughts about your two points

the incentive of delegation is staking rewards, not the governance voting

we have already concluded that governance should be disentangled from the underlying security system. Governance do not need any additional incentive system as the incentive is inherent. Governance should however have rails to keep voting rights holders in check. See the discussion in #409 and the draft presented in #503

the skin in the game of governance is in the staking token economy, not in the governance itself

the skin in the game of governance is a function of the economic model of the underlying chain, irrespective of the security system (that can be not dPoS and in fact gnoland is for example not dPoS). Entities with voting rights should benefit from the chain working flawlessly and remaining economically sustainable, and be negatively impacted otherwise. We have to abstract over these considerations you make as the economic model of gnoland, for example, is different and the "skin in the game" you talk about is achieved in another way.

A deeper and broader exploration of the fundamental issues does not lead to a more complex system. The simple or complex solution is a design choice. We must understand and identify the problems, trade-offs, and assumptions when we make these choices.

I invite you to read and contribute to the discussions in #409 and #503 as I think we have already made some analysis and reasoned about these concepts. This is also why I am advocating for keeping the Evaluation DAO design "simple" enough and scoped in its functionalities. We are already seeing that addressing on-chain governance is in and of itself a hard problem, that deserves to be treated independently. I invite @adr-sk to perhaps chime in with his thoughts on the matter.

In any case, we don't have necessarily to all co-operate and if you want to present a different angle and an alternative, you are more than welcome as we need competing solutions. However, I still suggest you give a read to our discussions so you can incorporate some points in your analysis and show how you would address those.

Again, thank you so much for the comments and valuable ideas.

I read #409 and #503 However, I took a different approach. Instead of diving into the solution, and treating designing DAO and a governance solution as separate tasks, I analyze the problems DAO needs to resolve through governance. Then, we make assumptions and layout options with trade-offs before we select solutions.

This process is essential to pick the right solution for the problems we understand and intend to solve.

After initial analysis, x/gov needs three crucial elements for Evaluation DAO and gno community governance.

The evaluation of DAO aims to attract contributors and select solutions to build the gno chain. Therefore, the score voting and ranking vote is much more efficient and fair than yes/no ballot proposition for software development that requires the request for proposals.
Incentives and skin in the game for Evaluation DAO members need to be clearly defined. It does not answer why members vote, what people get from delegated voting powers when there is no staking reward at the first place, and how to use skin in the game to align incentives so that people do not abuse the governance.
If we use ICS to secure the chain instead of POS, without a token bonding period. One layer of skin in the game of voting is gone. Since the bonding period lock in the token for x days, the adversary voting party take the same risk when a governance attack happens that damage the fundamental value of the token and chain.

I hope other people read our discussion and come up with 3rd or even 5th proposals It becomes apparent that we need the score voting and ranking voting to decide which solution stands out and explain why at the voting stage.

All of our solutions eventually will converge and finalize during the implementation stage, not at the current stage.

Part 2/3 will come out soon.

gnolang / gno