[ARFC] Technical Asset Listing Framework

Author: Aave Labs

Date: 2026-07-08

---

Summary

Aave Labs proposes adopting a standardized Technical Asset Listing Framework for assets seeking listing, continued listing, or material parameter expansion on Aave V3, Aave V4 and Horizon.

The objective is to improve the existing asset listing and monitoring process by making the technical requirements for assets listed on Aave more consistent, transparent, and repeatable across governance proposals, while establishing an ongoing monitoring baseline to ensure listed assets continue to meet the protocol's quality and safety standards over time. The framework is designed to complement existing risk-provider methodologies and the Aave Asset Classification Framework by defining a public baseline for technical safety.

The framework defines the technical information and requirements expected from asset issuers and review contributors. Formal technical assessment reports may include qualitative ratings or findings summaries for use by risk providers and governance contributors, but this ARFC does not prescribe rating reference values or define exhaustive blocker conditions.

Motivation

Aave's asset listing process has matured significantly over time, with deeper participation from risk providers, technical contributors, and governance stakeholders. As the protocol expands across more markets, asset types, and deployment environments, the technical requirements for listed assets need to remain clear enough for governance participants to evaluate proposals while being rigorous enough to capture the full asset risk surface.

Relevant requirements include ERC20 compatibility, predictable transfer behavior, bounded minting, robust privileged-role controls, reliable oracle paths, safe bridge topology, audited codebase, and appropriate disclosure of offchain arrangements or components where relevant information is not available onchain.

These issues are often technical, but they have direct implications for Aave's solvency, liquidations, collateral configuration, oracle design, and emergency response. A token with unbounded minting, weak upgrade controls, a stale or unsuitable oracle, bridge supply mismatch risk, an unclear redemption path, or limited transparency due to offchain arrangements can create exposure that is not visible from standard market metrics alone.

This ARFC proposes building on the existing process by making technical asset requirements explicit and standardized, so that future asset proposals can be evaluated against the same baseline and so that governance can clearly identify which assets satisfy the standard, which require mitigation, and which require further review or remediation.

Scope

The framework applies to:

• New asset listings on any instance of Aave V3, Aave V4 and Horizon.
• Existing listed assets undergoing material changes.
• Existing listed assets subject to periodic or out-of-cycle technical refresh.

The framework is intended to be deployment-aware. Where an asset exists across multiple chains, the asset is expected to satisfy the applicable requirements on each relevant chain, including per-chain contract implementations, oracle paths, bridge topology, access-control structure, and dependency configuration.

The framework does not replace market-risk analysis, liquidity analysis, legal review, or governance discretion. It provides a technical eligibility baseline to be used alongside the work of the DAO's risk providers and other relevant service providers. Ultimately, onboarding and parameter decisions remain with the DAO, based on the full set of available information, diligence, and recommendations presented through governance. (Liquidity and market-depth analysis is expected to be provided by the DAO's risk providers as part of their standard market-risk assessment, and findings from that process should be read alongside this framework's technical conclusions when governance evaluates supply caps, borrow caps, and collateralization parameters.)

Relationship with AAcA

Each asset should first be mapped to the relevant group under the Aave Asset Classification Framework. At the pre-screening stage, the asset's AAcA category is expected to be confirmed, and assets in a non-approved or sanctioned category should not proceed.

The AAcA classification determines which requirements require the deepest focus. For example, yield-bearing assets are expected to satisfy dedicated exchange-rate, withdrawal-path, and CAPO requirements, while bridged assets are expected to satisfy dedicated bridge and supply-integrity requirements.

Evaluation Methodology

This framework defines the technical requirements expected from assets seeking listing, continued listing, or material expansion on Aave. It is not intended to publish fixed rating reference values or a complete list of automatic rejection conditions.

When Aave Labs or another contributor prepares a formal technical assessment report, that report may include section-level qualitative ratings, risk labels, or other assessment outputs. Those labels should be treated as report-specific conclusions based on the asset reviewed, the relevant deployment, the available issuer disclosures, and the surrounding market and protocol context.

The review should separate factual findings from recommendations. For each section, the reviewer should identify:

• the relevant contracts and systems reviewed;
• the key finding;
• any required remediation;
• any residual risk that remains after mitigation;
• whether the finding should constrain listing parameters or exposure caps;
• a qualitative rating and assessment conclusion.

The absence of explicit rating thresholds in this ARFC should not be interpreted as acceptance of every implementation that technically satisfies the information request. Material weaknesses may still lead to reduced exposure, additional monitoring, delayed onboarding, or a recommendation not to proceed until remediation is complete.

Pre-Screening Requirements

Before a full technical review proceeds, the asset should satisfy the following pre-screening requirements:

• The asset contract must be deployed and verified on the target chain.
• The asset's AAcA group must be confirmed.
• The asset must not belong to an AAcA non-approved or sanctioned category.
• Existing Aave listings, if any, must be identified and used as parameter references where relevant.
• The closest comparable asset already listed on Aave must be identified.
• Proxy and implementation bytecode must match, or be reconciled against, the latest audited version where applicable.

If a comparable asset exists, it should be used as the initial reference point for oracle design, LTV, liquidation threshold, caps, and other collateralization parameters, subject to the new asset's own technical profile.

Standard Findings Report

Where a formal technical assessment report is prepared, it should use a standardized structure so that findings are comparable across assets and deployments. The assessment may include a rating, severity label, recommendation, or other report-specific conclusion. This ARFC does not define the reference values for that assessment. Where a section does not apply, the reviewer should explain why.

Framework Sections

The sections below describe the core technical areas that should generally be covered when evaluating assets for listing, continued listing, or material expansion on Aave. They are not intended to be an exhaustive or final list of requirements. Additional requirements may apply depending on the asset type, implementation design, deployment environment, issuer operations, external dependencies, or new risk considerations identified through governance and service-provider review.

For assets with material offchain components, including tokenized real-world assets, custodied instruments, and assets whose redemption or collateralization depends on legal arrangements rather than onchain mechanics, the requirements in this framework apply to the onchain layer. Offchain arrangements that bear on supply integrity, redemption reliability, or counterparty risk should be disclosed and assessed under Section 8 (Dependencies and Composability) and the Issuer Expectations section. Where an offchain component is a critical dependency, it should be treated with the same scrutiny as an onchain dependency.

1. ERC20 Compliance

Assets listed on Aave are expected to behave predictably under ERC20 integration assumptions and broader DeFi composability standards.

Technical requirements:

• name(), symbol(), decimals(), and totalSupply() must return sensible values.
• transfer() and transferFrom() must return a boolean.
• The asset must not have fee-on-transfer behavior.
• The asset must not rebase, unless a non-rebasing wrapper is used instead.
• The asset must not use ERC777 hooks or ERC1363 transfer callbacks.
• Any flash-mint capability must be documented and shown not to impair Aave accounting.
• Smart contracts must be able to hold and transfer the token without whitelist or address restrictions.
• Token decimals must be compatible with Aave integrations and frontend assumptions.

Fee-on-transfer behavior, rebasing behavior without a suitable wrapper, ERC777 hooks, or unsupported decimals that cannot be safely integrated should generally require remediation or a modified listing approach before the asset is considered under the framework.

2. Oracle

Aave requires a robust oracle path for each listed asset. The oracle path is a core safety dependency, and any feed design that does not use Chainlink as the primary source must be explicitly justified.

---

Due to the Snapshot character limit, the remainder of this proposal can be viewed on the Aave Governance forum.