ネットワーク全体の流動性

（セクション： エコシステムとネットワーク）

1）「トータル流動性」とは何か、なぜ必要なのか

• 最小限のRTO/RPOでの支払い/転送の速度と予測可能性。
• 資本の効率的な使用：少ない「デッドバランス」とダブルリザーブ。
• ドメイン間の相互運用性：ブリッジ、バンク、PSP、ステーブル、オン/オフランプ。
• 規制されたリスク：制限、緩衝、保険、監視。

2）流動性モデル

2.1集中型（カストディアルハブ）

単一の「流動性ハブ」は、地域/通貨/チェーンごとにプールを保持します。ただ、より高いカウンターパーティリスクとSPOFリスクを実装します。開始/小さい網のために適した。

2.2分散型（ドメイン別プール）

流動性は、スマートコントラクト/チャネルを通じて、多くのプロバイダー/マーケットメーカー（MM）、取引所に保存されます。より高い安定性、高度なルーティングとオンチェーンルールが必要です。

2.3ハイブリッド（推奨）

重要な通貨/ペイアウトのハブ+スケーリングのための外部MM/ブリッジ。管理-限界、誓約、保険基金の方針を通じて。

3）トポロジーとオブジェクト

流動性プール（LP）： 'LP {domain、 currency/asset}'、属性：balance、 buffer、 limits、 cost of capital （CoC）、 commission。
クレジットライン（CL）：二国間/多国間の制限と担保と使用あたりの価格。
ブリッジ：ロック/ミント/書き込み/リリースまたはメッセージング専用+ネッティングメカニクス。
ルーティングエッジ：有効な翻訳パス（on-us、 LP間、bridge/bank/PSP経由）。
保険ファンド：保険金内の赤字をカバーします。

4）主な指標と数式

• 'LD_T=Balance_T-Reserved_T'
• 使用率（U）-プール負荷：'U=Used/（ Balance）'

• 'CR=Available/ P95 （Demand_T）'（ターゲット≥ 1。5 ×）

• 'BUF=Buffer/ P95 （NetFlow_daily）'
• リバランスMTTR-トリガー後のアンバランス閉鎖までの平均時間。
• Cost-to-Serve （CTS per$）-$transferの手数料/ガス/スプレッドの合計。
• Payout SLA Hit Rate（ペイアウトSLAヒット率）-ターゲットとなる分/ブロック≤のペイアウトのシェア。

SLO（ランドマーク）：ペイアウトSLAヒット≥ 98-99％；CR ≥ 1。5 ×；リバランスMTTR ≤ 30分；1ドルあたりのCTS 10-15％でQoQ。

5）ルーティング（SOR-スマートオーダルーティング）

5.1つの目的

SLA/limitsが満たされている場合、フルコストとリスクを最小限に抑えたパスを選択します。

5.2トラックコスト

"TotalCost=Fee+Gas+Slippage+LiquidityPetal+TimePetal+RiskAdj'

流動性ペナルティ：U> 70％またはCR<ターゲットに対するペナルティ。
TimePetal：予測された確定/紛争ウィンドウ。
RiskAdj：制裁/国および取引相手のリスク。

5.3戦術

分割ルーティング：複数のLP/ブリッジに大規模な転送を分割します。
プリファンディング：ピーク時にLPプリチャージ。
引用のロック：低いCRの動的マークアップの短い窓のための価格を、固定して下さい。
再試行/alt-path：劣化時にバックアップパスに沿ったidempotentの繰り返し。

6）手数料と価格

基本料金（bps）+高SLAでの優先料金。
動的広がり：U> 80％または高いボラティリティで成長します。
階層化：ネットワークの「良い市民」のために低い（低リスク、安定した売上高）。
負の手数料プロモーション：流動性の赤字（需要によるリバランス）で方向性を刺激する。

7）流動性のリバランス

7.1トリガー

しきい値： 'U> 80％'または'CR <1。2`.

予測：予想需要のスパイク（ML/季節性）。
イベント：ターゲットドメイン内の手数料のブロック/フォーク/成長。

7.2つの戦略

TWAP/VWAPオーバーフロー：時間/ボリュームのユニフォーム。
ブリッジ/DEX上の原子スワップ（トークン用）。
ネット：ウィンドウの最後に相互の義務をクリア（時間/日）。
リバランスオークション：外部MMはオークション価格で不均衡を閉じます。
クロス通貨ヘッジ：米ドル相当を安定させるためのヘッジトランザクション。

7.3プライオリティポリシー

Money/Payment> Critical Operational Transfer。

8）リスクマネジメント

リスクの実行：引き出しリクエストのサージ→制限速度、動的スプレッド、SLAの一時的な拡張。
集中：カウンターパーティ/チェーン/銀行ごとの露出制限。
管轄と制裁：リスト、地理的制限、KYC/KYBとオフランプ。
技術：橋の失敗/PSPのガス価格の増加、論争は/窓を再調整します。
運用：キーリーク、誤った資産マッピング、誤った引用符。
保険：リスクファンド+再保険；透明な適用範囲の方針。

9）連鎖流動性および橋

信頼モデル：できればお金のためのライトクライアント/ZK；楽観的-ウィンドウを拡大しました。
清算ネットワーク：HTLC/保証領収書を持つチャネル/MM。
stablesのプール：資産の単一の正規レジスタ、小数点、アドレス、コースの会計。
橋網：ガスコストと時間を削減するためのバッチクリア。

10）コンプライアンスと監査

役割と大きな限界に影響を与えるためのKYC/KYB。
AML/制裁翻訳の前後（速度/行動フィルタ）。
監査ログと構成：署名、変更できないソリューションレジスタ。
データレジデンシー/PII：暗号化、匿名化、個別のストアフロント。

11）観察可能性、SLOおよびダッシュボード

• p50/p95 Time-to-Payout、 Success-Rate、 CTS per$、Utilization％、 CR、 Backlog、 Rebalance MTTR、 Quote Error、 poolの流動性利用率。

• Payout P95 ≤ 5分（ネットワーク間-最終ウィンドウ≤）、 Success-Rate ≥ 99。5％、 CR ≥ 1。5 ×、リレー/ブリッジの可用性≥ 99。9%.

• Ops： Success-Rate、 p95 TTP、 U％、 CR、 backlog、 burn-rate SLO。
• 流動性及び費用（日）：ドメイン別のTVL/Netフロー、$あたりのCTS、手数料収入、保険。
• リスク（週）：暴露、制裁の打撃、臨時指標、ブリッジ障害。

12）構成例（Pseudo-YAML）

プールとリミットポリシー

yaml liquidity:
pools:
- id: "LP:EU:EUR"
min_buffer_pct: 60 max_utilization_pct: 85 rebalance_threshold:
cr_min: 1. 3 utilization_max: 0. 80 fees_bps:
base: 8 priority: 5
- id: "LP:TR:TRY"
min_buffer_pct: 70 max_utilization_pct: 80 credit_lines:
- from: "LP:EU:EUR"
to:  "LP:TR:TRY"
limit: 2_000_000 collateral: "USDC"
rate_bps_daily: 1. 5 bridges:
- pair: ["ETH", "Polygon"]
finality:
mode: light_client confirmations: 20 rate_limits:
per_minute: 300 per_hour: 12000

SORパラメータ

yaml routing:
split_max_parts: 4 risk_adjustments:
utilization_penalty_bps: 25 # for every% over 70%
cr_penalty_bps: 50       # за CR<1. 2 time_penalty_ms_per_min: 5 prefer_paths: ["on-us", "light-client", "mm-auction"]

13）サンプルクエリ（疑似SQL）

ローディングおよびコーティング

sql
SELECT pool_id,
AVG(utilization) AS u_avg,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY demand_daily) AS p95_demand,
AVG(available) / NULLIF(PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY demand_daily),0) AS cr
FROM liquidity_snapshots
WHERE ts >= now() - INTERVAL '30 days'
GROUP BY pool_id;

ペイアウトSLA

sql
SELECT date_trunc('hour', finished_at) AS h,
100. 0 AVG(CASE WHEN EXTRACT(EPOCH FROM (finished_at - created_at)) <= sla_sec THEN 1 ELSE 0 END) AS payout_sla_hit
FROM payouts
WHERE created_at >= now() - INTERVAL '7 days'
GROUP BY 1;

$あたりのCTS

sql
SELECT date_trunc('day', ts) AS d,
SUM(fees + gas + slippage_cost) / NULLIF(SUM(amount_usd),0) AS cts_per_usd
FROM transfers_costs
WHERE ts >= current_date - INTERVAL '30 days'
GROUP BY 1;

14）運営規程

毎日：LP残差の調整、CR/U/MTTRレポート、ピークスケジュールによる自動リバランス。
毎週の委員会：制限の調整、手数料、ルート；CTSおよび失敗の分析。
SEVインシデント：ドメインのペアの単一の「停止クレーン」、公開ステータス、死後≤ 72時間。
キーとコンフィギュレーションの回転：署名、タイムロック、ロールバック。

15） Playbookインシデント

CRの落下<1。2と成長するbacklog

優先順位のTWAPリバランスを有効にし、コミッション/スプレッドを上げ、スプリットルーティングを有効にします。影響を受けるETAパートナーに通知します。

スクリプトの実行（大量出力）

スピード/クォータ制限を有効にし、一時的にSLAウィンドウを増やし、保険ファンドとMMオークションを使用します。

ブリッジ障害/ファイナリゼーションの増加

別のパス（messaging-only+nettingまたはbackup bridge）に切り替え、K-confirmationを上げ、引用符を更新します。

制裁/AMLトリガー

関連するプール/方向、手動レビュー、コンプライアンスレポート、スコアリングルールの更新を凍結します。

資産/レートマッピングエラー

資産の取引を停止します。、ディレクトリのロールバック、影響を受ける転送の再計算、パブリックノート。

16）実装チェックリスト

1.ドメインごとにプール/リミット/バッファと最小CRを記述します。
2.フルパスのコストとリスクを考慮したSORを含める。
3.リバランス（しきい値+TWAP/VWAP）とネットを設定します。
4.SLI/SLO （Payout SLA、 CR、 MTTR、 CTS）とダッシュボードを定義します。
5.赤字のための保険基金およびMMのオークションを始めて下さい。
6.コンプライアンスポリシー（KYC/KYB/AML/制裁）を承認します。
7.カオスおよびストレステスト（実行、ブリッジ障害、ガス接着）を実行します。
8.定期的に手数料、ルート、制限を確認します。

17）用語集

LP（流動性プール）-ドメイン/通貨の流動性プール。
CR （Coverage Ratio）-プールによる需要カバレッジの比率。
U（利用率）-使用済み流動性のシェア。
SOR （Smart Order Routing）-支払い/転送のインテリジェントなルーティング。
TWAP/VWAP-時間/ボリュームによるスムーズなオーバーフロー戦略。
$ごとのCTS-$transferのサービスのコスト。
ランリスク-大量の流動性の撤退のリスク。
ネッティング-バッチによる相互義務の清算。

ボトムライン：総流動性はルール、プール、ルートの管理可能なシステムであり、資本が効率的に働き、支払いが迅速かつ予測可能に行われます。ハイブリッドトポロジー、SOR、ダイナミックコミッション、厳格なSLO、リバランス規律を組み合わせることで、エコシステムは持続可能でスケーラブルで経済的に最適なネットワーク流動性を獲得します。