Harmony Exploit Reveals Cross-Shard Verification Vulnerability and Massive Unauthorized ONE Mint
Harmony’s internal supply tracker failed to register the incident.
On August 12, an attacker took advantage of weaknesses in Harmony’s outdated cross-shard verification mechanism, resulting in the protocol issuing billions of ONE tokens without a legitimate transfer behind them. Juiceberg, an independent analyst, had publicly highlighted this unusual minting before Harmony made any official statement.
Within an hour of the exploit, four billion new tokens had appeared, representing around 26% of the previously declared supply. However, the protocol’s totalSupply API failed to register the additional tokens, leaving all systems depending on this endpoint unaware of the increase.
According to Harmony’s own forensic report on August 17, a single wallet attempted 534 transfers of 5 billion ONE each in just 106 seconds. Of these, 477 transactions succeeded, moving a total of 2.385 trillion ONE. Harmony’s updated tracing model managed to match almost all the illegitimate issuance to specific wallets or service destinations.
SlowMist’s incident tracker estimated the exploit’s realized cash-out at $3.2 million, a figure that only covers the third-party loss, not the impact on all other token holders due to inflation.
This marks Harmony’s third critical security event in four years: The 2022 Horizon Bridge attack involving a compromised signing key, a staking logic vulnerability in 2023, and now a legacy verification flaw that remains under analysis.
ONE plummeted to a record low of $0.0005735 before Harmony had publicly identified the cause.
A fix was put in place within hours to stop further unauthorized minting.
Harmony later announced a rollback strategy, freezing Shard 0 at block 92,730,034 and Shard 1 at block 94,978,278, restoring both using replacement databases. According to this plan, all subsequent blocks would be discarded, with the chain resuming from blocks 92,730,035 and 94,978,279.
Whether this rollback has been carried out, and the final number of tokens minted, remains unconfirmed.
When a blockchain cannot accurately report its own supply, what is the actual basis for exchange valuations?
Credit: Harmony, SlowMist, Juiceberg, Matthew Barrett, Tech Times, ZachXBT, CertiK
Juiceberg made the first public disclosure, preceding any communication from Harmony.
On August 11, on-chain researcher Juiceberg reported the initial findings: Approximately 4 billion ONE were minted in empty blocks, about 26% of the reported supply at the time, and 2.8 billion were sent to exchange addresses as the price declined.
The same analysis pointed out another ongoing concern: Harmony’s totalSupply endpoint was not accounting for the unauthorized tokens.
It took nearly three hours for Harmony to respond.
The official Harmony account replied directly to Juiceberg’s post, mentioning coordination with exchanges, an active patch, and that rollback options were being considered. No specifics were provided regarding the total amount minted or the underlying vulnerability.
Shortly thereafter, Harmony released four wallet addresses and requested that all exchanges monitor and freeze any assets linked to them.
To contain the situation, Harmony suspended its bridge service. According to Harmony’s incident report, the emergency fix (v2026.1.1) was implemented at 06:30 UTC on August 12, following the bridge shutdown.
This intervention halted additional unauthorized minting.
However, ZachXBT publicly stated he would not investigate this case, arguing that no one should do so without compensation, referencing Harmony’s previous response to those who assisted in recovering assets after the 2022 bridge hack: "good job."
A few hours later, Harmony released further details, tracking 10,288 transfers across 409 wallets, identifying hundreds of suspicious deposits to exchanges, and noting that within four hours, 53% of validators had applied the patch.
The development team thanked validators but still did not publicly identify the root cause of the exploit.
If the official response lags behind the attacker, is the priority asset security or managing optics?
Credit Without Matching Debit
Harmony’s cross-shard protocol was intended to enable value transfer among four shards using a native, receipt-based method, instead of external bridges.
The receiving shard is supposed to check the receipt and accompanying proof before crediting funds. This system was intended to block cross-shard double-spending.
Harmony’s receipt-verification process for cross-shard transactions allowed valid receipts to be accepted multiple times.
Prior to IsCXMerkleProofReplayFixEpoch, the replay protection for receipts generated a spent marker based on CXMerkleProof.ShardID and CXMerkleProof.BlockNum.
Because the validation function did not securely link these fields with the signed source-block header for the relevant epochs, an attacker could alter them without invalidating the block’s signature, making a previously used receipt appear unprocessed.
While the block header itself could not be edited without breaking the signature, the Merkle proof’s identifying fields went unchecked. By changing these, an attacker could submit a used receipt as if it were new.
This allowed someone to take a processed cross-shard receipt and re-submit it with altered identifiers. Each altered version produced a unique marker, making the system treat it as unused, so the receipt would again be accepted.
This led to direct inflation of ONE, all occurring in empty blocks with no gas fees: The blockchain’s state root changed even though there were no regular or staking transactions.
Harmony also identified an issue with pre-staking quorum verification: uniformVerifier.IsQuorumAchievedByMask relied on the full committee size, not the number of enabled validators in the signer bitmap.
A nil signer mask was not rejected, and this code path was used for pre-staking era block header validation, including those attached to old cross-shard receipts.
Version v2026.1.1 of Harmony’s mainnet client patched both vulnerabilities. The update was tracked as PR #5101.
Which exact weakness, or combination, the attacker exploited is still not publicly confirmed.
Both failures allowed receipts or headers to pass validation when they shouldn’t have, neither required breaking cryptography. They simply depended on insufficient verification of the actual data.
If a blockchain cannot distinguish a header with no valid signers from one legitimately approved by validators, what is consensus securing?
The Accounting Gap
The “already spent” check was intended to prevent exactly what occurred.
Two minting events, two large transfers, four wallets flagged for freezing—all details are visible on-chain.
Mint Recipient 1 – (1,000,000,000 ONE): one17u300a40ll5wphd8kj5hktryhdjq3ml9f4phy4
Mint Recipient 2 (3,000,000,000 ONE): one1a5hur07z5vtvzhr35zkw8tfqedemkz8t88xgd7
The attack resulted in four billion ONE being minted in two empty blocks.
The second recipient rapidly transferred the funds: first to another wallet within ninety seconds, and then that wallet sent almost all of it to a third wallet within three minutes.
Transfer Transaction 1 (2,800,000,000 ONE): 0xf3d4e8b12479ae14cd5eae973a5f61b07d567b142a6ca1385471d5c288242c7f
Transfer Transaction 2 (2,799,999,999.99183949 ONE): 0x9a756ef9f95a4c737b3c7e87f04419e9391f226c631ff7b81c401619b0a4d678
Almost the entire sum was moved again in less than three minutes, at 01:05:24 UTC.
The four addresses Harmony requested exchanges to freeze are:
Freeze Wallet 1: one1uap8dx2z0qsjxqthm5flgcxkeepsz3gsrghnfn
Freeze Wallet 2: one17u300a40ll5wphd8kj5hktryhdjq3ml9f4phy4
Freeze Wallet 3: one1a5hur07z5vtvzhr35zkw8tfqedemkz8t88xgd7
Freeze Wallet 4: one1h56hkxmua0uzfv07fu04cudvtrl35u96pq47vy
These represent the confirmed initial wave, totaling four billion ONE, but Harmony’s incident accounting references two separate figures.
CertiK separately identified over three trillion ONE minted across six suspicious blocks.
A protocol may report two different scales for the same exploit.
On August 17, Harmony published a transaction flow analysis: A single forged-mint wallet attempted 534 transfers of 5 billion ONE each in 106 seconds, 477 of which succeeded, totaling 2.385 trillion ONE.
This accounts for nearly 79% of the provisional 3.01 trillion ONE reconstructed issuance.
Harmony said its preliminary model traced more than 99.9% of the forged tokens to a wallet or service, while a later analysis brought the match rate even closer to 100% (including transaction fees) at the analysis cutoff.
The tracing used block data, transaction receipts, and balances through Shard 0 block 92,805,850.
However, tracing movement is not the same as identifying or recovering funds. Harmony clarified that “traceable to a wallet or cluster” means the ability to follow the path to a wallet, pool, contract, exchange, bridge, or validator, not to the individual in control. A wallet might represent many unrelated users.
Harmony also distinguished traceability from what could be safely burned: Once the forged ONE entered centralized exchange wallets, DEX pools, LP positions, bridges, or other shared balances, burning the entire amount could affect unrelated users or disrupt services.
The first four billion ONE alone represented about 25% of the previously reported supply.
A dollar-value loss does not account for overall dilution among holders or distinguish between coins that were sold, frozen, pooled, or later erased by rollback.
If Harmony can follow the flow but cannot always determine control or safely recover the assets, what does “traceable” really mean?
Reversing the Damage
By the time the rollback was being prepared, Shard 0 had already stopped producing blocks.
Harmony stated that it halted at block 92,753,555 at 12:32:54 UTC on August 12 to enable the rollback. As a result, its public RPC endpoint may have returned a 502 error.
A rollback keeps all history up to a defined checkpoint and deletes subsequent blocks, along with their associated transactions.
An August 13 incident report from Harmony identified block 92,730,034 (timestamped 23:25:37 UTC on August 11) as the rollback point, one block before the first fraudulent cross-shard event.
By August 17, this rollback point became the official plan, with a one-block safety margin.
Harmony said it would lock Shard 0 at block 92,730,034 and Shard 1 at block 94,978,278, both at the same timestamp, and resume from 92,730,035 and 94,978,279.
Client v2026.1.2 was set to reject the hashes for all problematic blocks as part of this process.
This would not simply erase the attacker’s transactions—it would remove all blocks after the checkpoint, including valid user transactions.
Harmony considered alternatives such as targeted burning, blacklisting, selective replays, and token migration, but ultimately chose a full rollback using its built-in revert tool.
The scale is significant: Harmony’s archival range for Shard 0 from block 92,730,035 to 92,871,662 spans 141,628 blocks, including 109,126 regular and 315 staking transactions, all of which would be lost in the new chain history.
This matters because a rollback cannot revert funds that have already left the chain, such as those on exchanges or bridges. It only replaces Harmony’s on-chain records, not the state at external services.
Harmony has not publicly named the exchanges involved.
As of the latest update, the rollback was planned but not yet executed.
The bridge remains inactive and the emergency patch was deployed upon reaching sufficient validator participation.
If removing forged tokens means deleting over 109,000 user transactions, whose version of the ledger is being preserved?
Within four years, Harmony has experienced three major incidents undermining confidence in ONE’s security.
In 2023, a staking bug resulted in the unauthorized creation of 146.28 million ONE.
The most recent incident involved a flaw in the cross-shard receipt verification logic, allowing receipts to be processed repeatedly and crediting the destination shard without subtracting from the source.
These changes took place in empty, zero-gas blocks, with only the state root changing.
A rollback is intended to restore the chain to prior block heights, but this does not erase the broader impact: over 109,126 regular transactions are set to disappear from Harmony’s replacement ledger, and no exchanges have been publicly identified as involved.
A network created for seamless cross-shard coordination saw its most critical flaw in the very mechanism designed to secure that coordination.
If sharding is meant to make trust implicit, what happens when those trust assumptions fail?
Get new scam files the moment we publish them — usually 2–3 emails a week.