La gouvernance d’Aave évalue un cadre de risque à l’échelle du protocole qui s’appliquerait à chaque actif sur Aave V3, V4 et Aave Horizon, le fondateur Stani Kulechov déclarant que les actifs qui ne sont pas éligibles à la nouvelle norme seront supprimés. Une proposition complémentaire déplacerait l’oracle des risques Pendle PT vers une infrastructure appartenant à un protocole construite sur l’environnement d’exécution Chainlink.
Le fournisseur de services de gestion des risques LlamaRisk a publié mardi les deux propositions de demande de commentaires d’Aave sur le forum de gouvernance d’Aave. Le cadre plus large, publié mardi matin, couvre quatre niveaux de risque : le risque d’actif, le risque de pontage, la surveillance et les risques automatisés des systèmes Oracle et le risque de chaîne.
« Après l’adoption de la proposition, le cadre de risque sera appliqué à tous les marchés et actifs », a écrit Kulechov sur X mardi matin. « Les actifs qui ne répondent pas aux exigences de la nouvelle norme seront retirés d’Aave au cours des prochaines semaines. »
Les propositions constituent la première réponse concrète de gouvernance structurelle d’Aave à l’exploit KelpDAO LayerZero en avril, dans lequel les attaquants ont drainé 116 500 rsETH, les ont déposés en garantie sur les marchés Ethereum et Arbitrum d’Aave et ont emprunté 193 millions de dollars directement au protocole. Le total des garanties fournies par les attaquants a atteint 221,39 millions de dollars, selon le rapport d’incident de LlamaRisk du 20 avril. Un rapport d’incident LayerZero en mai, couvert par The Defiant, a révélé que le pont avait été rétrogradé d’une configuration DVN 2 sur 2 à une configuration DVN 1 sur 1 avant l’exploit.
Le cadre à quatre niveaux
Le framework régit Aave V3, V4 et Aave Horizon. Elle s’applique lors de l’intégration des actifs, lors des actualisations trimestrielles de due diligence et à chaque décision ultérieure de paramètre ou de dépréciation.
La layer 1 couvre le risque lié aux actifs, nécessitant une couverture d’audit, des programmes actifs de bug bounty, une liquidité de liquidation suffisante, des délais opportuns et une divulgation opérationnelle de l’émetteur. Les conditions de blocage strict incluent des programmes de bug bounty manquants ou matériellement faibles, une composition de signataires non divulguée et le refus de divulguer la pile opérationnelle. Un blocage dur arrête complètement l’intégration ; pour les actifs déjà cotés, cela déclenche un examen immédiat du niveau d’exposition.
La layer 2 traite du risque de pontage, en fixant un plancher contraignant sur les seuils définis par le vérificateur pour tout actif qui traverse les chaînes. L’exigence est indépendante du fournisseur : elle s’applique quelle que soit la pile de pont utilisée par l’émetteur. Un actif dont la configuration de pont ne répond pas à un élément obligatoire bénéficie d’un niveau d’exposition plus strict, comprenant des ratios prêt/valeur plus faibles et des plafonds d’offre plus faibles, jusqu’à ce que la remédiation soit terminée. L’exploit rsETH a traversé exactement cette lacune : la route Unichain-to-Ethereum a été configurée comme un DVN 1 sur 1, permettant à un paquet entrant falsifié de libérer 116 500 rsETH de l’adaptateur sans aucune gravure correspondante côté source.
La couche 3 codifie les systèmes de surveillance et d’oracle des risques automatisés en tant qu’infrastructure de protocole permanente, et non en tant qu’outils facultatifs. La couche 4 traite du risque de chaîne, en établissant des critères d’évaluation qui déterminent si Aave se déploie sur une chaîne et en fixant une limite supérieure permanente pour le niveau d’exposition de chaque actif répertorié sur cette chaîne.
Chaque recommandation générée par le cadre comporte un délai de mise en œuvre d’un mois. Les recommandations non mises en œuvre dans un délai d’un mois se transforment automatiquement en contraintes strictes sur le niveau d’exposition de l’actif.
PT Oracle appartenant au protocole
L’ARFC compagnon propose de migrer l’oracle des risques Pendle PT de l’arrangement actuel vers une infrastructure appartenant à un protocole sur l’environnement d’exécution Chainlink, connu sous le nom de CRE.
Le principal changement est la propriété. Dans la configuration précédente, les gestionnaires de risques détenaient une autorité d’écriture sur les paramètres Oracle clés avec une auditabilité en chaîne limitée. Aave Governance était propriétaire des contrats de destination, mais pas du système hors chaîne calculant les entrées. Dans le cadre de la structure proposée, Aave Governance détiendrait tous les contrats en cours. LlamaRisk détient uniquement un rôle de mise à jour sur un nouveau ParameterRegistry en chaîne, lui permettant d’ajuster les paramètres de méthodologie par actif sans un redéploiement complet du CRE.
LlamaRisk exécute l’oracle PT manuellement et transmet les modifications de paramètres via le chemin Risk Stewards depuis que Chaos Labs a quitté la gestion des risques d’Aave en avril. Le message du forum sur la gouvernance qualifie cet arrangement de « voie de transition qui n’a jamais été censée être permanente ».
Trois flux de travail Chainlink CRE remplaceraient le processus manuel. Les flux de travail calculent les taux implicites lissés, les taux d’actualisation et les paramètres de liquidation par mode E pour chaque marché Pendle PT, chacun publiant un rapport signé qu’un nouveau routeur en chaîne valide. Le routeur écrit de manière atomique sur l’oracle et déclenche l’exécution en une seule transaction. Chaque changement de paramètre est enregistré en chaîne et vérifiable indépendamment.
Les audits Certora porteront à la fois sur les nouveaux contrats et sur le code workflow de la CRE. Deux des trois nouveaux contrats, LlamaguardRiskOracle et ParameterRegistry, ont déjà été audités par deux équipes de sécurité dans le cadre d’un déploiement antérieur de LlamaGuard NAV. Le routeur est le seul composant sans couverture d’audit préalable.
Contexte de l’arc
Les documents déposés mardi font suite à deux étapes antérieures dans la récupération d’Aave après l’exploit d’avril. En mai, Aave a rétabli les ratios prêt/valeur WETH sur Ethereum, Arbitrum, Base, Mantle et Linea dans le cadre du plan de redressement rsETH. Le même mois, LayerZero a publié son rapport d’incident complet, qui révélait que le pont avait été rétrogradé d’une configuration DVN 2 sur 2 à 1 sur 1 avant l’exploit.
Les deux ARFC sont en phase de rétroaction de la communauté. S’ils parviennent à un consensus communautaire, chacun passera à un vote instantané avant de passer à une proposition d’amélioration Aave en chaîne.
