Anatomy of the Harmony ONE Exploit: Consensus Logic Failures and Token Minting

According to Halborn's forensic breakdown of the August 2026 Harmony incident, an unauthorized minting exploit on the Layer-1 generated approximately 4 billion ONE tokens — roughly $3.2 million at the time — by abusing a flawed consensus check. In the same week, CoinSpot.io reports a separate exploit on the BounceBit Layer-1 drained about 286 million BB tokens (~$3.1 million), prompting the team to suspend node operations and plan migration to BEP-20 on BNB Chain. For smart contract and L1 engineers, the two incidents land the same lesson: consensus and authorization logic at the chain level is now a primary attack surface.

The bug: counting keys is not counting validators

Instead of counting validators that actually signed a transaction, the protocol counted public keys listed within a signature mask. Public keys are, by definition, public. The check reduced to a length comparison on attacker-supplied data.

The attacker used this gap to submit a series of empty blocks that minted new tokens without passing through proper consensus. The totalSupply endpoint — the official source for circulating supply — did not update immediately to include the minted tokens. That lag gave the attacker a window to move tokens to exchanges before detection.

Scale, distribution, and the rollback

Per Halborn, the minted tokens were distributed across 409 wallets in 10,288 transactions. Total circulating supply increased by approximately 26%, and the ONE price dropped by roughly 40%. Harmony is planning a rollback to eliminate the excess supply.

What to verify in your own stack

The failure mode is not exotic. Three patterns to audit now:

• Quorum checks must verify signed messages, not signer identifiers. A signature mask listing public keys is not equivalent to a count of valid signatures. Consensus and multi-sig logic must check the cryptographic signature against a threshold — not the length of a candidate set.
• State endpoints that lag consensus are exploitable. If a totalSupply, balance, or similar view function does not reflect the latest state transitions in the same block, attackers can use that gap to move funds before detection. Reads must source from finalized state.
• Test empty-block and edge-case minting paths. The exploit here passed through blocks with no transactions. Unit tests must cover what happens when a block advances state without transactions.

On BounceBit, CoinSpot reports the team stopped nodes, requested exchanges freeze related addresses, and chose migration over a relaunch — the fork depended on Evmos infrastructure that no longer functioned as before. Chain-level dependencies outside your own codebase are also attack surface. Audit them with the same rigor applied to smart contracts.