[Discussion] Research on DAO Governance Process

General Discussion
1

ARCHIVED

iamcapote October 2, 2021, 3:17pm #1

I’m conducting research on the different governance process. Here is a list along with a brief description of how these projects governed themselves at the time of research. Note that their governance system and structure can change at any time.

First lets discuss some of the similarities between the projects. There are several similarities between the projects:

Most crypto projects follow a modified version of this:
GitHub - rust-lang/rfcs: RFCs for changes to Rust

Which produces a workflow similar to these stages:

  1. Ideas & Informal Discussion
  2. Informal Proposal
  3. Formal Proposal

Usually Projects will go back and forth between these stages until ideas are polished enough for DAO vote.

  • The first stage: Ideation is an obvious stage but some projects go at different lengths to promote ideas and proposal discussions. The difference lies in how the project engages in community discussion through the various channels like Discord, Telegram, Discourse, Twitter, etc.

In this post when talking about these projects assume they also use this first stage of informal discussion and leveraging social tools to enhance the discussion while talking about their governance process.

  • All of the projects have a minimum time of discussion before each proposal is submitted for an official vote.
  • Each proposal is made to be a firm suggestion of information to include.
  • There are a couple of types of votes: on-chain, off-chain, social media and forum polls. Projects leverage all social channels to gather polling data, discussion and ideas. Official votes are usually conducted on platforms like Snapshot & Tally, but there are other options that I will mention along the way.
  • The first few proposals that projects vote on have to do with governance itself and how the entity will be governed. This includes how proposals are going to be rejected or accepted and what platforms they will use in order to gather the votes and what tools will be official and not official. There are many subtle differences hopefully this post helps you navigate through them.

Yearn

  1. How on-chain proposals are passed
  2. Proposal How-To

Yearn follows the process of:

Propose > Discuss > Codify > Vote > Conclude > Execute

Authors of proposals submit them in the Yearn Discourse Forum. Proposals follow a specific template. The Yearn team leverages the Discourse setting of topic templates which prefills topics into a specific way making authors follow a strict pattern. An example template can follow: Tittle, Authors, Summary/Abstract, Status, Motivation/Rationale, Specification, Conclusion, In-Forum vote, Binding Snapshot vote, References, and Copyright if any.

When creating posts they suggest:

  1. Stick to the auto-generated template.
  2. Write concise title with no number. The number will be added by mods once on-chain voting starts.
  3. Add understandable aka non-tech aka eli-5 summary.
  4. Add an abstract: what will be done if the YIP is implemented (keep it below 200 words).
  5. Write a longer motivation with links and references if necessary.
  6. Add specifications if necessary.
  7. Formulate clear for and against positions.
  8. Include a poll to measure sentiment (public, results on vote).
  9. Don’t rush with putting a proposal on chain, keep discussion going for at least 3 days.

Proposals are voted on in Snapshot and once voted the multi-sig wallet implements the decisions.

According to this post (more info and details) they are in the process from converting from a multi-sig to a multi-sigDAO structure.

They previously used Aragonv1 and are considering on moving to Aragonv2. Migration to Aragon2 has caused the Yearn team to pause certain things in regards to governance and keep their multisig structure. They are also looking for alternatives like Colony , Aavee Governance Contracts, Tally , Gnosis Zodiac Module (also known as SafeSnap module) , and others.

Sushi

Discourse Post Describing a TL;DR Governance Process
https://forum.sushi.com/t/about-the-proposals-proposal-how-to/15

Use an identical structure to Yearn in regards to their forum and proposals.

`propose > discuss > codify > vote > conclude > execute

They also use Snapshot to vote for proposals. Once voted the multisig implements the decisions.

Bancor

Discourse Post Describing a TL;DR Governance Process
A Guide to BancorDAO Due Process - Information and Templates - Bancor Governance Forum

Bancor includes the Governance Forum (Discourse) as part of the place of where to post the proposals where users are encouraged to their proposals and ideas. An idea will generally from the topics Community_Chatroom (DISCUSSION), LEVEL_1 (DRAFTING), LEVEL_2 (FINAL VERSIONS) until finally it is submitted for Snapshot.In each category the proposal is polished from a draft into a final version. Once submitted they are Archived in a separate category. Level 1 and Level 2 proposals have limited availability to the public and you must sign up to Discourse to read about them. Proposals must have a specific timeframe in order to pass the vote to the DAO members so authors are expected to state a specific timeframe.

Bancor categorizes its proposals into Whitelisting Proposals, Liquidity Mining Proposals, and Bancor Improvement Proposals. Each proposal has a suggested Template that authors need to follow. Here is the template for Whitelisting a Project , Liquidity Proposal , and Bancor Improvement Proposals (this is one of the most complex proposal templates). Each proposal is made to be a firm suggestion of information to include.

Some proposals like Whilelisting must include details like Etherscan code & verification, Audits, Market Data and Benefits in order to be a legal part of its format.

Bancor recommends to use Telegram and Discord to discuss each proposal. In fact they recommend authors to talk with moderators to create a specific channel to tackle the proposal and discuss it entirely. Authors of proposals are expected to engage in discussion through the social mediums.

Proposal votes are made through through Snapshot. This tool allows a space to post in markdown the proposal and it is encouraged to have the exact format as the post did in the Discourse Forum. Bancor has other details in regards to the exact details of how would someone post on Snapshot their proposals.

Here is an image of their best practices of DAO approval: (image from BancorDAO Due Process )

Ren Project

Discourse post describing an overview of the whole governance process
https://forum.renproject.io/t/ren-governance-process/392

The Ren Project also uses the Discourse Forum as a part of their governance process. The informal proposals are posted in the forum as Requests For Comments (RFC) and they get polished into Ren Improvement Proposals (RIP). Once RIPs are validated they pass for a vote.

The Overall System in Steps:

  1. Request For Comment (RFC)
  • Clear & concise informal proposal that could evolve over time
  • Moderators review it when posted on the RFC Channel on the Forum
  • One week minimum consideration and review process before converting into a RIP
  • Authors are allowed to submit a Snapshot vote to poll on specifics
  • Authors create a summary of the discussions about said proposal
  • RFC are either rejected or accepted
  • If a proposal is simple and non-ambiguous enough it skips this stage

“Requests For Comment (RFCs) are intended to be part of a consistent and controlled path for proposing changes to RenVM, so that all stakeholders can be confident that RenVM is evolving towards a common utility for the whole blockchain ecosystem, and so that all stakeholders have the opportunity to be heard.”

The focus is to prevent proposals that are hastily prepared, have low-quality, have previously-rejected features, do not fit in the roadmap or vision of the project.
RFC have a specific template: Name, Scope, Objective, Category (Protocol, Token, Governance, Or Other), High-level Overview, Relevant history, Details, What is needed for the next steps.

“The team makes final decisions about RFCs. When a decision is made, it will be clearly signaled on the RFC thread.Regardless of acceptance or rejection, if the reasoning is not clear from the discussion in thread, the team will provide a rationale for the decision. All community members are encouraged to challenge any decisions that they think have been made in error.”

  1. Ren Improvement Proposal (RIP)
  • Clear, concise and unambiguous complete proposal
  • All parameters have clearly stated initial values
  • Methods of change through governance clear
  • Cannot change once proposed
  • Moderators review format and content
  • The team have veto ability to the RIPs being posted on forum which prevents hurting the project financially, reputationally, security-wise or in other ways.
  • They plan on making completion, acceptance and rejection of RIPs part of an on-chain governance mechanism with no central parties.
  • One week period minimum of waiting before choosing to vote on a RIP.

“Ren Improvement Proposals (RIPs) are intended to be part of a consistent and controlled path for proposing changes to RenVM, so that all stakeholders can be confident that RenVM is evolving towards a common utility for the whole blockchain ecosystem, and so that all stakeholders have the opportunity to be heard.”

RIPs follow a similar format to RFC: Name, Scope, Objective, Category (Protocol, Token, Governance, Or Other), High-level Overview, Relevant history, Details, What is needed for the next steps.

After a RIP has been accepted, its implementation will be planned and added to the backlog of the Ren core development team. This will include an indication of priority and estimated delivery date (where possible).

  1. Signaling using Snapshot to vote for the RIP
    Snapshot is an off-chain decentralized voting system. it has flexible voting strategies.
  • Minimum of three days of being in the forum to post on Snapshot.
  • Minimum of 4 days to vote on Snapshot
  1. If passed it will be handled by the Ren team.

BadgerDAO

Discourse Post Describing a TL;DR Governance Process
About the BIP | Badger Improvement Proposals category

"The BIP process is a modified version of https://github.com/rust-lang/rfcs 2 . The template also draws inspiration from one of our Badger Builder partners: forum.renproject.io . "

The governance process has three parts - Forum, Snapshot & Execution. Discussions start in the forum in the form of BIP, once it reaches a quorum of 40 votes it passes to Snapshot. Selected group are selected to push approved forum proposals to Snapshop. Finally the proposal is executed.

The BIP template follows a specific format similar to the one in Ren Project: Name, Scope, Objective, Category (Emissions, Sett Vault, Governance, New Product, other), High-level overview, low-level details, and business and technical requirements of implementing the proposal.
After a period of discussion, a team formal comment and a formal consensus is reached and the team will implement.

The proposals are posted in a Discourse forum them talked to in specific Discord channel to reach consensus and vote on the forum.

Aave

Docs on Governance
Governance - Governance

Docs on Governance & Architecture
Governance - Aavenomics

This project is currently running its governance in its second version called Aave Governance V2 which allows a new set of features.

Much like many other projects Aave has a governance token called AAVE and the stAAVE (stands for staked AAVE token) that give governance powers proportionally to the sum of their balance. However, Aave goes a step further and gives two powers to these tokens: Proposal Power and Voting Power. Users are allowed to delegate one or both of the governance powers associated with either token.

The governance process overview:

  1. Aave Request for comment (ARC)
  2. Aave Snapshot
  3. Aave Improvement Proposal (AIP)
  4. On-chain Governance Vote

ARCs

Aave Request for Comments start at the Aave Discourse Forum.
They have a specific template for each category that follows: Rationale, Relevant Links, Summary, Motivation, Specifications (Background about tokens, companies, marketcap, volume, dex data, graphs, holder data), Risk (assessments, Risk parameters, models,etc.), Next Steps, Effects, Resources and more. Here is a good proposal for Lido and another for a voting delay period . ARCs are expected to be informal AIPs but it is encourage to have all the information needed in an AIP. The template ARC is found here.

After an ARC is posted in the forum it is recommended to discuss and take a snapshot vote which according to them maximizes the chances of accepting an AIP.

The rationale behind the use of ARC is gathered in these posts: ARC: Aavenomics quarterly upgrade , ARC: Activation of Aave Protocol Governance V2 . In these posts the team introduce the separation of voting and proposing and part of the move from governance V1 to V2.

AIPs

Only members that have sufficient proposition power can propose an AIP. They recommend to start with an ARC, use the forum to discuss, and make a snapshot vote before making an AIPs.

AIPs start as Work in Process (WIP) and include all prior ARCs, Snapshot votes, and forum discussions. Once the AIP is written and polished it needs to be submitted into Github by forking the AIP repository and starting there (there are more instructions in that repository link). Once the repository is forked the new AIP is added using the AIP Github Template a series of steps are made in order to make a Pull Request to the Pending AIPs Branch.

AIP Statuses

  • WIP - an AIP that is still being developed.
  • Proposed - an AIP that is ready to be proposed on-chain.
  • Approved - an AIP that has been accepted for implementation by the Aave community.
  • Implemented - an AIP that has been released to mainnet.
  • Rejected - an AIP that has been rejected.

Once the AIPs pull request has been polished and reviewed, its prepared for on-chain governance. The review process is conducted via a CI Pipeline performed by the Aave Genesis Team. Then the review is uploaded to IPFS using their AIP uploader tool . The “payload” is reviewed and tested. Then a community member with enough proposition power is able to submit the AIP for on-chain governance which is a technical process that requires a developer to submit the payload and IPFS hash.

A more technical document detailing Aave’s vote and governance can be found here.

After all these process are implemented the final vote is conducted on the Aave app.

Here is an overview of their governance architecture from Docs on Governance Aavenomics

Comp

Discourse
https://www.comp.xyz/t/contributing-to-compound-protocol/48
Good Governance - Governance Process - Compound Community Forum
https://medium.com/compound-finance/building-a-governance-interface-474fc271588c
Delegation and Voting with EIP-712 Signatures | by Adam Bavosa | Compound | Medium

Proposals start in the COMP forum which simply are discussions about code and ways to implement that code via their Github. COMP token holders can make a proposals but the protocol also includes a whitelist of addresses that can create proposals. Once proposals are discussed enough they are submitted to the app. Voting and overall governance is restricted to the Compound App. Delegation and Voting occurs at this stage then the genesis team implements the code.

Governance Post-Mortem

Comp had a recent bug and are going through changes in their review process, more discussion about next possible changes here. I suspect that in the long-term there might be some changes in the governance in the long-term.

According to this post a community member discusses the possibility that the exploit was due to an inefficient review of large code changes before implementing proposals. They suggest that the bug was exploited after passing proposal 62. They evaluate the forum discussion thread of the proposal which they suggest there wasn’t enough testing of the code proposed in the forum. in his words: “We shouldn’t be voting yes on proposals that make big changes unless its been through rigorous testing”. They suggest a discussion involving the reversal of propositions to the multi-sig for “emergencies that require quick responses”. Currently they are working on a proposal 64 to revert proposal 62.

Uniswap

Overview of the whole Community Governance Process here

  1. Forum discussion
  2. Temperature Check
  3. Consensus Check
  4. Proposal Discussion
  5. Proposal Vote

The official documentations of the whole community governance process can be found here. This project admits that this whole process is a proposed structure and that this government system requires a degree of “metagovernance” discussion that have to do with the process of implementation. According to them “On-chain voting is not necessary to make updates to off-chain processes.”

Forum discussion

Uniswap leverages the Discourse forum and its user trust levels to participate in the discussion.

Temperature Check

Users of their discourse forum can perform what they call a “Temperature Check” which is when authors submit to the Uniswap Snapshot an idea that started in the forum for review and voting.

Consensus Check

Authors of Temperature Checks are encouraged to compile all the options that have gained support and create another topic in the forum with “Consensus Check” tittle and a link to the Snapshot. Topics that are posted as Consensus check that have not done a Temperature Check are removed by mods. Authors are encouraged to reach out to their networks to build support, form discussions, and solicit delegates to vote on it. Authors are expected to answer questions and respond to comments. After a period of 5 days a proposal is either rejected or included in a governance proposal for stage 3.

Governance Proposal

The final step in the governance proposals and should be based on the winning outcome from the Consensus Check.

The code should be written for this proposal which can be voted through any Governance portal. Uniswap uses on-chain governance portals through its app interface. This includes: Coinbase Custody , this?, Boardroom, and more recently Tally Uniswap. All proposed code should be audited by a professional auditor and this can be paid or reimburse by the community treasury.

Authors of Governance proposals must ensure that at least 10 million UNI is delegated to their address in order to submit a proposal, or they must find a delegate that has enough to meet the proposal threshold. Uniswap also encourages the use of Sybil to find delegates. Then they must call the propose() function of the Governor Alpha to deploy the proposal and start a seven day voting period. During this time the discussion is on going in the forum and social platforms. When proposals are passed a two day timelock follows before the code is executed.

A recent proposal about governance that was executed in the uniswap interface can be found here to be used as an example.

A more detailed overview of voting using the Uniswap interface can be found here.

A more technical discussion about governance protocols can be found here.

Uniswap also has a resource for risks involved in governance that can be found here.

8 Likes

[Discussion] Research on DAO Governance Process pt2

iamcapote closed January 18, 2022, 6:08pm #2

wuuuuup February 5, 2022, 5:14pm #3

Thanks for your immense research efforts