Un registro on-chain decodificato pubblicato sul forum di governance di Aave documenta tre concessioni di RISK_ADMIN_ROLE eseguite sul contratto ACLManager di Aave V3 Ethereum tra il 2 e il 30 settembre 2026. Secondo il registro, tutte e tre le concessioni provengono dall'indirizzo Executor della governance del protocollo, e una di esse è direttamente collegata alla proposta che attiva i Risk Steward su Aave V4.

Cosa mostra il registro decodificato

Il post di governance on-chain decodificato (ACLManager RISK_ADMIN_ROLE grants, Sep 2026 — decoded) identifica tre eventi di concessione distinti registrati nel contratto ACLManager, il registro centrale di controllo degli accessi di Aave per l'architettura V3. L'ACLManager è il contratto attraverso cui Aave V3 assegna e gestisce i ruoli amministrativi in tutto il protocollo, quindi le voci registrate lì definiscono chi detiene l'autorità delegata sui parametri di rischio. Nell'architettura di governance di Aave, il contratto Executor porta on-chain le proposte approvate. Secondo il post decodificato, tutte e tre le transazioni provengono da 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A, l'Executor della governance.

Due concessioni sono state registrate al blocco 25.891.729 il 2 settembre 2026, indirizzate agli indirizzi 0xbe28...7744 e 0x529e...F6c5. Le esatte identità contrattuali di questi due beneficiari sono state segnalate come non confermate nella fonte primaria; secondo la decodifica on-chain, il loro ruolo e scopo non erano stati pienamente verificati al momento della pubblicazione.

La terza concessione, al blocco 26.089.561 il 30 settembre 2026, è andata a un contratto RiskSteward verificato contenente circa 20.061 byte di codice distribuito. Tale concessione è direttamente collegata ad AIP-523, "Activate Aave Risk Stewards on Aave V4" (proposta di governance), eseguita all'incirca nella stessa data.

Perché RISK_ADMIN_ROLE è rilevante per la supervisione del protocollo

Il RISK_ADMIN_ROLE si colloca al di sotto del livello di governance completa nella gerarchia di controllo degli accessi di Aave. I detentori possono aggiornare le impostazioni del reserve factor, i tetti di supply e borrow, i rapporti loan-to-value, le soglie di liquidazione, i bonus di liquidazione e le configurazioni delle categorie E-Mode senza innescare un voto di governance separato per ogni aggiustamento. Insieme, questi controlli determinano quanta parte di un asset può entrare in un mercato, come la garanzia viene trattata durante le liquidazioni e come gli asset con comportamenti di prezzo correlati vengono raggruppati per una maggiore efficienza di prestito. Ciò che i detentori di RISK_ADMIN_ROLE non possono fare è mettere in pausa o riattivare le riserve, o attivarle e disattivarle completamente; tali azioni restano a ruoli con privilegi superiori.

L'implicazione pratica è la velocità. I gestori del rischio del protocollo che operano sotto RISK_ADMIN_ROLE possono rispondere alle condizioni di mercato, agli spostamenti di liquidità o alle anomalie degli oracle entro ore, anziché attendere un ciclo di governance di più giorni. Il ruolo è esercitato frequentemente nella pratica: alla data della post-mortem di aprile 2026 sull'incidente rsETH, i Risk Steward di Aave V3 avevano già eseguito circa 295 modifiche individuali di parametri sulle riserve V3.

AIP-523 estende l'architettura ad Aave V4

AIP-523 estende questo modello ad Aave V4 su Ethereum, Avalanche e Base. La proposta concede un'autorità RISK_ADMIN_ROLE limitata e revocabile, vincolata da limiti rigidi ai parametri anziché basarsi solo sulla reputazione del beneficiario, e il framework dei Risk Steward di Aave V4 è stato progettato per formalizzare tali vincoli on-chain.

Secondo il thread di governance di AIP-523, i tetti di supply e borrow possono essere aumentati di non più del 50% in un singolo aggiornamento di un Risk Steward sotto il framework V4.

I periodi di cooldown aggiungono un secondo livello di vincolo. Le modifiche ai tassi di interesse e ai tetti dell'hub prevedono un cooldown di 36 ore; i parametri degli spoke e delle garanzie richiedono 72 ore; gli aggiornamenti dei tetti dei prezzi degli oracle rientrano nell'intervallo tra 48 e 72 ore. Questi intervalli sono progettati per prevenire aggiustamenti rapidi che potrebbero essere sfruttati o accumularsi in modifiche strutturali significative senza visibilità per la community.

Considerazioni di governance e questioni aperte

La questione di design sollevata dalle concessioni di settembre non è se il ruolo sia utile — lo è chiaramente — ma se la community di governance mantenga una capacità di revisione significativa una volta che il ruolo sia in vigore. Il contributor del forum MconnectDAO ha chiesto direttamente: "come garantirà Aave che la discussione della community rimanga significativa e non solo un processo di approvazione formale?" La preoccupazione è strutturale: un voto di governance che concede un ruolo a tempo indefinito a un contratto pre-autorizza di fatto tutte le future modifiche dei parametri entro i limiti codificati in quel contratto.

Il contributor Roch33 ha delineato un livello base di trasparenza che affronterebbe parte di questa preoccupazione, chiedendo che ogni modifica di parametro registri il valore precedente e il nuovo valore, il limite approvato dalla governance applicato, la fonte dati utilizzata e la motivazione alla base dell'aggiornamento. Tale livello di divulgazione on-chain e sul forum permetterebbe alla community di verificare se le azioni dei Risk Steward siano risposte difensive ai dati di mercato o un progressivo spinta dei limiti.

I due beneficiari del 2 settembre, 0xbe28...7744 e 0x529e...F6c5, restano una questione aperta. Il post di decodifica on-chain ha segnalato la loro identità come non pienamente confermata, e nessuna copertura esistente ha chiarito quali contratti o fornitori di servizi rappresentino questi indirizzi. Finché ciò non sarà stabilito, la community non potrà valutare pienamente la portata dell'autorità delegata associata all'evento di concessione del 2 settembre al blocco 25.891.729. I punti di follow-up più concreti sono quindi la conferma di quei beneficiari, la divulgazione delle successive modifiche dei parametri rispetto ai limiti approvati e qualsiasi successiva azione di governance relativa alle concessioni.

Per la concessione RiskSteward del 30 settembre collegata ad AIP-523, la revocabilità è una caratteristica centrale del design. L'Executor della governance che ha concesso il ruolo può revocarlo tramite una proposta successiva, e i limiti ai parametri codificati nel contratto stesso forniscono un interruttore di sicurezza contro la deriva dei parametri anche se il ruolo non viene revocato. La combinazione di revocabilità e limiti codificati è intesa a mantenere l'autorità di rischio delegata subordinata alla governance. La panoramica 2026 di Aave sull'architettura V4 copre in dettaglio come il protocollo gestisce la delega del rischio cross-chain sotto il nuovo framework.