Harmony Plans to Roll Back 141,628 Blocks After a Forged Mint
Harmony intends to roll its blockchain back to a state recorded on 11 August 2026, discarding 141,628 consecutive blocks, after an attacker exploited a flaw in the network's cross-shard accounting to create ONE tokens backed by nothing. The defect sat in receipt verification between shards, the separate parallel chains Harmony splits its network across. A valid receipt could be processed more than once, so tokens were credited on one shard without being debited anywhere. The restart point is block 92,730,035 on shard 0 and block 94,978,279 on shard 1, a state timestamped 23:25:37 UTC on 11 August. As of 19 August, no finalised validator vote and no execution date had been published, and the amount forged is still reported several different ways.
The tally moved as the investigation ran
The first accounts, on 12 August, put the mint at roughly 4 billion ONE, equal to about 26% of a supply then reported at 15 billion. Later analysis raised it by three orders of magnitude. Harmony's own reconstruction, as relayed by crypto.news and news.bitcoin.com, describes a single wallet attempting 534 transfers of 5 billion ONE each inside 106 seconds, of which 477 succeeded, moving 2.385 trillion ONE. The Block puts the total at 3.01 trillion across six transactions into four attacker-controlled wallets. The figures do not reconcile, and the outlets carrying them have not reconciled them. We could not establish which total stands. What every account shares is that the early 4 billion print was superseded, not corrected downward. ONE was reported down about 37% in the first days and down 41.7% over seven days by 17 August, quoted at $0.0007175.
Why a rollback and not a burn
Harmony says it studied the alternatives and rejected each. Burning the forged tokens fails once they are dispersed, because the supply is no longer sitting in identifiable wallets. Blacklisting address clusters punishes whoever received a token last, not whoever created it. Selective transaction replay and a token migration were also weighed. "Of the options we studied, one fixed rollback window is the fairest and most secure," the team said. Dispersal is the reason: forged ONE reached standalone wallets, exchange accounts, decentralized-exchange routers and pools, liquidity-provider positions, bridge contracts, wrapped ONE, staking wallets and high-volume service wallets, and Harmony says more than 99.9% of those flows have been traced with help from an outside security firm. Tracing is not recovery. That gap is what a rollback is meant to close.
What the rollback destroys
Reversing to 11 August erases eight days of settled activity along with the forged mint. Inside those 141,628 blocks sit 109,126 ordinary transactions and 315 staking transactions, all of which cease to have happened. Most of that volume was machine-generated: 104,545 transactions, or 95.80% of the ordinary total, came from automated activity, including 75,430 completed swaps and 11,804 failed bot attempts. That composition is the argument for going through with it. It is also the reason the remaining share matters: those users did nothing wrong and have no say in the vote. Shard 1 is being reverted as a precaution even though the mint did not occur there.
A vote with no date
Containment came first. An emergency release, mainnet v2026.1.1, shipped on 12 August and was adopted by more than half of validators within hours; the cross-chain bridge was suspended and exchanges were asked to freeze linked addresses. None of that reverses the mint. The rollback still needs validators to run it, and the network has not said when. Two questions sit underneath: whether every exchange and bridge that credited forged ONE has been reached before the chain state changes beneath them, and what the receipt-verification fix looks like in the code, since a flaw that let one message be counted twice is the same class of defect that has cost bridge operators their funds this year. Unauthorized issuance itself is not new either: a stolen owner key produced the same effect in July. But that was a key management failure, and this one is in consensus.
Read also: XRPL Publishes xrpld 3.3.0 and Restores Two Pulled Amendments