Bringing app installation to the Aragon client

Status quo

Currently installing apps into existing DAOs is quite an involved process. The official solution for app installation is to follow a guide that shows how to do it using the aragonCLI. While installing apps using the CLI works, there are some challenges that are specially painful when doing it into a real, live organization.

Installing apps is a multi-step process. With the most basic instance, requiring an interaction with the Kernel (newAppInstance) and creating at least one permission in the app (otherwise the app isn’t considered installed in the organization). Installing a particular app that needs to work in a specific way may have an even more complicated process, specially if the organization doesn’t have a default permission structure, as it may require even more actions.

In a live organization, all of these actions should require passing a vote or pass some other process. The permissions required to perform those actions are too critical to be held by just one person (with those permissions unparametrized, someone could take over the entire organization). Some of these actions to install an app cannot be executed in parallel, requiring one to be executed after the previous step has been performed and some installation processes can open up attack vectors if not done atomically.

In aragonOS 3, we implemented the concept of the DelegateScript executor that could have been very useful for installing apps. Due to some concerns brought up during the audits and our inability to keep them while guaranteeing some needed security guarantees for that approach, we decided to drop them from aragonOS.

In this post, I propose a way to do complex app or app bundle installation into existing organizations, minimizing the governance overhead. If an installer exists for what needs to be installed, no matter how complex the installation is (think installing 20 app instances), it should only require one approval from the organization’s governance mechanism that can execute installers. This post builds on many ideas discussed in the past like Pierre’s “Should templates be apps?” and the attempts to build a ‘DAO engine’ for making templates more modular.

Architecture: Installers and the AppCenter app

An AppCenter app (looking for better names here, please suggest!) is installed into the DAO and it needs to be assigned the following permissions:

  • MANAGE_APPS_ROLE in the organization’s Kernel
  • CREATE_PERMISSIONS_ROLE in the organization’s default ACL
  • In order to make the AppCenter app more convenient, a change could be made in the ACL to allow an entity to be the ‘permission manager root’ (as discussed briefly in this issue). This would grant an entity ability to assign or revoke any permissions without being the permission manager for the permission.

Installing this app into existing organizations posses a bit of a chicken-and-egg problem (unfortunately we cannot use the AppCenter app to install itself), but it could be done in just two votes in most organizations (unless permission management for MANAGE_APPS_ROLE and CREATE_PERMISSIONS_ROLE have been changed from the template’s default): one to install the app and another one to grant it the necessary permissions and assign permissions for using the app.

Once installed, the app would allow to run installers that can install one or multiple apps with just one authorization process (a vote in most cases), initialize these apps in a particular way given some parameters and change many permissions in the organization atomically. If an installer cannot be run in just one transaction due to gas limitations, multiple installation steps can be authorized with a single vote and these steps can then be run without further authorization at any time.

Installers are run in the context of the AppCenter app instance with a delegatecall. Performing a delegatecall to an untrusted contract is really dangerous, specially if the target of the call were to selfdestruct. In this case, a selfdestruct would be the best thing a malicious installer could do, as it would prevent it from doing other malicious things in the DAO. We should be really careful in how we display information about installers, warn users when using non-curated installers and clearly explain the consequences of executing a certain installer.

Installers could be published to aragonPM as their own package (since there won’t be a one to one relationship between apps and installers, many installers could install one app in different ways or with other apps as companions) and even perhaps have a simple frontend in the package that can be used to parametrize the installer.

From the client’s perspective, adding support for it would be as simple as providing an interface to find curated installers (or input the address of an installer) and allowing to parametrize the installation.

I wrote an example prototype installer for Agent, which installs Agent into an existing organization and grants permission to execute actions with the Agent instance to a number of entities:

contract AgentInstaller is InstallerBase {
    bytes32 internal constant AGENT_APP_ID = 0x00;
    bytes32 internal constant AGENT_EXEC_ROLE = 0x00;
    function install(address[] calldata allowedExecutors, address permissionManager) external onlyInit {
        IKernel dao = kernel(); // it is running in the context of the AppCenter app, so we can get the Kernel
        IACL acl = dao.acl();
        Agent agent = Agent(address(dao.newAppInstance(AGENT_APP_ID, getBaseFromAPM(AGENT_APP_ID), new bytes(0), false)));
        for (uint256 i = 0; i < allowedExecutors.length; i++) {
            if (i == 0) {
                acl.createPermission(allowedExecutors[i], address(agent), AGENT_EXEC_ROLE, permissionManager);
            } else {
                // Even if the installer is not the manager, AppCenter is 'permissionManagerRoot' in the ACL (to be implemented)
								// so it can grant the permission regardless
                acl.grantPermission(allowedExecutors[i], address(agent), AGENT_EXEC_ROLE);   

Here is a full POC of the idea in Solidity:

Evolving templates

Using this idea of installers and the AppCenter app, we can also change the way templates work and make them easier to build (or for most cases even not necessary) by leveraging installers.

A basic template could deploy the DAO and install the minimum number of apps for a basic DAO and to allow the AppCenter to run. After this basic DAO is set up, the template could then just execute any needed installers need to get the DAO to the desired initial state. The advantage of this, is that anything that can be installed with a template would also be available for existing organizations to install.

Bonus: Aragon app monetization

Installing Aragon apps into an organization is completely free and using them is free as well. At the moment, there is no clear incentive for a developer to build an Aragon app other than needing it themselves or being paid to build the app by Aragon.

Something that installers could also allow is for app developers to provide an easy way to install their apps into organizations paying a small up-front fee, very similar to the Apple AppStore model.

Because installers run in the AppCenter app context, they are able to transfer funds out of the app if there are any. Prior to running an installer, the required fee could be transferred from the Vault (this could happen in the same vote), or the organization could decide to transfer a certain amount of funds to the AppCenter to pay for installations when needed.

Users would still be able to freely deploy apps manually and the installers could be forked and the fee removed, but these forked installers would likely not be added to the curated installer list (and appear as secure and vetted).

There has also been discussion in the forum last week about creating incentives for building apps that are actually used, and installers could be an easy way to log when applications have been installed in an organization. It would also allow for less gameable mechanisms (as Kernel events are really easy to game), in which in order for an installation to be counted, a certain amount of ANT needs to be locked for some time or a fee must be paid to the developer.


As a legacy Aragon user, this is my #1 desired feature. I would like to use it to install the Agent app.


For the record, an alternative flavor to this idea could be to write the installation scripts at the API level, instead of in Solidity.

The following sample uses new “encode” cli commands to blundle calls to newAppInstance and createPermission in an EVM script. Then, the script is passed on to a vote. Upon vote approval, a Finance and a Vault app are installed and set up.

We’ve already seen something similar in vote #48 of the association board:

An advantage of this method would be that there are no Solidity limitations involved, like the kind we experience with kits/templates, such as stack too deep errors. A disadvantage I can imagine is that this is less explicit and harder to trust than a smart contract. Also, I don’t know if this performs multiple external calls and ends up spending too much gas.