風險框架
Avana 如何在 Hub 和 LP 抵押品 Spoke 中提議、審查和執行風險變更。
概覽
Avana Risk Framework 定義如何在 Hub 與 LP Collateral Spoke 上提案、校驗並執行參數變更。涵蓋協議調整供給/借款上限、LT/LTV、利率輸入、市場狀態，以及依賴價格、利用率、池深度、集中度、波動、掛鉤、熔斷、部位健康等相關狀態時的控制。
LP 擔保不是單一同質資產類別。穩定幣 LP、相關資產 LP、加權池、集中流動性及其他 AMM 設計，都可能有各自的 Spoke 專屬估值路徑、清算路徑與失效模式。該框架存在的目的是讓這些差異體現在更新流程中，而不是被單一通用風險設定掩蓋。
在整個過程中有三個角色保持分開：Avana 風險發起者、Avana 風險守護者，以及 Avana 風險防禦者。建議例行變更的方與獨立檢查該變更的方不是同一方，且在緊急情況下可以採取行動的角色設計上比例行流程的角色範圍更有限。
運行規則: reducing risk should be easier than expanding it.
核心原則
角色分離
該框架將提議、審查和應急控制分配給不同的參與者，因此單一方不會獨自控制整個過程。
受約束執行
例行風險變更僅在保持在預定政策範圍內並通過驗證檢查時執行。
公開一致性
公開描述的更新應該與實際排隊等待執行的更新相同。
Spoke 意識
每個 LP 抵押品代幣都有其自己的上市規則、預言機假設、清算途徑和風險概況。
防禦非對稱
這個過程是刻意偏向的，因此降低風險比擴大風險更快更簡單。
角色
Avana 風險啟動者
為 Hub 與 LP Collateral Spoke 準備並建議常規風險參數變更的角色。
- 公布理由並將更新分類為防禦性或增長導向
- 將例行更新提交到時鎖定的執行路徑中
- 建議供應上限、借款上限、LT/LTV、準備金因子，以及在批准範圍內的利率變動
- 在預批准的 Spoke 模板內發起 Spoke 級降風險與池接入
Avana 風險守護者
對排隊的例行變更擁有否決權的獨立審查員。
- 確認排隊的更新與公開披露相符
- 確認該行動保持在核准的政策範圍內
- 基於無效的預言機、流動性或清算假設拒絕更新
- 在時間鎖視窗內，若會造成明顯的 Spoke 級或 Hub 級不穩定，則取消已排隊更新
Avana 風險防禦者
緊急專用角色過去用於處理當正常時間鎖定路徑過慢的情況。
- 將借貸上限或供應上限降低到防禦水平
- 凍結某個 Spoke 的新借款，或凍結某池、模板或 Spoke 的擔保使用
- 在預設的故障條件被觸發時，停用特定的適配器或借用路徑
- 在緊急情況下阻止新的債務創建，不得用於日常優化或增長行動
更新流程
常規變更遵循固定路徑，因此協議可以區分正常參數維護與緊急控制。標準順序是公開通知、提交、界限檢查、時間鎖、監護人審查，如果提案未被否決則執行。
公開通知
風險發起人發布擬議的變更、變更的必要性以及預期影響的範圍。
Submission
風險啟動者將擬議的變更放入框架使用的執行路徑中。
Validation
框架檢查確認更新保持在預定的約束範圍和批准的政策界限內。
Timelock
如果驗證通過，變更將進入延遲窗口，而不是立即執行。
Guardian 審核
在時間鎖期間，風險監護人會審查準確的排隊有效負載，並可在需要時取消它。
Execution
如果變更通過審查，它會在時間鎖到期後自動執行。
緊急路徑
如果符合緊急情況，風險防禦者可以使用具有較窄權限的單獨防禦路徑。
參數類別
參數變更並非都具有相同的風險，因此該框架會根據它們應該需要多少權限以及它們應該能夠移動的速度將它們分組。
防禦性變更
這些是最快的例行變更，因為它們減少了協議曝露。
- 降低借款上限
- 降低供應上限
- 降低 LTV 或清算門檻
- 凍結借貸或抵押品使用
- 收緊Spoke設定
常規有界變更
這些遵循標準的啟動者 -> 守護者 -> 時間鎖路線，在批准的範圍內。
- 謹慎的小幅增加上限
- 在核准範圍內適度調整參數
- 在現有的Spoke模板中添加新的池
治理級變更
這些超出了常規框架，需要更高層次的決策流程。
- 建立新的Spoke系列
- 啟用新的 LP 原語
- 新增一個甲骨文模型
- 啟用新的清算適配器
- 實質上擴大了超出預先批准假設的風險範圍
公開揭露
每一次例行更新都應該在提交前以一種格式發布，讓開發者、使用者和審查者能夠將通知與之後排程的具體操作進行比較。
最低揭露標準
- 受影響的Spoke
- 受影響的資源池或範本
- 當前參數
- 建議參數
- 更新原因
- 無論更新是防禦性還是成長導向
- 預期提交時間
- 預期鎖定時間窗口
- 相關的依賴或假設
一致的披露使審查提案是否存在範圍擴張、不匹配的假設或簡單的執行錯誤變得更加容易。
緊急行動
緊急行動是用於遏制，而非日常調整。它們應該很少使用，保持儘可能狹窄，並且結構化以便在理解即時風險後協議可以返回標準路徑。風險防禦者應僅在明確或高度可能的失敗情況使正常的限時路徑不安全時才採取行動。
緊急觸發條件
- Oracle 不一致性
- 清算路徑退化
- 異常的池行為
- 封裝程式依賴失敗
- 適配器級妥協
- 突發的 Spoke 級不穩定
行動後必要揭露
- The trigger
- 所採取的行動
- 預期期限
- 恢復正常運作的道路
緊急權限僅存在於定義明確或高度可能發生失效的情況下，在正常的時間鎖路徑等待是危險的情況時使用。它不是常規增長或優化的途徑。
建議、審查和緊急控制仍然是分開的，因為LP抵押品是一個由不同結構和失敗模式的市場組成的集合，而不是一個可互換的資產清單。