LTVと清算閾値の間になぜ意図的に差を設けるのか、同じ数字にしてはいけないのか？
もしLTVと清算閾値が同じ数字だったら、プロトコルが許可する最大額を借りた瞬間、あなたのポジションはすでに清算ラインの上に立っていることになる——資産価格にわずかでも不利な変動が生じれば、それが通常の日中の変動であっても、即座に清算が発動してしまう。ETHを例に取ると、過去1年間で1日の価格変動が2.5%を超えた日数は全取引日のほぼ半分を占めている。LTVと清算閾値の間に安全マージンがなければ、ほぼ半分の取引日で、借入を終えたばかりのユーザーのポジションが瞬時に清算の瀬戸際に追い込まれかねないということだ。
この間に設けられた差は、本質的にはプロトコルが意図的に資本効率の一部を犠牲にする（借りられる金額を理論上の上限より少し少なくする）ことで、ポジションが通常の市場のノイズによって誤って清算されないようにするための緩衝空間を確保しているのだ。この差の大きさも恣意的に決められているわけではない。変動性の大きい資産ほど、プロトコルはより大きな差を設ける傾向がある。なぜなら、通常の価格ノイズを本当の担保不足と誤判定せずに乗り切るためには、より大きな緩衝空間が必要だからだ。
リスクサービスプロバイダー（Chaos Labsなど）とプロトコルガバナンスでは、どちらの決定権が大きいのか？
プロセス上は、最終的な決定権はガバナンスにあり、リスクサービスプロバイダーにはない。プロバイダーの役割は定量分析と提案を提供することだ——過去のオンチェーンデータを用いて借り手のポジションをシミュレーションし、異なるパラメータ設定が極端な相場下でプロトコルにどれだけのリスクをもたらすかをテストした上で、その結論を具体的なパラメータ調整案としてまとめ、ガバナンスの審議に提出する。しかしこの提案が実際に効力を持つには、依然として正式なガバナンス提案という形を経て、コミュニティの投票やガバナンスが指定する役割による実行を通じてオンチェーンに反映される必要がある。
実務上、リスクプロバイダーの提案の可決率は概して高い傾向にあるが、その理由はガバナンスが決定権を譲り渡しているからではなく、プロバイダーが専門的で定量化された、モデルに基づいた分析を提供しており、一般的なガバナンス参加者にはそれに匹敵する専門知識でこうした数字に異議を唱える能力が欠けているため、そのまま採用する傾向にあるからだ。これはこの仕組みの潜在的な弱点でもある。ガバナンスは理論上最終的な拒否権を保持しているが、ガバナンスメンバーが実際にリスクプロバイダーのモデルの前提を疑う能力と意欲を持っているかどうかが、この「理論上のチェック機能」が現実にどれだけ実質的な意味を残しているかを決定づけるのだ。
Aaveのアイソレーションモードは、具体的にどのようにリスクを「隔離」するのか？
アイソレーションモードの核心的な設計は、新しい資産を独立した、借入上限のある小規模な資金プールに置くことであり、プロトコル内の他のすべての資産と同じリスクプールを直接共有させないことだ。ある資産がアイソレーションモード資産として指定されると、ユーザーがそれを担保としてプロトコルに預けた後、借り出せる資産の種類と総額はあらかじめ設定された上限内に制限される——たとえその資産の価格がその後暴落し、担保が無価値になったとしても、最大損失はこのアイソレーション資金プールの上限内に収まり、この資産とはまったく無関係なプロトコル内の他の資金プールに波及することはない。
このメカニズムが解決する実際の問題は、新しい資産には通常、十分な市場データの蓄積がなく、リスクプロバイダーが最初からその実際のボラティリティや流動性の深さを正確に評価するのが難しいということだ。アイソレーションモードは、「新しい資産の上場を完全に拒否する」ことと「新しい資産に即座に完全かつ無制限の担保資格を与える」という2つの極端の間に、中間地帯を見出すことを可能にする——範囲が制御されたサンドボックスを使い、この資産に一定期間、実際の市場でのテストを受けさせ、リスク評価を支えるのに十分なデータが蓄積されて初めて、アイソレーション制限を解除するかどうかを検討するのだ。
貸付プロトコルを使う前に、ある資産のLTVと清算閾値が妥当に設定されているかどうかを実際にどう調べればよいか？
第一のステップは、プロトコルの公式インターフェースや開発者ドキュメントで、その資産の現在のLTV、清算閾値、そしてアイソレーションモードやE-Modeカテゴリーに該当するかどうかを直接確認することだ——Aaveのような主要プロトコルの多くは、こうしたパラメータを資産詳細ページに公開しており、追加のツールなしで確認できる。数字を確認したら、その資産の時価総額、24時間取引量、主要取引所やオンチェーンDEXでの実際の流動性の深さと照らし合わせてみるとよい。ある資産の担保係数が比較的高く設定されている一方で、市場流動性が明らかに薄い場合、この組み合わせ自体が警戒すべきシグナルだ——これはまさにTectonic事件におけるTONICトークンの状況だった。
第二のステップは、そのプロトコルの背後に専門のリスクサービスプロバイダーが定期的にパラメータ審査を行っているかを確認し、そのプロトコル自身が発行するネイティブトークンが外部資産と同じ厳格な審査基準の対象になっているかどうかに注意を払うことだ。もしプロトコルのブログ、ガバナンスフォーラム、監査レポートの中にネイティブトークンのリスク評価に関する議論が見当たらない場合、それは通常この部分の審査が相対的に手薄であることを示しており、その資産にどう資金を投じるかを決める前に、自分自身のリスクチェックリストに加えておく価値がある。
あなたが借入プロトコルに1 ETHを預けると、インターフェースは借入可能な最大額がその価値の80%相当だと表示する。この80%という数字は市場が計算したものでも、コードが自動生成したものでもない。プロトコルガバナンスがリスク評価プロセスを通じて、各資産ごとに個別に設定したローン・トゥ・バリュー比率（LTV）だ。この数字は単なる技術的パラメータに見えるが、実際にはプロトコル全体にとっての第一の防衛線であり、ある資産に問題が起きた際にどれだけの連鎖的な損害を及ぼすかを直接左右する。2026年8月、Cronos上の貸付プロトコルTectonicが約7,500万ドルの攻撃を受けた原因は、プロトコルが自社発行の極めて流動性の低いガバナンストークンに20%の担保係数を設定していたことにあり、これにより攻撃者はわずかな資金で価格を操作し、トークンの実際の価値をはるかに超える資産を借り出すことができた。この事件は、普段誰も特に注意を払わない問題を白日の下にさらした——この数字は一体誰が、どうやって決めているのか？
Aaveを例にとると、各資産には関連しているが異なる2つのパラメータがある。LTVは「最初にどれだけ借りられるか」を決め、清算閾値（Liquidation Threshold）はポジションが「いつ担保不足と判定されるか」を決める。例えばWETHの場合、LTVは通常約80%に設定され、清算閾値は82.5%に設定される——この間に意図的に設けられた2.5%の差は、プロトコルガバナンスが設計した安全マージンであり、ユーザーが借入を終えたばかりで資産価格がまだ動いていない段階で、ポジションがすでに清算ラインに迫ってしまうことを防ぐ目的がある。この2つの数字は資産によって差があるのが通常だ。USDCのように価格変動が極めて小さい資産では、LTVと清算閾値はそれぞれ80%と85%程度に設定されることがある一方、WBTCのように変動が大きい資産では70%と75%程度にとどまることがある——資産が不安定であるほど、プロトコルが設定する安全マージンは保守的になる傾向がある。
Aaveのようなオンチェーンガバナンスを採用するプロトコルでは、ある資産を担保リストに加えられるかどうか、またそのLTVや清算閾値などのパラメータをどう設定するかは、理論上はAaveガバナンス提案（Aave Governance Proposal）を通過するか、ガバナンスが指定した資産上場管理者（Asset Listing Admins）によって実行される必要がある。しかし実務上、DAOガバナンスの参加者の多くはリスクモデルの専門家ではないため、AaveやCompoundのような大手プロトコルは、専門の第三者リスクサービスプロバイダー（Chaos Labsなど）を雇い、市場状況や資産の流動性を継続的に監視させ、定期的にリスクパラメータ調整の提案を受けている。こうしたリスクサービスプロバイダーは通常、過去のオンチェーンデータを用いて借り手のポジションをシミュレーションし、あるパラメータを調整した場合に極端な相場でプロトコル全体がどれだけのリスクを負うかをテストした上で、定量化された提案をガバナンスの審議に提出する。つまり、あなたがインターフェース上で目にするそのパーセンテージの背後には、「リスクサービスプロバイダーによるシミュレーション計算→ガバナンス提案→コミュニティ投票→オンチェーン実行」という一連のプロセスがあるのだが、ほとんどのユーザーは預金や借入の際にこのプロセスに触れることは一切ない。
Tectonicの事件を特に取り上げる価値があるのは、リスク審査プロセスにおける見落とされやすい死角、すなわちプロトコル自身が発行するネイティブトークンを露呈させたからだ。Tectonicの公式ドキュメントは低流動性資産が価格操作を受けやすいと明確に警告しており、チームは実際に2026年5月と6月に他の資産に対して動的な調整を行い、借入可能額を引き下げていた——これはこのリスク審査メカニズムが普段実際に機能していたことを示している。しかしTONIC自体の20%という担保係数は、明らかに同じ審査の対象になっていなかった。この状況は珍しいものではない。プロトコルが自社トークンを担保リストに加える際には、そのトークンに実際の用途を持たせ、需要を高めるという動機が伴うことが多く、この動機は「この資産が担保として使うのに十分安全かどうか」というリスク判断とは異なる目標に仕えており、両者の間にはガバナンス上、同等の厳格さで扱われない隙間が生まれやすい。
「新しい資産を上場させたいが、リスクがまだ十分に検証されていない」というジレンマに対し、Aave V3はアイソレーションモード（Isolation Mode）を導入した。これはリスクが高い、あるいは新しい資産を担保リストに加えることを認めつつ、それを特定の、上限額が制限された資産の借入にのみ使用できるよう制限し、プロトコル内の他の資金プールの安全性に影響を及ぼさないようにする仕組みだ。つまり、その資産を最初からプロトコル全体の資金とリスクを共有させるのではなく、まず「小部屋の中」で市場の検証を受けさせるということである。逆に、価格の相関性が非常に高い資産グループ（複数のドル建てステーブルコインや、ETHとそのステーキング派生商品など）に対しては、Aave V3のE-Mode（効率モード）が、同一カテゴリー内でユーザーがより高いLTVを得られるようにしている。これらの資産は価格の連動性が高く、同時に問題を起こす確率が比較的集中しているため、より低い安全マージンでも許容できるからだ。この2つの仕組みは方向性が逆だが、根底にあるロジックは同じだ——リスクパラメータは一律に適用される定数ではなく、資産の実際の流動性、変動性、相関性に応じて動的に調整されるべきものなのである。