Risk Framework
Jak Avana proponuje, przegląda i wykonuje zmiany ryzyka w Hubie i LP Collateral Spokes.
Przegląd
Avana Risk Framework definiuje, jak zmiany parametrów są proponowane, sprawdzane i wykonywane w Hubie oraz LP Collateral Spokes. Obejmuje kontrole używane, gdy protokół dostosowuje supply i borrow caps, ustawienia LT/LTV, wejścia stóp procentowych, status rynku i inne parametry zależne od cen, utilization, głębokości poola, koncentracji, zmienności, zachowania pegu, circuit breakerów, zdrowia pozycji i powiązanego stanu.
Zabezpieczenie LP nie jest jedną homogeniczną klasą aktywów. Stable LP, LP skorelowanych aktywów, poole ważone, concentrated liquidity i inne designy AMM mogą mieć własne ścieżki wyceny, likwidacji i tryby awarii właściwe dla spoke. Framework istnieje po to, by te różnice były odzwierciedlone w procesie aktualizacji zamiast być ukryte za jednym generycznym ustawieniem ryzyka.
Trzy role pozostają rozdzielone w całym tym procesie: Avana Risk Initiator, Avana Risk Guardian i Avana Risk Defender. Strona, która rekomenduje rutynową zmianę, nie jest tą samą stroną, która ją niezależnie sprawdza, a rola mogąca działać podczas awarii jest celowo węższa niż ścieżka rutynowa.
Reguła operacyjna: reducing risk should be easier than expanding it.
Core zasady
Rozdzielenie ról
Framework przypisuje proponowanie, przegląd i containment awaryjne różnym aktorom, żeby jedna strona nie kontrolowała całej ścieżki sama.
Ograniczona egzekucja
Rutynowe zmiany ryzyka wykonują się tylko wtedy, gdy pozostają w predefiniowanych granicach polityki i przechodzą kontrole walidacji.
Publiczna spójność
Aktualizacja opisana publicznie powinna być tą samą aktualizacją, która jest faktycznie kolejkowana do egzekucji.
Świadomość Spoke
Każde spoke zabezpieczenia LP niesie własne reguły listingu, założenia oracle, ścieżkę likwidacji i profil ryzyka.
Defensywna asymetria
Proces jest celowo stronniczy tak, by redukcja ryzyka była szybsza i prostsza niż jej rozszerzanie.
Role
Avana Risk Initiator
Rola, która przygotowuje i rekomenduje rutynowe zmiany ryzyka dla Hubu i LP Collateral Spokes.
- Opublikuj uzasadnienie i sklasyfikuj aktualizację jako defensywną lub growth-oriented
- Prześlij rutynowe aktualizacje do timelockowanej ścieżki egzekucji
- Rekomenduj zmiany supply caps, borrow caps, LT/LTV, reserve factor i stóp procentowych w zatwierdzonych zakresach
- Inicjuj de-risking na poziomie spoke i onboarding pooli w ramach wcześniej zatwierdzonych szablonów spoke
Avana Risk Guardian
Niezależny reviewer z uprawnieniem veta wobec kolejkowanych rutynowych zmian.
- Zweryfikuj, że kolejkowana aktualizacja odpowiada publicznemu ujawnieniu
- Sprawdź, że akcja pozostaje w zatwierdzonych granicach polityki
- Odrzuć aktualizacje oparte na nieważnych założeniach oracle, płynności lub likwidacji
- Anuluj kolejkowaną aktualizację w oknie timelocka, gdy tworzy oczywistą niestabilność na poziomie spoke lub Hubu
Avana Risk Defender
Rola wyłącznie awaryjna używana do containment incydentów, gdy normalna ścieżka timelockowana jest zbyt wolna.
- Obniż borrow caps lub supply caps do poziomów defensywnych
- Zamroź nowe pożyczanie na spoke albo zamroź użycie zabezpieczenia dla poola, szablonu lub spoke
- Wyłącz konkretny adapter lub ścieżkę pożyczki, gdy spełnione są predefiniowane warunki awarii
- Zablokuj origination nowego długu w warunkach awaryjnych — bez używania tej roli do rutynowej optymalizacji lub działań growth
Przepływ aktualizacji
Rutynowe zmiany podążają stałą ścieżką, żeby protokół mógł odróżnić normalne utrzymanie parametrów od containment awaryjnego. Standardowa sekwencja to publiczne ogłoszenie, zgłoszenie, kontrole granic, timelock, przegląd Guardian i egzekucja, jeśli propozycja nie zostanie zawetowana.
Publiczne ogłoszenie
Risk Initiator publikuje zamierzoną zmianę, dlaczego jest potrzebna i zakres, którego ma dotyczyć.
Submission
Risk Initiator umieszcza proponowaną zmianę w ścieżce egzekucji używanej przez framework.
Validation
Kontrole frameworku potwierdzają, że aktualizacja pozostaje w predefiniowanych ograniczeniach i zatwierdzonych granicach polityki.
Timelock
Jeśli walidacja przejdzie, zmiana wchodzi w okno timelocka zamiast wykonywać się natychmiast.
Przegląd Guardian
Podczas timelocka Risk Guardian przegląda dokładny kolejkowany payload i może go anulować, jeśli trzeba.
Execution
Jeśli zmiana przetrwa przegląd, wykonuje się automatycznie po wygaśnięciu timelocka.
Ścieżka awaryjna
Jeśli spełnione są warunki awaryjne, Risk Defender może użyć osobnej ścieżki defensywnej o węższym uprawnieniu.
Klasy parametrów
Zmiany parametrów nie niosą tego samego ryzyka, więc framework grupuje je według tego, ile uprawnień powinny wymagać i jak szybko powinny móc się ruszać.
Zmiany defensywne
To najszybsze rutynowe zmiany, bo redukują ekspozycję protokołu.
- Obniżanie borrow caps
- Obniżanie supply caps
- Redukcja LTV lub progu likwidacji
- Zamrażanie pożyczania lub użycia zabezpieczenia
- Zacieśnianie ustawień spoke
Rutynowe ograniczone zmiany
Podążają standardową trasą Initiator -> Guardian -> timelock w zatwierdzonych granicach.
- Umiarkowane podwyżki capów
- Umiarkowane strojenie parametrów w zatwierdzonych zakresach
- Dodawanie nowych pooli w istniejącym szablonie spoke
Zmiany na poziomie governance
Leżą poza rutynowym frameworkiem i wymagają ścieżki decyzyjnej wyższego poziomu.
- Tworzenie nowej rodziny spoke
- Włączanie nowego prymitywu LP
- Dodawanie nowego modelu oracle
- Włączanie nowego adaptera likwidacji
- Istotne rozszerzenie powierzchni ryzyka poza wcześniej zatwierdzone założenia
Publiczne ujawnienie
Każda rutynowa aktualizacja powinna być opublikowana przed zgłoszeniem w formacie, który pozwala developerom, użytkownikom i reviewerom porównać ogłoszenie z dokładną akcją, która później jest kolejkowana.
Minimalny standard ujawnienia
- Dotknięte spoke
- Dotknięte poole lub szablony
- Bieżące parametry
- Proponowane parametry
- Powód aktualizacji
- Czy aktualizacja jest defensywna, czy growth-oriented
- Oczekiwany timing zgłoszenia
- Oczekiwane okno timelocka
- Istotne zależności lub założenia
Spójne ujawnienie ułatwia przegląd propozycji pod kątem scope creep, niedopasowanych założeń lub prostych błędów egzekucji.
Akcje awaryjne
Akcje awaryjne służą containment, nie rutynowemu strojeniu. Powinny być używane rzadko, utrzymywane tak wąsko, jak to możliwe, i strukturyzowane tak, by protokół mógł wrócić do standardowej ścieżki, gdy bezpośrednie ryzyko jest już zrozumiane. Risk Defender powinien działać tylko wtedy, gdy zdefiniowany lub wysoce prawdopodobny warunek awarii czyni normalną trasę timelockowaną niebezpieczną.
Triggery awaryjne
- Niespójność oracle
- Degradacja ścieżki likwidacji
- Nienormalne zachowanie poola
- Awaria zależności wrappera
- Kompromitacja na poziomie adaptera
- Nagła niestabilność na poziomie spoke
Wymagane ujawnienie po akcji
- The trigger
- Podjęta akcja
- Zamierzony czas trwania
- Ścieżka powrotu do normalnej operacji
Uprawnienie awaryjne istnieje tylko dla zdefiniowanych lub wysoce prawdopodobnych przypadków awarii, w których czekanie na normalną ścieżkę timelocka jest niebezpieczne. To nie jest ścieżka do rutynowego growth ani optymalizacji.
Rekomendacja, przegląd i containment awaryjne pozostają rozdzielone, bo zabezpieczenie LP to zbiór rynków o różnych strukturach i trybach awarii — nie jedna wymienna lista aktywów.