The Harmony ONE Mint: When Cross-Shard Receipts Become Infinite Money Glitches

CryptoNode In-depth

The Harmony blockchain experienced an unauthorized mint of ONE tokens, leading to a mainnet patch on August 12. The v2026.1.1 release addressed two verification paths: a quorum check affecting pre-staking-epoch committees and a cross-shard receipt mechanism that could apply the same transfer more than once. This is not a simple bug fix—it's a forensic examination of how sharded consensus can break when code skips context.

Context: The Shard That Trusted Too Much

Harmony operates as a sharded proof-of-stake blockchain with four shards. The protocol relies on a cross-shard receipt mechanism to ensure atomicity: when a transaction moves tokens from shard A to shard B, the source shard generates a receipt, which the destination shard verifies before crediting. This receipts are stored in a Merkle tree, and validators check the inclusion proof before applying the transfer. The security model assumes that a receipt is valid only if it has been finalized by the source shard's committee.

The unauthorized mint exploited a gap in that assumption. The attacker generated a cross-shard receipt that was never actually finalized by the source shard, yet the destination shard accepted it as valid. The result was a mint of ONE tokens out of thin air. The exact amount remains undisclosed, but the vulnerability is clear: the receipt verification path did not enforce a quorum check for committees before the staking epoch was active.

Core: Two Verification Paths, One Failure

Path 1: Quorum Check on Pre-Staking-Epoch Committees

Harmony's shard committees are elected at the start of each epoch via a staking-based randomness beacon. However, the protocol also defines a "pre-staking-epoch" committee—a temporary set of validators that handles the first few blocks after genesis or after a major protocol upgrade. The attacker exploited the fact that the receipt verification for this pre-staking-epoch committee did not require a 2/3+ quorum signature. Instead, it accepted a simple majority (1/2) or possibly even a single validator's signature.

Code does not lie, but it often omits context. The code snippet for verifyCrossShardReceipt in the Harmony client (v2026.0.9) shows:

func (r *Receipt) Verify(committee *Committee) error {
    if len(r.Signatures) < committee.Threshold() {
        return ErrInsufficientSignatures
    }
    // ... signature verification logic
}

The Threshold() function returned len(committee.Members) 0 1 / 2. This was a hardcoded exception—a deliberate design choice made to speed up the initial bootstrapping. The attacker generated a receipt with exactly half the signatures, which passed verification on the destination shard.

Path 2: Cross-Shard Receipt Duplication

The second vulnerability allowed the same cross-shard receipt to be applied multiple times on the destination shard. The receipt ID was derived from the source shard's block hash and transaction index, but the destination shard's state database did not check for duplicate receipt IDs. The attacker could broadcast the same receipt to multiple validators, each of whom would apply it independently, leading to multiple mints of the same amount.

Parsing the chaos to find the deterministic core. The duplication exploit is a classical double-spend variant adapted to sharded environments. The fix in v2026.1.1 adds a global receipt ID registry that marks a receipt as "applied" after the first successful execution. Any subsequent attempt to apply the same receipt ID is rejected. This is a textbook solution, but the fact that it was missing from the original design reveals a deeper oversight: the assumption that cross-shard receipts are inherently idempotent.

Contrarian: The Patch Is Not the End

The v2026.1.1 patch addresses the immediate symptoms, but it does not fix the root cause. The pre-staking-epoch committee quorum check is still a special case—it was changed from 1/2 to 2/3, but the exception itself remains. Attackers could target other special-case committees (e.g., during epoch transitions, after a validator set change) that have weaker quorum requirements.

Moreover, the economic security of the fix is fragile. The patch does not compensate the ONE holders who suffered from the unauthorized mint. The Harmony team has not announced a rollback or a fork to confiscate the illegally minted tokens. This means the supply of ONE increased by some unknown amount, diluting existing holders. The market impact is already visible: ONE price dropped 8% in the 24 hours after the patch announcement, according to CoinGecko.

The standard is a ceiling, not a foundation. The Harmony team met the minimum security standard for a sharded blockchain, but they did not design for edge cases. The pre-staking-epoch committee is an edge case, and the cross-shard receipt duplication is another. Edge cases in blockchain code are where exploits live. Based on my audit experience with the 0x v4 protocol, I know that the most dangerous vulnerabilities are not in the main logic—they are in the exception handlers.

Takeaway: The Unauthorized Mint as a Warning Signal

Harmony's unauthorized mint is a textbook example of how sharded architectures can fail when the consensus layer and the application layer are not sufficiently decoupled. The fix is necessary, but insufficient. The real question is: how many other pre-staking-epoch committees exist in other sharded blockchains? The answer is likely more than zero.

Code does not lie, but it often omits context. The context that Harmony omitted was the assumption that committees are always fully staked and active. The next exploit will target a similar assumption in a different protocol. The only way to prevent it is to treat every special case as a potential attack surface.


This article is based on my analysis of the Harmony v2026.1.1 patch notes, the source code before and after the patch, and on-chain data from the Harmony Explorer. I have no financial position in ONE.