• This document is based on an (already outdated) reading of Governance 2.0 draft proposal https://hackmd.io/lrjvEBKFSCmyUhy9gUcGzA?view (april 13 about :) ).
• What we try to do: figure out how the power structure described in that document could be implemented, both in terms of on-chain contracts as well as UX/UI

3 projects:

• Gnosis Safe admin over other Safe signers
• Timelock-Veto decisions for Safe
• Constrained signers / transacters

On-chain Architecture (i.e. the contracts) and control

• Ownership of assets (strategies, vaults, treasure, YFI token) remains with of the original Multisig ("yChad") at https://etherscan.io/address/0xfeb4acf3df3cdea7399794d0869ef76a6efaff52
• The yteams are all (new) multisigs, as described in the gov2.0 doc
• Yteams have access to the yChad multisig via a Gnosis Safe TimeLock-Veto Module. This module (that is to be written) does the following things:
  1. ⏳👍 Optimistic execution: it allows one special address (of a yteam) to queue transactions in a timelock. When the timelock expires, the transaction can be executed by anyone.
  2. 🛑 Veto power While the transaction is in the timelock, any (or M/N?) of multsig owners can veto the transaction (i.e. remove it from the queue)
  3. 👮🏻It restricts the kind of proposal that the yTeam is allowed to submit to the timelock. For example, the ystrats wallet can only queue transactions that operate on the strategy contracts.
  • parameters of this module:
• There is a special case: the yOps gets the power to add and remove owners of the multisigs of the other yteams. In a vanilla Gnosis Safe contract, this power lies, of course, exclusively with the safe owners. A simple Safe module can be written that allows a specific address (this will be yChad) to add and remove owners.

UX/UI

Some types of users:

1. YFI holders, that want to discuss and vote on the proposals
2. Yteam members that want to create and queue proposals in the timelock
3. yChad Multisig owners that need to monitor and if necessary veto a transaction. Initially, they woudl also have the chanceto create transactions themselves.
4. (perhaps) Guards do not have any specific power other than that of observation, and anyone can be a guard. They are responsible for security, that no bad decision slips through. They monitor the queued transactions and signal the multisig owners in case of suspicious or malicious transactions

Each have their own requirements:

1. YFI holders need see and discuss proposals and eventually vote for or against them, but do not need to bother with the mechanics of security and execution. Snapshot interface (and its future iterations) will do fine
2. yTeam members can use the vanilla gnosis safe transaction builder to build transactions, but they probably would like something more userfriendly. Especially those yTeams that have precisely circumscribed responsabilities (like yBudget) will be happier with a friendly Gnosis plugin.
3. yChad Multisig owners would interact with a Gnosis safe plug in that lists the currently queued transactions and allows them to veto these.
4. Guards will want a dashboard in which they can see all transactions that are currently in the queue, so they can signal the multisig owners in case of any suspicious activity. The dashboard perhaps also shows any proposals that are currently being voted on , so that guards could, ideally, catch problematic proposals before they are queued in the Safe.

Transferring real power to YFI holders

Initially, YFI holders will just "suggest" outcomes via Snapshot and Snapsafe. This process is, of course, not trustless: it depends on result that can be doctored by the Snapshot administrator, and leaves some trust in the hand of the reality.eth arbitrators. Given the interests at stake (namely: everything that current multisig manages), these tools must still leave considerable power to the human multisig owners to maintain an acceptable level of security.

The final goal would be that these decision can made by YFI holders in a trustless (i.e. as hard to censor and manipulate as Ethereum itself) way.

One way of transfering real power to YFI users on-chain, while maintaining the cheap and quick snapshot mechanism for "normal" decision making, is to allow token holders to vote on-chain on transactions. This mechanism would only be used in emergencies (e.g. if the yteam superstructure breaks down the YFI holders can use on-chain voting to take control).

There is a spectrum of ways to connect the voting power of the YFI holders to the various yteams. For example, YFI holders could get a little power and be allowed queue transactions in a yteam wallet using the same time-lock-veto module we described above. They can become an owner next to the human multisig operators, with the same veto power. Or, in an absolute transfer of power, the YFI holders control yChad directly.

What needs to be built to get yTeams in a workable state

• Timelock-veto module for Gnosis safe, and a gnosis safe plugin to interact with it
• A gnosis safe module that allows a Safe to manage owners in another safe
• Deployment/upgrade tools for each of the yteams
• A dashboard in which all yteams, with their open proposals, and the transactions queued in the multisig, are shown

What needs to be built to transfer real power to YFI holders

• An integration of voting procedure that allows YFI holders to decide collectively to queue (and/or veto) transactions in the multisig.
• UI for this

Things that would help for smooth functioning of all this

• Custom transaction builders and parsers to make creating transactions and auditing them easier
• Lots of UI

Where we (Lego DAO) see ourselves in this

• We are very interested in helping to build this, but we are not interested in building this on our own. For example, the core of these plans revolve around Safe modules, and in an ideal world, the Gnosis team would build these.
• We are particularly interested in working with yearn on this because of the way that the yteams governance 2.0 meshes with our (non-revolutionary) idea of how DAOs should be built, and we see the opportunity here to help create something that is both (a) useful for yearn and (b) useful as a public good to a wider community.
• We have started to work on an mvp in which we started to work on some of these ideas https://github.com/LegoDAO/mvp/)