YAM Governance Process Analysis and Questions

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.


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:

  1. Early discussion usually starts in discord, where an idea is first presented and discussed.
  2. 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.
  3. If that poll is generally positive (there is no defined threshold) then it will proceed as a snapshot vote.
  4. 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.
  5. 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)

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

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)

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?


Precise discourse and analysis.
Dao is a new economic model, there’s no SOP to give any guidance. We should modify it better and better through what we have experienced and discussed. It needs to cover the balance between investor’s right and efficiency. If the investor didn’t take a look of what is happening in the community in a week, or they just keep watching but not to express their opinion. I think 3~7 days will be quite enough for gathering poll and discuss, no matter in forum or snapshot.
It would be much better for this topic if providing polls for different options.


最近关于简化和明确YAM DAO治理流程的问题引发了广泛的讨论,为了使我们我们可以明确当前的流程并提出改进建议,以下对相关讨论内容进行了梳理。这是第一部分,也是创建治理结构的第一步,希望大家可以权衡考虑自己对当前治理流程的看法,以及本文末尾提出的一些问题和建议。


在运行和改进Yam DAO的过程中,需要对不同形式和规模的提案决议作出选择。 到目前为止,治理决策的制定和通过流程,具有相对的特定性,通常表现为只由一小部分贡献者负责参与和实施。


  1. 早期讨论通常源自Discord频道,一般开始于一个想法,在提出后会加以探讨。
  2. 之后这些想法会转至Yam论坛以进一步加深讨论,在这一环节,一般会以提案的形式发布,其中包含具体目标、一定程度上的论述以及投票测试。
  3. 如果该提案的投票结果得到普遍的认可并且没有明确的阈值设定,那么之后该提案便会进入到链下快照投票(Snapshot)环节。
  4. 如果在链下快照投票环节该提案也获得了通过,那么它便会被移交至开发人员手中,进行代码的构建和修改、测试、审计等工作,直至部署部和实施。
  5. 最后一步是进行链上投票(on-Chain)以将代码在区块链上进行提交。由于此时大部分工作都已经完成,因此链上投票也具有一定的象征意义。所有上述这些环节,都是以解决问题和取得共识为导向而进行的。



在整个治理过程中,最困难的部分就是如何确定各方是否就有争议的提案决策达成共识。这一点对YAM而言尤为重要,由于Yam金库是是Yam DAO和YAM代币最为核心的价值主张,因此提案可以出现分歧,但Yam金库却无法产生“分歧”。基于此,那些与治理决策方向有分歧的YAM持有人就会变得较为被动。





  • 做出明确合理的决策;
  • 治理过程应保持干净透明;
  • 鼓励各方积极参与并出谋划策;
  • 确保可以听到不同的声音并对其予以尊重和纳入考量;
  • 确保提案内容在技术实施上是可行的;
  • 保证治理过程畅通并避免陷入僵局;



论坛讨论 + 民意测验 > 链下快照/签名投票 > 完成代码开发工作 > 链上投票 > 链上部署执行









































  • 如果发起方拥有足够数量的YAM,就可以跳过链上投票之前的所有环节直接发起链上投票。由于提案存在被否决的可能性,并且监护人(Guardian)拥有最终否决权,所以这其实算不上是一种有效的攻击手段,但它确实有可能会破坏治理程序运作的所依赖的社会共识机制。
  • 如果可以实施部署的人员数量受限,那么代码实施部署就会成为一个过于中心化的载体。另一方面,向外部开发人员开放与代码有关的工作又会增加潜在的安全风险。一个折衷的考虑方案是,特定提案的代码开发和审核工作由核心开发人员负责,以降低上述风险
  • 提案中有关代码部署实施的花费和审计费用通常未被考虑和列明,难以查询到相关数据。
  • 如果一个提案在代码开发期间(即链下快照投票和链上投票两个环节之间)需要做出重大更改,此时又无需重新提交链下快照投票(Snapshot),针对这一情况所带来的风险,目前暂时没有相应的治理处理程序。
  • 在链下快照投票(Snapshot)环节,二选一式(Yes/No)的提案投票具有明确的票数定额及通过规则,但目前针对其它类型提案投票的通过标准没有明确的规定,这部分的相关规则应予以阐明并获得批准。
  • 由于创建链下快照投票(Snapshot)只需要持有100枚初始发行数量(BoU)YAM代币,或是取得同等数量的授权委托,这可能会造成链下快照提案被滥用,或是同时创建某一提案的多个不同版本并造成混淆,从而破坏投票过程。这就需要核心团队采取行动,如隐藏/移除快照来避免这种情况的发生,而目前有关此类措施的规范尚未被明确。
  • 在论坛讨论环节和链下快照投票(Snapshot)环节,有关讨论时限和投票时限是累加还是叠加的规定尚不明确(具体是3天讨论 + 3天投票,还是讨论 + 投票共3天)。
  • 在提案以及链下快照投票(Snapshot)阶段,核心团队成员或其他社区成员应具备哪些权力来对社会共识原则进行监督管理?
  • 我们该如何判定一个提案在进入投票环节前,已经经过了充分的讨论?如果一个描述不足或是其内容不可能完成的提案被提交并表决通过,我们该如何处理?

We don’t seem to be getting much discussion about governance here. Maybe Ross if you can boil down your questions into polls? Basically a list of polls to get people’s opinions?

  • Would you like a list of poll questions to help decide on governance structure?
  • No Thanks Let’s just Discuss It.
  • I’d like the team to decide on all options then present it to community for vote.

0 voters

There hasn’t been a lot of discussion here so I will post some of my thoughts on answers to the issues I posed. These are my thoughts and not an official view of the team.

This issue speaks to our need to solidify our social consensus around off chain the governance process. All the process before an on chain vote is the way in which we assure that we are making good decisions for YAM and limit controversial actions.

See previous comment. The fact that the social consensus can be skipped is something we can use for emergency votes though. But this itself must live within our social consensus layer as an understanding of when it is acceptable to skip steps and how we go about determining that. Anything that does not fall within these guidelines can then be vetoed by the guardian without controversy.

In order for a proposal to be deemed a final proposal that can get a binding snapshot vote, it must contain specification information that includes what kind of development work is required and whether treasury funds will be needed to pay for audits or other expenses. I recommend that all proposals that get to the final step of the governance process either be approved by a member of the core team to verify that the proposal can be completed and explain what they think the development load will be, or propose that this work be completed by an outside team and provide funding estimates in the proposal.

If a proposal changes materially between what is in a proposal and is voted upon in a snapshot vote, these changes should be made clear as soon as they are known to be necessary. Either a new snapshot vote should be done to approve these changes or the on chain vote to approve this proposal should not be included with any other proposals.

Final snapshot votes should be performed as Yes/No votes. Any votes to determine weighting or distribution should occur prior to this final vote and the information obtained is what will be voted upon as a Yes/No vote.

I have a bold proposal for this. I would like to make the ability to create a final governance proposal limited to a specific group of YAM holders, while at the same time increasing the number of people who have an expanded role in YAM governance. We want the YAM community to feel empowered to help govern the DAO, and rewarding those who are active and contributing is a key element of this. I propose that we create a new internal group of contributors who have more access to the core team, additional mod powers in the discord and access to additional channels, and the ability to submit Proposals. This group should be flexible and it should be possible to become a member by hanging around and adding value. We do not want this group to serve as gatekeepers, but as ambassadors and helpers who will guide the governance process. Since anyone in this group can submit a proposal, non-group members can still submit ideas to “proposal brainstorming” and other locations on the forum, and if it can gain the support of one of these members or a member of the core team, they can help shepherd the idea into becoming a proposal.

In my mind, the speed of governance should not be the driving factor in our decisions. As a DAO, we are limited by our structure. Changing this structure fundamentally changes who we are, so we should try to understand where we can offload decisions that need to be made fast to those we feel comfortable empowering to make those decisions. This is what we are doing with YDS. The DAO does not move at a speed to make fast investment decisions so we are entrusting that power to our YDS investment manager and setting guidelines and guardrails for them to follow.

The base governance layer of the DAO should be making decisions for things that will be happening in the next quarter or the next year and not in the next week. Giving ample time for community members to come to understand the system and trade-off of decisions is important and as a DAO we cannot expect that everyone has time every day to commit to YAM.

assuming the rules are clear and have been ratified by the governance process then the core team and other community members tasked with making sure governance is running smoothly should feel empowered to enforce those rules. At the same time, there should be a process in which those who feel like they have been treated unfairly can have their voices heard.

Requiring specifications for the work to be done and either core team support or a commitment to get outside devs to do the heavy lifting is a start in this regard. In the end, voting on a proposal is what will determine outcomes, but we want to make sure that all constituents have an opportunity to make their voices heard.

I hope some of you governance nerds out there can chime in about what you think of these issues and others that I may not have thought of.

Yes, I agree or before it even get to this process, have a discussion with a team member to see what the current dev resources are, what and how the idea can be accomplished.

This might be a bit limiting but you had an idea that I really liked which was having “seconds” on proposals where anyone making a proposal would need someone to second their proposal. Seconds on proposals could be a group of community members that are familiar with the governance process and overall workings of Yam.

I think our ideas are very similar. This group of YAM community members are the “seconds.” Basically, in order for a proposal to move from “proposal brainstorming” to “proposals” category it needs a “second” who will make sure that it is crafted properly and meets the requirements. Making “seconds” the group that has access to create posts in the proposal category fulfills this requirement while relying on less moderation overhead (i.e. you and me having to close a bunch of posts that don’t have “seconds”).

from a purely practical note, the term “second” may not be the best as it has a second (haha) meaning and could get confusing in translation. Maybe something like “ambassador” or “facilitator” would be a better term.

1 Like

Somehow missed this very important discussion.

Some thoughts from my side:

  • DAOs might be new relative kind of economic organization, but has a large dependency to software development and therefore a strong overlap with open-source project governance and proven OSS best practices .

    • As reference for an OSS setup in the blockchain space I like the Baseline protocol as a good example: Open Source Community - Baseline Protocol (heavy enterprise IT stuff :nerd_face:)
    • In this case it might be an interesting exercise to translate the Baseline specification- and technical-steering committee to the YAM DAO setup.
    • The Zenhub Dashboard looks quite neat as well, would assume something like this is the prerequisite to manage exponential growth:
      Specifications Steering Committee - Baseline Protocol
  • Within the overall governance- and software-development process, I think there is in general room for improvements between the snapshots votes (or general DAO governance project) and changes to the GitHub repository.
    For example:

    • There could be some kind of technical integration between Snapshot votes and GitHub. I’m thinking of three aspects:
      • Manual mapping of GitHub commits and pull-requests to Snapshots votes. This could help to match the DAO governance process to the software development aspect, e.g. which artifacts were changed or created in GitHub for a certain Snapshot vote.
      • This is more like a brainstorming mode, but ideally there would be some technical integration between snapshot votes and github. For example some kind of approval process aligned with the snapshot vote and changes to the repository.
      • Or some kind of snapshot for a technical governance board to approve changes to the repository.
1 Like

Thanks for the thoughtful response! I will dive in to Baseline a bit.

Upon a quick browse the one thought I have is that it may be more “institutional” than we currently need. Baseline’s goal is to create a protocol that can be used by numerous large institutions and they will therefore want say in how it is governed. While that is similar to YAM, it is at a much larger and more corporate scale than our current needs.

To your second point, tie ins with Github are probably a good idea, but I will need to defer to the more technical members of the team who are using github day in and day out to determine how this is best achieved. As many non-technical members are probably not super versed with Github, we should make sure that it doesn’t become a requirement to use until it is needed. And that there is support to guide people through that process when it arrives at that point.

FYI, there is a governance meeting tomorrow (12/31) at 6:00 UTC if you would like to join. More details will be posted to the discord when they are worked out.