Zdekodowany rekord on-chain opublikowany na forum zarządzania Aave dokumentuje trzy nadania RISK_ADMIN_ROLE wykonane na kontrakcie Aave V3 Ethereum ACLManager między 2 a 30 września 2026 r. Zgodnie z rekordem wszystkie trzy nadania pochodziły z adresu Executora zarządzania protokołu, a jedno z nich jest bezpośrednio powiązane z propozycją aktywującą Risk Stewards na Aave V4.

Co pokazuje zdekodowany rekord

Zdekodowany post zarządzania on-chain (ACLManager RISK_ADMIN_ROLE grants, Sep 2026 — decoded) wskazuje trzy odrębne zdarzenia nadania zapisane w kontrakcie ACLManager, centralnym rejestrze kontroli dostępu architektury V3 protokołu Aave. ACLManager to kontrakt, poprzez który Aave V3 przypisuje i zarządza rolami administracyjnymi w całym protokole, więc zapisy w nim określają, kto posiada delegowaną władzę nad parametrami ryzyka. W architekturze zarządzania Aave kontrakt Executor realizuje na łańcuchu zatwierdzone propozycje. Wszystkie trzy transakcje pochodziły z adresu 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A, czyli Executora zarządzania, zgodnie ze zdekodowanym postem.

Dwa nadania zostały zrealizowane w bloku 25,891,729 dnia 2 września 2026 r., obejmując adresy 0xbe28...7744 i 0x529e...F6c5. Dokładne tożsamości kontraktów tych dwóch odbiorców zostały oznaczone jako niepotwierdzone w źródle pierwotnym; według dekodowania on-chain ich rola i cel nie zostały w pełni zweryfikowane w chwili publikacji.

Trzecie nadanie, w bloku 26,089,561 dnia 30 września 2026 r., trafiło do zweryfikowanego kontraktu RiskSteward zawierającego około 20,061 bajtów wdrożonego kodu. To nadanie jest bezpośrednio powiązane z AIP-523, "Activate Aave Risk Stewards on Aave V4" (propozycja zarządzania), która została wykonana około tej samej daty.

Dlaczego RISK_ADMIN_ROLE ma znaczenie dla nadzoru nad protokołem

RISK_ADMIN_ROLE znajduje się poniżej pełnego poziomu zarządzania w hierarchii kontroli dostępu Aave. Posiadacze mogą aktualizować ustawienia współczynnika rezerwy, limity podaży i pożyczek, wskaźniki loan-to-value, progi likwidacji, premie likwidacyjne oraz konfiguracje kategorii E-Mode bez wywoływania osobnego głosowania zarządczego dla każdej zmiany. Łącznie te mechanizmy kontrolne określają, ile danego aktywa może wejść na rynek, jak zabezpieczenia są traktowane podczas likwidacji oraz jak aktywa o skorelowanym zachowaniu cen są grupowane dla wyższej efektywności pożyczkowej. Posiadacze RISK_ADMIN_ROLE nie mogą natomiast wstrzymywać ani wznawiać rezerw, ani je całkowicie aktywować lub dezaktywować; te działania pozostają w gestii ról o wyższych uprawnieniach.

Praktyczną konsekwencją jest szybkość. Menedżerowie ryzyka protokołu działający w ramach RISK_ADMIN_ROLE mogą reagować na warunki rynkowe, zmiany płynności lub anomalie wyroczni w ciągu godzin zamiast czekać na wielodniowy cykl zarządzania. Rola jest w praktyce wykorzystywana często: według analizy powyIncidentu rsETH z kwietnia 2026 r. Risk Stewards Aave V3 wykonali już około 295 indywidualnych zmian parametrów w rezerwach V3.

AIP-523 rozszerza architekturę na Aave V4

AIP-523 rozszerza ten model na Aave V4 na Ethereum, Avalanche i Base. Propozycja nadaje ograniczoną i odwoływalną władzę RISK_ADMIN_ROLE, która jest ograniczona twardymi limitami parametrów, zamiast polegać wyłącznie na reputacji odbiorcy, a framework Risk Stewards Aave V4 został zaprojektowany, aby sformalizować te ograniczenia on-chain.

Zgodnie z wątkiem zarządzania AIP-523 limity podaży i pożyczek mogą zostać zwiększone o maksymalnie 50% w ramach pojedynczej aktualizacji Risk Steward w frameworku V4.

Okresy cooldown dodają drugą warstwę ograniczeń. Zmiany stopy procentowej i limitów huba podlegają okresowi cooldown 36 godzin; parametry szprych i zabezpieczeń wymagają 72 godzin; a aktualizacje limitów cen wyroczni mieszczą się w przedziale 48–72 godzin. Te interwały mają zapobiegać błyskawicznym zmianom, które mogłyby zostać wykorzystane lub narastać do istotnych zmian strukturalnych bez wiedzy społeczności.

Rozważania zarządcze i otwarte pytania

Pytanie projektowe podniesione przez wrześniowe nadania nie dotyczy tego, czy rola jest użyteczna — to oczywiste — lecz tego, czy społeczność zarządzania zachowuje realną zdolność przeglądu po wprowadzeniu roli. Autor posta na forum, MconnectDAO, zapytał wprost: "jak Aave zapewni, że dyskusja społeczności pozostanie istotna, a nie tylko formalnym procesem zatwierdzania?" Obawa ma charakter strukturalny: głosowanie zarządcze nadające kontraktowi roli bezterminowej faktycznie preautoryzuje wszystkie przyszłe zmiany parametrów w granicach zakodowanych w tym kontrakcie.

Autor Roch33 przedstawił podstawowy standard przejrzystości, który częściowo odpowiada na tę obawę, postulując, aby każda zmiana parametru rejestrowała poprzednią i nową wartość, stosowaną limit zatwierdzony przez zarządzanie, użyte źródło danych oraz uzasadnienie zmiany. Taki poziom ujawnień on-chain i na forum pozwoliłby społeczności audytować, czy działania Risk Steward są defensywnymi reakcjami na dane rynkowe, czy stopniowym przesuwaniem granic.

Dwóch odbiorców z 2 września, 0xbe28...7744 i 0x529e...F6c5, pozostaje otwartym pytaniem. Post dekodowania on-chain oznaczył ich tożsamość jako nie w pełni potwierdzoną, a żadne dotychczasowe doniesienia nie ustaliły, jakie kontrakty lub dostawcy usług reprezentują te adresy. Dopóki to nie zostanie ustalone, społeczność nie może w pełni ocenić zakresu delegowanej władzy związanego ze zdarzeniem nadania z 2 września w bloku 25,891,729. Najbardziej konkretne kroki następcze to zatem potwierdzenie tych odbiorców, ujawnienie kolejnych zmian parametrów względem zatwierdzonych limitów oraz ewentualne późniejsze działania zarządcze dotyczące nadań.

W przypadku nadania RiskSteward z 30 września powiązanego z AIP-523 odwoływalność jest kluczową cechą projektu. Executor zarządzania, który nadał rolę, może ją odwołać poprzez kolejną propozycję, a ograniczone limity parametrów zakodowane w samym kontrakcie stanowią zabezpieczenie przed dryfem parametrów nawet, jeśli rola nie zostanie odwołana. Połączenie odwoływalności i zakodowanych limitów ma na celu utrzymanie delegowanej władzy nad ryzykiem w podległości wobec zarządzania. Przegląd architektury V4 z 2026 r. szczegółowo opisuje, jak protokół obsługuje delegowanie ryzyka między łańcuchami w ramach nowego frameworku.