Suiブロックチェーン上のDeFiプロトコル「Scallop」で、約15万SUIが不正に流出したと報じられた。本件は、最新の中核コントラクトではなく、過去にデプロイされた古いコントラクトの脆弱性が悪用された点に重要な示唆がある。多くのプロジェクトが監査やバグバウンティを強化する一方で、「既に使っていないはず」「影響は限定的」と見なされがちなレガシー資産が攻撃対象になり得ることを、あらためて突きつけた事案だ。
流出の概要と注目点
今回のインシデントは、プロトコル全体の設計不備というよりも、古いコントラクトに残っていた弱点が突破口になったとされる。DeFiにおける典型的な損失要因は、価格オラクル操作、権限管理の欠陥、入出金ロジックの不整合、再入可能性、想定外トークン挙動（手数料付き・フック付き）など多岐にわたる。しかし本件が示す最も大きな論点は、脆弱性の種類そのものよりも「攻撃面（attack surface）の管理」にある。
プロトコルが成長するほど、機能追加や仕様変更に伴いコントラクトが増え、過去のモジュールが残存しやすい。たとえUIや公式導線から切り離しても、オンチェーン上に存在し続ける以上、第三者が直接コールできる可能性は消えない。古いコントラクトが資金に触れられる権限や、資産移動に使える経路を少しでも保持していれば、攻撃者にとっては「最短ルート」になり得る。
なぜ「古いコントラクト」が狙われるのか
レガシーコントラクトが狙われやすい背景には、運用と心理の両面がある。運用面では、監査や形式検証の対象が最新モジュールに偏りやすく、過去版のコードは監視が薄くなる。心理面では、「既に使われていない」「資金は新コントラクト側に集約した」という安心感が生まれ、緊急度が下がりがちだ。
さらに、攻撃者は公開リポジトリ、過去のデプロイ履歴、トランザクションログからコントラクト間の関係性を丹念に洗い出す。プロトコル内部での委任権限、移行用関数、互換レイヤー、管理者用の救済機能などは、設計意図が善良であるほど“抜け道”として機能してしまう場合がある。結果として、最新版が堅牢でも、旧版の一箇所の不備から資金流出に至ることがある。
DeFiに共通する攻撃面の増え方
近年のDeFiは、単機能のAMMやレンディングから、担保種別の多様化、流動性インセンティブ、クロスプロトコル連携、LST/LRTなど複合的な金融商品へ拡張している。機能が増えるほど、コントラクトは分割され、アップグレードや置き換えが頻発する。その過程で以下のような「残りやすい論点」が生まれる。
移行期の併存：新旧コントラクトが一定期間並走し、どこかが資金経路を保持したままになる。
権限の名残：旧版に残った管理者権限、モジュール間の許可設定、ホワイトリストが整理されない。
想定外の直接呼び出し：UIやSDKが触らない関数でも、チェーン上では誰でもトランザクションを送れる。
監視・検知の空白：監視ルールが最新版のイベントや関数シグネチャ中心で、旧版の挙動がアラート対象外になる。
今回のように「古いコントラクトが起点」という形は、こうした構造的な問題の延長線上にある。
被害を抑えるための実務的な対策
レガシーリスクはゼロにできないが、体系的に下げることはできる。重要なのは、監査やテストを「最新版」だけの行事にせず、プロトコル全体を資産と権限のグラフとして捉えることだ。
コントラクト棚卸しと攻撃面の最小化
まず必要なのは、稼働中・停止済み・移行中のコントラクトを一覧化し、どの資産に触れられるか、どの権限を持つかを可視化することだ。古いモジュールが残る場合でも、資金に触れないよう権限を剥奪し、アクセス制御で外部呼び出しを封じる設計を徹底したい。可能であれば、停止用のガード（フラグ）や、最小権限の原則に基づくロール設計へ統一する。
監視は「コード世代」ではなく「資産経路」で設計する
オンチェーン監視は、最新版のイベントだけ追っても不十分になりやすい。重要なのは、資産が動く経路（送金、引き出し、担保移動、清算、ミント/バーン、権限変更）を起点にルールを設計し、旧コントラクトでも同じ重要イベントが起きたら検知できる状態にすることだ。異常な引き出し頻度、想定外の呼び出し元、権限変更の兆候などをシグナルとして、即時対応につなげる。
移行設計に「終わらせ方」を組み込む
アップグレード計画には、ローンチ手順だけでなく「旧版を安全に終わらせる」手順が不可欠だ。移行完了後に、旧コントラクトを完全停止できるのか、停止できないなら資金経路と権限を完全に断てるのか、停止操作を誰がどの条件で実行できるのかを、事前に設計しておく必要がある。移行用の特権関数や一時的な回収機能は、期間限定・多段階承認・上限付きなど、悪用耐性を組み込むべきだ。
ユーザー側が取るべき行動
プロトコルの安全性はチームだけの課題ではない。ユーザーができる現実的な防御は、「預けっぱなし」を前提にしない資金管理に尽きる。具体的には、利用額を必要最小限に抑える、複数プロトコルに分散する、公式アナウンスや異常検知の情報に注意を払う、といった基本が効果的だ。また、インシデント発生時にはフィッシングが増えるため、補償申請や返金を装った誘導には特に注意が必要である。
今回の教訓：監査済みでも「残存リスク」は消えない
DeFiのセキュリティは、単発の監査や新機能のレビューだけでは完結しない。プロトコルが長期運用されるほど、過去のコード、過去の権限、過去の移行経路が“負債”として蓄積する。Scallopの事案が示すのは、最新部分を堅牢にしても、古いコントラクトという盲点が残れば被害が起こり得るという現実だ。
今後、Suiを含む新興エコシステムが成長し、プロトコルが複雑化するほど、レガシー管理の巧拙が安全性を左右する。チームは「どのコントラクトが存在し、何に触れられ、止められるのか」を継続的に更新し、ユーザーはリスクを前提に資産配分と情報収集を行う。DeFiの成熟とは、派手な新機能だけでなく、古い足場を確実に片付ける運用力によっても測られる。