Aave Proposes Unified Technical Standard for Asset Listings

Aave Labs proposes TALF, a unified asset-listing standard for Aave V3, V4 and Aave Horizon.

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

It sets unified technical requirements for asset listings, parameter expansions and ongoing monitoring.

The team proposes a minimum admission threshold. The goal is to remove ambiguities in assessments, make criteria transparent and institute continuous monitoring of already listed tokens.

The document does not supplant market-risk and liquidity analysis, legal review or DAO decisions. It is a baseline technical filter to be applied alongside the conclusions of risk providers and other ecosystem participants.

The framework covers three scenarios:

• new listings;
• assets with material parameter changes;
• periodic and ad hoc technical reassessments.

If a token exists across multiple networks, it must meet the requirements separately in each one—accounting for contract implementations, bridges, oracles, access rights and dependencies.

At the preliminary stage, an 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 should serve as a reference when configuring oracles, loan-to-value (LTV) ratios, liquidation thresholds and limits.

Strict requirements for ERC-20

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

Aave Labs proposes to codify the following requirements:

• predictable behavior of transfer() and transferFrom();
• no fee-on-transfer mechanics;
• prohibition of rebasing without a separate wrapper;
• disallow ERC777 hooks and ERC1363 callbacks;
• proper decimal support.

The ability to mint additionally via flash mint is not banned, but it must be disclosed and shown not to break internal accounting.

The contract must also not enforce allowlists for holding or transfers.

Chainlink as the primary price source

The proposal designates Chainlink as the primary price source on the target network. Any alternative scheme must be separately justified.

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

The absence of a reliable pricing mechanism, stale data or high oracle infrastructure risk should directly inform listing recommendations, risk parameters and monitoring.

Issuance controls and privileged roles

A separate section covers access rights and token issuance.

Aave Labs proposes disclosing all privileged roles in the ERC-20 contract and in external modules that can affect supply, balances, transferability or redemption.

The list includes:

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

These roles are assessed on a security scale from Level 0 to Level 5. The least robust are Level 0–1—single-key without execution delay or a multisig without an honest majority.

In the issuance and burning section, teams must document mint functions, the list of authorized addresses, limits and time constraints. A separate assessment of worst-case mint exposure in dollars—relative to Aave’s potential collateral exposure—is required.

Undesirable scenarios include:

• unbounded minting;
• the ability to increase the mint limit and consume it with a single address simultaneously;
• arbitrary burning of tokens from user wallets.

Pause, blacklist and upgradable-contract risks

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

For upgradable contracts, teams must disclose the proxy type, upgrade admin, the presence of a timelock and the upgrade history. A weak upgrade mechanism is explicitly deemed noncompliant with the listing standard.

Additional requirements for LSTs and LRTs

Additional requirements for exchange-rate mechanics apply to LST, LRT, wrappers and vault tokens.

Checks should cover:

• the potential to manipulate the rate via donations, flash loans or accounting quirks;
• the presence of a clear redemption mechanism;
• the sufficiency of secondary liquidity for liquidations.

An asset without a transparent redemption mechanism and adequate liquidity may face significant listing and risk-parameter constraints or be sent back for revision.

The initiative extends the course set after the KelpDAO incident. In early May, the protocol said it would revisit collateral and listing standards, broadening the focus from volatility and liquidity to cybersecurity, compatibility and technical architecture.

The ARFC does not introduce an automatic scoring system or a universal list of stop-factors. Technical reports may include qualitative assessments and risk labels, but hard thresholds for automatic rejections are not provided.

In May, the Aave lending protocol restored collateral parameters for wETH across six networks.