Title: [ARFC] Update the Asset Onboarding Framework

Author: Marc Zeller - ACI ( Aave Chan Initiative)

Date: 2023-11-21

Summary

This ARFC proposes an updated process for new asset listings direct to establish a streamlined governance process for adding new markets and streamline the listing of assets with existing Aave markets on new chains.

Motivation

New asset listings are important to keep Aave v3 relevant but we have received feedback that the current process is unclear and subject to delays. In addition, there is no specific process for listing assets on new Aave deployments when the asset is already listed with existing Aave markets. These “new” asset onboarding could benefit from a more streamlined process. Delays in governance decisions could impede the platform’s ability to scale, while most of the new asset listing votes are pro-forma and pass without much discussion. This listing framework aims to balance security and speed by providing a more efficient governance process for asset onboarding. We have established the precedent with past proposals that have improved timeliness and governance overhead. This ARFC is meant to define a clearer and accessible standard in the same spirit as the DAO’s historic process.

Specification

This proposal suggests a direct-to-AIP vote mechanism for listing assets that already have existing Aave markets on new chains. This expedited process ensures timely expansion of markets for new Aave deployments.

To summarize, here is an overview of the current standard proposal process:

• Post a TEMP CHECK governance thread for 5 days
• Snapshot vote for 3 days (24 hours after gov thread)
• Post an ARFC governance thread for 5 Days
• Snapshot vote for 3 days (24 hours after gov thread)
• Post an AIP vote for 5 days (Minimum 320k required)

This process takes around 23-25 days.

The current usage in the Aave DAO is to skip the TEMP CHECK and TEMP CHECK snapshot stages for assets already onboarded on other Aave pools, but that’s not defined as a rule in a framework yet, this process still takes 13-14 days on average.

This ARFC suggests New asset listings should follow the template below so that governance and risk managers can make informed decisions and provide timely feedback.

We propose that onboarding assets that already have existing Aave markets can be taken via a Direct-to-AIP process, similar to the existing Caps Update Framework. This will allow quick listing of assets that have already been approved by governance for other chains, while managing risk considerations like chain-specific liquidity.

There will be 2 paths now for new asset onboarding:

1. Net-new asset listings: Net new asset listings that don’t have current Aave markets will continue in the current process stewarded by ACI Skyward. Skyward is now extended to support the process directly at the TEMP CHECK snapshot stage instead of the ARFC stage.
2. Direct-to-AIP Vote asset listings for assets that exist in Aave markets: For assets that are eligible, an ARFC should be posted on the governance forum specifying the asset is a candidate for a direct-to-AIP framework process.

Direct-to-AIP asset onboarding proposals must satisfy all of the following conditions:

• Proposed asset must be an asset with at least one existing Aave market.
• Proposals should be submitted by a risk service provider or have received feedback from at least one risk service provider team.
• The proposed supply cap should not exceed 50% of supply on the respective chain.
• The Asset has a Chainlink price feed that is at least 90 days old.

1. Normal Governance Process:
   • For situations not covered by the direct AIP vote conditions, the standard TEMP CHECK governance process will apply.
2. Applicability:
   • The framework is intended for all V3 liquidity pools.
   • There will be a 24h minimum mandatory delay between the ARFC forum post and AIP publication.

FRAMEWORKS

• [TEMP CHECK] Format (Net - New Asset Listing)

Title: [TEMP CHECK] onboard (asset) to Aave v3 on (chain) pool

Author:

Date: in YYYY-MM-DD format

1. Simple Summary: A short description of the action desired
2. Motivation/Background:

Explain the motivation behind the intention to list the new Token and a background of that Token. Please take into account that the proposal need to include:

Asset Validation: This is the first and most crucial step, which includes a detailed analysis of the asset. It should provide a comprehensive understanding of the token, its functionality, and the ecosystem it operates within. The asset’s utility, its role within its ecosystem, its backers, and its performance over time should be part of this validation. This data helps determine whether the asset aligns with Aave’s values and goals.

1. Benefits of listing that token: Why it makes sense for all parties involved to pursue that new listing. Bear in mind that it needs to be as much clear as possible for governance to understand, and also explain very well Market Impact.

Market Impact: This includes an analysis of the potential impact of the asset’s inclusion on the Aave market. This should take into consideration the effects on liquidity, user adoption, and overall market growth. The new asset’s potential to attract new users, its impact on the platform’s liquidity, and its contribution towards the growth of Aave should be analyzed.

1. Chain to be deployed/listed: When explaining the intention of that asset to be in an specific chain and/or listing, justify as well the LTV, and basic information for the listing asset. Bear in mind that at [TEMP CHECK] stage, asset can be only in one chain, due to risk parameters recommendations.

2. Proof of Liquidity (POL) and Deposit Commitments: This information will be considered in the decision-making process to prioritize listings. To be more specific, some criteria to be used in decision making will be:

   a . If the chain’s treasury or foundation has commited to providing an initial liquidity pool for Aave or not

   b. If there are collaborations with external parties to bootstrap liquidity, to contribute to a more robust and diverse liquidity environment

   c. If there has been established plans to implement liquidity mining programs tailored made for Aave

   d. If the deployment supports staking and yield farming opportunities related to Aave

   e. If it has been contemplated a Grant to Aave DAO to incentivize that deployment in comparison to other similar proposals

3. Useful Links: Any additional information that can help Aave DAO to decide. When sharing useful links please include links to previous governance votes about that asset and parameters, that will help reader/user understand the reasoning behind it and make a clear decision when voting.

4. Disclaimer:

   Statement of Author potential conflict of interests and relationship with asset protocol and if they received compensation for publishing this proposal

5. Next Steps

   1. If consensus is reached on this [TEMP CHECK], escalate this proposal to the Snapshot stage.
   2. If the Snapshot outcome is YAE, this proposal will be escalated to ARFC stage
   3. Publication of a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage
   4. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal

6. Copyright: Copyright and related rights waived under CC0.

• [ARFC] Format: Direct-to-AIP asset listings for assets that exist in Aave markets or assets that successfully passed TEMP CHECK snapshot stage

Title: [ARFC] (Direct-to-AIP) Listing of (asset) to Aave v3 on (chain)

Author:

Date: in YYYY-MM-DD format

1. Summary: Direct-to-AIP for XXXX asset [existing asset in Aave markets] or [asset that passed TEMP CHECK snapshot]

2. Motivation/Background: Explain the motivation behind the intention to list the Token in another chain.

3. Chains to be deployed/listed: When explaining the intention of that asset to be in an specific chain and/or listing, include the listing parameters, and basic information for the listing asset. This information must be proposed by a risk manager or have input from at least one risk manager.

4. (optional) Audits / Security Reviews : Aave DAO values security above all. Potential listing token and protocol need to assure that risk evaluation have been taken account:

   Risk Assessment: This involves a thorough analysis of the potential risks associated with the asset, conducted by a reliable risk provider. The assessment should consider various market risks including the volatility of the asset, its liquidity, and any other potential risks specific to the asset. The asset’s historical performance, its susceptibility to market fluctuations, and its liquidity in different market conditions should be part of this assessment.

   Technical Considerations: This involves the technical details of the asset. It should include the contract address of the asset, which is an essential detail required for listing. Additionally, the proposed Loan-to-Value (LTV), Liquidation Threshold, and Liquidation Bonus should be mentioned. These parameters are necessary to understand the lending and borrowing mechanics of the new asset within the Aave ecosystem.

5. (optional) Useful Links: Any additional information that can help Aave DAO to decide. When sharing useful links please include links to previous governance discussions about the asset including both TEMP CHECK and TEMP CHECK snapshots.

6. Disclaimer:

   Statement of Author potential conflict of interests and relationship with asset protocol and if they received compensation for publishing this proposal

7. Next Steps

   1. If consensus is reached on this [ARFC], escalate this proposal to the Snapshot stage.
   2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal

8. Copyright: Copyright and related rights waived via CC0.

Disclaimer

The ACI is not presenting this ARFC on behalf of any third party and is not compensated for creating this ARFC.

Next Steps

1. If the Snapshot outcome is YAE, this proposal will be considered canon, and the guidelines will be adopted.

Copyright

Copyright and related rights waived via CC0.

---