Перейти до основного вмісту
логотип Avana

Risk Framework

Як Avana пропонує, рев'ює та виконує ризик-зміни по Hub і LP Collateral Spokes.

Огляд

Avana Risk Framework визначає, як зміни параметрів пропонують, перевіряють і виконують по Hub і LP Collateral Spokes. Він покриває контроли під час коригування supply і borrow caps, налаштувань LT/LTV, входів відсоткових ставок, статусу ринку та інших параметрів, що залежать від цін, утилізації, глибини пулу, концентрації, волатильності, поведінки пега, circuit breakers, здоров'я позиції та пов'язаного стану.

LP-застава — не один однорідний клас активів. Стейбл LP, корельовані LP, зважені пули, концентрована ліквідність та інші дизайни AMM можуть мати свій шлях оцінки, шлях ліквідації й режим збою на рівні spoke. Фреймворк існує, щоб ці відмінності відображалися в процесі оновлення, а не ховалися за однією загальною ризик-налаштуванням.

Три ролі лишаються розділеними протягом процесу: Avana Risk Initiator, Avana Risk Guardian і Avana Risk Defender. Сторона, що рекомендує рутинну зміну, не та сама, що незалежно її перевіряє, а роль, яка може діяти в аварії, навмисно вужча за рутинний шлях.

Операційне правило: reducing risk should be easier than expanding it.

Базові принципи

Розділення ролей

Фреймворк призначає пропозицію, рев'ю та аварійне стримування різним акторам, щоб одна сторона не контролювала весь шлях наодинці.

Обмежене виконання

Рутинні ризик-зміни виконуються лише коли лишаються всередині заздалегідь заданих меж політики й проходять перевірки валідації.

Публічна узгодженість

Оновлення, описане публічно, має бути тим самим оновленням, яке реально ставлять у чергу на виконання.

Обізнаність про Spoke

Кожен LP collateral spoke несе свої правила лістингу, припущення оракула, шлях ліквідації та ризик-профіль.

Захисна асиметрія

Процес навмисно зміщений так, щоб знижувати ризик було швидше й простіше, ніж розширювати його.

Ролі

Avana Risk Initiator

Роль, яка готує й рекомендує рутинні ризик-зміни для Hub і LP Collateral Spokes.

  • Опублікувати обґрунтування й класифікувати оновлення як захисне або орієнтоване на зростання
  • Надсилати рутинні оновлення в шлях виконання з timelock
  • Рекомендувати зміни supply caps, borrow caps, LT/LTV, reserve factor та відсоткових ставок усередині схвалених діапазонів
  • Ініціювати de-risking на рівні spoke та онбординг пулів усередині заздалегідь схвалених шаблонів spoke

Avana Risk Guardian

Незалежний рев'юер із повноваженнями veto над поставленими в чергу рутинними змінами.

  • Перевірити, що поставлене в чергу оновлення збігається з публічним розкриттям
  • Перевірити, що дія лишається всередині схвалених меж політики
  • Відхиляти оновлення на основі невалідних припущень оракула, ліквідності чи ліквідації
  • Скасовувати поставлене в чергу оновлення у вікні timelock, коли воно створює очевидну нестабільність на рівні spoke або hub

Avana Risk Defender

Лише аварійна роль для стримування інцидентів, коли звичайний шлях із timelock надто повільний.

  • Знижувати borrow caps або supply caps до захисних рівнів
  • Заморожувати нове позичання на spoke або використання застави для пулу, шаблону чи spoke
  • Вимикати конкретний адаптер або шлях позики за заздалегідь визначених умов збою
  • Блокувати нове походження боргу в аварійних умовах, не використовуючи це для рутинної оптимізації чи дій зростання

Потік оновлень

Рутинні зміни йдуть фіксованим шляхом, щоб протокол відрізняв звичайне обслуговування параметрів від аварійного стримування. Стандартна послідовність: публічне повідомлення, надсилання, перевірки меж, timelock, рев'ю Guardian і виконання, якщо пропозицію не veto.

1

Публічне повідомлення

Risk Initiator публікує намічену зміну, навіщо вона потрібна і який скоп очікується.

2

Submission

Risk Initiator поміщає запропоновану зміну в шлях виконання, який використовує фреймворк.

3

Validation

Перевірки фреймворку підтверджують, що оновлення лишається всередині заздалегідь заданих обмежень і схвалених меж політики.

4

Timelock

Якщо валідація проходить, зміна входить у вікно timelock замість негайного виконання.

5

Рев'ю Guardian

Під час timelock Risk Guardian рев'ює точний queued payload і може скасувати його за потреби.

6

Execution

Якщо зміна переживає рев'ю, вона виконується автоматично після закінчення timelock.

7

Аварійний шлях

Якщо виконано аварійні умови, Risk Defender може використовувати окремий захисний шлях із вужчими повноваженнями.

Класи параметрів

Зміни параметрів несуть різний ризик, тому фреймворк групує їх за тим, скільки повноважень вони мають вимагати і як швидко мають мати змогу рухатися.

Захисні зміни

Це найшвидші рутинні зміни, бо вони знижують експозицію протоколу.

  • Зниження borrow caps
  • Зниження supply caps
  • Зниження LTV або порога ліквідації
  • Заморозка позики або використання застави
  • Посилення налаштувань spoke

Рутинні обмежені зміни

Вони йдуть стандартним маршрутом Initiator -> Guardian -> timelock усередині схвалених меж.

  • Помірне підвищення лімітів
  • Помірне налаштування параметрів усередині схвалених діапазонів
  • Додавання нових пулів усередині наявного шаблону spoke

Зміни рівня governance

Вони поза рутинним фреймворком і потребують шляху рішення вищого рівня.

  • Створення нової родини spoke
  • Увімкнення нового LP-примітиву
  • Додавання нової моделі оракула
  • Увімкнення нового liquidation adapter
  • Істотне розширення поверхні ризику за межі заздалегідь схвалених припущень

Публічне розкриття

Кожне рутинне оновлення варто публікувати до надсилання у форматі, що дозволяє розробникам, користувачам і рев'юерам порівняти повідомлення з точною дією, яку пізніше ставлять у чергу.

Мінімальний стандарт розкриття

  • Зачеплений spoke
  • Зачеплені пули або шаблони
  • Поточні параметри
  • Запропоновані параметри
  • Причина оновлення
  • Чи є оновлення захисним, чи орієнтованим на зростання
  • Очікуваний час надсилання
  • Очікуване вікно timelock
  • Релевантні залежності або припущення

Узгоджене розкриття спрощує рев'ю пропозиції на scope creep, незбіжні припущення або прості помилки виконання.

Аварійні дії

Аварійні дії — для стримування, а не рутинного налаштування. Їх варто використовувати рідко, тримати максимально вузькими й структурувати так, щоб протокол міг повернутися до стандартного шляху, коли безпосередній ризик зрозумілий. Risk Defender має діяти лише коли визначена або високоймовірна умова збою робить звичайний шлях із timelock небезпечним.

Аварійні тригери

  • Неузгодженість оракула
  • Деградація шляху ліквідації
  • Аномальна поведінка пулу
  • Збій залежності wrapper
  • Компрометація на рівні адаптера
  • Раптова нестабільність на рівні spoke

Обов'язкове розкриття після дії

  • The trigger
  • Вжите дію
  • Намічена тривалість
  • Шлях повернення до нормальної роботи

Аварійні повноваження існують лише для визначених або високоймовірних випадків збою, де очікування звичайного шляху timelock небезпечне. Це не шлях для рутинного зростання чи оптимізації.

Рекомендація, рев'ю та аварійне стримування лишаються розділеними, бо LP-застава — це набір ринків із різними структурами й режимами збою, а не один взаємозамінний список активів.