Harmony Cross-Shard ONE Mint + ~$47M Key Losses

During the past week (2026/08/10 - 2026/08/16), the following 5 notable security incidents are featured, involving approximately $47M in total losses.

Date	Incident	Type	Estimated Loss
2026/08/10	Coinsbuy	Private Key Compromise	~$7.9M
2026/08/10	Unknown Whale Wallet	Private Key Compromise	~$25M
2026/08/12	Harmony	Validation Issue	Unknown*
2026/08/13	Kite	Private Key Compromise	~$14M
2026/08/15	Fox	Business Logic Flaw	~$117K

*Harmony reported a confirmed first-wave mint of 4B ONE and a broader reconstruction of approximately 3.01T ONE forged, of which approximately 2.385T ONE was transferred [1]. At the pre-incident price of ~$0.001183 the forged amount carries a nominal value of ~$3.56B, but that is roughly 200x ONE's total supply and far exceeds the token's market capitalization, so it is neither realizable nor confirmed realized loss. Harmony has since rolled the chain back to a pre-attack checkpoint, discarding the forged state [2]. Harmony is therefore excluded from the total losses.

Reasons for selection

Harmony: Selected because a chain-implementation replay-protection flaw enabled unauthorized native-token issuance at massive scale across the Harmony ecosystem. A separate pre-staking quorum-verification weakness was identified during the investigation, though its role in the exploit is unconfirmed.

Weekly Highlight: Harmony

Harmony is featured this week because the flaw lived in the chain implementation itself rather than in an application contract, an unusually high-impact failure mode because it can inflate the base asset of an entire Layer-1.

On August 12, 2026, Harmony, a sharded Layer-1 blockchain, suffered unauthorized minting of its native ONE token through a cross-shard receipt replay flaw. Destination shards identified an already-consumed receipt using fields that were not covered by the source committee's signature, so an attacker could re-present a genuine, previously credited receipt by mutating only those fields and have it credited again with no matching debit on the source shard. Harmony was reconciling a confirmed first-wave mint of 4B ONE with a broader reconstruction of approximately 3.01T ONE forged and approximately 2.385T ONE transferred by a forged-mint wallet; none of these is confirmed realized loss, and the final impact remains subject to rollback and exchange reconciliation [1][2]. During the investigation, Harmony identified a separate pre-staking quorum-verification flaw, though it has not confirmed whether the exploit relied on it.

Background

Harmony is a sharded Layer-1 blockchain. Each shard maintains its own independent state, so a source shard cannot directly modify an account on a destination shard. To move value between shards, Harmony uses an asynchronous, receipt-based design: the source shard debits the sender and emits a cross-shard receipt, and the destination shard later credits the recipient.

A cross-shard receipt records the transfer itself:

type CXReceipt struct {
    TxHash    common.Hash
    From      common.Address
    To        *common.Address
    ShardID   uint32
    ToShardID uint32
    Amount    *big.Int
}

The destination shard does not trust a bare receipt. The receipt travels inside a CXReceiptsProof, which carries a Merkle proof, the source block header, and the source committee's commit signature over that header:

type CXMerkleProof struct {
    BlockNum      *big.Int
    BlockHash     common.Hash
    ShardID       uint32
    CXReceiptHash common.Hash
    ShardIDs      []uint32
    CXShardHashes []common.Hash
}

type CXReceiptsProof struct {
    Receipts     CXReceipts
    MerkleProof  *CXMerkleProof
    Header       *block.Header
    CommitSig    []byte
    CommitBitmap []byte
}

The normal verification path validates the proof against the signed source header and its committee signature:

VerifyIncomingReceipts()
  -> IsSpent()
  -> ValidateCXReceiptsProof()
      -> VerifyHeaderSignature()
          -> verifySignature()
              -> DecodeSigBitmap()
              -> IsQuorumAchievedByMask()
              -> aggSig.VerifyHash()

Because the source shard performs the debit exactly once, the destination shard must ensure that each cross-shard receipt is consumed only once.

Vulnerability Analysis

The cross-shard settlement path contained two issues: a replay-protection weakness in how a consumed receipt was identified, and a pre-staking quorum-verification weakness.

Cross-Shard Receipt Replay

Replay protection recorded and looked up a receipt's "spent" marker, but its key came from two mutable fields of the Merkle proof:

CXMerkleProof.ShardID
CXMerkleProof.BlockNum

The Bloom hardfork strengthened this on mainnet at epoch 2964 (July 13, 2026), gated by IsCXMerkleProofReplayFixEpoch [3]: for a proof whose signed Header.Epoch() is at or after that epoch, IsSpent() and WriteCXReceiptsProofSpent() derive the spent-marker key from the signed source header (Header.ShardID and Header.Number) instead of those two fields. The stronger keying was never applied retroactively, though — for a proof whose Header.Epoch() predates the fork, both functions kept the legacy fallback to MerkleProof.ShardID and MerkleProof.BlockNum, which ValidateCXReceiptsProof() never bound to the signed header for those epochs.

Those two fields sit outside the commit signature, which covers only the source Header. Altering the Header would fail VerifyHeaderSignature(), but mutating MerkleProof.ShardID or MerkleProof.BlockNum breaks no check at all — not the header signature, and not proof validation, which for these epochs never tied them back to the Header. Because the legacy spent-marker key was derived from these unauthenticated fields, a receipt's replay-protection identity was decoupled from the signature that authenticated the rest of the proof: two proofs carrying the same signed header and receipts but different MerkleProof.ShardID or MerkleProof.BlockNum values were treated as distinct for spent-tracking purposes.

Pre-Staking Quorum Check

A second flaw affected pre-staking quorum verification. The uniformVerifier.IsQuorumAchievedByMask() logic compared the threshold against

len(mask.Publics)

treating it as the number of signers. But mask.Publics is the full list of committee public keys for a shard and epoch, not the set of validators that actually signed; that set is represented by the signer bitmap. As a result, an empty signer bitmap could still clear the quorum threshold, because the check measured committee size rather than enabled bitmap bits. Combined with an identity (all-zero) aggregate BLS signature, this could make a pre-staking-era source header appear to carry sufficient quorum.

Attack Analysis

The attacker started from a genuine, already-processed cross-shard receipt from a source-shard block predating the hardfork, then replayed it by mutating only its unauthenticated proof identity. The forged ONE was minted into four exploiter wallets. The following analysis is based on the transactions 0xf3d4e8b1...8242c7f and 0x9a756ef9...b0a4d678.

Step 1: The attacker obtained a valid historical CXReceiptsProof from a source-shard block before the hardfork. The proof contained valid receipts, a valid source block header, and a valid source committee commit signature.
Step 2: The destination shard had already consumed this receipt once and written its spent marker, keyed from the Merkle-proof fields.
Step 3: The attacker mutated only the unauthenticated proof identity fields, leaving the signed header and all signature-covered fields untouched:
```
MerkleProof.ShardID
MerkleProof.BlockNum
```
Step 4: The mutated proof was submitted as an incoming receipt in a later destination-shard block. IsSpent() derived the spent-marker key from the mutated fields and failed to find the earlier marker, so the receipt appeared unspent.
Step 5: ValidateCXReceiptsProof() still accepted the proof, because the mutated identity fields were not signature-covered while every authenticated field remained unchanged: the header hash and outgoing-receipt hash, the Merkle-proof block hash and receipt hash, the receipts hash, and the commit signature and bitmap.
Step 6: ApplyIncomingReceipt() executed on the destination shard and credited the recipient again via db.AddBalance(*cx.To, cx.Amount). No corresponding debit occurred on the source shard, because the original cross-shard transaction had already executed exactly once, producing native ONE inflation on the destination shard.

Conclusion

The root cause confirmed by the project was a protocol-level replay-protection failure: a cross-shard receipt's consumed-state identity was derived from unauthenticated proof fields rather than the signed source header, so an already-processed receipt could be credited a second time. Harmony also confirmed a separate pre-staking quorum-verification flaw, though the public disclosures do not establish whether the attacker used it here.

The patches close both gaps [4][5][6]. More broadly, a chain implementation must authenticate every field it uses to identify already-consumed state, and must judge quorum by the validators that actually signed rather than the full committee.

References

[1] Harmony incident update
[2] Harmony rollback plan
[3] Harmony Bloom hardfork (PR #5053)
[4] Commit 61afbf6: fix CX receipt spent-marker key
[5] Commit 7515262: fix quorum bitmap counting
[6] Harmony PR #5101

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.