Simple summary
Introducing the concept of Aave Asset class Allowlist (AAcA), a simple governance framework to require explicit categorisation by asset class of asset listing candidates, and governance pre-approval of the asset class itself before proceeding to specific asset listings.
Motivation
Following the current governance frameworks, whenever an external team or the Aave community itself seeks a new asset listing on Aave v3, the process consists of the following steps:
- TEMP CHECK (forum discussion and Snasphot). During this stage, the community performs a discussion and vote to “soft” signal if there is appetite for the asset to be listed, usually boiling down to track record of the asset and team, growth opportunities, and other types of non-morphological (non-technical, non-risk related) aspects of the asset.
- ARFC (forum discussion and Snapshot). Once the asset passes TEMP CHECK positively, it enters the ARFC stage, whose main objective is to trigger operational work streams of the Aave Service Providers (SPs): risk analysis from @ChaosLabs and @LlamaRisk, technical/security analysis from BGD Labs, and any other particular feedback from professional contributors.
- AIP (optionally forum discussion and on-chain Aave governance vote). If the due diligence from Service Providers gives a positive output, the asset listing lifecycle proceeds to the crafting of the on-chain proposal executing the listing in the pool/s, and the creation of said proposal in the governance contract for AAVE holders to vote on it.
We could say this procedure works relatively well: structured, but without falling into over-bureaucracy. Giving enough flexibility for SPs to maneuver, but without sacrificing quality.
However, DeFi assets have become more and more complex/diverse over the years in DeFi across all their verticals, and clear and numerous asset classes have appeared. While this asset class diversity is overall positive for the DeFi ecosystem and Aave, it naturally forced Aave DAO’s internal procedures to adapt, mainly boiling down to the quality and flexibility of its SPs when doing their due diligence procedures for any type of DeFi asset.
From BGD, we have observed lately that the complexity of assets combined with multiple parties involved in the evaluation has created high-level inefficiencies, for example, with assets arriving at analysis stages when, due to their nature, probably should not (cases like LP tokens, or assets having relatively complex strategies under the hood).
We think that to address this, some extra “formalisation” of asset classes on Aave is required:
- Explicitly define a list of DeFi asset classes currently listed on Aave, which covers a good part of all asset classes existing on DeFi.
- Explicitly define a list of which asset classes are pre-authorised to be candidates for listing on Aave, and consider it as a pre-filter to not proceed to ARFC if not. If a candidate asset listing is of an asset class not pre-approved, it requires first pre-approval of the asset class.
- Optionally define some simple alignment scale of the asset with Aave, considering aspects like whether the asset itself or the infrastructure around uses already the Aave protocol, if the asset belongs to/uses directly or indirectly a competitor of Aave, or if it is simply a neutral asset.
The value of this categorisation + allow-list is important, including but not limited to:
- Avoiding situations of an asset arriving to SPs for due diligence, and requiring very contradictory and important effort: e.g. if tokenisation of liquidity supplied in a lending protocol would be a candidate listing, Aave SPs would need to make a formal due diligence of the whole lending protocol behind and procedures; due diligence that gives very high value to the team behind the asset itself (dubious for the interest of the Aave DAO), and with SPs spending massive resources.
- By not having, for example, competitors’ liquidity protocols tokenization on the allow list, the due diligence simply is not started, and resources can be allocated to more productive tasks.
- Generally, adapting the governance framework to the current landscape of assets, not to the one from 2-3 years ago.
Specification
The introduction of the Aave Asset class Allowlist (AAcA) is a task that, if approved by the community, Service Providers can perform as a joint effort.
As with any collaborative project, it requires some initial organisation, and in our view, the steps for it could be the following:
Assets’ class initial categorisation
SPs involved directly in asset analysis (BGD, Chaos Labs, LlamaRisk) can come up with a list of asset class categories covering all the assets currently listed on Aave. This will already help to identify both “pure” cases (e.g., AAVE as governance token), or “complex” ones (e.g., LRTs with more/less complex strategies).
With risk providers working on a daily basis on asset profiling (liquidity monitoring, simulations), we think the work stream can be initiated by them (Chaos Labs, Llamarisk), and BGD will review the initial list and specifications before presenting the result here on the forum as a joint effort.
The output of this task will be a document on a public repository on the aave-dao Github organisation, listing all categories and assets within each one of them. This repository will also act as the future Allow-List.
Allow-list management
To be consistent, all asset classes with at least one asset listed on Aave will be part of the Allow-list to start with. But going forward, we think the following guidelines are reasonable for management of the Allow-list (and implicitly categories):
→ Addition to Allow-list
Whenever a TEMP CHECK for a new listing is created on the forum (or before it if going through channels like ACI’s Skywards), there will need to be a categorisation exercise.
If the asset belongs to a category in the Allow-list, the growth service provider (ACI) can simply assign the category, just confirming off-forum with analysis SPs (tech, risk) that it is correct.
If the asset clearly doesn’t belong to a category on the Allow-list, and the growth service provider (ACI) thinks adding to Allow-list could give value, they should request an analysis SP to initiate a process of categorisation of the asset first. This will trigger a process similar to what was described in categorisation: an analysis by SPs (BGD, Chaos, Llamarisk currently) to define the category with high-level pros/cons to the protocol.
Once that is ready, the growth service provider can decide to proceed with an ARFC to add the asset class to the Allow-list, or not.
→ Removal from Allow-list
The removal of an asset class will be a mainly non-retroactive measure, to apply for new listings: e.g., LRTs could be removed from the Allow-list, and that would mean that no other LRTs are to be listed.
In addition, this can potentially trigger risk work streams to reduce exposure to the asset class, but given that these could happen to be quite ad-hoc, we don’t see too much value in defining them at this stage.
→ Visibility of the currently approved Allow-list
See the previous categorisation section: a Github repository on the aave-dao org.
Next steps
- Gather any feedback from the community.
- After there is good support, proceed to an ARFC Snapshot, which, if passed, will act as a trigger for the defined work streams to SPs.
