「フラッシュローン攻撃」は映画にしか出てこないハッカーの見せ場だと思っていませんか。あなたが金庫にお金を預けて利息を受け取ることとはまったく別の話だと?Summer.fiの今回の純損失600万ドルは、よりによって一連の合法的な入金・償還操作から始まりました。この記事はそれを神秘的なブラックテクノロジーとして演出することはありません。まず誤解、会計の脆弱性、攻撃の流れを整理し、最後にあなたが金庫に入れたお金を本当に心配すべきなのかをお伝えします。
フラッシュローン攻撃はハッカーがあなたのウォレットに侵入することなのか？初心者にありがちな3つの誤解
フラッシュローン攻撃は映画のシーンのように聞こえませんか——ハッカーがあなたのウォレットを狙い、数秒で秘密鍵を解読してお金を空にする、というような?Summer.fiの今回の事件では、誰のウォレットも侵入されていません。攻撃者が使ったのはプロトコルが完全に開放している通常の機能であり、ただ会計データを水増ししてシステムに誤判定させただけです。これらの誤解を理解して初めて、後で説明する攻撃の流れが理解できるようになります。ここは私が見てきた中で初心者が最も誤判断しやすい部分でもあります。
誤解その1：秘密鍵の流出だけが「盗まれた」ことだと思い込む
多くの人は「プロトコルが攻撃された」と聞くと、反射的に秘密鍵が盗まれた、ウォレットがハッキングされたと考えます。この直感はフィッシング詐欺や偽ウォレットアプリには当てはまることが多いですが、Summer.fiのような金庫プロトコルには当てはまりません。攻撃者は最初から最後まで誰の秘密鍵も手に入れておらず、管理者権限も行使していません——彼が借りたフラッシュローン、預けたお金、償還の操作は、すべてSummer.fiが全ユーザーに開放している通常の機能です。
つまり、今回の脆弱性は「誰の鍵が盗まれたか」ではなく、プロトコルがどう計算するかにあります金庫内の資産を。秘密鍵をどれだけしっかり管理していても、会計ロジック自体に穴があれば、資産は水増しされて価値がなくなる可能性があります。これが、フィッシング対策や偽リンク対策だけでは不十分な理由であり、金庫自体の設計リスクこそが、今回の事件から本当に学ぶべき教訓なのです。
誤解その2：フラッシュローン攻撃を一般的な借り逃げ詐欺と同じだと思い込む
もう一つよくある誤解は、フラッシュローン攻撃を拡大版の借り逃げ詐欺のように考えることです。まるで大金を借りて悪事を働き、最後は借金だけ残して逃げるかのように。しかしフラッシュローンのルールはまったく異なります。借入と返済は同一ブロック、同一トランザクション内で完了しなければならず、完済できなければ取引全体が即座に失敗し、何も起きなかったことになります。
これは、攻撃者がそもそも「踏み倒す」リスクを負えないことを意味します。極めて短い時間枠の中で、借りた6,540万ドルを元本を上回る利益に変えて初めて、無事に逃げ切れるのです。この種の攻撃で試されるのは、会計ロジック上の穴を見つけられるかどうかであり、度胸があるかどうかではありません。初心者は「いくら借りたか」にばかり注目しがちですが、それでは本当に注目すべき操作手法を見落とし、この種の攻撃の背後にある準備の労力を過小評価することになります。
誤解その3：プロトコルの出金停止を、資金がすでに取り戻されたことだと思い込む
Summer.fi事件が発覚した後、プロトコルはすぐにすべての金庫の出金を停止しました。この動きは初心者に「お金はもう守られた」「損失はもう止まった」と誤解されがちです。実際のところ、出金停止は脆弱性がこれ以上悪用されるのを防ぎ、より多くのユーザー資産が同じ手口で吸い取られるのを阻止するためのものであり、資金が取り戻せたかどうかとは別の話です。
盗まれた600万ドルは、すでにCurveを経てDAIに交換され、Tornado Cashのようなミキシングツールに流れ込んでおり、現時点で公開されている回収の進捗はありません。プロトコルの公告に「停止済み」「調査中」といった文言を見かけても、それはプロトコルが止血をしていることを示しているだけで、あなたのお金がもう取り戻せたことを意味しません。つまり、出金停止が守っているのはまだ被害に遭っていないユーザーであり、すでに盗まれたそのお金とはまったく別の話です。両者を混同しないでください。
なぜ金庫の会計はこんなに水増ししやすいのか？まずtotalAssets()という攻撃の突破口を理解する
金庫（ボールト）は本来、みんなのお金を集めて収益を得るだけの仕組みなのに、なぜ会計がこんなに簡単に破綻してしまうのでしょうか?問題の核心は「プロトコルがあなたのために現在の価値をどう計算するか」にあり、お金を保管する方法そのものに問題があるわけではありません。持分（シェア）換算とtotalAssets()というこの重要な関数を理解して初めて、Summer.fiの脆弱性がどの段階にあったのかが見えてきます。
金庫（ボールト）はどうやって持分であなたの資産を換算するのか
あなたが金庫に預けたお金は、プロトコルが一件ずつ記帳してくれるわけではなく、一定数の「持分（シェア）」に換算されます。金庫の総資産を流通している持分の総数で割ったものが、1持分あたりの価値であり、償還時には持分にこの単価を掛け戻すことで、受け取れる資産額が算出されます。この設計は手間がかからず組み合わせやすい一方、代償としてシステム全体がたった一つの数字——金庫の総資産がいくらか——だけを信頼することになります。
総資産の数字が誤って計算されたり、人為的に操作されたりすれば、あなたがどれだけ慎重に預けていても、償還時に算出される金額はそれに応じて歪んでしまいます。Summer.fiのアーキテクチャでは、この計算作業はFleetCommanderというコントラクトが担当しており、その下にさらにArkと呼ばれる複数の戦略モジュールが接続され、それぞれ異なるレンディングプロトコルに投じて収益を得ています。持分換算のロジック自体には誤りはなく、間違っていたのはその換算に使われる総資産の数字の方でした。
totalAssets()とは何か、なぜ悪意ある者がそれを水増しできるのか
totalAssets()は金庫コントラクト内の関数の一つで、「この金庫が現在合計でどれだけの資産を保有しているか」をリアルタイムで返す役割を持っています。持分の単価はこの数字を元に算出されます。私自身、この脆弱性の説明を初めて見たとき、こんなに基礎的な部分に問題があったことに驚きました。Summer.fiのArkモジュールは計算の際、「コントラクトアドレスに直接預け入れられた資産」まで総資産に含めてしまい、そのお金が正規の入金プロセスを経て入ってきたものかどうかを区別していなかったのです。
この設計は事実上、裏口を残していたことになります。誰かが正規の入金経路を通さずに資産をArkへ直接寄付しさえすれば、totalAssets()はそのお金をそのまま計上し、1持分あたりの価値を押し上げてしまうのです。攻撃者のやり方は単純です。まず低コストで持分を買い集め、次に資産を寄付して単価を吊り上げ、最後に手持ちの持分を水増し後の金額に交換する、というものであり、金庫にもともとあった資産を一切盗む必要がありません。この突破口こそが、事件全体の核心なのです。
なぜフラッシュローンは1ブロック内で一連の操作を完結できるのか
フラッシュローンがなければ、上記の操作手法は成立しにくくなります。攻撃者はまず持分を買い集め資産を水増しするための大きな元本を用意する必要があり、資金コストが高く、リスクも大きいからです。フラッシュローンが解決するのはまさにこの問題です——瞬時に巨額の資金を借り入れ、同一ブロック内で持分の買い集め、資産の寄付、償還による換金を完了させ、さらに借入金を元利ともに返済する、という一連の流れを一気呵成に成し遂げるのです。
これが、この種の攻撃がしばしば数秒、1ブロックの時間内に終わってしまい、反応する暇すらない理由です。一般ユーザーにとって、重要なのはフラッシュローンの発動方法を理解することではなく、一つのことを見抜くことです：リアルタイムで総資産を計算し、なおかつ外部からの直接の資金寄付を許容する金庫設計は、理論上どれも同じ手口に狙われる可能性があるということです。これが、近年の監査会社がこの種の「単一ブロック内で完結する裁定」攻撃パターンに特に注目している理由でもあります。
Summer.fiの600万ドル事件は実際にどう起きたのか？フラッシュローン攻撃の全プロセスを解き明かす
原理を理解した上で、Summer.fiの今回の攻撃は実際にどのようにステップを踏んで起きたのでしょうか?一連の流れを振り返ると、どのステップも前述の脆弱性に正確に対応していることが分かります——これは各ステップの利益を綿密に計算した完全な計画であり、借入、水増しから換金、そして資金の洗浄まで、ほぼ一気呵成に進んでおり、その場のひらめきではありません。この3つのステップを解き明かせば、なぜこの種の攻撃が防ぎきれないのかがよりはっきり分かるでしょう。
第1ステップ：6,540万ドルのフラッシュローンを借り入れ、まずSiloの持分を買い集める
攻撃者の第1ステップは、フラッシュローンを通じて6,540万ドルを借り入れることでした。このお金は直接金庫の攻撃には使われず、まずSilo: Varlamore USDC Growthという資産を買い進め、一定数の持分を蓄積するために使われました。このステップは一見単純な市場操作に見え、いかなる脆弱性も利用しておらず、警告も発動していません。プロトコル自体がユーザーによるこの資産の購入を完全に許可しているからです。オンチェーンの記録から見れば、このステップ自体は完全に規則にのっとったものであり、事後に攻撃の流れを解析して初めて、その後の操作との関連が浮かび上がってきたものです。
このステップは後の操作の地ならしをするものです。自分の手元に十分な持分を確保しておいて初めて、資産価値が水増しされた後にこれらの持分で最大の利益を得るための元手ができます。この買い集めのステップがなければ、たとえtotalAssets()の水増しに成功しても、攻撃者はほとんど利益を得られず、計画全体が成立しません。
第2ステップ：Arkへ寄付してFleetCommanderのtotalAssets()を水増しする
持分を手に入れた後、攻撃者は次に手元に蓄積した資産をArkコントラクトへ直接寄付し、正規の入金プロセスを飛ばします。前述の通り、FleetCommanderのtotalAssets()の計算方法は「正規の入金」と「直接の寄付」を区別しておらず、この寄付された資産はすぐさま金庫の総資産に計上されてしまいます。
金庫の総資産は瞬時に押し上げられますが、流通している持分の数はそれに伴って増えません。結果として、1持分あたりに交換できる資産価値が人為的に吊り上げられることになります。このステップは事件全体で最も重要な操作であり、前の持分の買い集めは準備にすぎず、ここでこそ帳簿の数字に細工を加える核心が行われています。預金者の数や市場相場は、この水増しプロセスとは一切無関係であり、プロセス全体を通じて裏口の権限も一切使われていません。単純に計算ロジックの脆弱性が見つけられ、拡大利用されただけなのです。
第3ステップ：7,090万ドルで償還・換金し、資金がCurveを経てDAIに換わりTornado Cashへ流出
totalAssets()が水増しされた後、攻撃者の手持ちの持分は瞬時により価値の高いものになりました。彼は先に買い集めた持分を償還に出し、7,090万ドル相当の資産に交換しました。借り入れた6,540万ドルのフラッシュローン元本と手数料を差し引き、さらに先に投入した6,480万ドルの操作コストを加えても、純利益は600万ドルとなり、このお金はそのまま懐に収まりました。しかもこれらはすべて同一ブロック、同一トランザクション内で起きたことです。
裁定利益を手にした後、攻撃者は資金を元のチェーン上に留めることはせず、すぐにCurveを通じて資産をDAIというステーブルコインに交換し、追跡されたり取引所に凍結されたりするリスクを下げました。続いてDAIをTornado Cashのようなミキシングツールに預け入れ、資金の流れを断ち切りました。現時点まで、この600万ドルの行方について公開されている回収の進捗はありません。
同時期にBONK DAOでも事件が発生、金庫/国庫系プロトコルは特に危険なのか？
Summer.fi事件が発覚したのと同じ時期に、BONK DAOの国庫も約2,000万ドルが奪われたと報じられました。この2つの事件は、金庫や国庫系のプロトコルが特に問題を起こしやすいことを意味するのでしょうか?答えはそう単純ではありません：両事件の攻撃手法はまったく異なります。一方は会計の脆弱性であり、もう一方はガバナンス機構の抜け穴を突かれたものです。この違いを理解して初めて、プロトコルのリスクを評価する際にどこを見ればよいのかが分かります。
BONK DAOのガバナンス攻撃はSummer.fiの攻撃手法とどう違うのか
Summer.fiの問題はスマートコントラクトがどう資産を計算するかにありましたが、BONK DAOの問題はコードの脆弱性にはまったくなく、ガバナンスの投票メカニズム自体にあります。攻撃者はわずか約400万ドルを費やしてBONKトークンを買い込み、十分な投票権を蓄積した上で悪意ある提案を支持し、国庫に保管されていた約2,000万ドル相当、換算すると実に4.426兆枚に達するBONKトークンを自分が管理するウォレットに移しました。
一連のプロセスは完全にプロトコルのルールに沿って投票フローを完了しており、いかなるシステムへのハッキングも、いかなる秘密鍵の使用もありませんでした。問題は提案そのものが阻止されなかったことにあります。これはSummer.fiの「合法的な操作、数字の水増し」というパターンに似ており、どちらもルールそのものの抜け穴を突いたものです。ただしSummer.fiが突いたのは会計ロジックで、BONK DAOが突いたのは投票の閾値でした。
ガバナンス攻撃とスマートコントラクトの脆弱性、どちらの方が防ぎにくいのか
防御の難易度から見ると、スマートコントラクトの脆弱性は少なくとも監査、テストネットでのシミュレーション、コードレビューによって見つけ出すことができます。脆弱性はコードにそのまま書き込まれているため、誰かが時間をかけてチェックする気さえあれば、理論上は発見できます。ガバナンス攻撃が厄介なのは、投票メカニズム自体には誤りがなく、間違っていたのはタイムロックを設計していなかったこと、最低定足数の閾値、マルチシグによる再確認といった安全ブレーキです。
BONK DAOの今回のケースはまさにタイムロックがなく、提案が可決されるとすぐに実行され、誰にも反応する余地を与えませんでした。また最低定足数の閾値もなく、わずか400万ドルを費やしただけの人物が2,000万ドルの国庫の決定を左右できてしまいました。これに比べ、ガバナンス攻撃は事後のパッチで解決するのがより難しく、問題は決定メカニズム全体の設計思想にあり、コードを数行変えるだけでは対処できません。
あるプロトコルの金庫/国庫設計にリスクの緩衝があるかをどう判断するか
金庫や国庫系のプロトコルに出会ったら、まず3つのことを確認できます。第一に、資産計算のロジックが外部からの直接の資金寄付の影響を受けないか。第二に、重要な操作にタイムロックがあり、コミュニティに反応する時間を与えているか。第三に、ガバナンス提案に最低定足数とマルチシグによる再確認があり、少数の人間が巨額資金の行方を左右できないようになっているか、です。
この3つがどれも備わっていない場合、そのプロトコルは「効率」を「安全ブレーキ」より優先していることを意味し、いったん誰かが穴を見つければ、時間を稼げる緩衝は何もありません。コードの詳細を理解する必要はありませんが、少なくとも入金前にプロトコルのガバナンス文書やコントラクト設計の説明にこれらの仕組みが触れられているかを確認する習慣をつけることをお勧めします。これはプロトコルの体質の良し悪しを判断する最も直接的で、最も手間のかからない方法です。
事件発生後、影響を受けたユーザーの資金の現状と、対応はどこまで進んでいるのか？
お金が盗まれた後、プロトコルは通常真っ先に「対応済み」「調査中」といった公告を出しますが、これらの言葉は具体的にどの程度の進捗を表しているのでしょうか?この節ではSummer.fiとBONK DAOそれぞれの現在の進捗を整理し、「停止」「凍結」「通報」といった動きが実際にあなたのお金を取り戻せるものなのかを分かるようにします。
Summer.fiの現在の対応状況（金庫停止と資金の流れの追跡）
Summer.fiのプロトコルガーディアン（guardian）は事件発生後、真っ先にLazy Summer Protocol傘下のすべての金庫を停止し、脆弱性が繰り返し利用され損失が拡大するのを防ぎました。独立系の研究者たちが次々と分析を公開し、今回の攻撃が完全に正規の入金、償還、Arkからの引き出しといった合法的な関数によって行われたものであり、秘密鍵の流出や管理者権限は関与していないことを確認しています。
現時点で、Summer.fi公式はこの事件について正式な声明をまだ発表していません。資金の流れの追跡は主にオンチェーン分析コミュニティの継続的な観察によるもので、盗まれた600万ドルがCurveを経てDAIに交換され、最終的にTornado Cashに流れ込んだことが確認されています。金庫の停止が解決するのは「これ以上出血しない」ことであり、すでにいくらかの資産を取り戻したことを意味するものではありません。
BonkDAOのその後（取引所による入出金の凍結、法執行機関への通報）
BONK DAO側の動きは比較的積極的で、チームはSolana財団や複数の取引所と調整し、取引所に流れた不正資金を追跡・凍結していると公表しています。同時にこのガバナンス攻撃について法執行機関への通報にも着手しています。盗まれたBONKトークンの一部が取引所のアドレスへ移動し始めているのが確認されており、攻撃者が換金を準備している可能性を示しています。
取引所による入出金の凍結、法執行機関による調査への介入、これらの動きは攻撃者の換金速度を遅らせ、今後一部資金を取り戻せる可能性を高めますが、どれも「お金はもう取り戻せた」という保証ではありません。BONKはこの事件を受けて約8%から10%下落しました。トークンを保有している、あるいは資金を国庫のガバナンスに投じていたユーザーにとって、これは紛れもない損失であり、公式が声明を出したからといって自動的に消えるものではありません。
なぜ資金の凍結/マークされることが、必ずお金を取り戻せることを意味しないのか
取引所によるアカウント凍結、オンチェーン分析者によるアドレスへのマーク付け、これらの動きは進展があるように聞こえますが、資金を取り戻せるかどうかは、いくつかの条件次第です。攻撃者が資産を調査に協力する意思のある取引所に移したかどうか、先にミキシングツールを経由して追跡を断ち切ったかどうか、現地の法執行機関に国境を越えた協力を行う能力と意志があるかどうか、といった条件です。
Summer.fiの600万ドルはすでにTornado Cashに入っています——この種のツールが存在する目的は、まさに資金の流れの追跡を無効化することであり、その後の回収の難易度は大幅に上がります。一方、BONK DAOは一部の資金がまだ完全には手放されていないため、取引所に押さえられる可能性は確かに比較的高くなります。同じ「凍結中」「調査中」という言葉でも、その背後にある回収の可能性は天と地ほど異なることがあります。初心者は一括りにして考えるべきではありません。
DeFi金庫に入金する前、初心者が最も犯しやすい3つの判断ミス
この2つの事件を見て、いっそ金庫系の商品に手を出さない方が安全なのではと思うかもしれません。実は重要なのは触れるかどうかではなく、入金する前に正しい判断ができているかどうかです。多くの人が失敗するのは資金の運用が慎重でなかったからではなく、プロトコルを評価する方法が最初から間違った指標を使っていたからです。この節では最もよくある3つの判断ミスを整理し、あなたの心構えを立て直す手助けをします。
ミスその1：APYだけを見て、金庫の基盤資産構成やレバレッジ設計を見ない
APYの数字が魅力的であることは、多くの人が入金するかどうかを決める最初の、あるいは唯一の判断材料になっています。しかしAPYは「どれだけ稼げる見込みか」を教えてくれるだけで——この収益がどこから来るのかはまったく教えてくれません。基盤となるレンディングの利ざやによるものなのか、レバレッジ操作によるものなのか、あるいは新しい資金が絶えず入ってこないと支えられないような仕組みによるものなのか。収益の源泉が異なれば、負っているリスクも天と地ほど違います。
Summer.fiの金庫はもともと資金を複数のArk戦略モジュールに配分して収益を得る仕組みであり、戦略モジュールが多いほど、接続されるレンディングプロトコルが複雑であるほど、システムの攻撃対象領域は広がります。これはAPYが高いかどうかとはまったく別の話です。入金前に10分かけて金庫の資産配分の説明を確認することは、APYの数字を眺め続けるよりもはるかにリスク判断の助けになります。
ミスその2：知名度のあるプロトコルが保証している=スマートコントラクトにリスクがゼロだと思い込む
Summer.fiは無名の小さなプロトコルではなく、背後には一定の知名度と資金規模があり、これも多くのユーザーが当初喜んで入金した理由の一つでした。しかし今回の事件が証明したのは、プロトコルの知名度やチームの背景は、コードに脆弱性がゼロであることをイコールで意味しないということです。どれだけ成熟したチームでも、資産計算のロジックの中に見つかっていない穴を残している可能性があります。規模が大きく、利用者が多いことは、かえって人の警戒心を緩めさせ、最も基本的な安全確認を忘れさせやすいのです。
「みんなが使っている」「稼働してから長い」ことを安全性の唯一の保証だと考えるのは、最も陥りやすい心理的な落とし穴です。より現実的なやり方は、プロトコルが定期的に監査を受けているか、監査報告書がどれだけ公開され透明性があるか、過去にバグバウンティの実績があるかを確認することです。私自身、新しいプロトコルを評価する際は必ずまず監査報告書を探し、見つからなければそのまま見送ります。
ミスその3：緊急停止スイッチの存在自体が、プロトコルがリスクを認めている証拠だということを見落とす
ほぼすべての主流DeFiプロトコルには緊急停止メカニズムが備わっており、ガーディアンが異常を検知した際に真っ先にストップをかけ、損失の拡大を防げるようになっています。この設計は実は一つのことを物語っています。プロトコルチーム自身が、システムに誤りが起こりうると考えているからこそ、このブレーキを用意しておく必要があったのです。見方を変えれば、もしあるシステムが絶対に誤りを起こさないのであれば、そもそもこのような緊急スイッチを設計する必要はありません。
多くの人は「停止メカニズムがある」と見るとかえって安心してしまい、常に誰かが見張っていて資金は絶対に安全だと誤解しますが、停止メカニズムが存在する前提が、そもそもリスクが存在することにあるという点を見落としています。入金前に発想を変えてみましょう。もしプロトコル自身が緊急ブレーキを用意しているのなら、あなたも自分の資金のためにブレーキを用意していますか。例えば異なるプロトコルに分散配置する、資産に監視アラートを設定するなどです。
一般ユーザーができる自己防衛チェックリスト、リスクを最小限に抑える
これだけ多くの誤解と脆弱性について語ってきましたが、最も実際的な問題に戻りましょう。あなたに何ができるのか、リスクを自分が受け入れられる範囲まで下げるには?この節では入金前、入金中、事件発生時というこの3つの段階でそれぞれすべきことを整理し、抽象的なリスク意識を具体的に実践できる行動に変える手助けをします。それでは時系列に沿って、一つずつ整理していきましょう。
入金前にプロトコルの監査報告書とバグバウンティの実績をどう確認するか
どの金庫にお金を入れる前でも、まず時間をかけて3つのことを確認しましょう。プロトコルが有名な監査会社に監査を依頼したことがあるか、監査報告書が公開され閲覧できるか、長期的に運用されているバグバウンティ制度があるか。これらの情報は通常プロトコルの公式サイトや公式文書で見つけられます。もしあるプロトコルが監査報告書すら提示できない、あるいは懸賞制度が形骸化しているなら、警戒を強めるべきです。懸賞金額がプロトコルが管理する資金規模を合理的に反映しているかどうかも、注目に値します。
監査は万能薬ではありません。Summer.fiの脆弱性も事件発生前にまったく検証されていなかったわけではありませんが、少なくとも監査とバウンティの実績は、そのプロトコルチームが脆弱性を見つけるためにリソースを投入する意思があるかどうかを反映しています。この確認作業はそれほど時間もかからないのに、基本的な下調べすらしていない大量のプロトコルをふるい落とす手助けになります。
入金中は分散配置し、資産監視アラートを設定する
たとえすでにプロトコルを絞り込んでいたとしても、すべての資金を単一の金庫に集中させることはお勧めしません。異なるプロトコル、異なる資産タイプに分散配置することで、単一の脆弱性によってすべての資金が一度にゼロになるリスクを効果的に下げられます。これは伝統的な投資の「卵を一つのかごに盛るな」というロジックとまったく同じで、DeFiではかごがスマートコントラクトに置き換わっただけです。
また、自分の資産に監視アラートを設定することをお勧めします。例えば金庫のtotalAssets()の異常な変動、単一取引の金額が大きすぎるといった指標で、発動すればすぐに通知が来るようにします。この種の監視ツールはオンチェーン分析プラットフォームで通常自分で設定できます。攻撃の発生自体は防げませんが、異常を真っ先に知ることができ、事後にニュースを見て初めて自分も被害者の一人だったと気づくことにはなりません。
事件発生の瞬間、真っ先にすべき3つのこと
万が一あなたがお金を入れているプロトコルが本当に事故に遭ったら、慌てても無駄です。決まった順序で対応することで、初めて損失を最小限に抑えられ、後の賠償請求や調査協力に必要な証拠も残せます。以下の3つのことを、順番通りに行うことをお勧めします：
- すぐに自分の資産状況を確認する：公式の公告とブロックチェーンエクスプローラー上のウォレット記録を確認し、資金が実際に影響を受けているかを確かめます。自分で自分を怖がらせすぎないように、また影響を受けたポジションを見落とさないようにします。
- すべての取引記録と公式公告をスクリーンショットで保存する：攻撃発生時刻、金額、自分自身の入出金記録を含みます。これらの資料は後日、プロトコルの調査に協力する場合でも、法執行機関に通報する場合でも、必要な証拠となります。
- コミュニティの噂ではなく公式チャンネルに注目する：プロトコルの停止期間中は偽のカスタマーサポートや偽の賠償リンクといった二次詐欺が発生しやすくなります。必ず公式に検証されたチャンネルのみで最新の進捗を確認し、DMで送られてくる「資金回収を手伝います」といったリンクは一切クリックしないでください。
この3つのことを終えて初めて、他のポジションを持ち続けるかどうか、資産配分を調整するかどうかを評価する段階に移ります。事件発生時に最も避けるべきなのは、藁にもすがる思いで出所不明の「資金回収代行」サービスを軽々しく信じてしまい、かえって二次被害に遭うことです。
結論
Summer.fiの今回の事件は、最初から最後までハッカー映画によく出てくる侵入手法を一切使っておらず、頼ったのはすべてプロトコル自身が開放していた機能と、見つけられていなかった一つの会計上の脆弱性でした。BONK DAOの教訓も同様で、問題はコードが破られたことではなく、ルールそのものに穴が残されていたことにあります。この記事の狙いは、あなたにこれからDeFiの金庫を敬遠させることではありません——入金前に10分多くかけて監査を確認し、ガバナンス設計を見ておく方が、事後になってTornado Cashの記録の中に自分のお金を探すよりも、はるかに割に合うということをお伝えしたいのです。
