Bitgetのセキュリティ事故で流出した資産の一部が、Zcashの新しいシールドプール「Ironwood」に移された。 今回の焦点は、プライバシー技術そのものより、NEAR IntentsとTHORChainが不正資金への対応で異なる判断を示した点にある。 DEX・クロスチェーン利用者は、非許可型という言葉だけでなく、フロントエンド、ソルバー、ノード、流動性プールのどこに拒否・停止権限があるかを確認する必要がある。
Bitget事件で確認されていること
Decryptが2026年9月30日に報じたところでは、Bitget攻撃者は約2,700 ZECをZcashのIronwoodシールドプールへ移し始めた。記事掲載時の換算では約380万ドルに相当する。シールドプールに入る前後の取引は観測できても、プール内部では送信者、受信者、金額の対応関係が秘匿されるため、通常の公開台帳より資金経路の分析が難しくなる。
事故自体についてBitgetは、9月24日に確認したセキュリティインシデントにより、攻撃者管理アドレスへ移転された資産を約3億8,750万ドル相当と公式に更新した。対象にはETH、XRP、USDT、ZECなどが含まれる。同社は脆弱性を特定・修復し、利用者残高への影響はなく、財務上の影響はProtection Fundがカバーすると説明している。ただし、これはBitget自身の発表であり、回収額や捜査結果が確定したことを意味しない。
北朝鮮系攻撃者との関連も報じられているが、Decryptが明記する通り、政府機関による確定発表はない。オンチェーン上の資金移動、分析企業の帰属評価、刑事上の犯人認定は分けて扱うべきだ。
ZcashのIronwoodは何を秘匿するのか
ZcashのIronwoodは、NU6.3で導入された新しいシールドプールである。Zcash公式資料では、旧Orchard実装で2026年6月に公表された脆弱性への対処を背景に、7月28日にメインネット有効化が予定され、従来のzcashdは対応せず、ZebraとZalletへの移行が案内された。つまりIronwoodは単なる名称変更ではなく、ノード実装とウォレット環境を含むネットワーク更新の一部だ。
シールド取引は、BitcoinやEthereumの通常送金のように、アドレスと金額の関係を公開台帳上でそのまま追える設計ではない。入金と出金の存在は見えても、その間の対応付けが困難になる。この性質は給与、寄付、企業間決済など正当な金融プライバシーにも役立つ一方、盗難資金の追跡を難しくする用途にも悪用され得る。
重要なのは、「Zcashを使った」ことと「Zcashプロトコルが犯罪を承認した」ことを同一視しない点だ。プロトコルは取引規則を実行する。一方、取引所、ウォレット、ブリッジ、法定通貨の出入口は、それぞれ別の規制・リスク管理を持つ。Ironwoodから出た資産が中央集権型取引所へ入れば、そこで再び本人確認や資金源審査の対象になり得る。
NEAR Intentsがスワップを拒否した仕組み
Decryptによると、NEAR Intentsはリスク検知層「SHIELD」により、Bitget事件と関連付けられた5,000万ドル超のスワップ要求を拒否したと説明した。NEAR Intentsは、利用者が望む結果を提示し、複数のソルバーが履行方法を競うインテント型のクロスチェーン基盤である。基盤となるチェーンが誰でも利用できても、特定のソルバーや実行サービスが、すべての注文を無条件に引き受けるとは限らない。
この事例は「permissionless」の層を分解して考える必要性を示す。NEARプロトコルへのアクセス、NEAR Intentsの注文受付、SHIELDの判定、ソルバーの見積もり、最終チェーン上の決済は同じものではない。アプリケーション層で拒否されても、攻撃者が別のブリッジやDEXへ移る可能性は残る。実際、Decryptは攻撃者がTHORChain、Across、Chainflipなど複数の経路を試したと報じた。
利用者側にも影響がある。誤検知で注文が止まる可能性、審査中に価格が動く可能性、途中資金の返還に法的手続きが必要になる可能性を考慮しなければならない。NEAR Intentsのような経路では、最良価格だけでなく、拒否条件、返金手順、問い合わせ先を事前に確認することが実務的だ。
THORChainが個別凍結を選ばなかった理由
Bitgetは攻撃者アドレスへのサービス拒否をTHORChainに求めたが、THORChain側はネットワーク停止を個別資金の選択的凍結に使うものではないとの立場を示した。公式ドキュメントでは、THORChainの緊急停止は資金が危険にさらされる重大障害に対し、ノードオペレーターがネットワーク全体、または特定チェーンの署名処理を止める仕組みとして説明されている。判断は単一企業の管理画面ではなく、ノード投票やMimirパラメーターを通じて行われる。
これは「何も止められない」という意味ではない。公式手順には、重大な脅威の確認時に全体を一時停止し、ノードが緊急対応を協議する仕組みがある。ただし、プロトコル防衛のための全体停止と、外部事件に由来する特定アドレスだけの検閲は目的が異なる。THORChainは後者を採用しなかった。
NEAR IntentsとTHORChainの差は、善悪の単純比較ではなくアーキテクチャの差である。前者は注文受付・ソルバー経路にリスク判定を置き、後者はノード合意によるネットワーク防衛を中心に据える。利用者は「DEXだから同じ」とまとめず、どの層が判断主体なのかを見る必要がある。
DEXとブリッジに突き付けられた設計課題
Uniswapのような単一チェーン上のAMM、THORChainのようなネイティブ資産間DEX、NEAR Intentsのようなインテント型基盤では、資産移動の構造が異なる。AMMではプールのスマートコントラクト、THORChainではノードと保管庫、インテント型ではソルバーと決済経路が主な信頼境界になる。したがって、不正資金対応を一律のブラックリストで設計することは難しい。
厳格な遮断は盗難資金の換金を妨げる一方、誤検知や運営主体への権限集中を招く。遮断しない設計は中立性を保ちやすい一方、攻撃者に流動性を提供したと批判される可能性がある。さらに、攻撃直後に特定経路へ注文が集中すれば、流動性提供者は価格乖離、在庫偏り、裁定取引の遅延といった影響を受ける。
プロトコル側には、緊急停止条件の公開、制裁・盗難アドレス判定の責任主体、異議申し立て、誤検知時の返金、停止中のLP保護を明文化する課題がある。単に「分散型」「検閲耐性」と掲げるだけでは、利用者が実際の停止可能性を判断できない。
利用者と流動性提供者の確認事項
一般利用者は、クロスチェーン交換の前に、公式フロントエンドか、資金を一時保管する構造か、ソルバーが取引相手になるか、失敗時に元チェーンへ自動返金されるかを確認したい。NEAR Intents型では注文が拒否される条件、THORChain型ではチェーン停止時の出金待ちが重要になる。
流動性提供者は、手数料収入だけでなく、事件発生時にプールがどの資産を多く抱えるかを見る必要がある。不正資金が大量に交換されると、プールの在庫構成や価格が短時間で変わり、裁定が追い付くまで損失が拡大する可能性がある。Zcashのようなシールド資産を扱うサービスでは、入金前の履歴と出金後の受入先ポリシーも確認対象になる。
Bitgetは、任意の協力で資金凍結・回収につながった場合、それぞれ対象額の5％を報奨金とする制度を公式発表した。ただし、裁判所命令や法執行機関の要請による措置は対象外で、参加しても支払いが保証されるわけではない。利用者が独自に資金追跡へ参加する場合も、誤認公表や違法なアクセスを避け、公式の報告窓口を使うべきだ。
まとめ
Bitget事件後の資金移動は、Zcashのプライバシー、NEAR Intentsのアプリケーション層フィルタリング、THORChainのノード主導型ガバナンスという三つの設計思想を同時に浮かび上がらせた。Ironwoodは取引関係を秘匿するため追跡を難しくし、NEAR IntentsはSHIELDで疑わしい注文を拒否し、THORChainは個別凍結ではなくプロトコル全体の緊急防衛を優先した。
DEX利用者に必要なのは、抽象的な「分散型」というラベルではなく、注文を拒否できる主体、停止条件、返金経路、LPへの影響を具体的に把握することだ。事件の犯人帰属や回収状況は今後変わり得るため、Bitget、Zcash、NEAR、THORChainの公式更新とオンチェーン情報を継続して照合したい。
