メインコンテンツにスキップ
Avana ロゴ

リスクフレームワーク

Avanaが、HubおよびLP担保Spokeにわたるリスク変更をどのように提案、レビュー、実行するか。

概要

Avana Risk Framework は、Hub と LP Collateral Spoke 全体でパラメータ変更がどう提案・検証・実行されるかを定義します。供給・借入キャップ、LT/LTV、金利入力、市場ステータス、および価格・稼働率・プール深度・集中度・ボラティリティ・ペッグ挙動・サーキットブレーカ・ポジションヘルスなどに依存する制御を含みます。 LP 市場は、その資産構成、評価方法、清算ルート、および破綻の形態において異なる。そのため、安定した相関のある加重および集中流動性プールは、異なるリスクパラメータを必要とする場合がある。このフレームワークは、スポークやプールの更新をレビューする際に、これらの違いを適用する。

そのプロセス全体で、三つの役割は分かれたままです:Avanaリスクイニシエーター、Avanaリスクガーディアン、およびAvanaリスクディフェンダー。定常的な変更を推奨する当事者は、それを独立して確認する当事者とは異なり、緊急時に行動できる役割は意図的に定常的な経路よりも狭くなっています。

運用ルール: exposure-reducing actions follow a more direct path than changes that expand protocol risk.

基本原則

役割の分離

このフレームワークは、提案、レビュー、緊急封じ込めを異なる関係者に割り当てることで、一方の当事者が単独で全プロセスを管理することがないようにしています。

制約付き実行

ルーチンのリスク変更は、あらかじめ定められたポリシーの範囲内に収まり、検証チェックを通過した場合にのみ実行されます。

公開内容の一貫性

公開開示は、レビュー担当者が通知とキューに入ったペイロードを比較できるように、実行のために提出されたパラメータ変更を特定します。

Spoke 認識

各LP担保銘柄には、それぞれ独自の上場ルール、オラクルの前提、清算経路、およびリスクプロファイルがあります。

防御側に偏った非対称性

このフレームワークは、プロトコルのリスクを拡大する変更よりも、露出を減らす行動へのより直接的な道を提供します。

役割

Avana リスク発生者

Hub と LP Collateral Spoke 向けの通常リスク変更を準備・推奨するロール。

  • 根拠を公開し、更新を防御型か成長型かに分類する
  • 定期的な更新をタイムロックされた実行経路に提出する
  • 承認済みの範囲内で、供給上限、借入上限、LT/LTV、準備係数、および金利の変更を推奨する
  • 事前承認された Spoke テンプレート内で Spoke レベルのデレバレッジとプール・オンボーディングを開始する

Avana リスクガーディアン

待機中の通常の変更に対して拒否権を持つ独立したレビュー担当者。

  • キューに入れられた更新が公表内容と一致していることを確認してください
  • その行動が承認された方針の範囲内にとどまっているか確認する
  • 無効なオラクル、流動性、または清算の前提に基づく更新を拒否する
  • タイムロック期間中、明らかな Spoke レベルまたは Hub レベルの不安定を生むならキュー済み更新をキャンセルする

Avana リスクディフェンダー

緊急時専用の役割は、通常の時間制限付きルートが遅すぎる場合にインシデントを抑えるために使用されていました。

  • 借入上限または供給上限を防御的なレベルまで引き下げる
  • ある Spoke の新規借入を凍結する、またはプール・テンプレート・Spoke の担保利用を凍結する
  • 事前定義された障害条件が満たされたときに、特定のアダプターまたは経路を無効にする
  • 緊急時の条件下での新規債務の発生をブロックし、日常的な最適化や成長のための行動には使用しない

更新フロー

ルーティンの変更は固定された手順に従うため、プロトコルは通常のパラメータメンテナンスと緊急対応を区別することができます。標準の手順は、公開通知、提出、範囲チェック、タイムロック、ガーディアンによる審査であり、提案が拒否されない場合に実行されます。

1

公開通知

リスク開始者は、意図された変更、その必要性、および影響が予想される範囲を公開します。

2

Submission

リスクイニシエーターは、提案された変更をフレームワークで使用される実行パスに配置します。

3

Validation

フレームワークのチェックにより、更新があらかじめ定められた制約と承認されたポリシーの範囲内に収まっていることが確認されます。

4

Timelock

検証が通過した場合、変更は直ちに実行されるのではなく、タイムロックウィンドウに入ります。

5

Guardian レビュー

タイムロック中、リスクガーディアンは正確にキューに入れられたペイロードを確認し、必要に応じてそれをキャンセルすることができます。

6

Execution

変更がレビューを通過すれば、タイムロックが切れた後に自動的に実行されます。

7

緊急パス

緊急事態の条件が満たされる場合、リスクディフェンダーはより狭い権限で別の防御経路を使用することができます。

パラメータ区分

パラメータの変更は、そのリスクへの影響によってグループ化されます。各クラスは、制限されたルーチン更新からより広範なガバナンス承認が必要な変更まで、必要な権限と実行経路を定義しています。

防御的変更

これらはプロトコルへの露出を減らすため、最も迅速なルーチン変更です。

  • 借入上限の引き下げ
  • 供給上限の引き下げ
  • LTVまたは清算閾値の削減
  • 借入れまたは担保使用の凍結
  • Spokeの設定を締める

定型の範囲内変更

これらは、承認された範囲内で標準のイニシエーター -> ガーディアン -> タイムロックのルートに従います。

  • 控えめな上限の増加
  • 承認された範囲内での控えめなパラメータ調整
  • 既存のSpokeテンプレートに新しいプールを追加する

ガバナンスレベルの変更

これらは通常の枠組みの外にあり、より高次の意思決定の流れを必要とします。

  • 新しいSpokeファミリーを作成する
  • 新しいLPプリミティブを有効にする
  • 新しいオラクルモデルを追加する
  • 新しい清算アダプターを有効にする
  • 事前承認された仮定を超えてリスクの対象範囲を実質的に拡大すること

公開開示

定期更新フローでは、提出の前に公示が行われます。公示には影響を受ける市場と提案されたパラメータが記録され、開発者やレビュー担当者が記載された変更内容と実行のためにキューに入れられたペイロードを比較できるようにします。

最低開示基準

  • 影響を受けたSpoke
  • 影響を受けたプールまたはテンプレート
  • 現在のパラメータ
  • 提案されたパラメータ
  • 更新の理由
  • アップデートが防御的なものか、成長志向のものか
  • 提出予定時期
  • 予想されるタイムロックウィンドウ
  • 関連する依存関係や前提

これらのフィールドをキューに入ったペイロードと比較すると、実行前の影響を受ける市場、パラメータ値、タイミング、または仮定の違いが明らかになります。

緊急アクション

リスクディフェンダーの緊急経路は、通常のタイムロックを待つことが安全でない場合に、定義された、または高い確率で発生する故障を含むことに限定されます。その権限が狭いため、借入の制限や影響を受けたアダプターの無効化などの防御的な行動が可能です。日常的なパラメータ変更は引き続きイニシエーターおよびガーディアンのプロセスを使用します。

緊急トリガー

  • オラクルの不一致
  • 清算経路の劣化
  • 異常なプールの動作
  • ラッパー依存関係の失敗
  • アダプターレベルの妥協
  • 突発的な Spoke レベルの不安定性

対応後に必要な開示

  • The trigger
  • 取られた行動
  • 意図された期間
  • 通常運転への復帰の道

緊急権限は、通常のタイムロック経路で待機することが安全でない、定義済みまたは高確率の障害ケースにのみ存在します。これは日常的な成長や最適化のための経路ではありません。

提案、レビュー、および緊急時の役割の分離はLP市場全体に適用されますが、各市場はそれぞれ独自の評価前提、リスク限度、および清算の挙動を保持します。