Framework	Base	Front end library	Rep.	Philosophy	Key Feature
Aragon	EVM	aragon.js	PieDAO	vote-driven	Access Control Lists
Moloch	EVM	external projects	Moloch DAO	vote-driven	Rage Quit
DAOStack	EVM	arc.js	dxDAO	vote-driven	Holographic Consensus
Colony	EVM	colonyJS	clr.fund	vote-avoidance	Lazy Consensus
Tribute	EVM	tribute-ui	Flamingo	vote-driven	2-Layer Architecture

Definition of the term “DAO Framework”

The term “DAO framework” is not clearly defined and therefore the content of a project so titled is very malleable. The lowest common denominator of DAO frameworks is one or more smart contracts that represent the actual on-chain logic of a voting mechanism. These contain typical functions like propose(proposal p) or vote(proposal p, vote v). Simply these contracts can already be called a DAO framework. Moloch is such a framework, which is kept very minimal and only contains the essentials. Other frameworks, such as Aragon, contain much more complex smart contracts with more functionalities and also add JavaScript libraries to interact with the contracts. These libraries are just as necessary in almost every use case as the smart contract itself, so this can certainly be considered useful. Furthermore, entire modular systems for interfaces are available [1] up to completely finished software products such as Colony.

Moloch

Moloch is a very narrow, open source DAO framework that focuses essentially on pure smart contracts. The first commit is from 2018. It is based on the code of The DAO from slock.it and is described in a blog post as follows:

“Moloch’s summoner, Ameen Solemani, built the concept from the carcass of The DAO using a minimum viable approach. The primary “minimum viable” aspect really revolved around reducing the massive 1400+ lines of code to a much simpler (thus safer) 300 lines of code.” [2]

According to the white paper, the approach of the Moloch developers was to solve the basic social problem that personal incentives often do not coincide with the common good (so called Moloch problems). This is only partly understandable, since the basic idea of vote-based management of financial resources is not new even in the blockchain context. Moloch rather picks up this idea and makes it stable and applicable again after the failure of The DAO.

The minimal basis of the Contracts is justified with higher security (less code, less bugs), usability (easier to understand) and extensibility (functionality can be extended). However, it is particularly the aspect of extensibility that serves as a flagship for all DAO frameworks. The classic DAO, as used in The DAO, was basically extended with some interesting features, which were later adapted in this or a similar form by other frameworks. One example is the grace period after a successful vote [3].

Permissioned relative majority

Normally, the relative majority is not suitable for DAO voting, because the influence of a member on his own proposal is too strong. By a required “funding” or “sponsoring” of a proposal by other members this should be circumvented. Thus, other members should be convinced of a proposal in advance and fund a part of it. For a fully funded proposal, relative majority is then sufficient for execution.

Post vote grace period

Every member is offered the possibility to leave the DAO at any time. According to the number of own shares a payout will be initiated. Especially in the post vote grace period, this can be used if a member does not agree with the result of a vote at all.

The main component of the DAO is a common liquidity pool, here called Guild bank. Each member has exactly the same percentage of voting power as its share of the pool. Each member can liquidate votes and pay out his share of the pool (see rage quit). The shares are represented by DAO shares. These are also used for voting, cannot be transferred and are therefore not ERC20 compatible. The shares are always inflationary. This is due to the fact that new tokens are used when funds are issued, so that dilution takes place. As a result, everyone who holds that token ultimately bears some of the cost. The idea is that if the DAO increases in value in the long term, which is theoretically what every participating member is aiming for, no one loses anything.

This dilution is capped by the dilution bound. This serves as the maximum limit of dilution that an individual member can experience. The Moloch white paper gives the following example [3]:

’For instance, if 80% of the voting power of the guild were to Rage quit all at once, the remaining members would suffer a 5x dilution. When the proposal is being processed, the Dilution Bound would be triggered and the proposal would fail, i.e. no new Shares would be issued. Since Rage quitters would have taken their proportional holdings of ether, the total Guild Bank balance would be reduced but the remaining members would have exactly the same ether as before the proposal was processed. If the remaining members then wanted to, they could re-submit the proposal.’

During the initial creation of the DAO, also called guild initialize, the first member invites a number of members with his vote and sets an initial price per share. Figure 1.1 shows the constructor of the DAO with all parameters necessary for a deployment. Also the first member is defined as summoner here.

In every moloch DAO joining is only done via a membership proposal. A number of shares are requested, as in a normal issuance of funds, but in exchange for a tribute, which has to be deposited by an existing member. If the membership proposal is accepted, the deposited tribute goes into the guild bank and shares are mined for the new member. If it is rejected, nothing happens and the tribute is returned. This process requires to have already convinced a member to make the membership proposal, so only the most necessary has to be done on-chain. Only one functionality has been added here. The potential new member gets the possibility to withdraw the membership proposal within an abort period, if the submitting member has requested too few shares, for example.

During a proposal and the subsequent grace period, any member who has not given consent may ragequit the DAO with their own shares. All remaining members have to bear the costs. This is to prevent any negative impact on the DAO by malicious proposals. Everyone who agrees to such a proposal bears the costs for it (at least proportionally). This mechanism is also intended to create an incentive to possibly leave an existing DAO in order to create something new, different and possibly better (forking DAOs). This is also the only way to perform upgrades. There are no on-chain functionalities in this respect, so there is a rough consensus approach. The main contract Moloch.sol covers only 713 lines, the first version even only 414 [4].

The largest representative is MolochDAO, which is primarily used for funding Ethereum projects. Overall, Moloch requires less attention from the user. However, the governance process is somewhat slower (due to sponsoring of proposals). In addition, there is a higher risk that proposals will pass virtually ”unseen”. A Moloch-based DAO can also be optionally deployed and managed via DAOhaus, so that an existing front end can be used here as well, if desired.

Aragon

Aragon is a very comprehensive framework whose development itself is organized via a DAO. Aragon V1, including AragonClient and AragonConnect, is the main version of the framework. Under Aragon Govern, a new version is being developed based on the Optimistic enactment governance standard. This EIP is in ”draft” status at the time of research. [5]. Proposals should not require on-chain approval, but should include a separate and cost-efficient voting mechanism (like snapshot). Functions for veto votes remain in the smart contract, as these are used much less frequently. Aragon V1 is currently said to be used by over 2000 DAOs, including Decentraland and PieDAO. Aragon also offers a typical ”no coding required” solution, i.e. a way to deploy and operate via a hosted web application.

For the integration of a custom front end, the Javascript library aragon.js is provided, which is technically implemented as an abstraction layer of the function calls via web3.js. For testing purposes, a DAO creation was performed via an official deployment. Since decentralization plays a minor role here, the deyployment on the Binance Smart Chain test network was used.

The DAO is created with three initial members. Then a deposit is made with some test BNB (https://testnet.bscscan.com//tx/0xf89fad075ee6e9603181dd9892e204faddcf5fa9a14b8142fea7de5b7a7c6a13). Afterwards the tokens of one member were removed again. The interface seems very mature and no errors occurred during use.

DAOstack

DAOStack has been active since around 2017 and is mainly developed by the token sale funded DAOStack Limited based in Gibraltar [6]. The components are very well documented and the focus is more on not being seen as a finished product, but actually as a developer-oriented framework. This includes the well-known interface alchemy, which can be used for deployment and management.

The framework consists of four parts. These are the smart contracts, a JS library for migration, a client JS library and an user interface. The DAOstack-Hackers-Kit is also very interesting. In this repository there is an overview of all components and in addition to each a short statement with the heading “”Should I work at this level?”. In this case, the use of the client library in a custom front end or a modified version of the alchemy front end was considered a reasonable option.

Holographic Consensus

DAOstack promotes a feature called ”holographic consensus”. Behind this is a system that makes decisions about proposals based on smaller subgroups. The goal is to speed up the decision process by using the mechanism of a prediction market. Members can make predictions about the outcome of a vote. If the prediction is correct, the member receives a corresponding payout. This means that a critical mass of all members does not have to vote or even see the proposal each time. As soon as a threshold value of the tokens behind the prediction is reached, the proposal is ”boosted”. This means that now only a relative majority is required, similar to the sponsoring mechanism of a Moloch DAO. The definition of the different states a proposal can have is called the Genesis Protocol in the DAOstack documentation. It differs only slightly from other representations.

A major representative is KyberDAO, with a pool currently over $76 million. DAOstack’s smart contract library ”Arc” was audited [7] by chainsecurity in 2019. It forms the core of the framework and was deployed once on the network and can then be used via delegate calls. This scheme is very common, primarily to save GAS. The library contains various abstractions that stand for a specific functionality. For example, the avatar describes the DAO account and liquidity pool. The plugins contain optional additional functionality, such as reputation. Global constraints are customizable rules that are enforced by a controller. These global constraints serve as an access control list. This allows granular authorization structures within the DAO and is useful if the liquidity pool is divided into individual sections. For example, the group ”Developer” cannot propose a fund release from the pool of the group ”Marketing”.

Colony

Colony is a somewhat newer project and is not directly based on an existing DAO framework. It is also not primarily intended as a framework, but rather as a complete product for running a DAO, although all components are open source and also aimed at developers. The project started with a focus on the voting mechanism, which is also a central part of the white paper [8]. This is very different from other concepts. In the voting process, elapsed time affects the reputation and thus the weighting of the votes.

The project is backed by a limited company based in the Cayman Islands, which primarily drives the development and was also financed via a token sale. The first version was deployed on the Ethereum mainnet. Official support for the mainnet was discontinued in the course of the DeFi developments. Due to the high transaction costs, the contracts could no longer be used in a useful way. The new version of Colony (”Colony V2”) runs on the xDai blockchain. Colony can be considered as its own complete software solution. Currently, Colony V2 is still in a beta phase. The Colony components are well documented and also offer interaction libraries in JavaScript. The Colony Reputation System drops the reputation of any member of the organization, also called ”colony”, if they have not participated in voting for a longer period of time. Other services can use the reputation as well. The off-chain voting system snapshot, for example, offers colony reputation integration, so that the voting weight here also depends on the on-chain reputation. The philosophy of colony is that a DAO should be seen as a group of people doing something very specific, managing resources. Of course, the whole thing should be mapped completely digitally, and it essentially boils down to four components that are needed to make this happen. The office for day-to-day communication, for example, would be a Discord server. For project management, something like Notion could be used and for voting, a tool like snapshot or discourse comes in handy. The final component is the Authority, which reflects the consensus of all decisions and moves appropriate funds. This authority is resilient similar to a court of law and in a sense has the final say. Colony wants to be exactly this authority component. The interface is strongly oriented towards programs like Slack or Discord.

Just as in Discord, several ”servers”, i.e. communities, can be managed. Individual organizations are listed on the left in which the user is a member. Colony uses some components of the Ethereum ecosystem like the Ethereum Name System for usernames and registration. The initial creation of an organization is called bootstrapping. In the process, a token must also be registered as a so-called ”native token” of the colony. However, any ERC20-compatible tokens can be included within an organization. The liquidity pool is realized by funding pots, which simply represent shares of the entire pool for a specific area. The actual payments are called expenditures and describe the structure of a proposal e.g. to pay for a service. Very detailed authorization settings are possible. Individual subgroups (domains), for example, can have a leader who can also make limited modifications to the state of the domain to fix problems. For example, reputation penalties can be imposed. Such modifications are called arbitrations. These access control layer functionalities can be used in the front end abstracted by a configurable team structure. These teams are called domains and can in turn have subdomains. Each domain receives its funding pot from the root domain.

In the normal work process with Colony, proposals are created as actions. An action can be a token transfer, for example. In order for this to be executed, a minimum of the native token must be staked. This can also be done by other members who support the transfer. When the limit is reached, the action is executed unless someone triggers an objection in the remaining time. Parallels to the sponsoring and grace period of the Moloch framework can be seen here again. The Colony front end is in general one of the most mature interfaces that currently exist for DAOs.

Recovery Mode

There is a fallback mechanism, the recovery mode. If this is activated, authorized accounts get access to functions that can change the state of the contract. Each change requires a multisig from these accounts. This serves as a final safeguard and might be dropped one day when the code is mature.

„It is conceivable that colonies will be able to deactivate the recovery mode feature in the future, once the network and contracts have matured sufficiently.“ [8]

Security aspects to the centralized front end

Since much of the user activity in Colony’s front end takes place off-chain, redundant hosting or running multiple interfaces for the DAO is very difficult. This leaves the front end as a central target for attacks. The attacks affect the protection goal of availability and can theoretically be used in an attack scenario in which access to the web interface is blocked for certain members of the DAO. In this way, members can be specifically prevented from raising an objection. As a solution to this problem, a rudimentary emergency front end would be conceivable, which makes all important functions of the ABI easily usable for everyone and can be hosted by members themselves if necessary.

Colony Reputation Model

Each user has a reputation. This is implemented like a token without a transfer function. Reputation can be obtained on the one hand by receiving payment in the form of the native token (e.g. for a service rendered), during initial creation or through an arbitration (conflict resolution). The reputation is affected by an expiration mechanism, by which one loses exactly half of it over 90 days. However, this expiration is recalculated and updated every hour. These regular updates are calculated off-chain by the reputation mining protocol and then stored on-chain. The protocol simply serves to incentivize the valid execution of this calculation.

Tribute

The most recent candidate of the projects examined here is Tribute, a DAO framework developed by OpenLaw (now TributeLabs). It is based on Moloch’s Contracts and is also very extensively documented [9]. Tribute aims to create a better technical foundation through modularity. However, it became apparent in this research that a modular architecture is present in almost all representatives. So the question is to what extent there is actually a technical added value with Tribute.

Basically, the framework consists of two parts, the Core Contracts and the External Adapters. “Adapters” are exchangeable modules that serve as access points for the Core Contracts. Again, an access control layer is created by selectively controlling access between the two components. Unlike DAOStack, this access control layer is just not implemented as a separate controller component. The core contracts store only the state and offer functions for adding and updating an adapter. The available adapters are quite diverse and well abstracted. For example, there is the adapter ”voting” for classic on-chain voting, as in Moloch, and an adapter ”off-chain voting” for GAS-free off-chain voting with a fork of snapshot.

The implementations all look very appealing and also include a user interface, as well as subgraphs for the contracts. The user interface is being developed as a react application under the name Tribute-UI. It is a complete interface that can be self-hosted and allows both deployment and operation of the DAO.

Due to the fact that the framework has not been around that long, there are also only a few representatives that actively use it so far. However, one NFT-focused DAO named Flamingo now has 21 million euros [10] due to recent price changes in this area. An important indicator of security is always large liquidity pools that have not been hacked even after several years. While other frameworks have such representatives, Tribute is not yet as proven in this respect.

In detail, the architecture is actually even more modularized than in other projects, as the core contracts do not even specify a voting mechanism. The active development of new extensions, for example with regard to the integration of NFTs as a deposit option, are also very positive here.

References

[1]  aragon. aragonUI – Plug and play UI elements for Aragon apps. https://ui.ara gon.org/, 2021.

[2]  James Duncan. MolochDAO: a primitive solution. https://medium.com/metac artel/molochdao-a-primitive-solution-d11cc522b18e, 2019.

[3]  Ameen Soleimani, Arjun Bhuptani, James Young, Layne Haber, Rahul Sethuram. The Moloch DAO – Beating the Tragedy of the Commons using Decentralized Autonomous Organizations. https://github.com/MolochVentures/Whitepaper /blob/master/Whitepaper.pdf, 2019.

[4]  AmeenSoleimani.Moloch.sol,Version1desMolochDAOCoreContracts. https://github.com/MolochVentures/moloch/blob/master/v1_contracts/Molo ch.sol, 2019.

[5]  Jorge Izquierdo. ERC-3000: Optimistic enactment governance standard. https://github.com/ethereum/EIPs/pull/3000/files, 2020.

[6]  DAOStack. Setting the ground for the future of collaboration, Impressum. https: //daostack.org/, 2022.

[7]  chainsecurity. Security Audit of DAOSTACK’s Smart Contracts. https://chains ecurity.com/wp-content/uploads/2019/03/ChainSecurity_DAOstack_v2.pdf, 2019.

[8]  Alex Rea, Daniel Kronovet, Aron Fischer, Jack du Rose. COLONY Technical White Paper. https://colony.io/whitepaper.pdf, 2020.

[9]  TributeLabs. tribute-contracts, A new modular DAO framework, inspired by the Moloch smart contracts. https://github.com/openlawteam/tribute-contracts, 2021.

[10]  Flamingo DAO LLC. Flamingo Numericals 7,920.00 ETH Added. https://flamingodao.xyz/, 2022.