TL;DR
Present to the community a technical upgrade to align the implementation and architecture of Aave’s ecosystem Collector contracts across all networks.
https://github.com/bgd-labs/aave-collector-unification
Context
The Aave ecosystem, and more precisely its liquidity protocol (v1/v2/v3) collect fees in a decentralized way, which later on are used for example to fund grants, pay different services providers (us included), or pursue different other strategies, like those proposed by @Llamaxyz .
All these funds are stored in smart contracts denominated Collectors, relatively simple in nature, and allowing:
- Transferring out funds of any token.
- Give allowance of any token to any address.
- In the case of Ethereum (more on this later), create streams of payments, for example for service providers.
All these actions are controlled by the Aave Governance V2 smart contracts (or cross-chain governance), and due to technical reasons regarding upgradeable contracts, usually they are triggered by interacting with another contract called Controller of Collector, which simply acts as a layer of indirection with the Collector itself.
But in practice, this current organization has some points of improvement:
- The codebase of the Collector is different across instances of Aave. The most updated version is the one on Ethereum, with others for example not supporting streaming, just because of legacy reasons.
-
The pattern of
Controller of Collector <> Collectorcan be simplified and unified with other parts of the ecosystem.
Sometimes, this lack of technical unification creates overhead (both operational and of understanding) on contributors, specifically those interacting with the “treasury” side of the protocol like Llama, so we present this proposal to improve the system.
The proposal
The upgrade/unification of contracts we propose includes the following:
Upgrade to the most updated version of Collector everywhere
The smart contract used as implementation of the Aave v2 & v3 Collector (a common proxy for both) is the most updated of the ecosystem, activated on https://app.aave.com/governance/proposal/71/, and mainly adding streaming capabilities.
The initial step of this proposal is to have exactly the same implementation for all the networks.
Unify fee collection v2/v3 on Polygon and Avalanche
Currently, apart from Ethereum, Polygon, and Avalanche are the only networks with both instances of Aave v2 and v3.
This proposal will redirect all future fee collection of the v2 pools to v3’s Collector.
Simple migration of Collector’s funds on Aave v2
For both Polygon and Avalanche v2, instances, before redirecting fee collection the v3’s Collector, the proposal will send there all the accrued fees plus rewards incentives on those.
This will also facilitate the execution of this already pre-approved proposal by Llama https://snapshot.org/#/aave.eth/proposal/0x1b816c12b6f547a1982198ffd0e36412390b05828b560c9edee4e8a6903c4882
Simplify/improve ownership and interaction point of Collector’s
As mentioned before, apart from the Collector, currently there is an additional layer of indirection on the infrastructure: the Controller of Collector. This is required for technical reasons, as with transparent proxies (Collector is one), the “admin” with upgradeability permissions can’t call functions defined on the implementation itself.
As the same contract (governance Level 1 Short Executor) has factual control on both the upgradeability and implementation functions of the Collector (e.g. transferring funds out), we introduced the so-called Controller of Controller, which the Level 1 Executor uses to trigger functions like transfer().
Lately, this pattern has been generalized by OpenZeppelin with a smart contract called ProxyAdmin, which we have already introduced on not-so-critical pieces of infrastructure. But we think it should be introduced everywhere, especially in this case.
Ownership-admin chain before & after the upgrade
In practice, integration-wise the change will be the following:
- Currently, to transfer, approve or create streams, the Aave governance interacts with the Controller of Collector, and upgrades the implementation of the Collector, with the Collector proxy. This will be reversed now: to transfer, approve or create streams, the Aave governance will interact directly with the Collector holding the funds (more natural) and to upgrade or other admin actions over proxy, will interact with the ProxyAdmin contract.
Next steps
Given that is just a re-shuffling of contracts already live, not requiring deep security procedures from the providers of the community. Still, we will ask Certora and SigmaPrime to do a procedural review, to complement all our testing and internal procedures.
Additionally, given the purely technical nature, we don’t think it is necessary to have both Snapshot and on-chain governance proposal, so our intention is to go with the second whenever the preparations are ready, also as this will help other contributors like Llama to proceed with their plans.
As usual, we appreciate any feedback from the community.