Nomad Bridge Exploit

Summary

Nomad was a cross-chain messaging protocol built by Illusory Systems (co-founded by Pranay Mohan and James Prestwich) that used an "optimistic" security model: messages passed between chains were assumed valid unless challenged within a fraud window. It raised roughly $22.4M in a seed round announced April 2022, backed by Polychain, 1kx, Circle Ventures, and others, and marketed itself as a more secure alternative to trusted multisig bridges.

On August 1, 2022, Nomad's token bridge was drained of roughly $190M across Ethereum, Moonbeam, Avalanche, Evmos, Gnosis Chain, and MilkomedaC1. The cause was not a sophisticated cryptographic break but a single input-validation error introduced during a routine contract upgrade. Once one attacker demonstrated the exploit, the transaction was trivially copyable, and hundreds of ordinary wallets began replaying it by simply substituting their own address into the calldata. It became widely described as the first mass, "crowdsourced" hack in DeFi history.

Design (Mechanism)

Nomad relied on a Replica contract on each destination chain that verified incoming cross-chain messages against committed Merkle roots. Messages moved through two steps: prove (checking a Merkle proof of the message against a trusted root) and process (executing the proven message, e.g., releasing bridged tokens). A message was only supposed to be processed if its proof resolved to a root the contract recognized as "acceptable" via an acceptableRoot check backed by a confirmAt mapping of trusted roots and their confirmation timestamps.

The optimistic design meant off-chain "Updaters" attested to roots and "Watchers" could challenge fraudulent ones during a fraud window. In principle this reduced trust assumptions relative to a signing multisig. In practice, the security of the entire system hinged on Replica correctly rejecting any message whose proof did not resolve to a genuinely committed root.

Outcome

• Roughly $190M drained on August 1, 2022 (some reporting cites ~$186M).
• The attack was permissionless and copy-pasteable: after the first exploit transaction, more than 300 addresses replayed it, many being opportunistic bystanders rather than the original attacker.
• Nomad posted an official acknowledgement, unenrolled the Replica contracts to halt message processing, and on August 3, 2022 published a fund-recovery address (0x94A84433101A10aEda762968f6995c574D1bF154) with an up-to-10% white-hat bounty, promising no legal action for those returning at least 90%.
• More than 40 addresses returned over $36M to the recovery wallet, but the large majority of funds were never recovered.
• Nomad attempted a bridge relaunch in December 2022, but the protocol never regained meaningful traction and is effectively defunct.
• In 2025, Alexander Gurevich, a Russian-Israeli dual national, was extradited to the United States and charged (wire fraud, conspiracy, money laundering) in connection with the exploit; as of this writing he has been charged but not convicted.

Why it worked

The exploit "worked" — for the attackers — because the failure mode was maximally accessible. A June 21, 2022 upgrade initialized the trusted-root value to 0x00 (bytes32(0)). Because EVM storage returns 0x00 for any uninitialized slot, and Solidity mappings return 0x00 for absent keys, any forged message whose Merkle proof resolved to the zero value was treated as proven. The acceptableRoot check returned true for 0x00, so process() would execute essentially arbitrary messages, releasing tokens to whoever called it. No cryptography needed breaking; attackers copied a working transaction, swapped in their address and desired amount, and resubmitted.

Where the design broke

The upgrade that introduced the zero-root as "acceptable" defeated the very verification the optimistic model depended on. The bug survived despite a Quantstamp audit completed in early June 2022; the interaction between the initialization value and Solidity's default-zero storage semantics was not caught. Because the flaw was in the message-proving path rather than in signer keys, the optimistic fraud window offered no protection — Watchers had no fraudulent root to challenge, since messages bypassed the root check entirely. The low barrier to replay transformed a single incident into a multi-hundred-wallet drain, making both mitigation and later fund recovery far harder.

Lessons

• Initialization values are security-critical: setting a sentinel/default (0x00) as a trusted value collides with EVM/Solidity default-zero semantics and can silently authorize everything.
• Optimistic and fraud-proof systems only add safety when the underlying validity check is sound; a broken verification path makes the challenge window irrelevant.
• Audits are necessary but not sufficient — a clean audit report (here, Quantstamp) does not guarantee that later upgrades preserve invariants; upgrade diffs deserve the same scrutiny as initial deployments.
• Cheaply replayable exploits create "crowdsourced" drains where copycats amplify damage and complicate attribution, recovery, and legal response.
• White-hat bounties and recovery addresses can claw back some funds, but partial recovery (here ~$36M of ~$190M) shows they are a weak backstop compared to preventing the bug.

Redesign (EDITORIAL — hypothesis, not fact)

The following is analysis, not established fact. A safer design would never allow 0x00 (or any default-zero value) to be a valid root: acceptableRoot should explicitly reject the zero value and require a positive, nonzero confirmation timestamp before treating a root as trusted. Upgrade routines should assert post-conditions (e.g., "no acceptable root equals zero") in the same transaction, ideally enforced by invariant tests and formal specification of the proving path. A defense-in-depth layer — per-message and per-epoch value caps, rate limiting on process(), and an automated circuit breaker that halts the bridge on anomalous outflow — could have contained the loss even given the bug, buying time for Watchers or the team to intervene before hundreds of wallets replayed the exploit. Finally, making upgrades subject to a timelock plus mandatory re-audit of the changed proving logic would reduce the chance that a single routine deployment silently disables the system's core security check.