Pirate Chain says an attacker minted about 39.8 million unbacked ARRR after its Ironwood upgrade. Here is what is confirmed, what is disputed, and what holders and exchanges are being told to do.
Pirate Chain says an attacker minted about 39.8 million unbacked ARRR after its Ironwood upgrade. Here is what is confirmed, what is disputed, and what holders and exchanges are being told to do.
Quick answer: Pirate Chain (ARRR) says an attacker used two validation flaws to mint about 39.8 million unbacked ARRR on October 14, 2026, roughly eleven days after the network’s Ironwood upgrade activated on October 3. The team says both flaws are patched, the chain was rolled back to a block just before the exploit, and supply is again capped at 200 million. On October 22 it told users, miners, pools and exchanges to update to version 6.0.14 or later. That is the project’s account. A full technical post-mortem hasn’t been published, the official release notes read differently from the announcement, and no independent audit of the rollback has surfaced in the sources we checked. Treat the details below as single-sourced where we say so.
Pirate Chain is a privacy coin that grew out of the Komodo ecosystem and uses Zcash-style shielded transactions. On October 3, 2026, it began its Ironwood hard fork. According to an exchange-side summary of the announcement, Ironwood skipped Zcash’s Orchard pool, moved from the Sapling pool to a new design built on the Halo 2 proving system (which needs no trusted setup), and updated the Delayed Proof of Work (dPoW) layer inherited from Komodo.
Eleven days later, on October 14, a vulnerability surfaced. Pirate Chain’s own post on X says an attacker combined two validation flaws to create about 39.82 million counterfeit ARRR. Against a 200 million maximum, that’s close to 20% of the cap, and roughly 20% on top of the circulating supply of about 196 million shown on CoinGecko.
The project announced the problem on October 15. It asked users not to send, receive or use their wallets until further notice, and asked exchanges and mining pools to pause voluntarily. The network itself kept running. dPoW notary operators agreed to suspend notarizations temporarily.
Here the reporting gets thin, and honestly a bit inconsistent.
One write-up of the incident, citing project material, describes the flaws like this: coin-import verification didn’t properly require proof of an equivalent burn, so unbacked coins could be created, and non-canonical CheckLockTimeVerify (CLTV) scripts could cause output addresses to be misclassified. Another summary says the problem sits in the new supply-accounting layer, a “turnstile” meant to track value moving in and out of the shielded pool, and states that the exact technical failure hadn’t been disclosed.
The Crypto Times account says the counterfeit coins were minted in the transparent “Coinbase” pool. Crypto Briefing, by contrast, says the new tokens were moved quickly into the Sapling shielded pool, which would make them much harder to trace. Those descriptions don’t have to be mutually exclusive, since coins can be created in one place and moved to another, but none of the articles we read lays out the full path. Until the team publishes a proper post-mortem, the mechanism is a work in progress.
What the project does say, repeatedly, is that it has no indication its notary keys or its zk-SNARK cryptography were compromised. It also hasn’t confirmed any theft of ordinary user funds. Think of it as an inflation bug, not a wallet-draining bug. Everyone holding ARRR was diluted while the extra coins existed, but nobody’s keys were reported stolen.
The first announcement proposed reverting the chain to its state at 20:00 UTC on October 14. A few days later, the KuCoin blog summary reported that developers said a unilateral rollback isn’t possible on a decentralized network and described a coordinated hard fork instead, starting from the block before the unauthorized minting.
That distinction matters. On a chain with independent miners and node operators, nobody can simply declare history changed. A rollback only works if enough of the network runs the new software and builds on the earlier block. Pirate Chain’s October 22 post says that has now happened: the chain was rolled back to block 4,176,944 (October 14, 19:55:14 UTC), nodes running 6.0.14 or later reject the exploit block, dPoW notarizations resume, and supply is restored and capped at 200 million ARRR.
All of that comes from the project’s own post. We couldn’t find an independent confirmation of the block height, the share of hash power on the new chain, or whether any competing chain with the counterfeit coins still exists. If you hold ARRR on an exchange, the exchange’s own notice is the one that matters.
This is the part that should make a careful reader slow down. The Crypto Times piece compared the X announcement with the GitHub release notes for v6.0.14 and found they don’t line up.
The article speculates the exploit fix may have shipped in 6.0.10, but notes neither document says so. Pirate Chain hasn’t reconciled the two descriptions in anything we found. One earlier report, dated October 19, said the latest signed release it could find was 6.0.9, which predates the disclosure. Put together, the version history is confusing, and a confusing patch trail is exactly where operators make mistakes.
If you run a node, don’t guess. Read the official release page, verify the signature or checksum before installing, and confirm in the project’s official channels which version you need and whether a re-index applies to your starting version.
Exchange handling has been patchy in the reports. Crypto Briefing says NonKYC flagged deposits linked to the exploit, restricted the associated account and blocked withdrawals. An edgeX news summary says MEXC suspended ARRR deposits and withdrawals at the project’s request. We found no reporting on what other venues did, and the October 22 Crypto Times article reports no specific exchange response beyond the project telling exchanges to update.
The price barely reacted. Per CoinGecko snapshots cited in those articles, ARRR traded at about $0.27 to $0.28 on October 15, around $0.249 on October 19 and about $0.241 on October 22, with a market cap near $48 million and daily volume under half a million dollars. Those are thin numbers. In a market this shallow, a quiet price tells you little. It may mean holders trust the fix, or simply that few people are trading while deposits and withdrawals are paused.
If you’ve followed our look at market cap versus fully diluted valuation, this is a live example of why supply figures deserve scrutiny. A displayed market cap is only as good as the supply number behind it, and here the “real” supply was in question for over a week.
Inflation bugs are the nightmare scenario for privacy coins. On a transparent chain, anyone can audit total supply. In a shielded pool, the whole point is that individual balances and flows are hidden, so the network relies on cryptographic proofs and accounting rules to guarantee nobody mints value out of thin air. When that accounting fails, outsiders may not see it happening. This is a recurring risk class for shielded designs. Reporting on the Ironwood story notes that a soundness flaw was found in Zcash’s Orchard pool in May 2026 and that Pirate Chain said it was unaffected because it hadn’t deployed Orchard. Different code, different bug, same category of risk.
It also shows how a young upgrade behaves. Ironwood was live for eleven days before the problem surfaced. New cryptographic systems get audited and formally checked, and still ship with bugs. That’s not a knock on one team. It’s a reason to treat the first weeks after any consensus upgrade as the riskiest window. We saw a different flavour of the same lesson in the Balancer V1 exploit, where old code that couldn’t be patched became the target.
None of this is advice, but here’s what the sources say to do, and what common sense adds.
The project says it has not confirmed any loss of user funds and sees no sign that its shielded cryptography or notary keys were compromised. The issue it describes is unauthorized minting, which dilutes supply, rather than theft from wallets.
About 39.8 million, according to Pirate Chain’s post, which several outlets repeated. That’s roughly 20% of the 200 million maximum supply. It is a project figure, not independently verified.
Pirate Chain says yes, to block 4,176,944 at 19:55:14 UTC on October 14, and that updated nodes reject the exploit block. Independent confirmation was not available when we checked.
The project’s X post says yes, to 6.0.14 or later. The GitHub notes describe 6.0.14 as recommended and call 6.0.10 the mandatory security release. Check the official release page and channels before acting.
That’s your call, and nothing here is a recommendation. Note that liquidity is thin and some deposits and withdrawals have been paused, which makes prices a weak signal.
Disclaimer: This article is for information and education only and is not financial advice. Crypto assets are volatile and small-cap coins carry extra risk. Do your own research before making any decision.
Want more on how protocol failures play out? Read our breakdown of the Balancer V1 exploit and our guide to market cap versus fully diluted valuation, and subscribe to catch the next security write-up.