Een gedecodeerd on-chain register gepubliceerd op het governanceforum van Aave documenteert drie RISK_ADMIN_ROLE-toekenningen die zijn uitgevoerd op het Aave V3 Ethereum ACLManager-contract tussen 2 en 30 september 2026. Volgens het register kwamen alle drie de toekenningen van het governance-Executor-adres van het protocol, en een ervan is direct gekoppeld aan het voorstel dat Risk Stewards op Aave V4 activeert.

Wat het gedecodeerde register laat zien

Het on-chain gedecodeerde governancebericht (ACLManager RISK_ADMIN_ROLE grants, Sep 2026 — decoded) identificeert drie afzonderlijke toekenningsgebeurtenissen vastgelegd in het ACLManager-contract, het centrale toegangsbeheerregister van Aave voor de V3-architectuur. De ACLManager is het contract waarmee Aave V3 administratieve rollen binnen het protocol toewijst en beheert, dus de daar vastgelegde registraties bepalen wie gedelegeerde bevoegdheid over risicoparameters heeft. In de governance-architectuur van Aave voert het Executor-contract goedgekeurde voorstellen on-chain uit. Alle drie de transacties kwamen van 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A, de governance-Executor, volgens het gedecodeerde bericht.

Twee toekenningen vonden plaats op blok 25.891.729 op 2 september 2026, gericht op de adressen 0xbe28...7744 en 0x529e...F6c5. De exacte contractidentiteiten van deze twee ontvangers werden in de primaire bron aangemerkt als onbevestigd; volgens de on-chain decodering waren hun rol en doel op het moment van publicatie niet volledig geverifieerd.

De derde toekenning, op blok 26.089.561 op 30 september 2026, ging naar een geverifieerd RiskSteward-contract met ongeveer 20.061 bytes aan uitgerolde code. Die toekenning is direct gekoppeld aan AIP-523, "Activate Aave Risk Stewards on Aave V4" (governance proposal), dat rond dezelfde datum werd uitgevoerd.

Waarom RISK_ADMIN_ROLE belangrijk is voor protocolltoezicht

De RISK_ADMIN_ROLE bevindt zich onder de volledige governance-tier in de toegangsbeheerhiërarchie van Aave. Houders kunnen instellingen voor de reserve factor, supply- en borrow-caps, loan-to-value-ratio's, liquidatiethresholds, liquidatiebonussen en E-Mode-categorieconfiguraties bijwerken zonder dat voor elke aanpassing een afzonderlijke governance-stemming nodig is. Samen bepalen deze controles hoeveel van een asset een markt kan betreden, hoe onderpand tijdens liquidaties wordt behandeld en hoe assets met gecorreleerd prijsgedrag worden gegroepeerd voor hogere leenefficiëntie. Wat RISK_ADMIN_ROLE-houders niet kunnen doen, is reserves pauzeren of hervatten, of ze volledig activeren of deactiveren; die handelingen blijven voorbehouden aan rollen met hogere bevoegdheden.

De praktische implicatie is snelheid. Protocolrisicomanagers die onder RISK_ADMIN_ROLE werken kunnen binnen enkele uren reageren op marktomstandigheden, liquiditeitsschommelingen of oracle-afwijkingen, in plaats van een meerdaagse governancecyclus af te wachten. De rol wordt in de praktijk vaak toegepast: ten tijde van het post-mortem van april 2026 over het rsETH-incident hadden de Aave V3 Risk Stewards al ongeveer 295 afzonderlijke parameterwijzigingen uitgevoerd op V3-reserves.

AIP-523 breidt de architectuur uit naar Aave V4

AIP-523 breidt dit model uit naar Aave V4 op Ethereum, Avalanche en Base. Het voorstel verleent begrensde, herroepbare RISK_ADMIN_ROLE-bevoegdheid die wordt beperkt door harde parameterlimieten in plaats van uitsluitend te vertrouwen op de reputatie van de ontvanger, en het Aave V4 Risk Stewards-framework is ontworpen om die beperkingen on-chain te formaliseren.

Supply- en borrow-caps mogen binnen het V4-framework in één Risk Steward-update met niet meer dan 50% worden verhoogd, volgens de AIP-523-governancedraad.

Cooldownperiodes vormen een tweede beperkingslaag. Wijzigingen in hub-rentetarieven en caps hebben een cooldown van 36 uur; spoke- en onderpandparameters vereisen 72 uur; en updates van oracle-prijslimieten vallen in het bereik van 48 tot 72 uur. Deze intervallen zijn ontworpen om snelle opeenvolgende aanpassingen te voorkomen die misbruikt zouden kunnen worden of zonder zichtbaarheid voor de gemeenschap zouden kunnen uitgroeien tot aanzienlijke structurele veranderingen.

Governance-overwegingen en openstaande vragen

De ontwerpvraag die door de septembertoekenningen wordt opgeroepen, is niet of de rol nuttig is — dat is duidelijk het geval — maar of de governancegemeenschap na invoering van de rol nog over betekenisvolle beoordelingscapaciteit beschikt. Forumlid MconnectDAO vroeg rechtstreeks: "how will Aave ensure that community discussion remains meaningful and not only a formal approval process?" De zorg is structureel: een governance-stemming die een onbegrensde rol toekent aan een contract autoriseert vooraf feitelijk alle toekomstige parameterwijzigingen binnen de gecodeerde grenzen van dat contract.

Bijdrager Roch33 schetste een transparantiebasis die een deel van deze zorg zou wegnemen, met de oproep dat elke parameterwijziging de vorige waarde en nieuwe waarde, de toegepaste goedgekeurde governancegrens, de gebruikte gegevensbron en de onderbouwing van de update vastlegt. Dat niveau van on-chain en forumdisclosure zou de gemeenschap in staat stellen te controleren of Risk Steward-handelingen defensieve reacties op marktgegevens zijn of geleidelijke grensverlegging.

De twee ontvangers van 2 september, 0xbe28...7744 en 0x529e...F6c5, blijven een openstaande vraag. Het on-chain decoderingsbericht merkte hun identiteit aan als niet volledig bevestigd, en geen enkele bestaande berichtgeving heeft opgehelderd welke contracten of dienstverleners deze adressen vertegenwoordigen. Tot dat vaststaat, kan de gemeenschap de reikwijdte van de gedelegeerde bevoegdheid die hoort bij de toekenningsgebeurtenis van 2 september op blok 25.891.729 niet volledig beoordelen. De meest concrete vervolgpunten zijn daarom de bevestiging van die ontvangers, de openbaarmaking van daaropvolgende parameterwijzigingen binnen hun goedgekeurde grenzen, en eventuele latere governance-acties met betrekking tot de toekenningen.

Voor de RiskSteward-toekenning van 30 september die gekoppeld is aan AIP-523 is herroepbaarheid een kernkenmerk van het ontwerp. De governance-Executor die de rol verleende kan deze herroepen via een volgend voorstel, en de begrensde parameterlimieten die in het contract zelf zijn gecodeerd, vormen een vangnet tegen parameterdrift, zelfs als de rol niet wordt herroepen. De combinatie van herroepbaarheid en gecodeerde limieten is bedoeld om gedelegeerde risicobevoegdheid ondergeschikt te houden aan governance. Aave's 2026-overzicht van de V4-architectuur beschrijft in detail hoe het protocol onder het nieuwe framework omgaat met cross-chain risicodelegatie.