なぜ浅い流動性プールは特にウォッシュトレードされやすいのか。深いプールとの本質的な違いは何か？
これはAMM（自動マーケットメーカー）の価格決定メカニズムに関係している——プール内の資産比率が価格を決定し、プールが浅いほど、同じ金額の取引がもたらす比率の変動は大きくなる、つまりスリッページが高くなる。数千万ドル規模の流動性を持つプールでは、価格を50%押し上げるには数百万ドルの実際の資金が必要になり、その過程で観測可能な異常な取引量が生じる。しかしわずか数千ドルのプールでは、数百ドル程度の往復取引だけで価格を任意の水準まで押し上げることができ、取引量自体も小さいため監視アラートを発動させにくい。
これはまた、「この資産の時価総額はいくらに見えるか」と「この資産の流動性は実際どれだけ深いか」が別々に検証すべき2つの指標である理由でもある——攻撃者が作り出す帳簿上の時価総額は天文学的な数字になりうるが、基礎となる流動性プールは紙のように薄い可能性がある。
プロトコルが最低流動性の閾値を設定すれば、この種の攻撃を完全に防げるのか？
最低流動性の閾値は攻撃コストを大幅に引き上げるが、万能薬ではない。閾値をどの水準に設定するか自体が継続的な調整を必要とするパラメータだ——閾値を低く設定しすぎると（例えば5万ドルの流動性のみを要求する場合）、攻撃者にとって依然として負担可能なコストにとどまる。逆に高く設定しすぎると、本当に有望な新規プロジェクトを締め出してしまい、プロトコルの資産の多様性や競争力に影響を与えかねない。
より根本的な問題は、単一の閾値では「先に流動性プールを育てて、後で一気に抜き取る」という変種の手口に対応できない点だ。攻撃者は段階的に操作できる——まず合法的に十分深く見える流動性プールを構築して閾値審査を通過させ、トークンが担保として受け入れられた後、別の方法で流動性の大部分を抜き取り、事後的にプールを浅い状態に戻すことができる。これこそが、慎重に設計されたオラクルシステムの多くが、最低流動性の閾値をTWAPやホワイトリスト審査期間などの他のメカニズムと重ねて使用し、単一の防衛線だけに依存しない理由である。
TWAP（時間加重平均価格）は具体的にどのように操作コストを引き上げるのか？
TWAPの核心的なロジックは、単一時点の価格を信頼するのではなく、一定の時間窓（例えば過去30分間）にわたる価格の平均値を取ることにある。これは、攻撃者がTWAP価格を目標水準まで押し上げたい場合、瞬間的に価格を吊り上げて即座に攻撃を実行することができず、その時間窓全体にわたって吊り上げた価格を維持し続けなければならないことを意味する——つまり、時間窓が長くなるほど攻撃者が投入する必要のある資金と取引回数が大幅に増加する。なぜなら、その期間中に裁定取引者や他の市場参加者が取引に参入し、価格を正常な水準に引き戻そうとする可能性があり、攻撃者はその引き戻しの力に絶えず資金で対抗しなければならないからだ。
これがTWAPがフラッシュローン型の攻撃に対して特に有効だと考えられている理由でもある——フラッシュローンの資金は同一取引内で借り入れと返済を完結させなければならず、時間窓をまたいで価格操作を持続させる方法がないため、TWAPは本質的にこの種の攻撃パターンを無効化する。しかしDrift事件では、攻撃者は数日間にわたる段階的な手法を用いており、プロトコルのTWAP窓の設定が十分長くなければ、複数のブロックをまたいで徐々に価格を押し上げ突破する余地は依然として残る。
一般の預金者として、自分が資金を預けているプロトコルがどの資産を担保として受け入れているか、その担保のオラクル設計が堅牢かどうかをどうやって知ることができるか？
多くの貸付プロトコルは、公式文書やインターフェース上で「承認済み担保資産一覧」を公開している——これが最初に確認すべき場所だ。一覧に全く聞いたことのない、時価総額の出所が不明なトークンが含まれていれば、さらに調べる価値がある。第二に、その資産のオラクル価格ソースを確認する——プロトコルの技術文書やGitHubには通常、どのオラクルサービスを使用しているか（Chainlink、Pytなどのサードパーティオラクルネットワークか、プロトコル独自の内部価格決定メカニズムか）が記載されている。サードパーティオラクルネットワークは通常、複数の取引所のデータを集約しTWAPを適用しており、単一の浅いプールの価格のみを読み取るプロトコル独自の仕組みよりも一般的に堅牢である。
第三に、プロトコルにリスクパラメータの公開文書がある場合、その資産に供給上限（サプライキャップ）が設定されているかを確認できる。ある資産のオラクル設計に懸念があったとしても、プロトコルがその資産を借り入れまたは担保として使用できる総額を十分低く設定していれば、単一資産に問題が生じた際の最大損失は許容範囲内に抑えられる——これは全体的なリスク評価の際に合わせて考慮する価値がある緩和メカニズムである。
誰かに「わずか数千ドルで、新しく作られただけで実際の用途もないトークンが、数億ドル規模の資産を管理する貸付プロトコルに正規の担保として認められる」と言われたら、荒唐無稽に聞こえるだろう。しかしこれこそが、2026年4月に約2億8,500万ドルの損失をもたらしたDrift Protocol攻撃事件における重要な要素の一つだった——攻撃者は「CarbonVote Token」という偽トークンを鋳造し、わずかな資金でそのオンチェーン価格を操作し、最終的にプロトコルの価格オラクルにこのトークンを約1ドルの価値がある正当な資産として扱わせることに成功した。この手口がどのように機能するかを理解すれば、あるプロトコルのオラクル設計が本当にこの手口に耐えられるかどうかを判断する助けになる。
攻撃者はSOLやUSDCのような流動性の深い資産を操作しようとはしない。莫大な資金が必要になり、市場の異常監視を発動させやすいからだ。より賢く、より安上がりな方法は、全く新しいトークンを作成することだ——過去の取引履歴がなく、価格が吊り上げられた際に利益確定売りをする既存保有者もおらず、比較対象となる市場の「適正価格」も確立されていない。このトークンは白紙のようなもので、攻撃者はそこに好きな数字を書き込むことができる。
次に、攻撃者は分散型取引所（Solana上のRaydiumなど）にごく小規模な流動性プール、おそらく数千ドル程度を設置するだけでよい。ここで働く重要な原理はスリッページである——極めて浅いプールでは、少額の取引でも価格表示が劇的に動く。攻撃者は自己資金で売買を繰り返す（いわゆるウォッシュトレード）だけで、オンチェーンに表示される価格を望みの水準まで押し上げることができる——Driftの事件では、攻撃者は7億5,000万枚のトークンを鋳造し、わずか数千ドルの流動性だけで単価を約1ドルまでウォッシュトレードし、帳簿上の時価総額を実際にはそれほどの資金が流入していないにもかかわらず、理論上数億ドル規模まで瞬時に膨張させた。
価格のウォッシュトレード自体は直接的な損失を引き起こさない。本当のリスクは、プロトコルのオラクルシステムがこの操作された価格を信頼できるデータソースとして扱った瞬間に発生する。貸付やデリバティブプロトコルのオラクル設計が以下を実施していない場合、この手口によって突破されうる：最低流動性の閾値がない（一定規模を下回るプールからの価格は自動的に信頼されず却下されるべき仕組みがない）、時間加重平均価格メカニズムを採用していない（単一時点の価格は瞬時に操作されやすいが、時間窓をまたいだ平均は操作コストを大幅に引き上げる）、新規上場資産に対する観察期間やホワイトリスト審査プロセスがない（トークンは作成された瞬間に即座に担保として受け入れられてしまい、審査の関門が一切ない）、複数のデータソースによるクロス検証を併用していない（単一の取引所や単一の流動性プールの価格に依存することは、システム全体の信頼を操作されやすい単一のソースに賭けることに等しい）。
従来のスマートコントラクトの脆弱性（リエントランシー攻撃など）は、問題がロジック自体にあるため、コード監査で発見できる。しかしオラクル操作は「市場データそのものが偽造されうる」というより根本的な問題を悪用する。コードロジックは「オンチェーン価格を読み取り、それに基づいて担保価値を計算する」というプロセスを完全に正しく実行しているかもしれないが、読み取った価格そのものが最初から偽物だったのだ。Drift事件を分析した複数のレポートが、コード監査だけではオラクルシステムの安全性を保証するには不十分だと強調しているのはこのためである——監査は通常コントラクトロジックに欠陥がないかに焦点を当てており、オラクルの価格ソース設計が十分堅牢かどうかまでは必ずしもカバーしていない。
貸付プロトコルの流動性プールに資金を預けている場合、あなたの資金の安全性は、他のユーザーが預け入れた担保が実際にその価格に見合っているかどうかにある程度依存している。プロトコルが操作された価格の偽担保を受け入れてしまい、真相が明らかになってこれらのトークンの実際の価値がゼロに落ち込むと、プロトコルには不良債権が発生しうる——そして不良債権は最終的に預金者全体で負担することになりがちだ。次にプロトコルを評価する際は、どの資産を担保として受け入れているかだけでなく、それらの資産のオラクル価格ソースが単一の浅いプールなのか、それとも複数のデータソースと時間加重メカニズムによって保護されているのかも確認する価値がある。