Ramy ryzyka
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. LP rynki różnią się pod względem składu aktywów, metod wyceny, sposobów likwidacji i trybów awarii. Stabilna, skorelowana, ważona i skoncentrowana płynność pools może więc wymagać różnych parametrów ryzyka. Ramy uwzględniają te różnice podczas przeglądu aktualizacji dla odnogi lub pool.
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: exposure-reducing actions follow a more direct path than changes that expand protocol risk.
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ść
Publiczne ujawnienie identyfikuje zmianę parametru zgłoszoną do wykonania, aby recenzenci mogli porównać powiadomienie z oczekującą ładunkiem.
Ś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
Ramowy plan daje działaniom zmniejszającym ekspozycję bardziej bezpośrednią drogę niż zmianom, które zwiększają ryzyko protokołu.
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 są grupowane według ich wpływu na ryzyko. Każda klasa definiuje wymaganą władzę i ścieżkę wykonania, od ograniczonych aktualizacji rutynowych po zmiany wymagające szerszej zgody organów zarządzających.
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
Ogłoszenie publiczne poprzedza zgłoszenie w rutynowym przepływie aktualizacji. Rejestruje ono dotknięte rynki i proponowane parametry, aby deweloperzy i recenzenci mogli porównać zadeklarowaną zmianę z ładunkiem oczekującym na wykonanie.
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
Porównanie tych pól z oczekującym ładunkiem ujawnia różnice w dotkniętych rynkach, wartościach parametrów, terminach lub założeniach przed wykonaniem.
Akcje awaryjne
Ścieżka awaryjna Risk Defendera jest ograniczona do powstrzymywania zdefiniowanych lub wysoce prawdopodobnych awarii, gdy oczekiwanie na normalny timelock byłoby niebezpieczne. Jej węższe uprawnienia pozwalają na działania obronne, takie jak ograniczenie pożyczek lub wyłączenie dotkniętego adaptera. Rutynowe zmiany parametrów nadal korzystają z procesu Inicjatora i Strażnika.
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.
Rozdzielenie ról proponowania, przeglądu i awaryjnych ma zastosowanie we wszystkich LP rynkach, podczas gdy każdy rynek zachowuje własne założenia wyceny, limity ryzyka i zachowania związane z likwidacją.