Harmony $3.2M Cross-Shard Receipt Replay Exploit (Explained)

On August 11, 2026, Harmony's legacy cross-shard receipt-verification logic let an attacker replay an already-processed receipt as new, crediting one shard with no debit on the other. No key was stolen, no contract was drained, no flash loan was involved. The attacker minted ONE from empty blocks, an initial 4 billion tokens, later reconstructed at 3.01 trillion, while Harmony's own totalSupply endpoint stayed silent. A third-party estimate puts cash-out losses at $3.2 million, far under the real damage.

Protocol Background

Harmony runs four shards and moves value between them through a receipt-based, asynchronous cross-shard mechanism instead of an external bridge. A source shard produces a cryptographic receipt for an outgoing transaction, and the destination shard is meant to verify that receipt and its Merkle proof against a signed source-block header before crediting it, with every receipt spendable exactly once. That single-use guarantee, enforced through ValidateCXReceiptsProof and ApplyIncomingReceipt, is what the exploit broke.

Hack Analysis

The exploit lived in a legacy part of Harmony's cross-shard system. Before an upgrade called IsCXMerkleProofReplayFixEpoch, Harmony checked whether a cross-shard receipt had already been used by looking at two fields, CXMerkleProof.ShardID and BlockNum, instead of the signed block header those fields were meant to come from.

Because those two fields sat outside the header, they could be changed without breaking anything. The attacker took a cross-shard receipt that had already gone through once and edited its ShardID and BlockNum so the check saw it as brand new.

The destination shard accepted the altered receipt and credited it again, with nothing debited from the source shard to balance it out.

That's what let new ONE appear from nothing. It started at 23:25:40 UTC on August 11, first showing up on Shard 0 at block 92,730,036, a block with a changed state root but no real transactions in it.

The first confirmed mint landed in two credits: 1,000,000,000 ONE to 0xF722f7f6afffe8e0dda7b4a97b2c64bb6408efe5 then 3,000,000,000 ONE to  0xed2Fc1bfc2a316c15c71a0ace3ad20cb73bb08eb .

The second wallet moved fast, sending 2,800,000,000 ONE out within a minute and forwarding almost the entire remaining balance again three minutes later.

Root Cause

This wasn't a stolen key, and it wasn't a smart contract exploit on some outside protocol. A legacy verification check let a receipt's identifying fields be changed without ever being tied to the signed header meant to vouch for them, so an already-used receipt could pass as new.

Before the IsCXMerkleProofReplayFixEpoch upgrade, Harmony's spent-receipt check read two fields sitting outside the signed header instead of the header's own authenticated values. A second, separate bug in Harmony's quorum check meant an empty validator signature list could still pass as valid for old pre-staking blocks.

How QuillAudits Infrastructure Review Could Have Prevented This

Header-binding review for replay-protection keys. Any field used to derive a one-time-use marker needs to be part of what the signature actually authenticates. A review tracing IsSpent and WriteCXReceiptsProofSpent back to VerifyHeaderSignature would have caught CXMerkleProof.ShardID and BlockNum sitting outside that boundary for pre-fork epochs.

Legacy code-path coverage, not just active consensus logic. The quorum bug in uniformVerifier.IsQuorumAchievedByMask only mattered for pre-staking-epoch committees, exactly the kind of dead-looking legacy path that gets skipped when a review focuses on current-epoch flow. The eventual fix, counting only signers enabled via mask.IndexEnabled and rejecting empty or nil masks, is the kind of check a legacy-path review would flag before an incident, not after.

Independent mint and burn invariant monitoring. Relying on a single totalSupply RPC endpoint as the source of truth for supply integrity means an attacker only has to make that one endpoint lie. A monitor built on internal state-root deltas, rather than the exposed endpoint, would have flagged the empty, zero-gas blocks with a moving state root immediately.

Funds Flow After Attack

2,800,000,000 ONE moves out to 0x358A973400dA30334ffA39be8E02194BFe659Eb6 (one1xk9fwdqqmgcrxnl68xlguqsef0lxt84kmdyzyk)

The remaining 2,799,999,999.99183949 ONE moves to  0x15e5BF28eE8516Bb8B4eEd5F1a85bEC970Dd821C (one1zhjm728ws5tthz6wa4034pd7e9cdmqsuqfwjrr)

One of those wallets pushes 2,385,000,000,000 ONE out in 477 successful transfers within 106 seconds.

Harmony traces over 99.9% of the forged ONE to a wallet or service boundary, though not all of it is recoverable. The rollback restoring Harmony's pre-exploit ledger has since completed.

Post-Attack Mitigation

On August 12, Harmony confirms it's working with exchanges to freeze the funds while a patch and rollback options are in progress.

On August 13, Harmony publishes its full incident report, naming the cross-shard receipt replay and the pre-staking quorum bug as the two vulnerabilities behind the mint, and confirms that patch v2026.1.1 is already live.

On August 17, Harmony shares its rollback plan: the exact blocks it will keep, the alternatives it ruled out, and how far it has traced the forged ONE.

Harmony announces that validators have reached quorum on both shards and declares Stage 2 GO, pointing validators to the recovery guide.

A day later, Harmony confirms the rollback is complete. Both shards have run stably for over 24 hours, produced roughly 100,000 blocks, and moved from epoch 3002 to 3004 with near-full validator participation.

Relevant Addresses and Transactions

Attacker Wallets / EOAs

• Mint recipient, 1,000,000,000 ONE: one17u300a40ll5wphd8kj5hktryhdjq3ml9f4phy4
• Mint recipient, 3,000,000,000 ONE: one1a5hur07z5vtvzhr35zkw8tfqedemkz8t88xgd7

Downstream Transfer Wallets

• Received Transfer Tx1, 2,800,000,000 ONE: 0x358A973400dA30334ffA39be8E02194BFe659Eb6
• Received Transfer Tx2, 2,799,999,999.99183949 ONE : 0x15e5BF28eE8516Bb8B4eEd5F1a85bEC970Dd821C

Reference Code

• Fix pull request: PR #5101
• Patch release: v2026.1.1

Key Transactions

• Transfer Tx1, 2,800,000,000 ONE:  0xf3d4e8b12479ae14cd5eae973a5f61b07d567b142a6ca1385471d5c288242c7f
• Transfer Tx2, 2,799,999,999.99183949 ONE: 0x9a756ef9f95a4c737b3c7e87f04419e9391f226c631ff7b81c401619b0a4d678

Conclusion

No key was stolen and no cryptography was broken. A receipt-verification check that trusted unauthenticated fields let an already-spent receipt pass as new, and Harmony's own supply counter didn't notice while billions of ONE appeared from nothing. The initial 4 billion ONE wave was a fraction of the eventual 3.01 trillion. The rollback erased the forged blocks. It never reached what had already left the chain.