結論からいうと、Pirate Chainでは2026年10月14日、取引検証の二つの不備を組み合わせて約3,980万ARRRが無許可で作られました。公式説明では従来供給の約20%に相当し、不正発行分はSapling shielded poolへ移されています。当初示されたロールバック案は約14時間後に撤回されました。
今回確認されているのは、coin importに対応するburnの確認不足と、偽のCLTV風スクリプトを許可された出力と見誤る分類不備です。Ironwoodのshielded暗号そのものや利用者の秘密鍵が破られたと確認された事故ではありません。ただし、基礎暗号が破られていないことと、供給や運用上の問題が解決したことは別です。
この記事では、初報と後続情報を分けながら、何が起きたのか、なぜ不正発行が成立したのか、再開前に何を確認すべきかを初心者向けに整理します。ARRRの売買や価格を予測・推奨する内容ではありません。
まず確認したい3点
- 確認済み：約3,980万ARRRの無許可発行、Sapling shielded poolへの移転、当初のロールバック案の撤回です。既存残高の一斉流出やIronwoodの基礎暗号の破綻が確認された事故ではありません。
- 未確定：不正発行分を最終的にどう扱うか、対策済み安定版の確定番号、各サービスの全面再開条件、最終post-mortemは調査基準日の2026年10月18日時点で確定していません。
- 今すべきこと：送金を急がず、利用先がARRRの入金と出金を再開したかを別々に確認してください。公式を装う救済サイトやサポートにも、シードフレーズや秘密鍵は絶対に渡さないでください。
Pirate Chainで約3,980万ARRRが不正発行された
既存資金の直接流出ではなく新規発行だった
一般的な取引所ハッキングでは管理鍵を奪われて保管資産が外へ送られる場合があります。今回はそれとは異なり、コンセンサス検証をすり抜けた取引による無許可の新規発行です。「全利用者の残高が盗まれた」と表現するのは正確ではありません。一方、新規発行なら無害という意味でもありません。総供給が増えれば、一単位が供給全体に占める割合は小さくなり、既存保有者にも希薄化の影響が及び得ます。直接盗難と供給増は別々のリスクとして評価します。
不正発行分はSapling shielded poolへ移された
公式説明によれば、不正発行分は直ちにSapling shielded poolへ移されました。shielded poolでは送金経路や保有関係が公開台帳からそのまま読めないため、その後の全移動を追跡することは困難です。ただし、見えにくいこと自体が今回の発行原因ではありません。問題はpoolへ入る前段階で不正な値を受理した実装側の検証です。プライバシー機能と発行不備を混同せず、入口の検証とpool内部の処理を分けて考えます。
発見からロールバック撤回までの時系列
初動では10月14日20:00 UTCへの巻き戻しを告知
初動では10月14日20:00 UTCを基準にチェーンを戻す案が告知されました。同時に取引所、マイニングプール、利用者へ送受信や関連処理を止めるよう求める動きがありました。ロールバックは不正取引を履歴から外せる可能性がある一方、基準時点より後の正規取引も消し、取引相手や取引所の帳簿との不整合を生む重大な措置です。速報時点の案を実施済みの事実として扱ってはいけません。
約14時間後に一方的な凍結・巻き戻しを撤回
公式更新では当初案から約14時間後、一方的な凍結や巻き戻しは行わない方針へ変わりました。分散型ネットワークでは開発者が告知しただけで全参加者の台帳を同時に書き換えられるわけではありません。巻き戻しには参加者の広い協調が必要で、正当な取引を巻き込む影響もあります。撤回は事故がなかったことを意味せず、既存履歴を維持したまま別の復旧策を検討する判断です。
ネットワーク停止ではなく自主停止が要請された
報道ではネットワーク自体は停止していない一方、dPoW notarizationが止められ、関係者へ自主的な取引停止が要請されたとされています。チェーンがブロックを作り続けることと、取引所が安全に入出金を再開できることは同じではありません。承認数、再同期、修正版ノードへの移行、内部残高との照合が終わるまで、価格画面やブロック生成だけで通常運転と判断しないことが重要です。
不正発行を許した二つの検証不備
- 裏付けのないimportを受理：本来対応すべきburn（価値を消した証明）の照合が強制されない経路を通します。
- 偽CLTV風出力を誤認：実際には標準形でないスクリプトを、許可された出力のように見せます。
- shielded poolへ移動：二つの検証をすり抜けて作られたARRRをSaplingへ移し、公開情報だけでは以後の経路を完全に追えない状態にします。
まなぶ「coin importとburnって、普通の送金とは違うんですか？」
クリプ「別の場所で消した価値をこちらへ移す仕組みだよ。入れる量と消した量が対応するか厳密に確かめる必要があるんだ。」
coin importに対応するproof of burnが強制されなかった
coin importは別の領域で価値を消したことを根拠に、対応する価値を取り込む処理です。proof of burnはその「実際に消した」という証明です。修正ではConnectBlockに、各coin importへ対応するburn出力を要求する確認が追加されました。裏返せば修正前には、ブロック接続時にimport値とburn値の対応を強制できない経路が存在しました。帳簿に入金を記録するのに元帳側の出金を十分照合していなかった状態に近いと考えると理解しやすいでしょう。
偽CLTVスクリプトが許可アドレスへの出力と誤分類された
CLTVは一定の時点やブロック高まで支出できない条件を表すために使われます。別の修正は、見た目がCLTV形式に似ていても標準形ではないスクリプトを拒否します。修正説明では、実際には要求された条件を持たない出力が許可アドレス向けと誤分類され、ac_privateのtransparent-output制限を回避できたことが示されています。見た目ではなく実行される条件を標準形として厳密に検証する必要がありました。
二つの不備が発行量チェックと出力制限をすり抜けた
burnの対応確認が足りないだけなら別の出力制限が止めた可能性があり、出力分類だけの問題なら値の保存確認が止めた可能性があります。しかし今回は、裏付けのないimportを通す経路と許可された出力に見せる経路が同時に使われました。発行量チェックとtransparent-output制限の双方をすり抜けた構造です。防御を一段だけで考えず、値の生成、スクリプト分類、poolへの流入という境界ごとに不変条件を確認すべき事例です。
Ironwoodの暗号方式が破られた事故ではない
まなぶ「Ironwoodが形式検証済みなら、どうして不正発行が起きたんですか？」
クリプ「検証された範囲が違うからだよ。shielded回路を確かめても、チェーン固有のimport処理まで自動的に正しくはならないんだ。」
形式検証の対象はshielded回路である
形式検証は定義したモデルと仮定のもとで特定の性質を数学的に確かめる方法です。前提となる仕組みはゼロ知識証明の基礎も参照してください。Ironwood Bookはbinding signatureや値保存など、shielded回路に関する性質を定義しています。これは重要な保証ですが、ノード実装の全行、外部システムとの接続、チェーン固有のimport処理まで無欠陥だという万能保証ではありません。「形式検証済み」という言葉を見るときは、何を、どの仮定で、どこまで検証したのかを確認します。
pool内部の残高整合と外部入力の検証は別問題
shielded pool内部ではvalue commitmentなどを使い、秘密を公開せずに入出力の均衡を確認します。しかし外部からpoolへ入る値が正当かどうかは入口側の検証にも依存します。倉庫内の在庫移動が厳密でも、搬入口で架空の納品票を受理すれば総在庫が増える、という関係です。pool内部の残高整合と、coin importで持ち込まれる価値の裏付けは、連携しながらも別の検証境界です。
鍵やshielded暗号の侵害を示す証拠は確認されていない
公式はnotary鍵やshielded取引の基礎暗号が侵害された証拠はないとしています。これは利用者の秘密鍵が一斉に漏れたという説明を支持しない材料です。ただし「証拠がない」は最終調査の完了宣言ではありません。鍵侵害がなくても、不正発行、供給希薄化、入出金停止、取引の長期未反映といった影響は残ります。安心材料と未解決事項を別々に評価してください。
Ironwood有効化11日後に発覚、因果関係は未確定
Ironwoodは協調hardforkとして導入された
Ironwoodは任意でオンにする小機能ではなく、ノード互換性を分ける協調hardforkとして導入されました。事前案内ではfull-node walletを6.0.0へ更新する期限が示され、Orchardを飛ばしてIronwoodへ直接移行する方針が説明されています。hardforkではノード、ウォレット、取引所、マイニングプールが同じルールを理解する必要があり、移行部やpool間連携は重要な確認点になります。
本番有効化日は2026年10月3日
月次更新とexplorerの情報では、Ironwoodは2026年10月3日、block 4,161,185で有効化されました。事故発見は11日後です。この順序は確認できますが、「有効化したから必ずこの不具合が生まれた」という因果関係までは示しません。導入時期、影響を受けたコード、攻撃経路を分け、最終post-mortemで両者の関係がどう説明されるかを待つ必要があります。
explorerの統計値は更新状態も確認する
explorerは供給、pool残高、notarized height、稼働高を確認する有用な入口です。ただし事故対応中はインデックス更新が止まったり遅れたりし、pool分類や集計方法によって表示が異なる可能性があります。一つの数字だけを最終確定供給とせず、取得時刻、最新ブロック高、notarizationの状態、公式更新との一致を確認してください。
修正コードと正式な安全確認は分けて考える
burn照合と非標準CLTV拒否が追加された
対策コードはConnectBlockでcoin importとburn出力の対応を要求し、非標準のCLTV風スクリプトを拒否します。これは今回確認された二つの入口に対応します。ただし特定コミットで既知の経路を閉じたことと、類似経路を含む包括的な監査が完了したことは同義ではありません。回帰テスト、異常系テスト、複数の運用環境での確認がどこまで行われたかも重要です。
同時期にnoteロックとspend記録も強化された
同時期の別コミットでは、非同期取引builderでnoteをロックし、commit時にspendを記録する範囲が広げられました。これはウォレット側で同じnoteが競合して選ばれる問題を防ぐ強化です。事故対応と近い時期の変更ですが、約3,980万ARRRの不正発行を成立させた二つのコンセンサス不備と同一原因として混ぜないようにします。修正一覧は目的別に読みます。
6.0.9は不正発行対策済みの公開版ではない
署名済みの6.0.9リリースは2026年10月13日で、不正発行対策コミットより前です。そのため、番号が新しいという理由だけで6.0.9を今回の対策済み版として扱えません。バージョン確認では、公開日、問題の修正コミットを含むか、公式が事故対応版として指定しているかをセットで確認します。
6.0.10 beta系列と正式リリースを混同しない
10月15日時点では修正が6.0.10-beta3を含む開発系列で進められていました。betaは検証中の版であり、全利用者向けの安定版確定や取引所の再開を自動的に意味しません。正式なタグ、署名、ハッシュ、リリースノートを確認し、取引所やウォレット提供者が指定する版との一致を確かめるのが安全です。
追跡不能性と供給希薄化が残す影響
まなぶ「残高が盗まれていなくても、供給が増えた影響はあるんですか？」
クリプ「あり得るよ。直接盗難と、全体の中で持分が薄まる希薄化は別の影響なんだ。」
shielded pool移転後の経路は完全追跡できない
Sapling shielded poolへ移った後は、公開情報だけで不正発行分の全経路や現在の保有主体を完全に追跡できません。これは一枚ずつ目印を付けて凍結する対応を難しくします。NonKYCが疑わしい入金を検知して口座を制限したとの公式説明はありますが、一つの事業者での検知が全量の捕捉を意味するわけではありません。追跡できた範囲と推定を区別します。
約20%の供給増は既存保有者にも影響し得る
既存残高が帳簿上そのままでも、供給が約20%増えれば、各保有分が総供給に占める比率は下がります。これが希薄化です。市場価格への影響は流動性、取引停止、参加者の判断など複数要因に左右され、資料だけから具体的な値動きや回復時期は予測できません。「盗難ではないから影響ゼロ」「供給増だから必ず特定幅だけ下落する」という両方の断定を避けます。
explorer単独で供給の確定値を判断しない
供給の把握では、通常の採掘発行、不正発行、poolごとの残高、インデックスの更新状況を分けます。white paperが示す本来の発行設計と事故後の公式集計を照合し、最終post-mortemで計算方法が説明されるかを確認します。explorerの数字が別画面と合わない場合は、都合のよい方を選ばず、取得時点と集計範囲の差を疑ってください。
利用者・取引所が再開前に確認すべき条件
一般利用者が確認すること
公式リポジトリの正式リリースで、事故対策を含むバージョン番号、署名、配布物のハッシュ、リリースノートを確認します。SNS上の直接リンクや第三者が再配布した実行ファイルだけを頼らないでください。ノード運用者はバックアップ、停止手順、設定互換性を確認します。類似不具合を見つけた場合は、悪用手順を公開する前に公式security policyの窓口を使います。
取引所・ノード運用者が確認すること
Pirate Chainには複数のshielded poolがあり、設定資料にはSaplingとIronwoodのpool別consolidationやsweepが説明されています。取引所やウォレット運用者は、チェーン高だけでなく各poolのnote、未使用出力、スキャン範囲、再同期後の残高が一致するかを確認します。一部画面が最新でも、別poolのスキャンが遅れていれば入金を安全に反映できない場合があります。
取引所の入出金とnotarizationの再開条件を確認する
売買画面が動いていても、オンチェーン入出金が再開しているとは限りません。利用する取引所がARRRの入金と出金をそれぞれ受け付けるか、必要承認数を変更したか、保留中取引をどう処理するかを確認します。同時にdPoW notarizationの再開条件、最新notarized height、ノード版の要件も見ます。宛先側が停止中なら送信側で成功表示になっても長時間反映されない可能性があります。再開後に送る場合も、アドレス照合や少額テストを含む安全な送金手順を省かないでください。
情報発信者が確認すること
調査時点では、最終post-mortem、安定版の確定番号、全サービスの再開条件、供給をどう扱うかは未確定です。ロールバック撤回後に発行済み分をどう会計し、将来の発行や利用環境をどう整えるかは公式説明を待つ必要があります。更新を読む際は公開日時、公式性、古い方針の訂正有無を確認し、初報を現状として再拡散しないでください。
利用者別チェックリスト
まず「確定した事実」「公式の暫定説明」「第三者の推測」を分けます。確定した事実として扱えるのは、日付、不正発行量の公式説明、修正差分に現れた検証追加、ロールバック撤回などです。これに対して、攻撃者の全行動、現在の全保有先、最終的な供給処理、価格への影響は同じ確度では語れません。記事や投稿を読むときは、主語が公式チーム、コード差分、報道、匿名投稿のどれかを見て、更新日時も確認します。見出しが現在形でも本文が撤回前の情報だけなら、現状確認には使えません。
ウォレット利用者は、残高表示と送金可能性を分けて確認します。残高が見えていても、ノードが古い、poolのスキャンが終わっていない、送付先の取引所が入金を停止している、といった状態はあり得ます。公式ウォレットの対象バージョン、同期高、SaplingとIronwoodの処理状況、送付先の入金告知を順番に見ます。シードフレーズや秘密鍵を入力させる非公式な救済サイトは使わず、サポートを名乗る相手にも共有しません。急いで復旧を試すことが、別の盗難リスクを増やす場合があります。
取引所利用者は、現物の売買可否とオンチェーンの入出金可否を分けます。取引所内の注文が通っても、外部ウォレットからの入金や外部への出金が停止していることがあります。入金アドレスが表示されるだけで受付中とは限りません。公式のステータスページや告知で、ARRRの入金、出金、保留取引、必要承認数を個別に確認します。再開直後は処理が集中する可能性もあるため、期限のある支払いに使う場合は相手側の受付状態まで確かめる必要があります。
ノード運用者は、コミットの存在をそのまま本番導入の指示と読み替えません。自分の運用が追うブランチ、配布物の署名とハッシュ、設定ファイルの互換性、データディレクトリのバックアップ、再同期の要否を確認します。取引所やプールでは、変更前後の残高照合、未処理入出金、pool別note、監視対象のblock heightを記録し、再開条件を文書化します。単にプロセスが起動したことではなく、不正なimportを拒否する版で合意状態を追えていることが確認点です。
notarizationについては「停止した」という情報と「チェーン自体は動いている」という情報が同時に成立します。dPoWによる確定性の補助が止まっている間もブロック生成が続く可能性があるため、稼働中という一語だけでは安全性を判断できません。最新のnotarized heightが更新されているか、運営側がどの条件で再開を宣言したか、利用先がその状態をどう扱うかを確認します。ブロック数だけを数えて通常時と同じ承認判断をしないことが大切です。
供給については、約3,980万ARRRと約20%という公式説明を基準にしつつ、explorerの表示を単独の確定値にしません。事故前後で取得した時刻、集計対象のpool、インデックスの最終更新高が違えば、数字は一致しない場合があります。不正発行分を技術的または会計上どう扱うかが決まるまでは、「すでに全量が無効化された」「完全に回収された」といった表現を避けます。ロールバック撤回後の回復策は、実装方法と合意方法の両方が示されて初めて評価できます。
セキュリティ上の説明では、基礎暗号、コンセンサス検証、ウォレット処理、サービス運用の四層を分けます。今回、公式が基礎暗号やnotary鍵の侵害を示す証拠はないと述べても、コンセンサス検証の不備は確認されています。また、その不備が修正されても、各サービスが新しい版へ移行し、残高照合を終えなければ運用は復旧しません。一つの層の安全確認を全体の安全宣言へ広げないことが、誤解を避ける基本です。
今後の最終post-mortemでは、根本原因、影響した期間と取引、検知方法、二つの不備がテストを通過した理由、修正と回帰テスト、供給の扱い、再開基準が説明されるかに注目します。説明が更新された場合は、この記事の数字や未確定事項も再検証が必要です。現時点の情報は2026年10月18日の調査JSONに基づくスナップショットであり、将来の正式版番号や復旧方針を先回りして断定するものではありません。
情報源の優先順位も決めておくと混乱を減らせます。原因と修正内容は公式リポジトリのコード差分、版の状態は署名済みリリース、事故対応方針は日時が新しい公式更新、個別サービスの利用可否はそのサービス自身の告知を優先します。報道記事は時系列を把握する助けになりますが、初報の「ロールバック予定」が後から撤回されたように、公開時点以後の変更を含まないことがあります。複数の記事が同じ数字を書いていても、元が一つの公式発表なら独立した確認が複数あるとは限りません。出典が何を直接確認し、何を別資料から引用したかまで見ることが重要です。
利用者が記録しておくとよい項目は、使用中のウォレット名とバージョン、最終同期高、送金した場合のtransaction ID、送付時刻、宛先サービスの告知、問い合わせ番号です。シードや秘密鍵そのものは記録共有の対象にしません。未反映が起きたときも、同じ送金を慌てて繰り返す前に、取引がネットワークへ送信済みか、宛先が受付を停止しているかを確認します。サポートへ伝える情報と、絶対に渡してはいけない認証情報を分けておけば、事故に便乗した詐欺にも備えやすくなります。
取引所やプールの運用判断では、再開を一つのスイッチとして扱わず、観測、入金検知、必要承認、内部反映、出金作成、ブロードキャストを段階ごとに試験します。SaplingとIronwoodの双方を扱う場合は、poolごとの残高とnote管理を照合し、修正版ノードが拒否すべき取引を拒否することも検証対象です。障害前の手順をそのまま戻すのではなく、どの条件を満たせば次の段階へ進むか、異常時にどこで停止するかを決めます。これは利益を得るための助言ではなく、台帳と顧客残高の不整合を避けるための運用上の確認です。
判断を急がないことも対策の一部です。未確定の版や再開時刻を推測で補わず、公式発表に変更があれば古いメモにも訂正を残します。情報を共有するときも確認日時と出典を添えれば、撤回前の案が独り歩きするのを防げます。
まとめると、今回の核心はIronwoodの暗号破りではなく、coin importのburn確認とCLTV出力分類という二つの実装上の検証不備です。約3,980万ARRRの不正発行、約20%の供給増、Saplingへの移転、ロールバック撤回は確認できます。一方、最終的な供給処理や安定版、全面再開は未確定です。公式の署名済みリリース、取引所の入出金、notarization、post-mortemを別々に確認してください。
現時点の最小行動は三つです。公式の対策済み安定版と利用先の入出金再開が確認できるまで送金を急がないこと、秘密鍵やシードフレーズを誰にも共有しないこと、約3,980万ARRRの最終的な供給処理は未確定だと理解しておくことです。
