https://lh5.googleusercontent.com/IE3bv4q7xx8HsQhLRHRwA0Ckk_hBmeFek1xknAK4TshsPOdO4CyNvXTnddIiUBlSd9XgUcSyPwEDCCoo4MGUfAtvHroCvtInTcfWwZNPTnoQ_mMSgFLmVtVBSgYi4o2Dq-NC_8Oz

Lego DAO Framework

Minimal Architecture for DAOs

A framework to develop DAOs on Ethereum

This is an early stage document, a work in progress, and we expect this document to change.

All comments welcome

A blueprint for DAOs

One basic starting point of is that a "on-chain DAO" is naturally divided into different functional groups:

1. The Avatar 🏦 holds the assets of the DAO (tokens, permissions on other contracts). The main purpose of this module is security: this is where constraints are defined and where basic permissions are set. In our MVP, we use the Gnosis Safe for this module.
2. The Decision Engine 👍⚙️👎 is where the logic of the DAO decision procedures is defined. It defines rules about how proposals are made, how votes are cast and counted, etc In our MVP, we adapt Compounds contracts
3. The Voting Power 💪⚖️ module defines how much influence each address has in the decision procedure. This voting power can be simply based on the balance of an ERC20 token, or it can be the result of complex calculations on the basis of staked or locked tokens. In our MVP, we will use a snapshottable token from OpenZeppelin.

⚖️

Adopting this tripartite architecture has several reasons:

• Modularity: if we precisely define the interfaces between the 3 modules, this means we can easily "switch out" one module for another. For example, it allows for a DAO to upgrade it's decision engine, without needing to change the Avatar (i.e. the address where the DAO's assets live) or the token address.

• Security Depending on a battle-tested and robust on-chain wallet like gnosis safe for the avatar we obtain a more secure system. Security measures like constraints on execution or time-locks can be defined independently.

• An upgrade path for existing DAOs that already use Gnosis Safe. At the moment of writing, many existing DAOs have adopted this 3-part structure, by typically holding their on-chain assets in a Gnosis Safe, using Snapshot for their Decision Engine, and derive their voting power from an on-chain contract.

• Optimization Separating a DAO into different modules connected with well-defined interfaces is useful for re-using components, but it is essential if a DAO decides to run different processes in different execution environments (for example, have the voting power and asset management on main net, but run the voting engine on a cheap and fast side chain). This is of course the approach taken by snapshot.

• Relations between DAOs by clearly identifying the on-chain "identity" of the DAO, there are clear "connection points" for relationships between DAOs.

Avatar

This component is responsible for holding the assets of the DAO - these assets can in the form of transferable tokens, but can also be in the form of voting rights or other on-chain permissions. This module can, in theory, be a very simple execution relayer, but in practice could be an on-chain multi-sig wallet such as Gnosis Safe 🏦