Aave Labs has published an ARFC proposing a new standardized Technical Asset Listing Framework (TALF) for Aave V3, V4, and Aave Horizon.

Aave Labs has published an ARFC proposing a new standardized Technical Asset Listing Framework for Aave V3, V4, and Aave Horizon.

The framework establishes consistent technical requirements for asset listings, parameter expansions, and ongoing monitoring. pic.twitter.com/OO9hwJK80T

— Aave (@aave) May 28, 2026

The framework sets uniform technical requirements for asset listings, parameter expansions, and continuous monitoring.

The team proposes introducing a minimum admission threshold to eliminate ambiguities in assessments, enhance transparency, and initiate ongoing monitoring of already listed tokens.

The document does not negate the analysis of market risks, liquidity, legal expertise, and DAO decisions. It serves as a basic technical filter to be applied alongside the findings of risk providers and other ecosystem participants.

The framework covers three scenarios:

  • new listings;
  • assets with significant parameter changes;
  • periodic and ad-hoc technical re-evaluations.

If a token exists on multiple networks, it must meet the requirements separately for each, considering contract implementations, bridges, oracles, access rights, and dependencies.

Initially, the asset must be deployed and verified on the target network, classified under the Aave Asset Classification Framework, and not fall under prohibited or sanctioned categories.

If a comparable instrument already exists in the protocol, it is recommended to use it as a benchmark for configuring oracles, loan-to-value (LTV) ratios, liquidation thresholds, and limits.

Strict ERC-20 Requirements

One of the central sections focuses on token compatibility with the ERC-20 standard.

Aave Labs proposes the following requirements:

  • predictable operation of functions transfer() and transferFrom();
  • no fee-on-transfer mechanics;
  • prohibition of rebasing without a separate wrapper;
  • rejection of ERC777 hooks and ERC1363 callbacks;
  • correct support for decimal places.

Additional issuance through flash mint is not prohibited, but it must be disclosed and confirmed that it does not violate the protocol's accounting.

The contract must not impose restrictions on the lists of allowed addresses for storage and transfers.

Chainlink as the Primary Price Source

Chainlink is proposed as the primary source for quotes in the target network. Any alternative scheme must be justified separately.

For yield-bearing assets, the use of CAPO is allowed, which limits assumptions about exchange rate or value growth.

The absence of a reliable pricing mechanism, outdated data, or high infrastructure risk from oracles must be directly reflected in listing recommendations, risk parameters, and monitoring.

Emission Control and Privileged Roles

A separate section addresses access rights and token issuance.

Aave Labs suggests disclosing all privileged roles both in the ERC-20 contract and in external modules that may affect supply, balances, transferability, or redemption of the asset.

The list includes:

  • owner;
  • admin;
  • minter;
  • burner;
  • pauser;
  • blacklister;
  • roles related to bridges and adapters.

A security scale from Level 0 to Level 5 is introduced for these roles. Levels 0–1 are considered the least secure—single key without execution delay or multisig without a trustworthy majority.

The section on issuance and burning requires documentation of issuance functions, a list of authorized addresses, limits, and time constraints. The worst-case mint exposure in dollars is evaluated concerning Aave's potential collateral exposure.

Undesirable scenarios include:

  • unlimited issuance;
  • the ability to simultaneously increase the issuance limit and utilize it from a single address;
  • arbitrary burning of tokens from user wallets.

Risks of Pausing, Blacklisting, and Upgradable Contracts

Pause and blacklist functions are highlighted as a separate risk area. They can directly impact liquidations and fund withdrawals. Management must understand who controls these powers and whether the address-blocking mechanism can disrupt liquidations in the protocol.

For upgradable contracts, the type of proxy, update administrator, presence of a timelock, and upgrade history must be disclosed. A weak update mechanism is explicitly deemed non-compliant with the listing standard.

Additional Requirements for LST and LRT

Additional requirements for exchange rate mechanics are introduced for LST, LRT, wrappers, and storage tokens.

It is proposed to check:

  • the potential for price manipulation through donations, flash loans, or accounting peculiarities;
  • the existence of a clear redemption mechanism;
  • sufficient secondary liquidity for liquidations.

An asset without a transparent redemption mechanism and sufficient liquidity may face significant listing restrictions and risk parameters or be sent back for revision.

This initiative continues the course set after the KelpDAO incident. In early May, the protocol announced its intention to revise collateral assessment and listing standards, shifting the focus from volatility and liquidity to cybersecurity, compatibility, and technical architecture.

However, the ARFC does not introduce an automatic rating system and does not contain a universal list of stop factors. Technical reports may include qualitative assessments and risk labeling, but there are no strict thresholds for automatic listing denial.

Recall that in May, the Aave lending protocol restored collateral parameters for wETH across six networks.