なぜこの事件は一般的なハッキングやスマートコントラクトの脆弱性ではなく「ガバナンス攻撃」に分類されるのか？
重要なのは、攻撃者が最初から最後までプロトコル自体が意図的に設計し、完全に公開していた機能だけを使ったという点だ——資産を預け入れてガバナンストークンを得る、提案を提出する、提案に投票して可決する。これらのステップはすべて、Term Vaultsのガバナンスシステムがもともとガバナンストークンを保有する誰にでも実行を許していた通常の操作であり、スマートコントラクトのロジックの制約を回避したステップは一つもなく、コード内の誤りを悪用したわけでもない。CertiKとPeckShieldの両セキュリティ企業は、この事件を「コントラクトのバグ」ではなく「ガバナンス攻撃」（governance exploit）と明確に分類している。その違いはこうだ——コントラクトのバグとはコード自体が誤って書かれていることを指し、ガバナンス攻撃とはコードは完全に正しく書かれているものの、ガバナンスの仕組みのパラメータ設計（投票トークンの希少性や、十分な牽制機能があるかどうかなど）そのものに経済的な弱点があり、攻撃者が実際にどの技術的防御線も突破することなく、低コストで意思決定権を買い取れてしまう、という点にある。
攻撃者がわずか0.5 ETHでほぼ絶対的な投票権を獲得したということは、Term Vaultsのガバナンストークンの総流通量が異常に少なかったことを意味するのか？このような状況はよくあるのか？
事件で明らかになった詳細によれば、攻撃者はまず資産をTerm金庫の持分トークン（tmvETH）に変換し、それをガバナンスラッパーコントラクトに預け入れて対応するガバナンストークン（gtmvETH）を受け取った——これはこの特定の金庫製品が事件発生当時、極めて少額の預け入れだけで圧倒的多数の投票権を占められるほど、ガバナンストークンの総量が実際に少なかったことを意味する。DefiLlamaのデータによれば、事件発生前のTermの金庫製品の総ロック価値（TVL）は約1245万ドルであり、DeFi業界全体の規模と比べると大きくはない。このような規模が小さく、稼働開始からまだ日が浅く、ガバナンストークンが広く分散保有されていない金庫製品は、ガバナンストークンがすでに多数の保有者に分散している成熟したプロトコルと比べて、この種の投票権集中という弱点が生まれやすい性質を本質的に持っている。
この状況は業界で初めて起きたわけではない。DefiLlamaの統計によれば、2026年にはすでにガバナンス攻撃に分類される事件が複数発生しており、その中で最大規模のものは7月に発生したBonkDAOに対する悪意ある提案で、約2000万ドルの損失をもたらした。これはガバナンストークンの集中度が低すぎるという構造的な弱点が、Term Vaultsに固有のものではなく、新しく稼働を始めたばかりの規模の小さいDeFiガバナンスシステム全般が注意すべきリスクの一種であることを示している。
この種のガバナンス攻撃に対して、一般的なスマートコントラクト監査やセキュリティ審査は、事前にこのリスクを発見できるのか？
これこそがこの事件が明らかにした核心的な矛盾だ。従来のスマートコントラクト監査は通常、コードのロジック自体が誤って書かれていないかを検査の重点とする——リエントランシー攻撃の脆弱性、整数オーバーフロー、権限管理ロジックの誤りといった技術的な問題を対象とし、これらのチェックは「このコードがあらゆる入力に対して設計意図通りに動作するか」を問うものだ。しかしガバナンス攻撃が突きつけているのはまったく別の層の問題だ——コードは確かに設計意図通りに完全に実行された。投票の仕組みは正しく票数を集計し、票数に応じて正しく提案の可決・否決を判断した。問題はコードにあったのではなく、「誰が投票資格を持ち、投票権を得るのにどれだけのコストがかかるか」という経済的パラメータそのものが、十分厳密に設計されていなかったことにある。
一部のより高度なセキュリティ審査サービスは、「ガバナンストークンの保有集中度」や「多数の投票権を獲得するのに実際にかかる市場コスト」を審査範囲に組み込み始めているが、この種の経済セキュリティ監査（economic security audit）は現時点で業界の標準装備とは言えず、ほとんどのチームは依然としてコード自体に焦点を当てた従来型の監査を行っている。これこそが、トレジャリーや金庫型製品が資金調達の際、「監査を通過した」ことを示すだけでなく、ガバナンストークンの保有分布状況や多数決を獲得するのに実際に必要なコストも同様に開示する価値がある理由だ。預金者がこの種のリスクを自ら評価できるようにするためであり、「監査通過」をすべての層のセキュリティ保証を含むものと誤解しないためだ。
Term Vaultsに直接資産を預け入れていないが、この事件は一般のDeFiユーザーにとってどのような実践的な参考価値があるのか？
最も直接的な参考価値は、「この金庫製品が分散型ガバナンスを謳っていること」と「そのガバナンスシステムに実際に誰かが牽制として機能しているかどうか」がイコールではないことを示す、具体的で検証可能な事例を提供したという点だ。次にDAOガバナンスやコミュニティ投票の仕組みを強調する金庫、レンディング、イールド型製品を評価する際には、いくつか具体的な問いを立てる価値がある——そのガバナンストークンの総流通量と保有分布は透明で公開されているか。過去の提案投票には実際に複数の独立したアドレスが参加してきたか、それとも投票率が長らく低く名ばかりの仕組みになっていないか。特に資産の移転権限に関わる重要な提案が可決された後、資産が実際に動かされる前に誰かが異常に気づいて介入できる時間的猶予を与えるタイムロックやマルチシグの仕組みが存在するか。
より広く言えば、この事件はガバナンス型製品における「監査通過」というラベルが実際にどこまでをカバーしているのかを見直すきっかけにもなる。本記事の冒頭で述べた通り、監査が検証するのはコードのロジックが正しいかどうかであり、「このガバナンスシステムの投票権が、わずかなコストで買い占められないか」ではない。この二つの間に必然的な論理的関連性はなく、預け入れの前にこの区別を念頭に置くことは、「分散型」を謳う製品が実際にどれだけ分散化されているのかをより正確に判断する助けとなるだろう。
2026年8月23日、分散型レンティングプロトコルであるTerm Financeの戦略金庫（Term Vaults）から約850万ドル相当の資産が失われた。内訳は約2,843 ETH（約687万ドル）と168万USDC（その後約160万DAIに交換）だった。セキュリティ企業のPeckShieldとCertiKはそれぞれ独立して損失額を追跡・確認し、資金の流れを同一の攻撃者アドレスに特定した。しかしこの事件で最も異例なのは損失額そのものではなく、攻撃者が目的を達成した方法だ——最初から最後まで、スマートコントラクトは一切破られておらず、秘密鍵も一切盗まれていない。攻撃者が行ったのは、プロトコルのルールに完全に従った「合法的な投票」であり、ただその票をすべて自分自身に投じただけだった。
セキュリティ企業Go Plus Securityが公表した技術分析によれば、攻撃者の手口は極めてシンプルだった。まず約0.5 ETHを0.485 tmvETHに交換し、その資産をTerm VaultsのYearn v3インフラ上に構築された治理ラッパーコントラクトに預け入れ、同等量のガバナンストークンgtmvETHを受け取った——まさにここに問題があった。この治理システムの投票トークンは、明らかに十分な流通量や保護メカニズムを欠いており、攻撃者はこの極めて小さな預け入れだけで、ほぼ絶対的な投票権を獲得することができた。投票権を得た攻撃者は、番号5の提案を自ら提出し、他の投票者がほとんど参加せず対抗提案も出ないまま、自らその提案を可決させ、金庫資産への引き出し権限を直接手に入れた。
Term Labsは事件発生後速やかに対応し、すべてのMeta Vaultへの預け入れ機能を恒久的に停止（この決定は取り消し不可能）、関連するDAOガバナンスの役割を剥奪し、引き出し機能は開放したままにした。同時にTerm Financeの中核となるレンティング市場自体は影響を受けていないと述べた。Yearnチームもこれに応じ、Termの影響を受けたコントラクトが確かにYearn v3アーキテクチャ上に構築されていたことを確認したが、攻撃者が実際に悪用したのはYearn自体のコードではなく、Termが自社の金庫製品向けに専用開発した治理ラッパーコントラクトだったとした。この区別は重要だ——この事件は最初から最後まで「コードが破られた」事件ではなく、関与したすべての取引は、プロトコル自体のルールの下では完全に有効かつ正当な操作だった。
この事件は、見落とされがちなリスクを白日の下にさらした。スマートコントラクト監査が検査するのはコードのロジックに欠陥がないかどうかであり、監査の範囲には通常「このガバナンスシステムの投票権が、わずかなコストで買い占められないか」という問いは含まれない。「分散型ガバナンス」を謳う金庫製品に資金を預け入れる前には、いくつかの点を確認する価値がある——そのガバナンストークンの総流通量が、少額の資金で多数の投票権を買い占められるほど薄くないか、悪意ある提案が可決された後に対応時間を稼げるタイムロックやマルチシグの仕組みが存在するか、そして過去に実際のコミュニティメンバーが投票に参加し不正な提案を牽制してきた実績があるか——ガバナンスシステムが名ばかりで、普段誰も提案キューを見ていないような状態になっていないか。あるコントラクトが監査を通過しているかどうかは「コードが正しく書かれているか」に答えるものであり、「その投票を誰かが気にかけていたか」には答えられない。