Aave a proposé une norme technique unifiée pour la liste des actifs

Aave Labs a publié un document ARFC proposant une nouvelle structure de listing standardisée (TALF) pour Aave V3, V4 et Aave Horizon.

Aave Labs a publié un ARFC proposant un nouveau cadre standardisé de liste d'actifs techniques pour Aave V3, V4 et Aave Horizon.

Le cadre établit des exigences techniques cohérentes pour les listes d'actifs, l'expansion des paramètres et la surveillance continue. pic.twitter.com/OO9hwJK80T

– Aave (@aave) 28 mai 2026

Il établit des exigences techniques uniformes pour le placement des actifs, l'expansion des paramètres et la surveillance continue.

L'équipe suggère d'introduire un seuil minimum de tolérance. L'objectif est d'éliminer les divergences dans l'évaluation, de rendre les critères transparents et de lancer une surveillance constante des jetons déjà ajoutés.

Le document ne remplace pas l'analyse des risques de marché, de liquidité, l'expertise juridique et les décisions du DAO. Il s’agit d’un filtre technique de base qui doit être appliqué en conjonction avec les conclusions des fournisseurs de risques et des autres participants de l’écosystème.

Le cadre couvre trois scénarios :

• nouvelles inscriptions ;
• actifs avec des changements de paramètres significatifs ;
• réévaluation technique périodique et non programmée.

Si un jeton existe sur plusieurs réseaux, il doit répondre aux exigences séparément dans chacun d'eux – en tenant compte de la mise en œuvre des contrats, des ponts, des oracles, des droits d'accès et des dépendances.

Au stade préliminaire, l'actif doit être déployé et vérifié dans le réseau cible, classé dans le cadre de classification des actifs Aave et ne pas appartenir à des catégories interdites ou sanctionnées.

Si un protocole dispose déjà d'un instrument comparable, il est proposé de l'utiliser comme guide lors de la mise en place des oracles, des ratios de collatéral (LTV), des seuils et limites de liquidation.

Exigences strictes pour ERC-20

L'une des sections centrales est consacrée à la compatibilité des tokens avec la norme ERC-20.

Aave Labs propose de consolider les exigences suivantes :

• fonctionnement prévisible des fonctions transfer() et transferFrom() ;
• manque de mécanismes de commission pour les transferts (frais de transfert) ;
• interdiction de rebasage sans wrapper séparé;
• éliminer les hooks ERC777 et les rappels ERC1363 ;
• prise en charge correcte des décimales.

Possibilité d'émission supplémentaire via menthe éclair n'est pas interdit, mais il doit être divulgué et confirmé qu'il ne viole pas les registres comptables du protocole.

Le contrat ne devrait pas non plus imposer de restrictions sur les listes d'adresses autorisées pour le stockage et les transferts.

Chainlink – Source de prix de base

Il est proposé d'utiliser Chainlink comme principale source de cotations dans le réseau cible. Tout système alternatif doit être justifié séparément.

Pour les actifs générateurs de revenus, il est permis d'utiliser CAPOce qui limite les hypothèses sur le taux de change ou l’appréciation de la valeur.

L'absence d'un mécanisme de tarification robuste, des données obsolètes ou un risque élevé d'infrastructure des oracles devraient être directement reflétés dans les recommandations de liste, les paramètres de risque et la surveillance.

Maîtrise des émissions et rôles privilégiés

Un bloc séparé est dédié aux droits d'accès et à l'émission de jetons.

Aave Labs propose de divulguer tous les rôles privilégiés tant dans le contrat ERC-20 que dans les modules externes pouvant affecter l'approvisionnement, les soldes, la transférabilité ou le rachat d'un actif.

Sur la liste :

• propriétaire;
• administrateur (admin);
• émetteur (monnayeur);
• brûleur;
• opérateur de pause (pauser);
• opérateur de liste noire (liste noire);
• rôles associés aux ponts et aux adaptateurs.

Pour ces rôles, une échelle de sécurité est introduite du niveau 0 au niveau 5. Les niveaux 0 à 1 sont considérés comme les moins fiables – une clé unique sans délai d'exécution ou une signature multiple sans majorité honnête.

La section sur les rejets et la combustion nécessite une documentation des fonctions d'émission, une liste des adresses autorisées, des limites et des restrictions de temps. Évalué séparément pire exposition à la menthe en dollars – par rapport à l'exposition potentielle aux garanties d'Aave.

Parmi les scénarios indésirables :

• émission illimitée ;
• la possibilité d'augmenter simultanément la limite d'émission et de l'utiliser avec une seule adresse ;
• gravure aléatoire de jetons à partir des portefeuilles des utilisateurs.

Risques de pause, de listes noires et de contrats renouvelés

Les fonctions pause et liste noire sont affectées à une zone de risque distincte. Ils peuvent affecter directement les liquidations et les retraits de fonds. La direction doit comprendre qui contrôle ces pouvoirs et si le mécanisme de blocage d'adresses pourrait perturber les éliminations de protocole.

Pour les contrats mis à jour, vous devrez divulguer le type de proxy, l'administrateur de mise à jour, la présence d'un timelock et l'historique des mises à niveau. Le mécanisme de mise à jour faible est directement décrit comme ne répondant pas à la norme de cotation.

Exigences supplémentaires pour LST et LRT

Pour LST, TLRles wrappers et les jetons de stockage introduisent des exigences supplémentaires pour la mécanique des taux de change.

Il est proposé de vérifier :

• la possibilité de manipuler le taux de change grâce à des dons, prêts flash ou des fonctionnalités comptables ;
• disponibilité d'un mécanisme de remboursement clair ;
• suffisance de liquidité secondaire pour les liquidations.

Un actif sans mécanisme de remboursement transparent et sans liquidité suffisante peut faire l'objet de restrictions importantes sur les paramètres de cotation et de risque ou être envoyé pour révision.

L'initiative poursuit le cap annoncé après l'incident avec KelpDAO. Début mai, le protocole a annoncé son intention de réviser les normes d'évaluation et de cotation des garanties, en étendant l'attention de la volatilité et de la liquidité à la cybersécurité, à l'interopérabilité et à l'architecture technique.

Cependant, l'ARFC n'introduit pas de système de notation automatique et ne contient pas de liste universelle de facteurs d'arrêt. Les rapports techniques peuvent inclure des évaluations qualitatives et un étiquetage des risques, mais il n'existe pas de seuils stricts pour le refus automatique d'inscription.

Rappelons qu'en mai, le protocole d'atterrissage Aave a restauré les paramètres de provisionnement du wETH dans six réseaux.

Vous avez trouvé une erreur dans le texte ? Sélectionnez-le et appuyez sur CTRL+ENTRÉE