Thanks @AptosFoundation, for the ARFC. Even if we have not been involved directly in this project, given our role on Aave DAO’s technical and security side, we would like to give some overall thoughts for the community.
High-level, this is an ad-hoc expansion of the Aave protocol to a different environment, and even if a fully legitimate proposal, expectations/implications should be understood:
-
The implementation loosely mirrors the Aave v3 features and patterns on its latest v3.3 version, but unlike other expansions of Aave v3 to EVM networks, it is not exactly Aave v3.3: it is not the same codebase (language/patterns-wise), there are certain divergence features-wise, upgrade procedures or control model are not the same at inception.
This is not negative by itself, but simply makes it an exception to the other instances. -
Aside from the core protocol and some peripheral components, Aave v3 has countless other tools and procedures around it. These will not be realistically available to the DAO on launch, as it would require almost swapping all DAO resources to Aave on Aptos, which, at least from our side, we don’t think is in any way possible.
-
All Aave v3 expansions are always decentralised by default, based on on-chain governance proposals and the Aave decentralised infrastructure that factually activates the pool on the new network and immediately gets control over it. As commented on the ARFC, this will not be the case for Aave on Aptos, as even if temporarily, Aave Labs has been proposed to hold all critical permissions of the instance. We agree that the technical limitations of reproducing the infrastructure required for decentralisation are high, and not realistic in the short term, but it is still very important for the Aave DAO to understand that factually, it will not have control over this instance.
-
BGD Labs has not been involved in any capacity with this expansion, the reasons being that initially we were not aware of it, and once we became aware, didn’t really fit in our scope of work for the DAO: related to what we previously commented, in environments pretty different from EVMs, the effort required to expand with the quality of EVM is major, and in what concerns us, we think our involvement and expertise are better allocated to different parts of Aave.
We would like to clarify, though, that this is not any type of exception on our side towards Aptos, but applicable to previous cases even closer to Ethereum, like Starknet. -
Given the involvement of Aave Labs in both this project and Aave v4, it could make sense to clarify how exactly both will fit lifetime-wise. As commented on the phased approach, Aave on Aptos will require multiple months to have feature parity with other instances, while at the same time, Aave v4 is expected to be released in the upcoming months.
This is even more important than the strategy regarding v3 upgrades on EVM networks, precisely due to being a project built completely ad-hoc from scratch, not a live system leader in the industry, which should be maintained and improved to maximum standards. -
The current public Aave on Aptos repository is license/copyright-wise with All Rights Reserved to Aave Labs. It is important for the DAO to understand if this will change in the future.
-
As a documentation feedback, we encourage the team that developed the v3 port to explicitly outline the differences in basic network infrastructure directly affecting the Aave protocol. For example, the tokenization approach itself is totally different compared with EVMs, which has deep implications for flows on the Aave protocol. This extends to all audit reports and security procedures documentation.