Aragon Nest Proposal: Dandelion Orgs 🌼

Abstract

1Hive is interested in exploring how smart organizations (DAOs) can help open source communities better reward and attract contributors. We believe Aragon is the best platform to build on because of the rich ecosystem of existing applications available to Aragon smart organization.

Recently new governance mechanisms have been experimented with by Moloch DAO and its forks in a new, standalone smart contract with some early signs of success, and we believe we can make these mechanisms even more valuable to users by implementing them as modular and composable Aragon apps.

We propose breaking the monolithic Moloch concept into the following modular Aragon apps:

Redemptions: Allows users to manage a list of eligible assets held within an organizations Vault and allow members of the organization to redeem (burn) organization token in exchange for a proportional amount of the eligible assets.
Token Request: Allows users to propose minting tokens in exchange for a payment to the organization, subject to the approval of existing members.
Lock: Allows an organization to require users to lock a configure amount of tokens for a configurable amount of time in order to forward an intent.
Delay: Allows an organization to require a configurable delay before an action may be executed.
Dissent Oracle: Enhances the voting app to implement an ACL Oracle which allows an organization to configure permissions that restrict actions to only members which have recently voted Yes.

These applications can be combined with the existing Vault, Finance, and Token Manager apps to create an organization template based on the fundamental mechanism and game theory used in Moloch. But unlike Moloch, this organization could easily be extended by incorporating the task management and issue prioritization capability of Autark's Projects and Dot Voting apps or implement streaming payments via Aragon One's upcoming Payroll app. We call this variation on the Moloch concept, Dandelion Orgs, as they can quickly grow by adding members and capital, but in the event of a contentious decision disperse just as rapidly.

Besides being useful as a template, the individual applications can complement other organization patterns as individual components:

The CFDAO has a known vulnerability to spam attacks, and the Lock app could be a drop-in solution that would significantly increase the cost of such an attack.
The Delay app could be used to implement optimistic operations within an organization, where members can take actions without requiring a vote, but they can be paused by other members, and canceled via a vote. The delay app would also adopt the same interfaces as the voting app so that it will be compatible with Proposal Agreements.
The Token Request application can be used to provide permissioned fundraising capabilities.
The Redemptions app establishes "exit rights" and enables organization's tokens to have a clear baseline valuation based on a claim on the organizations underlying liquid assets.
The Dissent Oracle could provide better voting incentives particularly when combined with an application like Redemptions or Aragon Black's upcoming Fundraising application which guarantee some sort of exit.

Beyond simply extending the library of Aragon apps, this proposal intends to highlight the value and network effect associated with a modular and composable platform like Aragon.

From the 1hive perspective, we have been eager to get started and have gone ahead and implemented the Redemptions application and deployed to Rinkeby. If you'd like to try it out you can do so in our Rinkeby demo org. We've also completed some basic feasibility research and have documented how we intend to implement the remaining apps. { Token Request, Lock, Dissent Oracle, Delay }

Deliverables

Aragon Apps

Redemptions
Token Request
Lock
Dissent Oracle
Delay

Organization Templates

Dandelion Org Template

Documentation

Each application will include documentation on how the organization can be deployed, and how to interact with it.

Grant size

Funding: 100k DAI

$15k for each Aragon App (Main-net)
$10k for Dandelion Org template and onboarding site (Main-net)
$15k budget for audits and bug bounties

Success Reward:

$30k ANT

Development timeline

We estimate needing approximate 1 month to deliver each App, though we plan to do some development in parallel, and conduct audits all at once. We expect to be able to deliver everything to main-net in approximately 5 months.

Hey there,

Thanks for coming up with this proposal! Great to see how it leverages and enriches the composability of already existing Aragon Apps.

First a few questions:

About the Redemptions app: as long as we remember the Fundraising App developed by Aragon Black should have a similar mechanism to redeem bonding curve tokens in exchange for pool assets. Does development effort with Aragon Black overlap here? If so, will you use the already code/spec?
About the Token Request app: I am wondering how different this system is from just asking to withdraw tokens from the vault or creating a vote to mint tokens through the token manager app?
Do you plan to implement UIs for each of the 5 apps? Asking especially for the Delay and Dissent Oracle apps as its not specified in their current documentation. For the Token Request app, you say that you do not see a UI as necessary to change the app parameters and that CLI would be enough, why? Eager to understand the reasoning behind these choices.
Do you have a paper detailing how the different apps would work together to recreate the Moloch DAO setting? This one is more driven by curiosity

Overall this proposal is abundant in terms of new features, which is a good point. The Lock app as an anti spam system, the Dissent Oracle App and the Delay App all sound like powerful additions to enrich already existing governance tools in Aragon DAOs. We also appreciate your anticipation of the audit and app documentation, these are great practices.

Looking forward to clarifying the different points above.

About the Redemptions app: as long as we remember the Fundraising App developed by Aragon Black should have a similar mechanism to redeem bonding curve tokens in exchange for pool assets. Does development effort with Aragon Black overlap here? If so, will you use the already code/spec?

The redemptions mechanism is fairly different (and complimentary) to Fundraising's bonding curve mechanism. The bonding curve acts as an automated market maker, offering to exchange reserve assets based on a market price, the offered price times the outstanding supply equals the tokens market cap, however, as people buy/sell against the curve the price offered will change. In contrast redemptions allows organizations to imbue tokes with a right to claim a proportional share of assets the organization holds. All token holders could choose to redeem at the same time time and it would not impact the exchange rate for any of the token holders, because order doesn't matter. The two apps could be used together to provide a meaningful link between the bonding curves reserve and the discretionary pool of the org, effectively creating a price floor for the bonding curve based on the discretionary pool assets.

About the Token Request app: I am wondering how different this system is from just asking to withdraw tokens from the vault or creating a vote to mint tokens through the token manager app?

There is a big difference in the trust model of an atomic transaction versus a sequential transaction. You could replicate the functionality of the token request by depositing funds into the finance app and then minting tokens in the token manager... but either the person making the request must deposit the funds first and hope the organization will mint them tokens later, or the organization must mint tokens first and hope the new member subsequently deposits tokens. The token request app allows this type of interaction to happen without either party taking on this risk.

Do you plan to implement UIs for each of the 5 apps? Asking especially for the Delay and Dissent Oracle apps as its not specified in their current documentation. For the Token Request app, you say that you do not see a UI as necessary to change the app parameters and that CLI would be enough, why? Eager to understand the reasoning behind these choices.

In generally I don't think creating UIs for changing parameters is the highest priority, parameters should not change frequently, and when they do it is fairly reasonable to expect the person initializing the change to have an understanding of interacting with the contracts via the CLI. While a UI for this would be a nice to have, and we could potentially include it, I wouldn't make it a requirement simply because it would potentially delay being able to realize the core utility of the applications. This pattern of making parameter changes only possible via the CLI is present in applications like Voting and Finance already, so given it hasn't been a priority to expose these in the core apps, it doesn't seem like it should be a priority to expose them here.

The dissent oracle will be implemented by forking the existing voting app and adding additional logic and implementing the oracle interface. Users would install the dissent-voting-app and use it as they would the standard voting app, but they would be able to use the dissent oracle as a parameter when configuring permissions. Right now there is no easy way to create permissions with parameters (either in the CLI or in the permissions app ui), our assumption is that setting these permissions is likely to be a more advanced option and focusing on enabling this functionality within the CLI and simply exposing in the permissions app that permissions has parameters associated with it in the permissions UI. The Delay app will have a UI, similar to the voting app, allowing people to see actions which are pending and execute them after the delay has occurred. It will also provide roles for pausing and cancelling.

Do you have a paper detailing how the different apps would work together to recreate the Moloch DAO setting? This one is more driven by curiosity

Are you thinking a document which compares and contrasts the dandelion org template with that of moloch? This is not something we have directly (beyond what is described here), but could be put together.

Hello @lkngtn,

The two apps could be used together to provide a meaningful link between the bonding curves reserve and the discretionary pool of the org

Interesting! In this case the token used for both app would be the same I guess?

There is a big difference in the trust model of an atomic transaction versus a sequential transaction.

Thanks for clarifying.

This pattern of making parameter changes only possible via the CLI is present in applications like Voting and Finance already, so given it hasn't been a priority to expose these in the core apps, it doesn't seem like it should be a priority to expose them here.

Don’t you think that in the long run it would make sense to limit the need to use the aragonCLI to the most heavy and specific use cases? Casual DAO users may want to update parameters frequently in order to find the right tuning as they discover how their DAO’s app dynamics play out. In the latter case, accessing parameters through the UI seems to be the most frictionless option. Now of course, that’s up to you to assess if implementing a UI is worth considering according to your target users. If quantifiable, eager to hear about the effort you think this would require?

I’m less sensitive about having to use the CLI for the Dissent Oracle parameter as I feel the use case is already more specific and destined to more advanced users.

Are you thinking a document which compares and contrasts the dandelion org template with that of moloch?

Indeed, we were curious to learn more about the main app workflows that would take place in Dandelion Orgs compared to the traditional Moloch DAO implementation. We will not request it for the application but it could be a useful read.

Let’s clarify these few points and we should be able to approve the proposal for a RFF!

Interesting! In this case the token used for both app would be the same I guess?

Correct, in this scenario both the bonded token and the token used to redeem would be the same.

Don’t you think that in the long run it would make sense to limit the need to use the aragonCLI to the most heavy and specific use cases? Casual DAO users may want to update parameters frequently in order to find the right tuning as they discover how their DAO’s app dynamics play out. In the latter case, accessing parameters through the UI seems to be the most frictionless option. Now of course, that’s up to you to assess if implementing a UI is worth considering according to your target users. If quantifiable, eager to hear about the effort you think this would require?

Longer term definitely, we should make pretty much everything accessible from the UI... My reasoning is more around short-term prioritization. It feels more important to get things out and available to users asap, then to spend time working on exposing rarely used functionality in the most frictionless experience possible.

I'm also not sure what that experience should look like, personally I think it might make sense for there to be an Aragon client standard for exposing application settings (think how you go to a settings app in iOS to adjust most application settings rather than going to the app itself). But I would not want to include something like that in the scope of a grant like this (it would require lots of coordination with flock teams, and create dependencies on A1 which maintains the client).

We could potentially create a simple UI for settings on a per app basis, like has been done for Autarks Projects app... but I would worry that down the line this would just need to be redesigned and re-implemented.... Given the state of things like the app center, in order for users to really tweak settings and experiment they will (atleast for the time being) need atleast one member to be comfortable using the CLI--so I don't think that having the UI for this would really enable more experimentation than would be possible without the UI.

Anyways, if you feel like it's critical for the grant to include a setting UI as part of the deliverables, we can discuss how that impacts our scope and go from there. Let me know what you think is best. :)

The two apps could be used together to provide a meaningful link between the bonding curves reserve and the discretionary pool of the org, effectively creating a price floor for the bonding curve based on the discretionary pool assets.

Perhaps what you are wanting to do is split the assets between a bonding curve pool and a discretionary pool. Then simply require any investment in the DAO to be split into a proportion going to the bonding curve pool, and a proportion going to the discretionary pool. For example, for an early-stage startup a .1:.9 split would be fitting, whereas for a mature startup a .5:.5 split would be fitting (thanks @proofoftom). This matches @burrrata's idea here (curve = bonding curve pool, community vault = discretionary pool), @themathematicianisin's idea here, and my idea here, which I've combined here.

Perhaps what you are wanting to do is split the assets between a bonding curve pool and a discretionary pool.

No this is not the intention because this is functionality that belongs (and exists) within then fundraising app already. You may be interested specifically in the fee percentage functionality.

This is not actually relevant to the interaction with Redemptions as far as I can tell. As Redemptions doesn't care how assets get put into a specific vault, just that they are there. The relationship between the fundraising apps bonding curve and the redemptions app is that if you have the same token used for both, the token holder has the option to either exchange the token for assets via redemptions OR exchange it for bonding curve collateral via fundraising. The bonding curve acts as an automated market maker and so the price can change, but with redemptions there is an arbitrage opportunity that exists if the price offered by the automated market maker dips bellow what would be available from redemptions.

I'm also not sure what that experience should look like, personally I think it might make sense for there to be an Aragon client standard for exposing application settings (think how you go to a settings app in iOS to adjust most application settings rather than going to the app itself). But I would not want to include something like that in the scope of a grant like this (it would require lots of coordination with flock teams, and create dependencies on A1 which maintains the client).

Given the state of things like the app center, in order for users to really tweak settings and experiment they will (atleast for the time being) need atleast one member to be comfortable using the CLI--so I don't think that having the UI for this would really enable more experimentation than would be possible without the UI.

We get your points here. It would be nice to chat about that at the Flock level indeed. Do you think it would be a relevant topic to bring up on Aragon All Devs? It might help determine the best time to prioritize this kind of standard.

We're going to approve this proposal and are looking forward to seeing a RFF from the Dandelion Orgs team!

This is not actually relevant to the interaction with Redemptions as far as I can tell. As Redemptions doesn't care how assets get put into a specific vault, just that they are there. The relationship between the fundraising apps bonding curve and the redemptions app is that if you have the same token used for both, the token holder has the option to either exchange the token for assets via redemptions OR exchange it for bonding curve collateral via fundraising. The bonding curve acts as an automated market maker and so the price can change, but with redemptions there is an arbitrage opportunity that exists if the price offered by the automated market maker dips bellow what would be available from redemptions.

Ah thanks for clarifying. So there's a fundraising apps bonding curve, a fundraising apps fee percentage, and a redemptions app.

We get your points here. It would be nice to chat about that at the Flock level indeed. Do you think it would be a relevant topic to bring up on Aragon All Devs? It might help determine the best time to prioritize this kind of standard.

Definitely. I think it could be worth bringing it up, though I'm not sure it should be a high priority to address until after its is possible to install and uninstall apps in the UI from the App Center.

We're going to approve this proposal and are looking forward to seeing a RFF from the Dandelion Orgs team!

Great, The PR for the RFF has been created. 💙

Closing as this has been approved and no longer requires attention.

aragon / nest