The Iron Fish team traced abnormal wIRON issuance to a flaw in its own blockchain. The published fix targets new chains; plans to preserve existing balances or reimburse users have not been announced.
The team behind privacy blockchain Iron Fish said in its October 31 announcement that it was ending all remaining support for the network. It made the decision after finding a flaw that let an attacker spend the same value repeatedly and create unbacked value. It also said it had published a fix and detailed technical report before closing and archiving its code repository.
The investigation began with abnormal wIRON issuance on Base and activity involving the ChainPort bridge. Iron Fish says it traced the problem to its own blockchain while reviewing logs with ChainPort. According to the announcement, an attacker repeatedly exploited the flaw, consolidated the resulting notes and exited through ChainPort. No flaw in ChainPort’s own code was reported.
In its October 28 warning, the team said full one-to-one backing of wIRON on Base could not be assured and urged users to avoid buying it or using the bridge. It has not disclosed how many tokens were created, the final financial loss, the number of affected users or a reimbursement schedule. Withdrawing support also does not, by itself, establish that all independent miners and nodes have stopped.
The team’s post below announces both the investigation’s findings and its decision to withdraw the remaining support.
Iron Fish’s announcement about the flaw and network support
The post loads from X when you open it.
How the same value could be spent again
In their technical report, the developers trace the flaw to how payment records are stored in a Merkle tree. A record called a note represents value that can be spent. When a transaction consumes that note, the network checks a unique spending marker called a nullifier to prevent the same value being used again.
The old design filled a missing right-hand branch by copying the left-hand branch. Under some conditions, a note could be presented as occupying a different position while still producing the same root hash. Because the nullifier depends on position, it would change. An attacker could therefore present the same value with another spending marker, escaping checks that reject markers already used.
The attacker must know the note’s contents and have authority to spend it. An attacker could reuse a note with a value greater than zero that they controlled; the flaw did not give them authority to spend somebody else’s private notes. If value was actually deposited at two separate positions, matching note commitments are not inherently invalid. The flaw arises when the network accepts a copied position that was never separately funded.
The privacy proof keeps the note’s position hidden. Although the network checked the public tree size and historical root, the old circuit did not compare the private position with that size. A zero-knowledge proof could consequently be valid under the flawed rules. The developers do not claim that the mathematics of the proof system was broken.
The team traced the branch-copying behavior to a prototype change dated February 18, 2019. The old change alone does not explain every step by which the flaw reached the live network. The team says the relevant code path was within the scope of both external and internal audits, but the flaw was missed.
The patch does not migrate the existing chain
The fix fills missing branches with designated empty values at each level instead of copying their neighbors. Developers also changed the code that calculates roots and the paths used to prove that a note exists, including historical roots. They added checks for tree truncation, invalid sizes and conflicts between simultaneous cache operations.
| Component | Reported status |
|---|---|
| Spending circuit and Groth16 parameters | Unchanged; the transaction serialization format is also preserved. |
| Existing mainnet and testnet | Incompatible with the new roots; no migration is provided. |
| New chain | Participants must agree on a new genesis block and network parameters. |
| Previously inflated balances | The patch alone does not identify or reverse them. |
Developers say the fix was tested locally on October 28. Their tests generated two valid proofs spending the same value with different nullifiers under the old rules. The new consensus rules, which govern transaction acceptance, reject the old roots but accept a proof path built under the new rules. Developers reported passing tests, but did not report a completed independent cryptographic review.
The migration problem is that the new roots differ from the old ones from the chain’s first block. Operators cannot simply switch software at an arbitrary block height and continue the existing history. The code targets a new chain and provides no activation height, dual-root arrangement or plan to migrate old balances. Developers wishing to preserve an existing chain would have to design separate consensus rules and submit them to security review.
Developers regenerated the genesis block for their development network, retaining the 42 million IRON allocation, recipients and transaction memos. That development-network work does not restore mainnet users’ balances. Because note positions remain private, investigators cannot identify every abusive transaction or the total amount simply from valid historical proofs and distinct public nullifiers. Past transactions need a separate investigation.
Maintenance began in April
In her April 20, 2026 statement, founder Elena Nadolinski said the foundation had moved the project into maintenance after its development company was acquired by Coinbase. Unable to sustain the pace of active development, it had stopped future grants and would not renew existing ones. The foundation said it would keep operating bootstrap nodes, the block explorer and its website.
Nadolinski wrote in April that this infrastructure was not essential to the network’s operation and that community miners and nodes could keep it running. The latest decision withdraws support that had previously been retained. The team has not announced a separate shutdown time for each service or an independent community continuation plan.
The team also expressed concern about software that cannot be upgraded quickly and about AI making vulnerability discovery easier. It argued that safety restrictions on leading US models, compared with open models stripped of those restrictions, were creating a disadvantage for defenders. That is the team’s assessment; it supplied no evidence that AI was used in the Iron Fish attack.
