A Forged Trillion Tokens Made Cross-Shard Replay Risk Impossible to Ignore

Harmony’s proposed rollback after an attacker forged more than 3 trillion ONE tokens is not only an extraordinary supply incident. It is a clear lesson in a foundational interoperability requirement: a cross-shard receipt must prove that an authorized source event occurred and that its resulting claim can be executed exactly once. A Merkle proof can establish that a receipt was included in a specified source commitment; together with verified source consensus or finality and receipt-origin checks, it can establish the first fact. It cannot establish the second.

On August 12, Harmony confirmed unauthorized minting after reports that 4 billion ONE had been created. Five days later, The Block reported that Harmony’s reconstruction put the total at 3.01 trillion forged ONE across six transactions, and that validators planned to roll back Shard 0 and Shard 1 to a point before the confirmed forged mint. The reported cause was a cross-shard receipt verification flaw that let valid receipts be processed repeatedly, minting assets without a corresponding debit elsewhere.

That is a dramatic failure, but its underlying logic is compact enough to state in one sentence: a destination chain treated proof that a message existed as if it were proof that the message had never been used before.

For builders, that distinction should be central to any design involving shards, bridges, rollups, appchains, settlement layers, or asynchronous smart contract calls. A network may have excellent cryptography, fast finality and an honest validator set, yet still lose its monetary integrity if a receipt can be redeemed twice.

The security question is not simply, “Can the destination verify the source?” It is more demanding:

1. Can the destination verify that the source transaction was real?
2. Can it verify exactly what that transaction authorized?
3. Can it verify that the receipt is intended for this destination, contract and execution environment?
4. Can it ensure that the receipt changes state only once?
5. Can it preserve those guarantees when source blocks reorganize, relayers retry and operators invoke emergency powers?

The answer must be designed into the entire receipt lifecycle. It cannot be added by a Merkle proof at the end.

The small event that becomes a big claim

Consider a simple transfer between two shards of the same network.

Alice holds 100 ONE on Shard 0 and wants to move it to Shard 1. A safe transfer is not merely a message saying, “Give Alice 100 ONE on Shard 1.” It is a state transition with two linked consequences:

• Shard 0 debits, locks or burns 100 ONE from Alice.
• Shard 1 credits or mints 100 ONE for Alice.

If Shard 1 creates the credit once, the system remains balanced. If it creates the credit twice, 100 ONE has turned into 200 ONE from the user’s perspective. If it creates the credit 30 times, the inflation is 2,900 ONE. The original debit on Shard 0 still happened only once.

This is why cross-domain messaging is more than transport. It is distributed accounting.

A receipt is usually the portable representation of the source-side event. It may include a source transaction hash, log index, source shard identifier, destination shard identifier, sender, intended recipient, amount, payload, nonce and the source block or state root that commits to it. A relayer carries that receipt and its proof to the destination.

The proof establishes a limited but important statement: a particular item was included in a particular commitment. If the commitment is valid and sufficiently final, the destination can trust that the source chain recorded the item.

But inclusion is not consumption.

The operational temptation is easy to understand. A destination contract wants a simple rule: if a valid proof shows an eligible source event, execute the requested action. That rule supports permissionless relaying, which is valuable. Anybody can deliver a message, reducing dependence on a designated operator.

Yet permissionless delivery creates a necessary corollary: anybody can submit the same valid proof again. The protocol must make repeated submission harmless.

Authenticity and uniqueness are different jobs

The first security property is authenticity. The destination should be able to answer: did the source chain actually authorize this message?

That normally requires validation of several things:

• the source block header or a trusted commitment to it;
• the source chain or shard identity;
• the Merkle inclusion proof;
• the source contract or system module that emitted the receipt;
• the receipt fields;
• the destination chain, shard and contract encoded in the receipt;
• the relevant finality condition.

A correct inclusion proof prevents an attacker from fabricating an event that never appeared in the committed source data. It can show that receipt R was part of a source block’s receipt tree.

The second property is uniqueness, often implemented as replay protection. The destination should answer: has receipt R already caused an effect here?

No static cryptographic proof can answer that question by itself, because the question concerns the destination’s changing local state. A Merkle proof delivered at 10:00 a.m. can remain perfectly valid at 10:01, 10:05 and next week. The source receipt does not become false because it was already redeemed. It is still authentic. It is simply no longer actionable.

That means a secure destination needs durable state such as:

consumed[receipt_id] = true

The check, the state update and the credited action must happen as one atomic transition:

require(valid_proof(receipt, proof))
require(!consumed[receipt_id])

consumed[receipt_id] = true
execute(receipt)

The sequence matters. If execution happens before the consumed flag is written, a reentrant call, failed write or unexpected transaction path can reopen the replay window. If the flag is stored in a separate database or a relayer service rather than consensus state, different validators can disagree about whether a receipt was spent. If the receipt identifier is ambiguous, two encodings of the same economic event can bypass the check.

The desired property is often called exactly-once delivery. In practice, the protocol should distinguish two layers:

• At least once delivery: a valid message may be submitted repeatedly until one submission succeeds.
• At most once execution: successful execution can alter destination state no more than one time.
• Exactly once destination execution: together, the two properties prevent duplicate destination effects, but end-to-end settlement still requires stronger atomicity or reconciliation across independently finalized source and destination state machines.

Networks can often tolerate at least once transport. They cannot tolerate more than once minting.

This distinction applies beyond token transfers. A cross-shard receipt may call a contract function, unlock collateral, release a withdrawal, create a governance vote, register an NFT ownership change or trigger an oracle update. Every one of those effects can be corrupted by replay if the design assumes that authenticated means fresh.

For token minting, the effect is immediately legible because supply increases. For governance or contracts, the resulting damage can be subtler. A repeated execution might issue duplicate voting power, repeatedly release escrowed funds, or invoke a privileged action more than once.

The receipt must bind the full execution context

A receipt identifier is not just a convenience field. It is the protocol’s definition of what counts as “the same message.”

The safest approach is to derive an identifier from an unambiguous canonical encoding of the event and its domain. A conceptual format might be:

receipt_id = H(
  protocol_version ||
  source_chain_id ||
  source_shard_id ||
  source_block_hash ||
  source_transaction_hash ||
  source_event_index ||
  source_contract ||
  destination_chain_id ||
  destination_shard_id ||
  destination_contract ||
  payload_hash
)

An implementation need not use this exact layout. But it must answer why each field is either present in the identifier or reliably bound elsewhere in the verification process.

The source location fields distinguish two separate events that happen to carry the same payload. The source contract field stops an unrelated contract from producing a lookalike event. The destination fields prevent a message valid for one shard, chain or application from being accepted in another context. The payload hash binds the economic instruction itself, including recipient, asset and amount.

This is domain separation. It is a deceptively practical defense. Cryptographic objects are often valid wherever their verifier accepts them. Domain separation makes a proof or signature useful only for the intended protocol, network version and destination application.

Imagine a receipt that says only, “credit Alice 100 ONE.” Its inclusion proof might be correct. But without destination binding, could Shard 2 accept it as well as Shard 1? Could a test environment accept it? Could a different version of the transfer contract interpret the payload differently? Could an asset bridge and a staking module both parse the same bytes as authority to issue value?

A well-designed receipt must make those questions boring. The answer should be no because the verifier checks exact identities, not because developers assume contracts will never be confused.

Versioning deserves similar care. Protocol upgrades alter serialization, asset mappings, proof rules and execution paths. A receipt produced under version one should not silently acquire new semantics under version two. A version field, a distinct receipt namespace or a carefully controlled migration lets the destination know which logic governs the message.

The same consideration applies to asset identifiers. A receipt should never rely on a ticker alone. “ONE,” “USDC” or “ETH” is not sufficient context for an interoperable accounting instruction. The destination needs to know which source asset, which issuer or canonical contract, which route and which representation are being credited. Otherwise, a valid proof may authorize the wrong asset accounting.

Where a Merkle proof stops

Merkle proofs are powerful because they efficiently authenticate membership in a large data set. A source block may contain thousands of receipts, and a recipient need not download every one to establish that a particular receipt was included. The source block’s root commits to all leaves. A short path of hashes connects the receipt to that root.

That is a proof about source history. It says nothing about destination history.

For a source receipt R, a destination verifier needs two distinct facts:

Source fact: R is included in a sufficiently final source commitment.
Destination fact: R is not recorded as consumed in the current destination state.

The first fact is usually proven cryptographically. The second is checked against live state and then changed by the transaction itself.

That distinction explains why an attacker does not necessarily need to break signatures, compromise validators or forge a hash. If the protocol will accept a genuine receipt again and again, the attacker’s ideal input is a valid receipt. The proof is not counterfeit. The accounting rule is incomplete.

A useful analogy is a concert ticket. A venue worker can verify that a ticket was issued by the organizer. That is authenticity. The scanner must also record that the ticket has entered the venue. That is uniqueness. If the scanner merely verifies the barcode and never logs a redemption, the same genuine ticket can admit an unlimited number of people.

Cross-shard systems must be stricter than physical venues because the attacker can automate submissions at machine speed, route proceeds through pools and bridges, and distribute assets across addresses before operators can respond.

The Block reported that one Harmony wallet moved nearly 2.4 trillion forged ONE in less than two minutes, and that much of the forged supply passed through decentralized exchange pools and bridges. That speed explains why a technical flaw in message handling can quickly become a systemwide recovery problem.

Exactly once requires atomic execution

The consumed-message registry needs more than a mapping. It needs carefully defined transaction semantics.

The ideal destination operation is:

1. Decode the receipt in canonical form.
2. Verify its source origin and finality.
3. Verify the intended destination and application.
4. Derive or read the canonical receipt identifier.
5. Check that the identifier is unused.
6. Mark it consumed.
7. Apply the destination effect.
8. Commit all state changes or revert all of them together.

Steps 5 through 8 must be atomic. If a transaction fails after marking the receipt consumed, the protocol needs to decide whether the mark reverts with the transaction. In most smart contract systems, that is the desirable result. The receipt remains usable because no destination effect occurred.

If a transfer calls an external recipient contract, the protocol must also be wary of reentrancy. A recipient should not be able to call back into the bridge or receipt handler before the consumed flag is set. The typical defensive order is checks, effects, then interactions. Verify first, write the consumed state second, then conduct any external call or asset transfer.

There is a subtle economic question too: who pays for failed relays? If a relayer submits an invalid proof or a duplicate receipt, it should lose only the transaction fee, not cause shared protocol state to mutate. If the protocol has a special compensation mechanism, that mechanism must be just as replay-resistant as the original action.

Some designs use sequential nonces rather than individual receipt IDs. For example, a source channel may send messages numbered 1, 2, 3 and so on, while the destination stores the largest accepted sequence number. This can be efficient, but it introduces ordering assumptions. If message 4 arrives before message 3, can the destination process it? If it cannot, a delayed or censored message can block the channel. If it can, the destination may need a bitmap or sparse set of delivered nonces rather than a single counter.

Neither approach is universally superior.

• A per-message identifier permits out of order execution and simple duplicate rejection, but uses persistent storage for every consumed item.
• A strictly increasing nonce can compress state, but may require ordered delivery and creates liveness dependencies.
• A bitmap can allow limited out of order execution, but requires precise handling of windows, gaps and pruning.

The key is that the execution model and the replay-protection model must agree. A protocol cannot advertise asynchronous, unordered delivery while securing itself with a single “next expected nonce” counter that only works when messages arrive in sequence.

Finality is part of the receipt, not an afterthought

A destination may correctly reject replays and still make a bad credit if it acts on a source event that later disappears.

This is the finality problem. A receipt in a proposed source block, or even in a block that appears likely to win, is not necessarily permanent. If the source chain reorganizes, the original debit can vanish while the destination credit remains. The bridge or shard transfer has then created value from a source history that no longer exists.

The destination therefore needs a finality gate. Its form depends on the architecture:

• In a shared security system, the destination may verify a finality certificate signed or attested by the validator set.
• In a proof-based system, it may verify a succinct proof that the source state is final under the relevant consensus rules.
• In a trusted or federated bridge, it may rely on a designated signer set, accepting different trust assumptions.
• In an optimistic system, it may wait through a challenge period before allowing irreversible settlement.

The product tradeoff is direct. Faster acceptance improves user experience and capital efficiency. Stronger finality reduces the chance that a destination credits a source event that can be reverted. For high value transfers, many systems require slower, stronger confirmation paths. For lower value or highly liquid actions, some may use risk limits or liquidity providers that absorb settlement latency.

That does not eliminate replay protection. Finality and uniqueness solve different problems.

Finality asks whether the source debit is permanent. Replay protection asks whether the destination credit has happened already. A secure cross-domain protocol needs both.

Reorganizations also complicate receipt identifiers. If an ID is based on a source block hash and that block reorganizes, the protocol must ensure that a replacement receipt cannot be treated as a new authorization for the same economic debit. Conversely, if the ID omits source location and relies solely on payload fields, distinct legitimate transfers with identical payloads may collide.

The protocol needs an exact definition of event identity. A robust definition generally starts with the source event’s unique location, then binds its full semantic content.

Recovery turns an engineering bug into governance

The reason a rollback can become the least-bad option is not that rollbacks are painless. They are not. They discard transactions, disrupt users and test confidence in the network’s normal finality guarantees.

But when invalid supply spreads, every alternative requires choosing who absorbs losses.

The Block reported that Harmony evaluated burning the forged ONE, blacklisting wallets and migrating the token before selecting a rollback window. It also reported that Harmony said much of the supply could not be safely burned because it had already moved through exchange accounts, decentralized exchange pools and bridges.

A burn sounds clean only when the stolen assets are isolated. Once forged tokens are mixed into automated market maker pools, centralized exchange deposit balances, collateral positions or bridge reserves, a targeted burn can remove value from people who did not exploit the system. Blacklists have a similar problem. They may freeze an attacker, but they can also strand market makers, liquidity providers and downstream holders who received tainted assets without knowing their origin.

A migration can establish a fresh token supply, yet it introduces a different ledger reconstruction challenge. Which balances count? At what snapshot? How are deposits on exchanges reconciled? How are wrapped or bridged representations treated? Every boundary creates an exception, and exceptions invite disputes.

A rollback instead says that the invalid source state never becomes canonical. It is an attempt to preserve a single accounting rule at the chain level: transactions after a chosen point are removed for everyone, rather than selectively repaired wallet by wallet.

That is why recovery powers should be treated as part of protocol design, not merely a social fallback. A bridge or sharded network should document:

• who can pause receipt processing;
• whether validators can halt specific routes;
• whether a governance vote can change verification rules;
• whether a rollback is technically possible;
• what finality promise users receive before and after an emergency;
• how exchanges, liquidity providers and integrators will be notified;
• which state snapshots and audit trails support recovery decisions.

The presence of emergency powers is not automatically a flaw. Concealed or undefined emergency powers are much more dangerous. Builders and users need to know the governance boundary before it is tested.

A practical review checklist for builders

The Harmony incident provides a concise audit framework for any system that transfers value or authority across execution domains. A team evaluating a bridge, sharded chain or cross-rollup protocol should be able to answer every question below in writing.

The most revealing test is simple: take one valid receipt and submit it twice.

Then submit it through two different relayers at nearly the same time. Submit it before source finality. Submit it after a simulated source reorganization. Submit the same payload from another source shard. Submit a valid receipt to the wrong destination contract. Submit it again after a contract upgrade. Submit it inside a transaction designed to reenter the receipt handler.

If any case produces a second economic effect, the system does not have exactly-once delivery. It has an accounting liability.

The durable lesson for interoperable systems

Cross-shard messaging is becoming more important because modular blockchain architectures depend on it. As execution spreads across rollups, appchains, shards and specialized networks, users will increasingly expect assets and applications to move as naturally as data moves across the internet.

That expectation is valuable, but it changes the nature of the security perimeter. The relevant boundary is no longer only a smart contract or a validator set. It is the handoff between two independently evolving state machines.

The winning designs will not merely prove that a source event occurred. They will define a complete, testable lifecycle for that event:

• a real debit or authorization on the source;
• a uniquely identified receipt;
• a cryptographic commitment and inclusion proof;
• a finality condition appropriate to the value at risk;
• permissionless relay where useful;
• strict destination and application binding;
• durable, consensus-visible consumed state;
• atomic execution;
• explicit policies for reorgs, upgrades and emergencies.

That architecture is less glamorous than a new proof system or a faster relay network. Yet it is the layer that determines whether interoperability behaves like a reliable accounting system or a minting machine.

Harmony’s reported exploit made the distinction painfully visible. Authentic receipts are not enough. A protocol must also remember that it has already honored them.