Worked example · 2026-10

Pirate Chain — two validation failures let a transaction create ~39.8M ARRR, ~20% of supply, eleven days after the Ironwood upgrade — Pirate Chain (ARRR) / Pirate Chain L1 — 2026-10-14

Loss

~39.8M ARRR minted without authorisation (~20% of supply). SlowMist's tracker values it at ~$10.7M; the amount actually realised is unknown, because the coins went straight into the Sapling shielded pool. NonKYC restricted an account that received related deposits. Pirate Chain has not reported loss of existing user balances beyond the dilution.

OAK Techniques observed

OAK-T9.014 (Protocol-Client Consensus Bug — primary, per the project. Pirate Chain: "a transaction validation vulnerability in Pirate Chain source code … allowed the unauthorized creation of approximately 39.8 million ARRR", combining "two validation failures bypassing the issuance check and incorrect interpretation of the output scripts." The flaw sat in the new transparent supply-accounting layer around Ironwood's turnstile, activated 2026-10-03. The project says notary keys and the shielded-pool cryptography are not compromised. See techniques/T9.014-protocol-client-consensus-bug.md).

Attribution

pseudonymous.

Key teaching point

A turnstile only protects supply if every path into the pool goes through it. The upgrade added accounting meant to stop a shielded pool paying out more than entered it; a transaction that both skipped the issuance check and was mis-parsed at its outputs created coins the turnstile never saw, and moved them where nobody can follow. New consensus code next to a shielded pool deserves the same scrutiny as the cryptography, because the shielding hides the evidence afterwards.