Introducing aragonOS: Say hi to modular and extendable organizations

Aragon’s new exokernel-inspired architecture

The advent of decentralized organizations will create new forms of human coordination that we cannot even grasp yet.

Therefore, our success as a project will come from being able to support many different types of organizations, from a small consulting firm to a decentralized meme market.

Decentralized governance is getting a lot of attention lately, and while interesting models are starting to emerge, we are still in the early days of its development. For the first time in history, we will be able to experiment with different human governance models from the comfort of our chairs. In previous eras, trying out new governance models could end up very badly for society, even with wars or human catastrophes.

We want to be the key component that lets us all experiment with new governance models that make the world a more fair and efficient place.

In the process of developing our latest release, we found several shortcomings that needed to be addressed. Some components such as bylaws or voting were too tightly coupled with building of traditional organizations on Aragon.

We realized that we needed to make some changes in the architecture of our smart contract systems to allow more flexibility and to make it easier for third party developers to extend the functionality in the future.

For those interested in a more technical and detailed document about aragonOS, you can find the full documentation in our Wiki.

The new architecture

aragonOS smart contract architecture is based on the idea of an organization being the aggregate of multiple components (called applications) and a pillar that is the Kernel, which governs how these applications can talk to each other and how other entities can interact with them.

The core of all organizations, the Kernel

The Kernel acts as the coordinator of all the components in the organization.

It has been kept as small as possible, providing only two main features, upgradeability and authorization.

Upgradeability

Smart contract upgradeability is a topic we spend a lot of time thinking about at Aragon. We need to ensure that the organizations that run Aragon will be securely available for years to come. To achieve that, it is essential to provide a way for upgrading every component in an organization, including the Kernel itself.

The Kernel is able to both upgrade itself (the upgraded Kernel could remove the ability to perform further upgrades) and other apps relying on it.

This is made possible thanks to what we call DelegateProxies. A delegate proxy is a very thin contract that, instead of containing business logic, delegates its logic on to another contract. Given that the reference of the other contract can be fetched dynamically, using this construct, the underlying logic of the contract can be changed.

Authorization and the Access Control List

One of the beauties of Ethereum is that an address can represent anything. From a 12 year old kid on the other edge of the world, to an AI, or even your refrigerator! From a technical point of view, an address can represent any smart contract which can encode arbitrary logic.

Taking advantage of the fact that an address can represent anything, our Access Control List (ACL) can simply be based on keeping track of whether a particular address has permission to perform a set of actions. This enables us to push complex authorization logic outside of the Kernel.

Two examples of this are:

• Instead of having the notion of groups of entities (e.g. employees of an organization) baked in the ACL, a separate Group contract can be created that performs actions as someone in the group wants to. The Group contract is responsible for keeping track of all its members.
• More interesting authorization mechanisms such as a democracy can be implemented this way too. A Voting contract only performs actions when a vote has successfully met its requirements and has been approved.

When designing an open authorization system that will be used to customize many kinds of organizations, a balance between security and usability must be made. On one hand it is important that new permissions can be added or modified, but on the other hand we want to protect against dangerous scenarios. Scenarios in which a permission to perform a destructive action can be modified too easily. Even if the action is the same (just grant this one permission to another entity), the context of which permission is being acted on is a decisive factor.

We ended up making a system which allows explicitly setting who can modify or revoke permissions for every action. This feature allows for some permissions to be easily granted or modified, while at the same time keeping permissions over important actions very hard to change.

Applications, right in your organization

Applications are smart contracts that can be added to an organization taking advantage of the Kernel's ACL and upgradeability features.

All relevant business logic (except for authorization which is concentrated in the Kernel) lies at the Application layer. Applications are also entities that can perform actions on other applications, such as the Voting app.

An example of two important applications with an interesting interaction is the one between the default Finance and Vault apps. The Vault app holds and manages the organization's assets (tokens). Given that the Finance app has been granted permission to transfer tokens that are held by the Vault, the Finance app is able to transfer tokens when needed, but doing so with its own specialized logic that keeps track of budgeting. By keeping them as distinguished apps, it allows for disabling the Finance app in the case that it's leaking funds, just by removing the permission of the Finance app to access the Vault. Another advantage is that any other apps that require access to funds can also use the same Vault in the organization.

We have built an initial set of default applications that can be used to manage organizations. However the full potential of Aragon will be unleashed when third party developers start building custom apps on the platform.

Apps that can be built on top of Aragon range from different voting mechanisms to economically incentivized project management tools. We can't wait to see all the different kinds of apps that the developers will come up with.

Current state of aragonOS

We have implemented the Kernel and six default applications that can be used as the basis for some organizations. All the code is open source and can be viewed and assessed in the aragonOS repo. We are still in the midst of polishing some aspects, but will start looking into external audits to the codebase soon (we'll publish details on the audits next week).

We have the full documentation for aragonOS in our wiki. It is not a final version and we will be making changes and keep on improving it. Feedback is more than welcome!

Does everything above sound like an interesting challenge?

We are currently hiring experienced Solidity developers to help continue building out Aragon. You can check the openings here!

And if you're not into Ethereum programming, we are also looking for people for some other technical and non-technical roles, check out all the job openings in the Jobs section of our new Wiki.