Aave Labs a publié le 29 mai une proposition ARFC (Aave Request for Comment) proposant d’établir un cadre technique standardisé de mise en ligne d’actifs pour Aave V3, V4 et Horizon. Les actifs présentant de graves défauts techniques feront l’objet d’une réduction des plafonds d’emprunt, de restrictions des paramètres de collatéral, d’un report de la mise en ligne ou d’une recommandation de refus d’intégration à la plateforme. La proposition précise que le cadre ne remplace pas l’analyse des risques liés au marché et les jugements de gouvernance, mais fournit une base technique de qualification.
Les sept « risques cachés » confirmés par la proposition ARFC et la conception centrale du cadre
Dans la proposition, Aave Labs confirme que le cadre vise à traiter sept catégories de « risques cachés » : émission illimitée, contrôle faible des mises à niveau, incohérences d’approvisionnement via ponts, absence de transparence du chemin de rachat, dépendance à la garde hors chaîne, chemins d’oracle peu fiables, ainsi que l’absence d’audit des dépendances externes. La proposition met particulièrement l’accent sur un examen supplémentaire des actifs dépendants hors chaîne tels que les actifs inter-chaînes, les actifs générateurs de rendement et les RWA, y compris la structure des ponts, les arrangements juridiques hors chaîne, les mécanismes de garde et l’intégrité de l’approvisionnement.
Le cadre définit six niveaux de sécurité pour des rôles privilégiés (niveau 0 à niveau 5), allant de l’absence de délai pour une clé unique (niveau 0) à la gouvernance DAO on-chain avec time-lock (niveau 5) ; les cas où le niveau de sécurité est inférieur à 2 sont définis comme une « configuration de sécurité faible », ce qui déclenchera des restrictions d’accès plus strictes. Concernant les chemins d’oracle, Chainlink constitue la principale source de données requise, et toute conception qui n’est pas basée sur Chainlink doit fournir une justification claire.
Le processus d’intégration de gouvernance en six étapes et le mécanisme de mise à jour annuelle confirmés par la proposition
Aave Labs confirme que le cadre doit être intégré au processus de mise en ligne des actifs selon une procédure en six étapes : présélection (vérifier la classification AAcA et la validation des contrats), examen technique (évaluer selon les huit sections centrales du cadre), coordination avec le fournisseur de risques, publication des documents de gouvernance, suivi des corrections, et mise à jour continue.
La proposition confirme que l’évaluation de tous les actifs actifs listés doit être mise à jour une fois par an, et immédiatement après tout changement majeur, y compris les mises à niveau de contrats, les déploiements de nouveaux réseaux, les changements de routage des ponts, les changements de détenteurs de rôles privilégiés et les événements de sécurité. L’émetteur doit notifier à l’avance Aave Labs et les parties concernées au niveau du DAO les changements pertinents conformément aux obligations continues.
Questions fréquentes
Quel est l’état actuel de gouvernance de la proposition ARFC d’Aave Labs, et a-t-elle été approuvée ?
L’ARFC fait partie du processus « Aave Request for Comment » et constitue une phase de discussion d’une proposition de gouvernance ; elle n’est pas encore entrée dans un vote officiel ou une approbation. La proposition doit être examinée et votée par les participants à la gouvernance d’Aave DAO avant de pouvoir être mise en œuvre officiellement.
Le cadre couvre quels scénarios, et pour lesquels ne s’applique-t-il pas ?
Selon la proposition confirmée, le cadre s’applique à : l’ajout d’actifs sur n’importe quelle instance de Aave V3, V4 et Horizon ; les changements majeurs de paramètres d’actifs déjà listés ; et les mises à jour techniques régulières ou non périodiques. Le cadre ne remplace pas l’analyse des risques liés à la liquidité et à la profondeur de marché ; cette partie reste sous la responsabilité des fournisseurs de risques du DAO.
Quel type de défaut technique déclenche un refus d’intégration ou une restriction de mise en ligne ?
Selon la proposition confirmée, les défauts qui déclenchent des restrictions incluent : la frappe sans limites, une « configuration de sécurité faible » avec des rôles privilégiés dont le niveau de sécurité est 0 ou 1, des incohérences d’approvisionnement via ponts, l’absence d’un chemin d’oracle approprié, et des problèmes d’audit graves ou à haut risque qui n’ont pas été résolus. Ces défauts entraîneront une réduction des plafonds d’emprunt, une limitation des paramètres des collatéraux ou une recommandation de refus d’intégration à la plateforme.
