1Hive recently received an Aragon Nest grant to build Dandelion Orgs, a set of Aragon applications and an organization template for deploying an Aragon DAO that is functionally similar to MolochDAO, but with the notable advantage of modularity and extensibility provided by the Aragon platform and its growing library of applications.
The fundamental mechanism that defines MolochDAO is the ability for members to exit the organization with a proportional share of the organization's assets, so long as they have not recently voted to approve a pending proposal. This creates a loose partnership where members can exit before a bad or otherwise controversial decision is made, and because of that guarantee there is less friction for collaboration in the first place.
MolochDAO was developed with a philosophy of minimizing complexity and code footprint. The organization does not try and do everything, but what it does do it does very well. In contrast, Aragon has been built with a philosophy of modularity and code-reuse. As a result there is a growing library of useful, audited, off-the-shelf components that can be combined to create and expand a software-defined organization. After reviewing the specification we determined that there were some key features of MolochDAO that we wanted to replicate in order to enable Aragon organization to adopt similar mechanisms, but stay true to the Aragon development philosophy of creating modular and re-usable components.
Specifically we wanted to make sure that we met the following requirements:
- Members should be able to redeem tokens for a proportional share of the organizations assets
- It should be possible to restrict exit actions based on whether the individual had voted yes in a pending proposal.
- New members should be able to propose a payment to the organization in exchange for the organizations tokens
- Proposals should require the proposer to lock tokens in order to ensure that the incentives of voters are aligned with their votes
- Users who choose to vote no, or not vote, should be able to see whether a proposal has passed before deciding to exit.
We expected this to be fairly straightforward, but it turns out that in order to make the design work well we have had to dig into some lesser known features of aragonOS like ACL Oracles that to our knowledge have not been used by any other Aragon apps at this point. ACL Oracles are essentially small helper functions that plugin to Aragon's access control list (ACL) to do more sophisticated permission evaluation. There is some information in this post about how we are using ACL Oracles, but we plan to write a more thorough and general post about how ACL Oracles can be used to make the Aragon Stack more useful. This post will focus on exploring the functionality of each app within the Dandelion org template from a high level. The apps included in the 1Hive Dandelion Org are as follows:
- Token Request
- Dissent Oracle
We will release these apps individually for any Aragon DAO to incorporate as well as in an easy to deploy template that combines these apps to replicate the functionality of MolochDAO on Aragon.
Allows users to manage a list of eligible assets held within an organization's Vault and allows members of the organization to redeem (burn) organization token in exchange for a proportional amount of the eligible assets.
The Redemptions app by itself addresses the first of our requirements. It is similar in purpose to that of MolochDAO's ragequit function, but the logic for whether or not a member can redeem their token is externalized using Aragon's permission system.
Also unlike the ragequit mechanism in MolochDAO, the Redemptions app works with both ETH and ERC20 tokens. An organization can manage an array of eligible tokens and users can redeem for a proportional share of all of these tokens.
This can be useful, as it allows organizations to hold a strategic portfolio of liquid assets, as opposed to only ETH.
If you don't want to deploy yourself, you can also demo the functionality on rinkeby you just need to mint yourself some tokens in the tokens app and then try redeeming them.
Allows users to propose minting tokens in exchange for a payment to the organization, subject to the approval of existing members.
MolochDAO has two proposal types: one where shares are minted in exchange for tribute and another to allocate funds towards proposals. With Dandelion, there are many types of proposals possible depending on what permissions the org has been granted and what apps are installed. With an app like Aragon Agent installed, a Dandelion org can have proposals to interact with arbitrary external contracts.
However, there is currently no way in Aragon for a user to propose minting tokens in exchange for payment, and this is what the Token Request app provides.
We think this will be a huge benefit to the wider Aragon ecosystem even outside of the Dandelion template as it enables a form of permissioned fundraising.
Allows an organization to require users to lock a configurable amount of tokens for a configurable amount of time in order to forward an intent.
In MolochDAO, proposers are required to place a 10 ETH deposit down when submitting a proposal. This deposit is held by the DAO until the proposal is resolved and then return to the proposer regardless of the vote outcome. Since proposals in MolochDAO are queued and processed one at a time, the amount of time the funds will be locked when deposited depends on the number of proposals currently in the queue. This discourages people from extending the proposal queue.
In a Dandelion organization, to avoid tightly coupling the lock app to the voting app we have diverged a bit from MolochDAO's deposit mechanism. With the lock app the amount of time funds must be locked when submitting a proposal is dependent on the number of actions that particular address has submitted within a given time, not on the current number of pending proposals. So the more proposals an individual member submits, the more opportunity cost they face. We think this will work well despite the lock mechanism itself not being sybil resistant, because proposal submission is restricted to existing members and membership is permissioned.
It's worth noting that the lock app could be designed to more closely resemble MolochDAO's deposit mechanism. To do this we would need to initialize it with a voting app address and have the lock time be based on the number of pending proposals in the queue at the time the proposal is submitted. However, we felt that the lock app would be more broadly useful if its anti-spam mechanism was not dependent on a specific voting app implementation and so we opted against this path. If there is demand for this specific implementation, we would consider creating a variation on our lock app to support this behavior.
Allows an organization to require a configurable delay before an action may be executed.
In MolochDAO, after a proposal passes it does not execute for an additional grace period. This period allows for members to become aware of a proposal passing and ragequit.
In both mechanism the delay does not increase the amount of time when members are actually eligible to redeem, if someone voted yes they are only guaranteed the ability to exit for a window of time between the proposal they most recently voted yes on and the time of the proposal that triggered their desire to rage quit. This window will always be at the very end of the delay/grace period, so the delay or grace period should be thought of as a way to ensure that there is adequate awareness of proposals passing before they are actually executed, but users will need to plan to send a transaction within that window.
In our delay app we are also implementing pause/unpause and cancel permissions, which can be useful for supporting other processes. For example an ACL oracle could be used to allow cancelling proposals if the token supply has decreased by a configurable percentage. This pattern of implementing roles to pause/unpause and cancel pending actions will likely be implemented in other voting and approval related Aragon apps to accommodate dispute resolution processes.
An example of a configuration which creates an internal dispute resolution process is as follows: Some permission can be granted to the delay app, and then the ability to forward an intent and pause can be granted to the lock app. Users can perform actions unilaterally by locking tokens, but anyone can pause the intent, and then a vote would only be required to unpause or cancel the action.
Voting and Dissent Oracle:
Tracks and returns whether a user should be able to perform an action based on their recent voting behavior.
In order to effectively address our requirements we will need to fork the existing voting app provided by Aragon One and add some additional functionality. Specifically we need to keep a mapping between an address and the most recent proposal start time where the user voted
yes. We also need to ensure that votes cannot be executed early and that proposal start times can be consistently spaced apart.
We can use the mapping to create a separate app, the Dissent Oracle that implements the ACL Oracle interface. The Dissent Oracle essentially returns true or false and can be referenced in Permissions. The Dissent oracle is initialized with the Voting app addresses and uses the new mapping to evaluate if the user has voted
Yes on a proposal within a configurable time frame (for the dandelion template this will be the
delayDuration, if they have then oracle returns false. We can use this to restrict the
redeem function in redemptions, so that anyone who has voted
yes within that time frame cannot exit.
This mechanism is quite a bit different than how
ragequit is implemented in MolochDAO. In MolochDAO the voting and grace period are connected, and the voting app can track what the highest index of a vote a user has voted
yes on and evaluate whether a proposal has been fully processed based on its index value. In a Dandelion org the voting app is connected to the delay app to create the voting and grace period and these apps are not aware of one another. So instead of relying on index values, the dissent oracle uses time since the last yes vote so that the creator can account for additional processes that happen after the vote passes (like the delay).
The main trade-off here is that in MolochDAO if someone votes yes on a proposal and it doesn't pass then it is considered immediately processed. With a Dandelion Org the user would not be eligible to rage quit again until after the proposals delay period. Both implementations ensure that if a user does not vote yes on a proposal that was created after a proposal which (if passed) would trigger them to exit, they will have an opportunity to exit.
We believe the proposed Dandelion organization template does a good job of replicating the core properties of the MolochDAO mechanism. In addition, Dandelion organizations can easily incorporate apps like Agent and Payroll to be more broadly applied and extended than the original MolochDAO implementation.
We also think that many of the individual components will be useful outside the context of MolochDAO-like organizations, and will prove to be valuable contributions to the Aragon ecosystem.
However, the one area that we really cannot replicate is the simplicity and reduced code footprint of MolochDAO. By implementing as modular components on Aragon, we are explicitly sacrificing this simplicity in favor of flexibility and extensibility. So if you are looking to deploy an instance of MolochDAO exactly as it was originally designed, it may always be the better choice. However, if you like the game theory of MolochDAO but would also like to support other types of proposals or want to have access to the growing library of Aragon apps to extend the organizations functionality, the Dandelion template will likely serve you well.