Ein decodierter On-Chain-Eintrag im Governance-Forum von Aave dokumentiert drei RISK_ADMIN_ROLE-Grants, die zwischen dem 2. und dem 30. September 2026 auf dem Aave V3 Ethereum ACLManager-Contract ausgeführt wurden. Laut dem Eintrag gingen alle drei Grants von der Governance-Executor-Adresse des Protokolls aus, und einer davon ist direkt mit dem Vorschlag verknüpft, der die Risk Stewards auf Aave V4 aktiviert.

Was der decodierte Eintrag zeigt

Der decodierte On-Chain-Governance-Beitrag (ACLManager RISK_ADMIN_ROLE grants, Sep 2026 — decoded) identifiziert drei einzelne Grant-Ereignisse, die im ACLManager-Contract verzeichnet sind, dem zentralen Zugriffssteuerungsregister von Aave für die V3-Architektur. Der ACLManager ist der Contract, über den Aave V3 administrative Rollen protokollweit vergibt und verwaltet; die dort verzeichneten Einträge definieren also, wer delegierte Befugnisse über Risikoparameter besitzt. In Aaves Governance-Architektur führt der Executor-Contract genehmigte Vorschläge on-chain aus. Alle drei Transaktionen gingen laut dem decodierten Beitrag von 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A aus, dem Governance-Executor.

Zwei Grants wurden am 2. September 2026 im Block 25.891.729 verzeichnet und zielten auf die Adressen 0xbe28...7744 und 0x529e...F6c5. Die genauen Contract-Identitäten dieser beiden Empfänger wurden in der Primärquelle als unbestätigt markiert; laut der On-Chain-Decodierung waren ihre Rolle und ihr Zweck zum Zeitpunkt der Veröffentlichung nicht vollständig verifiziert.

Der dritte Grant, im Block 26.089.561 am 30. September 2026, ging an einen verifizierten RiskSteward-Contract mit rund 20.061 Bytes bereitgestellten Codes. Dieser Grant ist direkt an AIP-523, „Activate Aave Risk Stewards on Aave V4" (Governance-Vorschlag), gebunden, der etwa zum selben Zeitpunkt ausgeführt wurde.

Warum die RISK_ADMIN_ROLE für die Protokollaufsicht wichtig ist

Die RISK_ADMIN_ROLE liegt in Aaves Hierarchie der Zugriffssteuerung unterhalb der vollständigen Governance-Ebene. Inhaber dieser Rolle können Reserve-Factor-Einstellungen, Supply- und Borrow-Caps, Loan-to-Value-Quoten, Liquidation Thresholds, Liquidation Bonuses und E-Mode-Kategoriekonfigurationen aktualisieren, ohne für jede Anpassung eine separate Governance-Abstimmung auszulösen. Zusammen bestimmen diese Kontrollen, wie viel eines Assets in einen Markt gelangen kann, wie Sicherheiten bei Liquidationen behandelt werden und wie Assets mit korreliertem Preisverhalten für höhere Krediteffizienz gruppiert werden. Was Inhaber der RISK_ADMIN_ROLE nicht können, ist Reserven pausieren oder fortsetzen bzw. vollständig aktivieren oder deaktivieren; diese Maßnahmen bleiben höherprivilegierten Rollen vorbehalten.

Die praktische Folge ist Geschwindigkeit. Protokoll-Riskmanager unter der RISK_ADMIN_ROLE können auf Marktbedingungen, Liquiditätsverschiebungen oder Oracle-Anomalien innerhalb von Stunden reagieren, statt einen mehrtägigen Governance-Zyklus abzuwarten. Die Rolle wird in der Praxis häufig ausgeübt: Stand der Post-Mortem-Analyse zum rsETH-Vorfall im April 2026 hatten die Aave V3 Risk Stewards bereits rund 295 einzelne Parameteränderungen über die V3-Reserven hinweg ausgeführt.

AIP-523 erweitert die Architektur auf Aave V4

AIP-523 erweitert dieses Modell auf Aave V4 auf Ethereum, Avalanche und Base. Der Vorschlag verleiht eine begrenzte, widerrufbare RISK_ADMIN_ROLE-Befugnis, die durch harte Parametergrenzen eingeschränkt ist und nicht allein auf dem Ruf des Empfängers beruht; das Aave V4 Risk Stewards Framework wurde entwickelt, um diese Beschränkungen on-chain zu formalisieren.

Supply- und Borrow-Caps dürfen im V4-Framework in einer einzelnen Risk-Steward-Aktualisierung um höchstens 50 % erhöht werden, wie aus dem AIP-523-Governance-Thread hervorgeht.

Cooldown-Perioden bilden eine zweite Einschränkungsebene. Änderungen an Hub-Zinssätzen und Caps unterliegen einer 36-stündigen Cooldown-Periode; Spoke- und Sicherheitenparameter erfordern 72 Stunden; Updates der Oracle-Preisgrenzen liegen im Bereich von 48 bis 72 Stunden. Diese Intervalle sollen schnelle Anpassungen verhindern, die ausgenutzt werden oder sich ohne Sichtbarkeit der Community zu erheblichen strukturellen Änderungen summieren könnten.

Governance-Erwägungen und offene Fragen

Die durch die September-Grants aufgeworfene Designfrage lautet nicht, ob die Rolle nützlich ist – das ist sie offensichtlich –, sondern ob die Governance-Community nach Einführung der Rolle über eine aussagekräftige Prüfkraft verfügt. Der Forums-Beitragende MconnectDAO fragte direkt: „how will Aave ensure that community discussion remains meaningful and not only a formal approval process?" Die Sorge ist struktureller Natur: Eine Governance-Abstimmung, die einem Contract eine unbefristete Rolle verleiht, autorisiert faktisch alle künftigen Parameteränderungen innerhalb der im Contract kodierten Grenzen vor.

Beitragende Roch33 skizzierte eine Transparenz-Grundlinie, die einen Teil dieser Sorge adressieren würde, und forderte, dass jede Parameteränderung den vorherigen und den neuen Wert, die angewandte governance-genehmigte Grenze, die verwendete Datenquelle sowie die Begründung der Änderung protokolliert. Dieses Maß an On-Chain- und Forum-Offenlegung würde es der Community ermöglichen zu prüfen, ob Risk-Steward-Maßnahmen defensive Reaktionen auf Marktdaten oder schrittweise Grenzausweitungen sind.

Die beiden Empfänger vom 2. September, 0xbe28...7744 und 0x529e...F6c5, bleiben eine offene Frage. Der On-Chain-Decodierungsbeitrag kennzeichnete ihre Identität als nicht vollständig bestätigt, und keine bestehende Berichterstattung hat geklärt, welche Contracts oder Dienstleister diese Adressen repräsentieren. Solange dies nicht feststeht, kann die Community den Umfang der delegierten Befugnisse im Zusammenhang mit dem Grant-Ereignis vom 2. September im Block 25.891.729 nicht vollständig beurteilen. Die konkretesten Folgepunkte sind daher die Bestätigung dieser Empfänger, die Offenlegung nachfolgender Parameteränderungen gegenüber ihren genehmigten Grenzen sowie etwaige spätere Governance-Maßnahmen zu den Grants.

Beim RiskSteward-Grant vom 30. September, der mit AIP-523 verknüpft ist, ist der Widerrufbarkeit ein Kernelement des Designs. Der Governance-Executor, der die Rolle vergeben hat, kann sie über einen nachfolgenden Vorschlag widerrufen, und die im Contract selbst kodierten begrenzten Parameter-Caps bieten einen Schutzmechanismus gegen Parameterdrift, selbst wenn die Rolle nicht widerrufen wird. Die Kombination aus Widerrufbarkeit und kodierten Grenzen soll sicherstellen, dass die delegierte Risikobefugnis der Governance untergeordnet bleibt. Aaves 2026er Übersicht der V4-Architektur behandelt im Detail, wie das Protokoll die grenzüberschreitende Risikodelegation im neuen Framework handhabt.