Customizing Organizations with Aragon CLI 🛠


Currently users of Aragon can choose from creating a Token Democracy organization with one Token and one Voting app instance installed, or a Multi-sig organization with one Token and one Voting app instance installed.

These templates provide a simple on-boarding, but in practice offer limited real world utility. Simply allowing users to install/deploy new instances of applications to their organization would massively increase the utility of Aragon for end users.

Eventually the app center will offer this functionality, but right now a much shorter term solution is to use the CLI. The CLI has so far only been used for the purpose of aiding developers to build third party applications, but this functionality could be polished a bit to enable power users to unlock significant utility and functionality that currently exists at the contract level but has not been exposed through the UI. Even if the the UX is too complicated for the average user, this will enable more technical users that are not necessarily developers and motivated early adopters to start leveraging the more powerful features of Aragon immediately.

The gap between functionality in the CLI to enable these users versus the gap in functionality in the UI is significant, and getting the CLI updated to support this use case in the near term would enable us to experiment with real-world use cases such as running a cooperative organization (as suggested by a community member on the forum), or a meritocratic reputation driven organization (which most of our community members probably are unaware is possible with 0.6).

These use cases are not rigid configurations that we can easily create a kit for, but rather built on specific configurations and compositions of permissions and the token manager and voting applications–and we don’t really know exactly which combinations or even if a single one-size fits all combination (without the possibility to install and reconfigure apps) would ever be particularly useful. Therefore rather than focus on creating new onboarding templates, or one off-custom kits, we should focus on enabling motivated users to either install different combinations of apps or get help from a more technical community member to help them get started.

We should also prioritize and support community initiatives like Aragon Cooperative that seek to engage the Aragon Community and dogfood the product!

In order to get there I’ve taken the initiative to try and create the Aragon Cooperative organization using the Aragon CLI and have run into a number of hopefully minor challenges.

Shareable Deployment Scripts

With this approach, rather than creating a full daokit/template and onboarding experience a custom configuration can be shared and modified using a much simpler deployment script. These scripts would not require deep understanding of solidity or web3 deployment processes to get up and running as they would essentially take the form of a shell script. The following is a very simple example of a script that could be used to create a “blank slate” DAO and then install the vault application.



aragon init ${NAME} bare
cd ${NAME}

aragon dao new | tee ${TMP_FILE} DAO=$(grep "Created DAO" ${TMP_FILE} | cut -d ':' -f 2 | tr -d '[:space:]')

aragon dao install ${DAO} vault | tee ${TMP_FILE} VAULT=$(grep "Installed" ${TMP_FILE} | cut -d ':' -f 2 | tr -d '[:space:]')

Required CLI improvements/bug fixes

Currently not possible to use the CLI without initializing an App project

Currently the CLI throws Error: This directory is not an Aragon project if the Aragon CLI is used outside of an Aragon App Project directory.

Since aragon dao [command] can be used to interact with a DAO which has been deployed on Rinkeby or Mainnet using Frame as a signing provider, It should be possible to deploy a DAO either from the command line or from the onboarding ui, and then interact (adding new apps, changing permissions, executing actions) from the CLI, without initializing an app project.

Github: 294

Token Manager Install Catch-22

If you setup a local RPC instance and wish to deploy a new token manager into a DAO there is a catch-22. The token manager cannot be initialized unless there is a deployed minime contract with the token manager’s address set as its controller and you cannot deploy the token manager (and get its address) without initializing. :man_shrugging:

Allowing the user to deploy applications and then initialize them with a separate command would resolve this issue.

Github: 295

Minime Deployment from CLI

If you want to deploy a token manager app, it depends on having a Minime token. However, there is no option from the CLI in order to deploy this dependency. For a developer who is familiar with deploying arbitrary code this would be a minor annoyance as it would require them to deploy the Minime token separately–but for a power user who understands Aragon Apps but isn’t an experienced solidity developer this is a blocking issue.

I recommend providing an option for deploying minime token instances using the CLI.

Github: 296

Permissions are inaccurate

After installing an app from the CLI the application’s permissions indicate both the applications Roles as having Any Entity set as their Allowed Entities and their Manager.

This is confusing (and inaccurate) as any entity cannot manage the role, and any entity cannot perform the action.

Github: 297

Permissions cannot be created

After installing an app from the CLI the permissions must be initialized using dao acl create [dao] [app] [role] [entity] [manager] however this command fails when trying to set the [entity] and [manager] to the the account which the CREATE_PERMISSIONS_ROLE with the error Cannot find transaction path for executing action.

Github: 298

Ideas for Improving Onboarding and Useability of Alba (Aragon 0.6)

I’ve been thinking more about the Space Decentral DAO today, and how it would be great to start using Aragon for assigning non-transferable tokens to community members so we can start to decentralize operations more and grow.

These feature requests mentioned here would be really valuable, because I am currently seeing Space Decentral as having child-DAOs and hence needing multiple Token Manager instances.


This should be possible as soon as a couple of PRs will get merged. The status can be tracked here: