One of the main objectives behind the P2P Models project at the technical level is the development of a framework to build an infrastructure for collaborative economies which do not depend on central authorities. The framework should offer small modular and functional components that act as building blocks to form these economies by creating and configuring DAOs. In a previous post we explained the general features of Committees. The application allows us to create, delete and modify groups within a DAO.
Each committee created is made up of the following components:
- A token that each committee member receives
- A Token Manager app to manage and configure the token
- A Voting app that allows you to create votes among members to carry out the tasks and objectives of the committee
- An optional Finance app, in case you want to associate an asset fund that the committee can control. This is useful if the committee needs “money” to be able to carry out its tasks, for example.
When creating a committee, the application allows you to define a set of initial members, configure voting parameters such as duration, percentage of approval or percentage of quorum for voting. It also allows you to define token parameters such as uniqueness (whether you want members to be able to accumulate more than one token or not) and transferability (whether you want members to be able to transfer tokens to others).
Committees offers three main functionalities
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.
Example of the use of Committees
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:
Relevant technical aspects of the application
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:
- 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:
internal returns (address memory apps)
Kernel _dao = Kernel(kernel());
ACL acl = ACL(_dao.acl());
MiniMeToken token = _createToken(string(abi.encodePacked(_committeeTokenSymbol, ” Token”)), _committeeTokenSymbol, 0);
TokenManager tokenManager = _installTokenManagerApp(_dao, token, _tokenParams);
_createTokenManagerPermissions(acl, tokenManager, this, this);
_grantTokenManagerPermissions(acl, tokenManager, manager);
_mintTokens(tokenManager, _initialMembers, _stakes);
Voting voting = _installVotingApp(_dao, token, _votingParams, _votingParams, _votingParams);
//Only token holders can open a vote.
_createVotingPermissions(acl, voting, manager, manager);
_changeTokenManagerPermissionManager(acl, tokenManager, manager);
apps = address(tokenManager);
apps = address(voting);
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.
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.
- 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.
Challenges and difficulties
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:
- 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
- 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.
- 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.
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
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.