An overview of each committee created, showing information and data about it, such as name, description, members and general data of the token and voting, in addition to the possibility of adding new members.

There exists the possibility to manage the committee’s permissions, either to create them or to delete them. They are divided into two categories:

• Group permissions: To execute actions with these permissions, the committee token is required and a vote is taken in which all committee members participate
• Individual permissions: To execute actions with these permissions you only need to have the committee token.

Event history of all actions performed by committee members, whether with individual or group permissions. In this way, you have a better idea of what is going on within the committee and what has been done.

Finally, it is necessary to mention the permissions that Committees have, which allow us to control who or what accesses the application’s functionalities: 

• CREATE_COMMITTEE_ROLE: Permission to create a committee.
• MODIFY_INFO_ROLE: Permission to modify a committee.
• DELETE_COMMITTEE_ROLE: Permission to delete a committee.
• MANAGE_MEMBERS_ROLE: Permission to add/delete committee members.

The practical scope of the use of Committees is wide. Below we further explain  the functionalities by means of examples and the other applications of Aragon previously described.

Let’s suppose that there is an application called Admissions where individuals can upload admission applications that are processed by the organization to decide whether or not they can join the DAO. The application has a permission called MANAGE_ADMISSION, which allows the entity that has it (either another Aragon application or an individual) to accept or reject applications. 

In addition, let’s suppose that there is a DAO that follows the governance scheme below:

The DAO has four applications: Voting, Token Manager, Committees and Admissions. 

Every member of the DAO has a token called APP, which is created by the Token Manager and allows them to create or participate in voting in the Voting app, which upon approval means they can create, modify or delete committees, and add or remove members. This is because the Voting app has all the permissions of Committees, so you can access all its features. 

To add a new member to the DAO, all you have to do is create an APP token, which can be done by the Admissions application with the permission of the DAO token manager.

We want to speed up the process of managing new participants by creating a committee called Membership that is responsible for accepting or rejecting candidates by analyzing their applications for admission. We could configure the permissions in the following way:

In this section we will comment on some of the technical aspects that we consider to be the most interesting and that have been highlighted during the development of Committees:  

1. Dynamic installation of Aragon applications: Instantiating and dynamically deploying Aragon applications such as Voting or Token Manager every time a new committee is created is one of the innovative aspects of the application.  Not only because it has never been done in any other Aragon application, but also because it takes full advantage of the framework’s capabilities, allowing the creation of more complex governance models. Next we can see the role of the Committees’ smart contract in charge of creating and configuring the permissions of the new committees’ applications:

The Smart Contract receives as parameters everything necessary to create a committee and returns the addresses of the two new applications deployed (Voting and Token Manager) that constitute the new committee. It uses two important smart contracts offered by the aragonOS module:

• Kernel: exposes functions that allow us to install new applications without having to worry about all the logic related to the deployment and version management of your smart contracts
• ACL: short for Access Control List. This contract is in charge of managing permissions and exposes functions that allow us to create, grant and revoke permissions.

To further simplify the process an ancillary contract was created containing functions that call the Kernel and ACL to create and configure the Voting and TokenManager permissions. In the code shown previously we can see these functions, which are all those that start with an underscore.

2. Dynamic subscription to events from other applications: Because Committees install a Token Manager and Voting for each new committee, you need to listen to those applications to maintain proper committee status. We have used a pattern that can be found in different Aragon applications that allows us to listen to or subscribe to external smart contract events (both old and future) to update the status of our application. Using certain functionalities of aragonAPI and RxJS (JavaScript library for reactive programming) we have extended the pattern so that you can dynamically listen to events from each new application you want to instantiate. In this article, David Llop explains the pattern in more detail.
3. Managing permissions within an Aragon application: Creating, granting or removing permissions from the front end of an Aragon application can be more difficult than it seems. Being able to communicate with the smart contract ACL using the modules offered by Aragon has its limitations. It was necessary to change the client of Aragon slightly making a pull request to the relevant official repositories.

There are some characteristics of Aragon that make its domain complex and the development of smart contracts with Solidity can present certain complications. Some difficulties arising from these problems were:

1. Aragon is complex: You could say that the learning curve of the framework is more of a wall than a curve. There are many underlying technologies behind Aragon that the developer must more or less master in order to begin to understand the functionalities that the modules offer and to be able to use them in the development of moderately complex applications
2. Debugging can be a very complicated task: Bugs that may appear throughout the development of the application can be difficult to detect, to locate their origin or to solve; or even the exceptions that arise in the framework. Some difficult problems to detect can be: errors related to the compilation or deployment of the smart contracts or errors coming from the background script. Errors related to the preparation and configuration (set up) of the framework can also be difficult to detect, due to the fact that Aragon returns unspecified exceptions. It can happen that you spend a lot of time preparing and running the application only to realize an hour after you had the wrong Node.js version.
3. Framework with fragile dependencies: The release of new versions of some of the framework’s module packages may affect the application’s performance. This can be a bit frustrating when you are in the middle of developing the application, because the app may work this week but not next week. An example of this is Aragon’s CLI (command-line interface). Certain updates broke the Committees app completely. 

The development of Committees in Aragon has been like a rollercoaster ride, it has had its ups and downs. It is possible that the developer is lost and does not find the solution to the problem or thinks that there is no solution possible. However, when it is finally found, the satisfaction is indescribable. 

Development with Aragon can be incredibly complex and learning how to use it can be challenging. But once we get over the learning curve we realize that truly amazing things can be developed.