Governance Open Thread

Governance Open Thread

As promised, here is an overview of ideas I and others have been working on around improving yearn Governance for open discussion.

I do not have all the answers. I have some opinions I’ve shared below and I’m totally open to changing and evolving if people have better ideas.

I apologize if I’ve made any mistakes, misundstood things, missed details, or poorly communicated concepts below. I erred on the side of speed and openness in sharing my thoughts rather than caution and diligence. Let’s work on this together – we can update the below and add details via comments, then potentially revise this into some kind of action plan and then a proposal or two.

Much of the below is based on the work of others, though if there are errors the fault is mine. I apologize for not comprehensively crediting folks, again erring on the side of speed here. Here are some of the people who’s ideas and work has informed this post: @lex_node @lehnberg @aliatiia @cyrus @Zakku @Substreight @chris @Arcturus @vsh_p2p @banteg @milkyklim and many others.

Please help us improve this through constructive discussion. I’ve asked @dudesahn and @Dark
to moderate closely — no personal attacks or trolling please. Let’s give each other the benefit of the doubt and see if we can’t create something beautiful together.


  • This post is an open discussion on how to improve Yearn governance
  • As per YIP-41 extension we have 3 months to transition from the multisig to a “multi-DAO” structure or propose some other new method of governance
  • Transitioning means spreading decision-making and transaction execution powers to different groups and mechanisms
  • Options for decision making, execution, and voting are discussed below

Action Items:

This list is a work-in-progress and will be updated through the discussion.

  • Propose a new allocation of key decision making powers to 1) YFI-holders, 2) main multisig, 3) specific independent workgroups
  • Enumerate specific independent workgroups and their powers
  • Distribute some transaction execution powers off of the multisig
  • Clarify the control surface of YFI voting
  • Create a spec for a new DAO platform for YFI voting
  • Clarify the role of the main multisig

The Multisig

YIP-41 and Multisig Transition

In August 2020, YIP-41 (Temporarily Empower Multisig) was approved by YFI holders to:

  1. temporarily empower yearn Multisig members “to make personnel & budgetary decisions” for a six-month period; and
  2. task the Multisig with “facilitating the creation and transition to a multi-DAO structure”.

On February 24th, YIP-59 extended these powers for 3 months, giving us a little more time to make the transition.

In considering how to implement this transition, let’s start by looking at what the multisig is currently doing and why this transition is important.

Multisig Powers

The multisig has been granted decision-making powers by YFI holders through the passing of four proposals. These proposals are quoted below. Text not pertaining to multisig powers has been removed.

YIP-41: Temporarily Empower Multisig [link]

YIP-54: Formalize Operations Funding [link]

YIP-56: Buyback and Build [link]

YIP-57: Funding Yearn’s Future [link]

The Multisig in Practice

In practice, the multisig does not act as a workgroup making all of these decisions themselves. What has emerged within Yearn organically is a number of interconnected workgroups that take on various responsibilities, make decisions, then propose these to the multisig for execution.

The Multisig reviews these decisions, offers feedback, and then signs them at each signer’s discretion. The essential role of the Multisig is as a safety valve rather than a decision-making or executive body.

Two Kinds of Powers

There are two important ways to think about transitioning power from the multisig:

  1. power to make decisions
  2. power to execute transactions

IMO we should implement a system that moves as much of these two powers off of the multisig and onto the most appropriate decentralized structures as possible.

Power to Make Decisions

Regarding decision-making, Yearn is already working as a kind of multi-DAO structure. As mentioned above, the majority of work at Yearn gets done in a number of interconnected work groups. Generally these groups cooridinate using telegram. Here are some examples of groups and some of what they do:

YFI Docs

  • Manage and organize
  • Write content for

YFI Finance

  • Data aggregation and analysis
  • Create financial reports
  • Budget management


  • General facilitation across all Yearn projects

YFI Doers

  • Coordinating across different teams
  • Deciding on community grants

YFI Content

  • Memes

YFI Compensation Working Group

  • Compensation design

YFI Web Advisors

  • Discussion, feedback, and testing of yearn frontends

YFI Copywriting

  • Copywriting

On quick count, I have 36 telegram groups with the YFI prefix we use when making a new workgroup. Some are temporary, some go idle after their work is done, and some have hundreds of messages a day.

Why transition decision making powers from the multisig? One reason is because most of them already are being made in these emergent groups and it’s working well.

Specifying and formally delegating certain decision-making powers to a number of these groups will significanly help our efficiency and the distribition of leadership within Yearn. While many contributors feel empowered to make decisions, the lack of structure or clarity around who is allowed to decide things often results in too many decisions flowing to the Ops team which is a poor use of resources.

Power to Execute Transactions

This is the kind of power often associated with DAOs (a multisig is a kind of DAO). The power to interact with contracts and move funds. This kind of power requires the security of something like the Gnosis SAFE multisig that we use.

The Yearn multisig executes on average 1.5 transactions a day, and some days many more. These are often complicated transactions that take a tremendous amount of work. As I’m writing this, banteg has just sent a message in one of our telegram groups asking for help:

And beyond creating the transactions, each one needs to be verified and signed by at least six signers. (you can see the list of our signers on the FAQ.) This is a lot of work, and risk, for the signers to take on.

Every kind of DAO mechanism — Gnosis SAFE, Aragon, Colony, MolochDAO, DAOStack, etc — has a high degree of technological friction in their operation. This is well worth it when we are talking about securing millions of dollars, but less of a great solution for some other transactions.

IMO we should work to transition as many of the transactions off of the multisig as we can while not sacrificing the operational flexibility that is one of Yearn’s superpowers.

Let’s look at the options for executing transactions, from highest friction & most secure to lowest friction & least secure:

  • Coin-voting DAOs with on-chain execution
    • DAO platforms: Aragon 2, MolochDAO, Colony, etc
    • Governance libraries like Compound and Aave
    • Others?
  • Gnosis SAFE Multisig
  • EOA Wallet

We have work to do looking at the kinds of transactions the multisig currently executes and seeing what the other options are, for instance:

We could move some transactions to a DAO with on-chain execution.

  • If we implement a new DAO platform with on-chain execution, transactions that require a vote, such as interacting with the YFI minting contract, could be moved off the multisig completely
  • As it is now we use snapshot to vote and then the multisig executes the spec for proposals that pass with binding votes
  • With on-chain execution for some votes the code would be included in the proposal and automatically executed if the proposal passes. This system does need some kind of breaker such as a court of multisig to intervene in some cases, such as if a bug is found in the code after it passes. But note that it’s a huge waste of resources to spend effort codifying proposals to the point where they are production-grade quality, only for them to be voted down and thrown away.

We could create additional multisigs

  • We have tried this already when we created a docs multisig to distrubute docs budget, but that didn’t work well since there wasn’t that much money flowing and the friction was too high
  • We recently gave the strategists multisig the power to control experimental vaults on, this is a better example as this team has high technical capabilities, the need for security isn’t as high as the production vaults controlled by the main multisig, and it offloads work from the main multisig

And in some cases, discretionary EOA wallets should be used

  • Many companies have petty cash funds. Often at yearn contributors pay small expenses out of pocket since it’s too much work to go through the normal channels
  • @milkyklim currently has a 10k USDC allowance on the main multisig he can use without other signers which enables faster action and is independently auditable

But even by spreading some execution power around, there is no way I can see to get rid of the multisig completely, nor should we – it’s a valuable tool. Most decisions should still be executed by the multisig, but some could be offloaded including via on-chain execution from YFI voting (a small fraction of transaction) or those that don’t require the security of the multisig.

Multisig Summary

Ok, summarizing the above and adding some other small points, here’s what we need to do:

  • We have 3 months to transition to a multi-DAO structure, let’s shoot for passing a proposal here this month
  • Topics to consider in the propsoal
    • on-chain execution for YFI voting
    • delegating some transactions to other multisigs or EOAs
    • delegating some decision-making powers to workgroups
    • clarifying what decisions are not delegated and can only be made by voting
    • clarying how YFI voters can revoke delegation and hold teams accountible
    • a plan for regular rotation of multisig signers
    • clarifying what principals the multisig uses to verify transactions are valid and can be signed

The last two points I haven’t mentioned yet. Although the multisig is primarily our system to execute decisions, what specific decisions should the multisig make? Outside of whatever set of operational decisions stay in their power, what is the criteria they should use for deciding whether to sign or not? Something like: Is this transaction valid within yearn’s set of rules? or, could this transaction be fraudulent? Etc. Let’s clarify this.

YFI Voting

Although we have no specific mandate to improve YFI voting, I think many of us will agree this needs some work. This has been discussed a bit above, but let’s separate out some todos here:

  1. Do we need a platform for on-chain execution?
  2. Do we need vote delegation?
  3. What other voting systems should we consider?
  4. We need to decide and clarify more specifically what YFI voting should control
  5. We need to better document and communicate our voting rules

Platforms for On-Chain Execution

Aragon 2

I had been working with Aragon on a proposal to use Aragon 2 for this purpose. This has been paused after some large changes at Aragon One, the company that develops their protocol. I really like Aragon and their team — I just felt it prudent to hold off for now since long-term stability is an important factor when chosing a platform for Yearn. Not ruling this direction out at all, just giving it some space.

Lots of good things about Aragon 2, some good links to review in Jorge’s post. Tl;dr is that it uses snapshot for gasless voting and can add in on-chain execution with a multisig or court in the middle for dispute resolution.

Other Options

There is no clear best direction for us right now that I can see. There are a lot of cool developments we should track and consider though. Here’s a short list:

  • Colony v2 comes out soon
    • So many good ideas here, definitely interested in testing it, but unsure of how it would fit our workflow
    • Can work on xDAI
  • Aave’s Governance contract
    • Similar to Compound’s but I’m told it lets you parameterize quorum and timelock more easily
    • I think it’s just on mainnet
  • New projects to track

Clarify what YFI Should Control

In the early days of yearn there was a proposal to have Andre appear on a podcast. At that time this kind of proposal made some sense, but it no longer does and it illustrates the confusion around YFI voting.

There is no document that explains what YFI can or can’t be used to vote for. This is not just a documentation issue, it’s a collective intelligence issue – it is not something we as a community have fully figured out yet. And it’s time that we did.


This post outlines some developing ideas around improving the multisig and YFI voting. There are many options for how to implement our governance, and no one option is correct.

Where one system may work for one community, it may not work for another. Different communities have different needs and we are all experimenting. For instance, some people think that the DAO should make all the decisions via voting. That’s one POV and some DAOs do that. IMO it’s not a great fit for Yearn’s contributor community that has a bias towards trusting each other and taking action. That’s why I believe our model of constrained delegation has emerged and been quite successful, though not always clear enough. Delegating authority to people or groups does not invalidate decentralized governance – it’s just another postion in a multidimensional gradient of dynamic and evolving governance options. We get to decide how we want Yearn to run.

Towards that end, there are a lot of interesting concepts I haven’t gone into here, like liquid democracy, conviction voting, and other theories of governance — totally up to discuss those and more, what I have outlined above is by no means meant to be comprehensive.

This post is a starting point for discussion. Please weigh in and share your thoughts on how we can improve Yearn’s governance.


One missing option which seems the most promising to me right now is the upcoming Gnosis Safe DAO module. It allows to submit executable proposals via Snapshot voting, which I’m very excited about. Currently we mostly craft these bundles internally using Chief Multisig Officer tool I developed. With DAO module, one potential pathway towards higher degrees of decentralization could look like this:

  1. Social contract. Multisig promises to act in accordance with off-chain votes.
  2. Safety switch. Executable proposals which can be vetoed by multisig signers.
  3. No hands. Multisig owners are fully replaced by the DAO module.

One potential concern with DAO module is it relies on an external oracle such as reality.eth, which currently safeguards only $7m in Omen markets. This is a few orders of magnitude lower than what we require.

Upd: SafeSnap is unveiled.


An excellent choice. I m in.


Optimistic governance (only requiring token voting when stuff goes wrong) is the future! But I think it’s probably unworkable to delegate execution authority from Yearn ($1B+ in TVL) to a third party arbitration oracle with potentially much less economic security. We’re working on some other options for managing execution at Tally, and hope to have more to share soon :slight_smile:

I think a more feasible workflow is (1) snapshot vote to approve changes, (2) multisig transaction to queue changes into timelock, and (3) an on-chain, YFI token based mechanism for cancelling multisig transactions if necessary (eg if they didn’t follow the instructions of the snapshot vote).

As a side benefit, multisig signers face uncertain legal risks and giving tokenholders veto power over multisig actions may help reduce signers’ exposure and liability.

Aave’s governance mechanism is pretty cool, I’m a big fan. But I think the Compound style governor alpha is potentially a better choice for a few reasons:

  • It’s already becoming a standard, with a lot of protocols launching with this framework
  • Standardization allows for Yearn to benefit from other people’s open source dev work and governance tooling
  • The Aave governance feature allowing for multiple quorum/voting periods based on the type of proposal can be replicated by deploying multiple Compound style governor contracts and/or timelocks

Compound style governor mixed with 1inch dao-like style settings framework is more comfortable for me.


Hey guys - maybe I can explain how the oracle (reality.eth) works and address some concerns.

In reality.eth anyone can “Ask a question”. In the context of this module, the question would be: “Was there a snapshot proposal with a specific Safe payload that was accepted via a snapshot vote”.

Now anyone can answer this question and suggesting the answer is either “yes” or “no”. To set the answer you would need to post a bond - this could be denominated in any token - in the context of Yearn you would, of course, choose YFI. The minimum bond could e.g. be 1 YFI token. As soon as someone submitted an answer a countdown will start for e.g. 24h (this can be configured). If you disagree with the answer you can post a different answer but you would need to double the bond. This game continues until the leading outcome does not flip anymore for 24h.

Found this infographic from a very old Gnosis whitepaper with basically the same concept:

Once it ends those that placed the tokens on the losing outcome will lose them towards those that staked on the winning outcome. This game can of course be always won by a 51% majority of YFI holders. So as long as you guys believe more “honest” than dishonest YFI stakers can be activated in case of an attack then this should be “safe”.

Optional reality.eth has the concept of an “arbitrator”. The arbitrator is simply an address (can implement itself any logic (EOA, multisig, DAO, …). There is an arbitration fee - and at any time the arbitrator can be called by anyone by paying the arbitration fee. As soon as the arbitrator is called the “escalation game” as described above will end and the arbitrator will decide which side won.

In omen.eth (prediction market) were reality.eth is used as an oracle staking is done in ETH but for ~35ETH this can be stopped and the court would decide as an arbitrator.

P.S: In addition to all of that - as @banteg mentioned in the post - it will be possible to use the Safe Snapp module still with owners that would always have “veto power”. (note the owner can also be any contract)



Thank you for your clarifications.


Let me add a few options and datapoints for your consideration:

On-Chain Execution Tools:

  • Kleros Governor: A tool for decentralized enforcement of proposal execution (post).
    • You specify a frequency of execution of transactions (weekly for example)
    • You deploy a Yearn Governor contract and move proper admin rights to this contract
    • When one or several proposals have been accepted on Snapshot, anyone can submit a list of transactions with the correct data enforcing the proposals and locks an ETH deposit with it.
    • The list goes through a challenge period.
    • If nothing is disputed, Txs are executed. If someone challenges by submitting a competing list, it goes to dispute in Kleros Court.

We’re also working on a Snapshot plugin to better link Snapshot and Governor. It’s on mainnet but can be deployed on xDAI (tweaking the proxy we use for xDAI Omen to bring the disputes to mainnet).

Gnosis Multisig DAO Module

As discussed in previous posts, it’s also a great solution fit for your needs. It uses Reality.eth as an oracle which is often plugged to Kleros Court as arbitrator for large value use cases.

Total Value Securable
Concerning your doubt about the order of magnitude of value that can be secured by such an architecture, there is no definite number to be shared but to attack the Kleros Court, you‘d need to 51% attack the whole General Court (because of the appeal system) which would cost from “infinity” if you wanted to mount an instant attack (more PNK staked in court than liquidity available in DEX and CEX) to tens/hundreds of millions of dollars for the perfect attacker who slowly makes its way into the system by buying PNK over a year without anyone noticing it.

N.B. Kleros is in process to handle arbitration for an insurance protocol with a similar order of magnitude as Yearn’s TVL.

Optimistic Governance

Finally, I’m also a big proponent and supporter of Optimistic Governance with a “constitution” to uphold and low friction on decisions. However, I don’t think it should be based on a native token voting system for disputes:

  • Voting with all YFI holders every time there is a governance dispute will introduce economic bias, community-wide vote fatigue triggering low participation in those critical decisions, or the development of a dedicated arbitration system that will neither benefit from the security of combination of use cases on one single arbitration layer nor the incentive tweaking needed to ensure the viability of such a system.

  • It would also go against the separation of power needed in DAO: Legislative (Making and voting the proposal) should not use the token for voting than Judiciary/Executive (Make a judgment on or execute those proposal)

That is why, whatever the system selected for optimistic governance is (Colony, Gnosis Multisig DAO Module, etc…) an external third-party arbitration system seems more appropriate to handle the disputes about uncompliant proposal enforcements and it decreases even further the multi-sig signers’ legal liability.


Hi folks! Dennison from Tally, I’d like to +1 @monet-supply and go a bit farther.

The standard is spreading, and besides our own tooling there are plenty of alternative interfaces and components that exist to support Compound’s Governance structure. It’s secure and the Yearn community would have plenty of options when it comes to supporting it. There are subgraphs, gas refund mechanisms, identity solutions, interfaces and more. It’s becoming a defacto standard in the Defi space and is basically plug and play with things like Multisigs, etc…

Happy to answer any questions as well!


I quite liked the idea of Aragon 2, just curious have they gotten back in touch with Yearn at all after the shake-up, or do we just expect that this will take quite a long time for them to resolve their internal affairs?

I really like 1inch’s governance platform.


Hi everyone, sorry for arriving late to the party. Thanks @tracheopteryx for kicking this off. I’d like to offer another option to the mix…

A handful of former DAOstack employees have been working on filling a need in the governance space (tentative name is “lego DAO”). Our group includes two former CTOs as well as others with a deep understanding of the challenges that come with governance. Below is a high level of what we aim to do.

Our vision

We plan to take a pragmatic, community-first, approach to building a simple DAO governance solution.

  • Our first priority is to work with design partners to address the current needs of the market
  • We do not want to build a keys-in-hand DAO solution, but rather a loose framework, in which we fit existing tools and tie them together (Snapshot, Gnosis Safe, Compound governance, various decision procedures)
  • Any software and ideas we create will be open source - we are creating a public good
  • While creating working software, we will document best practices and governance strategies for projects, and create standards and APIs that help us and the wider community reuse and iterate on our software. This is what makes us more than a simple “dev shop”: our model here is OpenZeppelin.


We will be approaching various projects to bootstrap this effort, including DXdao, Compound, Gnosis DAO, and YFI. The idea here is to initially find a few funders that can also function as design partners, and develop the project in partnership with and with funding from those partners. From our experience, almost every project in the space faces similar problems, and there is much benefit in this type of knowledge sharing.

Ownership and DAO

Eventually, the hope is that this project will be funded, governed, and built by the community. By the nature of our game, this likely means that there will be a DAO and a governance token.

From an early stage, we are considering creating a token that will be distributed to those people who help build the project as well as to people or groups providing capital to the project. In particular, this means that we can offer design partners, in exchange for their funding, a corresponding amount of tokens that represent a say in future decisions.

We are working on a more detailed technical spec and would love to get Yearn’s input for some of the key design decisions. Looking forward to seeing next steps here!


Hi @banteg, This is Deli from Automata. I have a proposed voting solution that is almost complete and I would be keen to hear your feedback.

It’s called Witness and

  • Voting is conducted off-chain so there is no gas cost and a wider range of token holders can participate in governance without being deterred by high gas fees
  • Chainhook — If desired, it is possible to trigger on-chain execution based on the voting results. Chainhook enables calling of the on-chain contract which was registered at proposal creation
  • Privacy — You can choose different types of votes with different private levels e.g. Public (full disclosure of voter address and number of votes), Medium (only number of votes), and Private (only voting result is published — voter identities and number of votes are not).
  • Delegation — Users can choose to delegate their vote to another address. This will further save cost through an off-chain delegation process
  • Modular — Each of these functions can be used as standalones, or together. E.g. if a project wants to use Witness as a signaling tool without on-chain execution, that is also possible.

Here’s a diagram on how it works

Detailed writeup here

@tracheopteryx, @monet-supply, @koeppelmann and @dennisonb (sorry i’m not allowed to tag more ppl) I would be grateful if you could provide your comments as well and keen to see if we could collaborate.

1 Like