Les électeurs d’Aave DAO décident de déléguer ou non des contrôles de risque V4 limités sur Ethereum et Avalanche à Risk Stewards, des outils qui permettent aux opérateurs approuvés d’apporter des modifications limitées sans passer chaque mise à jour par un vote de gouvernance complet. La proposition attribuerait également des rôles d’urgence sans délai que le logiciel de gestion actuel ne peut pas utiliser.
Le vote Snapshot s’est ouvert le 3 septembre à 15 h 46 UTC et devrait se terminer aujourd’hui, le 6 septembre, à la même heure. L’approbation n’activerait pas le système en soi. Aave Labs a déclaré que les charges utiles correspondantes devraient toujours être exécutées via le Conseil de sécurité V4.
Le code n’est pas non plus présenté comme entièrement audité. Dans sa proposition de gouvernance, Aave Labs a déclaré que les contrats Risk Steward faisaient l’objet d’un audit Certora et que l’engagement était en voie de finalisation.
La tension centrale de la proposition se situe entre l’autorité attribuée maintenant et les fonctionnalités disponibles plus tard. Chaque Risk Steward recevrait des rôles de gestion des risques Hub and Spoke ainsi que des rôles d’urgence Hub and Spoke. Ces quatre rôles n’auraient aucun délai d’exécution une fois accordés.
Cependant, la version considérée n’appelle aucun des sélecteurs d’urgence, et la documentation actuelle de l’intendant n’expose pas ces méthodes. Les autorisations d’urgence resteraient inertes jusqu’à ce qu’une future version ajoute la prise en charge. L’attribution des rôles maintenant permettrait à cette version ultérieure de répondre à une urgence sans attendre un autre cycle de gouvernance pour y accéder.
La refonte plus large des autorisations diviserait les contrôles du configurateur Hub and Spoke de chaque instance V4 en cinq catégories granulaires : deux rôles de contrôle d’indicateur, un rôle de liste, un rôle d’urgence et un rôle de gestion des risques. Les sélecteurs en dehors de ces catégories conserveraient des rôles d’administrateur de domaine résiduels. Les administrateurs de domaine existants recevront les nouveaux rôles afin que leur portée actuelle soit préservée.
Les définitions de rôle proposées limitent la catégorie d’urgence aux actions de sécurité à sens unique. Les appels Hub peuvent désactiver ou arrêter les actifs et les Spokes. Les appels Spoke peuvent suspendre ou geler des réserves individuelles ou toutes les réserves. Ces fonctions ne peuvent pas réactiver, relancer, relancer ou débloquer le marché concerné. Les rôles distincts de contrôle du pavillon, qui peuvent changer d’état dans les deux sens, ne seraient pas accordés aux Risk Stewards.
Les mises à jour de routine des paramètres s’effectueraient sous différents contrôles. La proposition fixe des temps de recharge minimum de 36, 48 ou 72 heures, selon le paramètre, et limite jusqu’où chaque mise à jour peut le déplacer. Les mêmes limites s’appliqueraient à Ethereum et Avalanche et couvriraient les paramètres de taux d’intérêt, les facteurs de garantie, les paramètres de liquidation et les plafonds oracles. Ils ne contraignent pas les sélecteurs d’urgence.
Cette séparation explique pourquoi le plan peut combiner une maintenance limitée plus lente avec une autorité d’urgence immédiate sur papier. Cela soulève également une question de responsabilité, car les rôles sans délai seraient en place avant que le délégué syndical puisse les exercer. Les participants au forum ont demandé des justifications publiques, des rapports post-action, des examens périodiques et des rapports sur la fréquence et l’ampleur des actions de gestion. Aucune de ces mesures ne constitue une exigence dans la proposition actuelle.
Si l’instantané réussit et que le Conseil de sécurité exécute les charges utiles, le changement immédiat serait un accès sans délai aux contrôles de paramètres limités. Les pouvoirs d’urgence unidirectionnels seraient prépositionnés pour une future version du steward, mais ils ne seraient pas encore utilisables.
