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(), andtotalSupply()must return sensible values.transfer()andtransferFrom()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.
Technical requirements:
- A Chainlink price feed must exist on the target chain and be used directly or through a CAPO adapter where appropriate.
- Feed decimals must follow Aave standards.
- The price feed must remain within its expected heartbeat and deviation threshold, or any deviation from the expected parameters must be explicitly justified.
- Comparable oracle adapters from existing Aave deployments should be identified where applicable.
- The Chainlink market-risk tier must be reviewed and documented.
For yield-bearing assets, CAPO must be used where required to limit exchange-rate or price-growth assumptions. Missing or stale oracle infrastructure, materially elevated feed risk, or the absence of an appropriate oracle path should be escalated to risk providers and reflected in onboarding, parameter, or monitoring recommendations.
3. Asset Operations Access Control
Assets must have clear access-control and supply-security guarantees across both the ERC20 token and any periphery contracts that can affect token supply, balances, transferability, or redemption. In addition to mapping each privileged role, the review should assess how those roles are assigned across addresses, whether responsibilities are concentrated, and whether the assignment structure creates correlated failure modes.
Each privileged role should be classified under a standard level model. For the purposes of this framework, a weak security configuration refers to any role holder at Level 0 or Level 1: a single externally owned account with no timelock, or a multisig that does not meet an honest majority threshold. References to “weak security configuration” elsewhere in this framework should be read against this definition.
| Level | Description |
|---|---|
| 0 | Single key or EOA with no delay; no multisig protection |
| 1 | Multisig below honest majority (i.e., fewer than a majority of signers are required to act independently) |
| 2 | Multisig at honest majority (i.e., a majority of signers required), no timelock |
| 3 | Multisig with short timelock below 48 hours |
| 4 | Multisig with timelock of at least 48 hours |
| 5 | Onchain DAO governance with timelock |
The role-holder classification should inform exposure limits, monitoring expectations, and any remediation requested from the issuer. Pause and blacklist authority may require faster operational paths than mint, burn, or upgrade authority, but should still be controlled by robust multisig or timelock structures.
3a. ERC20 Role Mapping
Issuers are expected to disclose and document all privileged roles on the ERC20 contract.
Relevant roles include, where applicable:
- owner or admin;
- default admin;
- minter;
- burner;
- pauser;
- blacklister;
- bridge or adapter roles;
- any other protocol-specific operational role.
For each role, the issuer is expected to provide the holder address, holder type, security configuration, and the admin hierarchy that can grant or revoke the role. Role concentration must be explicitly assessed.
3b. Periphery Role Mapping
Periphery contracts include any contracts outside the ERC20 token that hold any role of the token, can affect token supply or user balances, or can alter any fundamental function of the token. This may include bridge adapters, minters, treasury controllers, fee receivers, redemption contracts, staking wrappers, and other privileged modules.
Issuers are expected to identify all relevant periphery contracts, verify source code, disclose their own admin controls, and confirm that they are not upgradeable under weaker controls than the token itself.
3c. Minting and Burning Logic
Assets must provide strong supply-integrity guarantees. Issuers are expected to document who can mint, who can burn, the conditions under which these actions occur, and whether caps or rate limits exist.
Technical requirements:
- Exact mint and burn functions must be identified.
- Authorized callers must be documented.
- Minting must be subject to hard caps or per-period limits.
- The address that raises or removes caps must be separate from the address that consumes the cap.
- Worst-case mint exposure must be estimated in USD and compared against Aave’s potential collateral exposure.
- Burning must not be possible against arbitrary user wallets by a privileged address.
- Mint and burn events must be emitted for supply observability.
Minting controlled by an address with a weak security configuration, especially where minting is unbounded or subject only to very loose limits, a single address that can both raise and consume mint limits, or arbitrary burning from user wallets should generally require remediation or materially constrain onboarding and exposure recommendations.
3d. Pause and Blacklist Capability
Pause and blacklist controls must be documented because they can directly affect Aave liquidations and user withdrawals.
Technical requirements:
- Pause or freeze authority must be identified.
- Blacklist authority, if present, must be identified.
- The address holding these permissions and its security configuration must be documented.
- Blacklist functionality must not be able to unilaterally prevent Aave liquidations without governance awareness.
Pause and blacklist controls may be operationally necessary for some assets, but their effect on Aave must be explicitly understood before onboarding or expansion.
3e. Upgradeability
Assets and critical periphery contracts must have a clear and secure upgrade model. Where contracts are upgradeable, the authority controlling the upgrade path must be identified and appropriately constrained.
Technical requirements:
- Proxy type must be identified, including transparent proxy, UUPS, beacon, or immutable deployment.
- Proxy admin or upgrade authority must be identified.
- Upgrade authority must not rely on an address with a weak security configuration.
- Proxy admin or upgrade authority must be a multisig, timelock, or DAO-controlled address with verified source code and sufficient economic backing.
- Timelock delay must be documented.
- Contract history must not contain suspicious or undocumented upgrades.
A weak security configuration upgrade path is not aligned with the expected standard for assets listed on Aave. A multisig without a meaningful timelock may still be acceptable in some cases, but should generally constrain exposure until governance has sufficient confidence in the issuer’s operational setup.
4. Exchange Rate and Yield Mechanism
This section applies to yield-bearing assets, wrappers, LSTs, LRTs, vault tokens, and similar instruments.
Technical requirements:
- The exchange-rate function must be identified and documented.
- The rate must be monotonically non-decreasing under normal conditions, unless negative performance or slashing is part of the asset design.
- The rate must not be manipulable in a single transaction through donations, flash loans, or accounting shortcuts.
- The listed token must not rebase.
- Slashing or negative-rebase passthrough must be understood and reflected in parameters.
- The withdrawal path must be clear and acceptable for liquidations.
- If required, CAPO growth cap must be set at a defensible value relative to expected yield.
- Rate precision and rounding behavior must be documented.
An exchange rate that can be manipulated in one transaction, a yield-bearing asset without CAPO where CAPO is required, or an asset with no redemption path and insufficient secondary liquidity should generally require remediation or materially constrain onboarding and exposure recommendations.
5. Token Architecture
Assets must have a token architecture that is compatible with Aave integrations and does not introduce hidden supply, transfer, or access-control assumptions.
Technical requirements:
- Supply mechanics must be understood, including fixed cap, inflation schedule, or issuer-controlled supply.
- Transfer restrictions must be documented and compatible with DeFi composability.
- The token must not rely on
tx.originfor access control. - The token contract must not allow
delegatecallsto arbitrary contracts. - All privileged functions must be explicitly documented and access-controlled.
- There must not be multiple entry points for the same token supply, including duplicate deployments, legacy token addresses, or migration contracts that affect the same supply without clear accounting.
6. Bridge and Cross-Chain Risk
Assets whose supply integrity depends on bridges must satisfy additional bridge and cross-chain supply requirements.
Technical requirements:
- The origin chain and canonical supply must be identified.
- The target-chain representation must be documented.
- The bridge or messaging system must be identified.
- Verifier, attestor, oracle, or DVN configuration must be documented.
- Rate limits and escrow mechanics must be documented.
- Bridge admin and upgrade controls must be identified.
- Weak controls on the origin chain must be assessed as part of the target-chain listing.
Bridge review should not be limited to the target chain. If the origin-chain canonical token is upgradeable, mintable, or controlled by weak access controls, that weakness can undermine the full cross-chain supply model regardless of the bridge implementation.
Bridge dependencies with weak security configurations, missing verification, unbounded minting across bridges, or materially weak bridge-admin controls should be escalated and reflected in onboarding, exposure, and monitoring recommendations.
7. Audit and Security History
Assets are expected to have a recent and relevant security review history covering the deployed contracts and critical dependencies.
Technical requirements:
- The current deployed version must be covered by reputable audit work.
- There must be no unresolved Critical or High findings.
- Audit date must be recent relative to the latest meaningful code change.
- A bug bounty should exist and be proportionate to expected TVL.
- Past incidents, if any, must be documented with post-mortem and remediation.
- Deployed code must match the last audited version at the relevant commit hash.
- The issuer must have a communication channel and commit to pre-notifying Aave teams of material changes.
No audit, unresolved Critical or High audit findings, or a past exploit without documented remediation should generally require remediation or materially constrain onboarding and exposure recommendations.
8. Dependencies and Composability
External dependencies must be documented because they can impair the listed asset even if the token contract itself is sound.
Relevant dependencies include staking protocols, vaults, bridges, custodians, oracle systems, validator operators, restaking layers, and redemption infrastructure.
Technical requirements:
- All external dependencies must be identified.
- Each dependency must have its own audit and production history.
- Dependency governance must not be able to unilaterally impair the asset without onchain visibility.
- Withdrawal queues and timing must be compatible with liquidation assumptions.
- Validator, operator, or custodian concentration must be documented.
- Slashing or insolvency scenarios must be quantified where applicable.
A critical dependency with weak admin security configuration or no audit should generally require remediation or materially constrain onboarding and exposure recommendations.
Issuer Expectations
This framework addresses the technical dimensions of asset eligibility. We would expect this framework to be extended into a complimentary non-technical asset listing framework that will address issuer-facing expectations beyond the on-chain and smart contract layer, including legal structure, entity disclosure, regulatory status, operational practices, the legal treatment of property interests in the underlying asset, and other factors relevant to governance’s assessment of an issuer’s suitability for listing. Issuers should expect to meet both technical and operational requirements, as offchain structure and operations can directly affect onchain risk.
Where reasonable confidentiality concerns exist, disclosures can be made privately to the relevant risk provider or service provider rather than published in full. However, the public governance post should still summarize the finding, the rating, and the residual risk in a way that allows the DAO to make an informed decision.
Governance Process Integration
This framework should be incorporated into the asset onboarding and expansion process as follows:
- Pre-screening: confirm AACF classification, contract verification, comparable Aave listings, and basic eligibility.
- Technical review: assess the asset against the framework sections and identify any material technical concerns.
- Risk-provider coordination: align technical findings with market-risk parameters, caps, oracle configuration, and listing conditions.
- Governance publication: include the standardized findings table in the relevant governance proposal.
- Remediation tracking: document any required issuer remediation and whether it is a precondition to listing or a post-listing commitment.
- Ongoing refresh: assessments should be refreshed annually for all actively listed assets, and immediately when a material change occurs. Material changes include contract upgrades, new chain deployments, new or modified bridge routes, changes to privileged role holders or security configuration, mint-cap modifications, dependency changes, and security incidents affecting the asset or a critical dependency. Service providers and Aave Labs should flag these to the DAO as they become aware. Issuers must provide advance notice under their ongoing obligations.
The framework should not create unnecessary friction for straightforward assets with strong controls and simple architecture. Its purpose is to make the requirements more predictable and to ensure that technical issues are surfaced before they become protocol exposure.
Treatment of Findings
Findings should be translated into clear governance and risk-management consequences. Depending on the issue, this may include lower supply caps, lower borrow caps, reduced LTV, no collateral usage, additional monitoring, issuer remediation, periodic refresh requirements, or a recommendation to defer onboarding or expansion.
Formal technical assessment reports may use qualitative ratings or severity labels to communicate conclusions to risk providers and governance contributors. Those labels are applied within the context of the specific report and should not be read as fixed reference values defined by this ARFC.
Where governance elects to proceed despite material unresolved findings, the proposal should clearly state the residual risk and the rationale for accepting it.