TL;DR
With the release of Horizon approaching, this post aims to provide visibility and our opinion to the community (members of the DAO and SPs) regarding the activation strategy intended by Aave Labs, more precisely, in the control roles of the system and code versioning.
In addition to that, we also propose an alternative configuration to consider, which, in our opinion, is more natural towards the goal of friendly forks.
Context: multi-roles configuration on Aave friendly forks
With Aave Labs nearing the release of Horizon, and the team forwarding us to review an Aave governance proposal, we would like to comment with the community on certain implications of the intended approach, which, at least for us, were understood differently during the TEMP CHECK and ARFC stages.
The confusing component arises mainly from the fact that the “Operational” and “Executive” roles defined in the Horizon proposal are not morphologically correct in the current status of the Aave DAO.
The reasons why we think that are the following:
- As we explain in the post of our approach to friendly forks, the friendly forks framework was very loosely defined, but the substance behind it was relatively clear:
The Aave DAO at the moment has, in one hand, infrastructure, brand and intellectual property that can allow other entities to use for a price; on the other hand, the Aave DAO has defined historic procedures, know-how and hired entities (SPs), that support the executive arm of the DAO (the AAVE holders via governance) running the ecosystem (Aave pools, GHO, Staking, etc). It is a business venue for the DAO to modularise that, and allow other entities to, under certain conditions, use the first component of tech, brand, and general IP. - Assuming a precise framework setup for the previous, it is true that 2 main roles appear in the Aave DAO <> fork relation:
- The entity with executive power on the fork (we will call it the fork manager going forward). By substance, the entity acting as some type of licensee of the infrastructure and with the power to control and manage the pool.
- The entity owning the IP of the licensed infrastructure (we will call it the IP owner going forward). In this case, the Aave DAO, allowing the fork manager to use the infrastructure, brand, and other benefits (e.g. this case, the GHO credit line) under certain conditions.
With the previous understood, we can narrow down the unnatural aspect of the previous versus what is defined in the Horizon proposal to the definition of Operational role encompasses basic management of the instance (ownership and upgrade of the contracts, execution of governance proposals .
This is contradictory to the split Executive/Operational roles in the Aave DAO/protocol context.
Ownership and upgradeability of an Aave pool are by definition , the highest form of executive power in the context of a system like the Aave pools. The reason is straightforward: whoever has control over the upgradeability of the system has full executive control, superseding any other role. It can change the smart contracts’ logic, it can replace any other entity with roles, it can execute the function of any other sub-role, etc.
The whole configuration and strategy around all Aave DAO instances is proof of that, with the governance contract being the executive power of the pools, and then delegating limited operational roles to, for example, the Aave Protocol Guardian for emergency actions, or others like Risk Stewards (implementing constraint logic to change different risk parameters).
Even more, on the whole description of dual roles,
“Operational” and “Executive” responsibilities for the instance. While the Operational role encompasses basic management of the instance (ownership and upgrade of the contracts, execution of governance proposals), the Executive role oversees risk management, assets listing, and general configuration
there is a pretty strong case to be made that roles are factually reversed: what is defined as “Executive” there is factually operational (management only on the asset and risk side); while “Operational” is factually executive.
The previous could be, in some cases, a minor matter of terminology and nothing else, but in this case, it is, in our opinion, a pretty important topic, with major implications.
To delve into that, let’s dig into some Horizon high-level characteristics:
- Due to the limitations of the Aave DAO listing security tokens on the instances it directly controls, Horizon separates that from the DAO by establishing another entity, which then uses the aforementioned infrastructure and brand from the DAO. So the entity behind Horizon (the fork manager), actually enters into some type of agreement with the Aave DAO for the usage of its infrastructure and brand, for a price.
Here, it is obvious that the DAO still having superadmin control on a pool implies that the DAO has control over a pool with security tokens listed. Thus, Horizon becomes a layer purely on the asset issuance, as the superadmin is factually the DAO. - Similar to any other case where the IP owner (Aave DAO) permits the use of the infrastructure and brand to another entity, that entity is currently allowed to modify the software however deemed appropriate for their use case. In the case of Horizon, due to the nature of the pool, this is a mandatory requirement, as Aave Labs correctly did.
At the same time, and as we described in our post on friendly forks’ approach, this customisation, added to the fact that the base version of Horizon is v3.3, makes it not doable for all the DAO infrastructure to support seamlessly. Moreover, aside from simply being an item outside of scopes like ours (BGD), even the review stage of Horizon itself is contradictory: there is no point for entities engaged with the DAO, like us, maintaining a different version (currently v3.5) to have a say on a custom fork.
This lack of review would be fine if the full control would be on the fork manager, but the moment the pool gets voted via Aave governance, and the Aave governance gets super-admin control, it creates an uncertain scenario where code produced by somebody external to the DAO, not following the latest version of the software, will be voted by uninformed AAVE holders.
Options to move forward
With the previous in mind, we would like to raise different options to be discussed:
Option 1. The first option is to go forward with the proposal of Aave Labs as it is, for the DAO activating Horizon and getting superadmin control. This will imply:
- The DAO factually gets superadmin control over the Horizon pool, with any liability associated with that.
- At the same time, a different entity/ies can perform critical actions, such as listing assets, permission participants, configuring oracles, and, in general, everything aside from assigning existing roles on the protocol, and upgrading some core contracts.
- On our side, we will NOT review the specifics of that instance, due to the aforementioned custom nature.
- We don’t recommend any friendly fork instance not to use the latest Aave v3 version as a base; same applies naturally to Horizon.
- In the future, the DAO may need to vote on proposals like upgrades of the Horizon smart contracts. Even if having a decentralize voting engine like the Aave governance arguably adds to the security of the Horizon system, the reality is that the DAO will vote in a system that doesn’t manage in terms of assets and configurations, whose codebase didn’t decide, and which technically could have been partially upgraded in some components by the fork manager (e.g. tokens implementations).
So the voting via Aave governance becomes a relatively “blind” process, hence, unhealthy.
Option 2. Similar to other friendly forks in progress, Aave Labs changes the control model to the most natural one:
- Aave Labs is the superadmin of the system in the smart contracts, via official smart contracts of the DAO (PermissionedPayloadsControler & Executor flow).
The system allows adding any length of time lock, and also decouples permissions-wise submitting candidate proposals from cancelling them. This means that while Aave Labs can be the entity creating payloads unilaterally, they can nominate, for example, a Security Council with different members, to cancel potentially malicious proposals, or any upgrade having an unexpected effect.
Similar to any other friendly fork, we (BGD) can support both explaining the control model of the PermissionedPayloadsController, and setting it up on behalf of Aave Labs, if required. - We still recommend that Aave Labs upgrades the base version to v3.5, instead of using v3.3. Even if by principle we think following the latest upstream afterwards should be optional, we believe that, at the beginning, is a very bad idea. Starting with the latest version as base only benefits the fork manager in the future: being able to reason very similarly to the Aave DAO production upstream contracts, making it substantially simpler to apply any future DAO upgrade on top of Horizon, not skipping versions, potentially being fully compatible with different tooling out-of-the-box, amongst others.
Moreover, each upgrade of v3 includes improvements, making the codebase more solid, both security and usability-wise.