Introducing aragonOS 5: Disputable apps

August 26, 2020

aragonOS has come a long way since its last major release in October 2018.

Two years later, it now secures more than $300M and 1500 on-chain organizations on Ethereum’s mainnet. Over fifteen Aragon apps, built as composable “governance Legos” to be plugged into aragonOS, have launched on mainnet and provide these organizations with unparalleled flexibility. Hundreds of active projects now rely on these core contracts as a dependency.

While we were proud of how far aragonOS has taken us thus far, we couldn’t help but continue researching where to take it next. After months of tinkering, we’re excited to announce aragonOS 5 together with our technical vision of how Aragon organizations will soon be able to opt into the security offered by Aragon’s emerging digital jurisdiction, Aragon Court.

Integration with Aragon Court: Disputable Aragon apps

As many of you know, considerable effort has gone into Aragon Agreements for the push towards the Phoenix phase of the Aragon Network. Agreements are the mechanism that will enable organizations to define acceptable actions with a subjective set of rules, which would otherwise be impossible to encode into a smart contract. It will act as the bridge between an Aragon organization and Aragon Court, providing organizations with the substantial new capability to challenge members' actions and raise them as disputes to Aragon Court.

We’ve designed Agreements as a general framework to allow any Aragon app to become disputable. This means the Agreement itself won't allow users to dispute actions in their organizations but instead can be linked with compatible apps such that the actions in those individual apps can become disputable. For example, one could build a disputable voting app whose ongoing votes can be disputed based on the Agreement’s rules. Another example is a registry app, whose entries could be challenged if they don’t abide by the Agreement.

Agreements framework diagram

This introduces a new flavor of Aragon apps, connected to Aragon Court, whose actions can be subjectively governed by an arbitrator—Aragon Court, for example.

One of the most important new pieces is the IAgreement interface. This component has two main responsibilities: on one side, it acts as a shared registry for disputable apps to register potentially disputable actions. On the other side, it hides the complexity of dealing with an arbitrator so it's easy to integrate. In order to enforce this, we also introduced a new flavor of Aragon app called DisputableAragonApp. This component provides the base communication logic with IAgreement-like entities.

Quality of life

1. Forwarding interfaces

A second major upgrade is related to the forwarding interface and was partially motivated by our work developing the disputable framework. We realized that it was relevant and mandatory for every action created from a disputable app to have additional contextual information attached.  Therefore, we introduced the concept of IForwarderWithContext, a forwarder that allows additional information to be provided when forwarding an action.

We took the opportunity to update our internal contract architecture to better support the different flavors of forwarding interfaces now available along with this change.

2. AragonApp interface

IAragonApp was introduced with the idea of defining a common but simple interface across all Aragon apps, making it easier for off-chain tooling and UIs to detect Aragon organizations and apps.

3. ERC165

A final introduction was the addition of ERC165 identifiers for some of the core components of aragonOS. This change was also partially motivated by the disputable framework's introduction, with ERC165 identifiers now available for IDisputable and AragonApp.


The past two years have made it painfully clear to us that aragonOS was not originally packaged well for npm. It often took minutes and gigabytes of hard drive space, not seconds and kilobytes, to install and use the contracts or ABIs from aragonOS in your project.

We’ve taken the opportunity to reduce what is publicly exposed from the @aragon/os package, so the install is much lighter than before. To achieve this, we’ve stopped exposing all non-contract related files, including tests, configuration files (including the Truffle configuration!), and deployment scripts.

It is also worth mentioning that we have migrated the aragonPM contracts away from aragonOS and into its own separate repo. This was always a periphery system built on top of aragonOS, rather than directly integrated, and splitting it out allows us to decouple the two sets of contracts.

We are delighted to announce aragonOS 5’s upcoming release. If you would like to take a look at the code in detail, feel free to jump into the release candidate. The code is frozen and currently being audited by Coinspect—stay tuned because we will do our best to publish the release with updated technical documentation as soon as possible!

The first implementation of an Aragon organization using aragonOS 5 and Disputable Voting will be the recently announced Aragon Network DAO. You can read more about its technical details in this blog post

An important note about this upgrade is that even though we considered doing an upgrade of the solidity compiler version that aragonOS uses, we decided to stay with 0.4.24 to reduce our changes' surface area. However, we are continuing to investigate opportunities to bump into a newer compiler version in the future.