価格とLTV以上のもの
単純なトークンは通常、直接的な市場参照で価格付けされ、標準ロジックで清算できます。LPポジションはできません。その価値は原資産、プール構造、資産間の関係、手数料の発生、流動性の深さ、集中流動性の場合はアクティブレンジに依存します。ストレス下ではこれらの変数が複合します。Aave v4でLP担保借入をサポートするプロトコルは、価格を割り当てLTVを設定する以上のことをしなければなりません。それがAvanaが構築されている問題です。
アーキテクチャと評価
第一のセキュリティレイヤーはアーキテクチャです。AvanaはAave v4のhub-and-spoke構造を使用します。hubは共通流動性レイヤーを保持し、リザーブ会計を管理し、ソルベンシー制約を強制します。spokeはLP固有の担保ロジックが存在する場所です：准入、評価ルール、プール固有のリスクパラメータ、清算動作。LP市場がストレスを受けた場合、そのストレスは無関係な担保タイプ全体の前提を書き換えるのではなく、spoke内に封じ込められることを意図しています。Avanaでは、spokeはセキュリティ境界の一部です。
第二のレイヤーはオラクルと評価設計です。LPポジションは単一のフラットフィードで安全に価格付けできません。Avanaはデュアルソースフレームワークを使用します。外部価格フィードが原資産の主要参照を提供し、AMM由来の価格付けが独立した検証として機能します。借入力は両ソースが許容範囲内で一貫している場合にのみ存在します。リスクは市場レベルで割り当てられます。プール構造、資産相関、流動性深度、レンジ集中度がすべて担保処理を形成します。借入力はポジションの弱い側面に固定され、ボラティリティ、流動性品質、ストレス前提に対するプールレベルの調整が加わります。
ヘルスと清算
第三のレイヤーはヘルスモニタリングです。LPポジションは担保として投稿された後もアクティブなままなので、ローンが開かれた後もリスクは凍結しません。価値は価格変動、手数料生成、レンジ移行、プール品質の変化とともに変わります。Avanaは時折のスナップショットに頼るのではなく、ポジションごとの継続的なヘルス評価を実行します。ヘルスファクターは、そのローンに対して担保モデルがまだ成立しているかのライブシグナルです。
清算は前提が試される場所です。LP担保は通常のトークンのように清算できません。Avanaのアプローチは、可能な場合は元本を破壊する前にポジションに埋め込まれた手数料を回収し、ローンを修復するのに十分な流動性のみを除去し、決定論的決済を優先する実行パスでアンウィンドをルーティングすることです。Smart Agentsは実行インフラを提供します：ポジションの監視、データの照合、実行のシミュレーション、逆境下でのアンウィンド。それらは後から取り付けられた考え余りではなく、Avanaの安全システムの一部です。
オペレーションと変更管理
運用レイヤーは、ガバナンスとリスク設定が担保処理と同じ規律を必要とすることを前提とします。リスクパラメータは構造化されたプロセスを通じて変更されます。機密性の高い変更はタイムロックとレビューの背後にあります。緊急コントロールは真に不利な状況のために存在します。モニタリングは個別ポジションを超えて市場カテゴリ全体に及びます。LP担保をサポートするプロトコルは静的設定だけに頼ることはできません。
LP担保は、セキュリティがシステムとして扱われる場合にのみAvanaで実現可能です。アーキテクチャがリスクを分離します。オラクルが現実を検証します。評価が複雑さを保守的な借入力に変換します。ヘルスチェックが漂流を監視します。清算がvenueが許す限りの精度でソルベンシーを回復します。運用コントロールがフレームワークの進化を統治します。これらのレイヤーのどれも単独では十分ではありません。