DxSale、インシデントに関する説明を公開：v2以降の流動性ロック契約は影響なし

2026年5月30日

DxSale、インシデントに関する説明を公開：v2以降の流動性ロック契約は影響なし

最近のBNB Chainにおける流動性ロッカーの悪用により、DeFiにおける長年の疑問が再燃しています。「古いインフラ」は、基盤となるチェーンが進化するにつれて、再び危険になる可能性があるのでしょうか？2026年5月下旬、攻撃者は2021年まで遡る旧式のDxSale流動性ロックを標的とし、オンチェーンでの資金移動を引き起こし、かつてDxSaleの初期ロッカーアーキテクチャに依存していたプロジェクトの間で懸念が広がりました。

2026年5月30〜31日頃（タイムゾーンによる）に公開されたフォローアップ説明で、DxSaleは、問題はv1ロック契約に限定されており、v2以降のバージョン（v2、v3など）は影響を受けていないと述べました。後者の契約は監査済みであり、ユーザーのロックされた資産は安全であると報告されています。

以下に、何が起こったのか、なぜチェーンレベルの「アトミック」実行機能が古い契約でエッジケースを露呈する可能性があるのか、そしてLPとトークンチームが次に何をすべきかについて、実践的な内訳を示します。

BNB Chainで何が起こったか（2026年5月29日）

2026年5月29日、BNB Chain上で、主に2021年頃の約1,400件の古いLPポジションが枯渇したという報告が表面化しました。被害額は約730万ドルと推定されています。インシデントを追跡した複数のレポートは、攻撃者が所有権/特権制御の操作と一致するアプローチを使用し、その後、スワップやデポジットを通じて資産をルーティングしたと指摘しています。

インシデントで広く引用されている攻撃者のアドレスは以下の通りです。

0xC4574DDE...2EeaFA69 — **BscScanのアドレス追跡**で確認可能

公開されている概要では、攻撃者が資金をBNBに統合し、2,958 BNB（当時約187万ドル）を2つの主要ウォレットに移動させた後、取引所への入金アドレスにルーティングし、PancakeSwap経由でスワップしたとも説明されています。分かりやすいインシデント概要については、**CointelegraphのTradingViewへのミラー記事**を参照してください。

DxSaleの核心：「爆発半径」はv1のみ

DxSaleの説明は、3つの主要な主張を強調しています。

影響を受けた契約は、2021年にローンチされた初期の「v1」流動性ロック契約である
v2以降のロック契約は影響を受けていない
後世代の契約は異なるアーキテクチャで構築され、セキュリティレビュー/監査を受けている

ユーザーは常に契約アドレスと、特定のロックの監査範囲を確認すべきですが、**CertiKのDxSale用Skynetプロジェクトページ**を介して、DxSaleのプロジェクトセキュリティと監査履歴をクロスチェックできます。

DxSaleのバージョン管理に慣れていないユーザーのために、DxSale自身のドキュメントでは新しいロッカー（例：DxLock V2流動性ロッキングドキュメント）を区別しており、特定のプロジェクトがどのツールや契約世代を使用していたかを確認するのに役立ちます。

「アトミックトランザクション」が古い想定を破る理由

DxSaleは、根本原因をBNB Chainの新しい「アトミックトランザクション」スタイルの実行と、初期v1ロッカー設計との互換性の問題に帰しました。

現代のEVMエコシステムにおいて、「アトミック」とは、複数のアクションを1つのオール・オア・ナッシングのトランザクションにバンドルすること（中間状態が決して永続しない）を指すことがよくあります。この方向性は、アカウント抽象化やバッチ処理プリミティブ（EIP-7702スタイルのメカニズムを含む）の広範な採用により、2025〜2026年に加速しました。

BNB Chainは、スマートウォレットとアカウント抽象化のアップグレードについて公に議論しています。**BNB ChainのPascalハードフォーク発表を参照してください。単一トランザクションの委任/バッチ処理の概念を普及させた基盤となる標準については、Ethereum EIPsのEIP-7702**を参照してください。

DeFiセキュリティにおける重要な教訓

レガシー契約が「長年機能していた」としても、新しいトランザクションパターンは古い脅威モデルを無効にする可能性があります。特に、契約が管理者権限、異常な所有権フロー、または呼び出しの構成方法に関する想定に依存していた場合はなおさらです。

これが、2025〜2026年のDeFiセキュリティの議論が、以下にますます焦点を当てている理由の1つです。

イミュータブル vs. アップグレード可能な契約リスク
特権ロールと所有権の境界
新しいチェーン機能と実行環境の下で契約が安全であり続けるか

流動性プロバイダーとトークンチームが今すべきこと

1）LPが使用したロッカーバージョンを確認する

古いBNB Chainプロジェクトのコミュニティメンバーである場合は、「ロックされている」ことが安全だと安易に考えないでください。チームに以下を提供するよう依頼してください。

正確なロッカー契約アドレス
ロックID / ロックページ
v1かv2以上かの確認

アドレスしかない場合は、BscScanから始め、契約の作成時期、所有者関数、および過去のトランザクションを調査してください。

2）「監査」を必要条件と捉え、十分条件とはしない

監査はリスクを軽減しますが、特にチェーンの動作が進化する場合には、リスクを排除しません。監査参照を起点とし、以下を評価してください。

特権関数はまだ存在するか？
所有権を変更できるか？
引き出しに影響を与える管理者制御のパラメータは存在するか？

3）攻撃者は忘れられた契約を標的にすると想定する

このエクスプロイトは、繰り返されるパターンを示しています。攻撃者は、監視が弱く、対応者が遅いため、休眠中の流動性とレガシー契約をしばしば狩ります。

4）移行中および緊急時のアクション中に署名キーを保護する

このようなインシデントは、しばしば「緊急移行」を引き起こしますが、これはフィッシングや悪意のある署名プロンプトの最盛期です。

OneKeyのようなハードウェアウォレットは、秘密鍵をオフラインに保ち、トランザクションのオンデバイス確認を必要とすることで役立ちます。これにより、侵害されたコンピューターやブラウザ拡張機能が有害な承認をサイレントに署名する可能性を減らします。これは脆弱なDeFi契約を修正するものではありませんが、プレッシャー下でdAppsとやり取りする際の個人の運用セキュリティを大幅に向上させます。

結論

2026年5月のインシデントは、レガシーな流動性ロッカー契約が、実行機能が急速に進化するペースの速いチェーンで、再びシステムリスクになり得ることを浮き彫りにしました。
DxSaleの声明は、問題を2021年頃のv1ロッカーに限定されたものとし、v2以降の契約は影響を受けていないと位置づけています。
ユーザーとチームにとって、実行可能な要点は、古いロックの棚卸し、契約バージョンの確認、そして2026年の現実（アトミックバッチング、委任実行、そしてより速い攻撃者のプレイブック）に合わせたセキュリティプラクティスのアップグレードです。

BNB Chainで財務を管理したり、定期的にDeFiトランザクションに署名したりしている場合は、OneKeyを、ハードウェアベースのキー分離、慎重な許可管理、そして冷静で検証可能なインシデント対応ワークフローといった、より広範なセキュリティ体制の一部として検討してください。