This is the first part of a larger discussion about governance within the YAM DAO. This is the first step in creating a framework to understand our current process and propose improvements. I encourage everyone to weigh in on what they think of the current process as well as if they have thoughts or suggestions about some of the questions and issues posed at the end of this post.
.
Introdution
In the process of running and improving the Yam DAO, there will be many different decisions that need to be made. These decisions will come in many shapes and sizes. So far, the process for developing and approving governance actions has been relatively ad hoc and is often led by a small group of contributors.
The general flow for decision making has been as follows:
- Early discussion usually starts in discord, where an idea is first presented and discussed.
- From there it moves to the discourse forum, and is usually presented as a proposal with objectives, some level of specification and a poll to vote on.
- If that poll is generally positive (there is no defined threshold) then it will proceed as a snapshot vote.
- If it passes the snapshot vote then it is considered ratified and handed over to developers to create the code modifications to build it, test it, audit it, and implement it.
- Finally, there is an on chain vote to commit the code to the blockchain. This last vote should be mostly symbolic as all the work has already been done and the goal with the rest of the process is to iron out previous consensus issues beforehand.
Most governance actions were non-contentious, but there have been a few contentious ones that have passed. These were the compensation proposals, the proposal to change the rebase sell percentage, and the proposal to remove rebasing. In all of these actions, initial pushback on the proposals led to adjustments and resubmission to assuage concerns.
Other actions, like the ragequit proposals, have been split into multiple pieces to come to consensus in smaller steps. This process has also been somewhat ad hoc, but speaks to a more flexible model where larger issues can be approached in smaller chunks with different governance criteria.
The most difficult part in this process is determining whether consensus has been reached on contentious proposals. This is especially important in YAM, since governance by fork is severely hampered by an un-forkable treasury. As the YAM treasury is central to the value proposition of the YAM DAO and the YAM token, there are few options for YAM holders who disagree with the direction of governance decisions.
With proposals that are split close to 50/50, this is a losing proposition for all sides if it means half the token holders will be disgruntled or exit. This should drive all YAM holders toward better understanding each other’s positions and some kind of compromise.
At some point it may not be possible to fully compromise and some YAM holders may exit when a proposal they disagree with is passed. These situations should be discouraged, and situations like this are a large reason for having strong social consensus around the goals, mission, and values of the YAM DAO. Without a unified understanding by token holders as to what YAM is and is striving to become, conflict will inevitably arise.
These issues are in some ways beyond the scope of the governance flow. But a well defined governance flow will allow all participants to focus their efforts on the specific actions they are proposing. It will also help participants in the process gain information about whether what they are proposing will be contentious or not, and what elements of their proposals may need to be tweaked to improve them.
.
.
Goals of a Good Governance Process:
- Make good decisions
- Governance process should be transparent and clear.
- Encourage contribution and involvement.
- Make sure opposing views can be heard and considered.
- Make sure a proposal is technically feasible
- Keep the governance process moving and free of gridlock.
.
.
Analysis of the Governance Process as it currently exists
In this post by Trent, he describes the current governance process as it applies to Forum discussions. In it, he lists the proposal flow as:
Forum Discussion + Poll > Off-chain Signalling(Snapshot) > Code Production > On-chain Vote
Below, I will break down each step.
.
Forum and Discord Discussion
Proposals start as a post on the YAM forums or in the Discord server. Trent’s post linked above describes the current process. Proposals should generally follow the template provided on the forum and include a poll. Discussion should last at least 3 days before submitting for a snapshot vote.
There is no requirement for a post or poll to have a specific result to submit a snapshot vote. This part of the process currently relies on community members choosing to follow these rules.
.
Off-chain Signalling/Snapshot (Binding, but only through social consensus)
Pre-requisites:
It is expected that the proposal has been discussed on Discord and the forums for 3 days and “the community signals its interest.” Enforcement of this rule falls to social consensus.
Submission Requirements
Proposal = 100 BoU YAM
Quorum = 200,000 BoU YAM voting “For” the proposal.
There is nothing hard-coded to set a maximum or minimum voting period, but the current documentation specifies that snapshot voting be 3 days. It is unclear whether these 3 days can overlap with the 3 days of discussion on the forum or if they are additional. Either way, enforcement of this rule falls to social consensus. Certain core team members have the ability to hide/remove snapshot votes from the voting interface, but the norms around removing snapshot votes is unclear.
50% of votes required to pass if a Yes/No Vote. It is unclear what the procedure is if the vote is weighted between multiple options. But previous proposals were considered to pass if they met quorum and the average was accepted as the outcome of the vote.
If this proposal requires modifications to deployed contracts, or for new contracts to be deployed, then that development work happens after this step and before the final on chain vote. There is no requirement to resubmit for a snapshot vote if the implementation of the proposal is changed between snapshot and on-chain voting.
If the proposal does not require modification to contract code or the creation of new contracts on Ethereum then the proposal is final if passed.
.
Code Production
Pre-requisites:
A passed snapshot vote is a signal that there is consensus on this topic and development work can be done with minimal risk.
Development work is done primarily by the core devs of the project and the development work for governance actions is prioritized by the core team depending on its perceived importance and time sensitivity. Some governance actions require significantly more developer time to implement and may require audits. Developer time is currently a bottleneck for the implementation of complex governance proposals.
.
On Chain Voting requirements (Binding through Ethereum consensus)
Pre-requisites:
Snapshot vote has passed. (social consensus)
Code must be ready as this step creates new contracts or implements the changes to the existing contracts running on Ethereum.
Standard Governance Vote
Submission requirements = 50,000 BoU YAM
Quorum = 200,000 BoU YAM voting “For” the proposal
2 day voting period (12345 blocks)
12 hour time lock after vote closes
Guardian can stop the proposal at any time during these 60 hours if deemed malicious.
50% of votes required to pass.
Contributor Payment Vote
Submission requirements = 25,000 BoU YAM
Quorum = 100,000 BoU YAM voting “For” the proposal
3 day voting period (18514 blocks)
12 hour time lock after vote closes
Guardian can stop the proposal at any time during these 84 hours if deemed malicious.
50% of votes required to pass.
There is nothing that will prevent someone with access to the above submission requirements from proposing an on-chain vote. This proposal then is dependent upon reaching quorum and passing with a majority of “For” votes. That it may not have gone through any of the previous steps does not matter unless the Guardian deems that it is malicious and blocks it. The norms around what is malicious or not are not defined anywhere.
.
.
Issues and questions with the Current Governance Process
-
The only truly binding governance decisions occur once an on-chain proposal passes. Everything else is built upon varying layers of social consensus.
-
All steps before an on-chain vote can be skipped if a proposer has enough YAMs to propose a vote. While this is not a powerful attack vector since the proposal can be voted down or the Guardian can veto, it does risk undermining the social consensus around how the governance process works.
-
Code implementation of proposals is a centralization vector if the number of people who can implement proposals is limited. Opening up the coding work to outside developers adds security risks. A middle ground where core developers offer to write and or review code for specific proposals may help mitigate this issue.
-
Code implementation costs and audit costs are often not considered in proposals and these numbers are often hard to find.
-
There is no governance procedure in the event that a proposal requires significant changes in the code development phase between snapshot voting and on-chain voting. This risks a proposal changing significantly between votes.
-
In the snapshot process, Yes/No votes have clear quorum and passing rules, but other voting types, which have been used, do not. These should be clarified and confirmed.
-
Because all that is required to create a snapshot vote is holding or having 100 BoU YAM delegated to you, it is possible to spam snapshot votes or create confusing alternate versions of votes to derail the process. This would require administrative actions from the core team and the norms for these actions have not been defined.
-
In the forum proposal and snapshot process, it is unclear whether the time requirements to discuss and have snapshot votes open are additive or overlapping (i.e. 3 days of discussion and then 3 days of voting, or 3 days of discussion and voting).
-
What power should core team members, or other community members have in policing the social consensus rules within the proposal and snapshot voting phase?
-
How can we determine if a discussion has progressed to a point where it should be voted on? What happens if a vote occurs on a proposal that is underspecified or impossible and it passes?
)