Skip to content
Blockchain Posts

protocol

Zcash patches Orchard soundness bug with NU6.2 emergency hard fork

An under-constrained Orchard circuit could have minted undetectable counterfeit ZEC. Zcash froze the pool with a June 2 soft fork, then re-enabled it via NU6.2 the next day.

by 5 min read
protocolzcashsecurityinfrastructure

Zcash core developers patched a critical soundness bug in the Orchard zero-knowledge proof circuit through a two-stage coordinated upgrade this week — first an emergency soft fork that disabled all Orchard transactions at block 3,363,426 on June 2, 2026, then a hard fork called NU6.2 that re-enabled the shielded pool with corrected proving and verification keys at block 3,364,600 on June 3. The flaw, found in a private audit and never observed in the wild, could in principle have let an attacker mint ZEC out of nothing inside the shielded pool — where, by the protocol's privacy design, the counterfeit coins would have been indistinguishable from legitimate ones. The releases are public: zcash v6.12.5 shipped the soft fork on June 2, and zcash v6.20.0 shipped NU6.2 on June 3.

What happened

Taylor Hornby, an independent security researcher running a paid audit for Shielded Labs, identified the bug on May 29 and disclosed it the same evening to engineers at the Zcash Open Development Lab (ZODL), the Electric Coin Company (ECC) and the Zcash Foundation. Hornby has confirmed publicly that he used an AI-assisted auditing framework to surface the flaw — the first publicly acknowledged consensus-critical bug in a major chain attributable to a machine-driven audit.

Core engineers spent May 30 to June 1 building two patches in private under coordinated-disclosure discipline: a minimal soft fork to neutralize the exposure immediately, and a corrected circuit shipped in a hard fork. Miners and exchanges were briefed before public disclosure. The Zcash Foundation's Zebra node was rebuilt in parallel and shipped as Zebra 4.5.3 and 5.0.0.

Mechanism — a soundness gap in the proving circuit

Orchard is Zcash's current-generation shielded pool, built on the Halo 2 proving system. Transactions inside Orchard reveal nothing about sender, recipient or amount; the network relies entirely on a zero-knowledge proof to assert that no value is created and nothing is double-spent. The proof is only safe if the proving circuit is sound — meaning that no invalid witness can produce a verifying proof.

The disclosed bug was an under-constrained section of the Orchard circuit handling an elliptic-curve check. Per the public disclosure, an attacker could have supplied false inputs that nevertheless passed the check, producing a valid-looking proof for a transaction whose value balance was wrong. Because amounts inside Orchard are encrypted, the resulting fake mint would not have shown up as an out-of-place balance anywhere a node could check.

The patch in NU6.2 replaces the affected constraints and bumps the Orchard circuit's verification key. Any historical proofs that exploited the bug — if any exist — would not verify under the new key, but the privacy design means nobody can prove from chain data alone whether the bug was ever exploited.

Impact

  • Total ZEC supply is not directly observable inside Orchard. Shielded Labs and the Zcash Foundation have stated they believe the probability of prior exploitation is low because the flaw required specialized knowledge of the circuit internals, but neither organization can offer cryptographic proof that supply is intact.
  • Exchanges and custodians paused ZEC deposits and withdrawals between the soft fork and the NU6.2 activation to avoid processing in-flight Orchard transactions that would either be rejected by the soft fork or rendered invalid by the new circuit.
  • Sapling-pool transactions were unaffected. Sapling uses a separate (older) circuit. Transparent (t-addr) transactions were also unaffected.
  • Node operators on zcashd ≤ 6.12.4 and zebrad < 4.5.3 lose consensus with the rest of the network at the NU6.2 activation height if they do not upgrade.

What to watch

  1. Shielded Labs' proposed supply-proof upgrade. Shielded Labs has floated a follow-on Zcash upgrade that would let the network prove total ZEC supply by tracking the value entering and leaving each shielded pool over time. The proposal is now governance-bound and has not been scheduled.
  2. A formal write-up of the circuit defect. Hornby and ECC have committed to publishing a technical post-mortem once the upgrade has settled — including the specific constraint that was missing, the audit methodology, and the test vectors used to confirm the fix. As of publication, neither the post-mortem nor a CVE has been issued.
  3. Independent re-audits. A soundness bug surviving multiple rounds of cryptography review is the kind of finding that triggers re-audits of adjacent circuits — including the upcoming "Crosslink" hybrid PoS work and any Halo-2-based circuits used outside Zcash.

Context — a second consensus-critical Zcash disclosure in nine days

This is the second consensus-critical patch on Zcash inside a fortnight. On May 29 the Zcash Foundation shipped Zebra 4.5.0 and a 4.5.1 hotfix, closing a P2SH sigop-counting mismatch that could have split the chain between Zebra and zcashd nodes. That batch was discovered through traditional code review and a long-standing vulnerability-disclosure pipeline; this one was discovered by a research team running an AI agent against a circuit specification.

For ZK-based protocols generally, the NU6.2 episode is a forcing function. Soundness bugs in production proving circuits are rare in public discourse but not unheard of — Aztec and Polygon have each published similar near-misses in prior years. The novelty here is the disclosure path: a paid third-party auditor, working with a machine-driven test framework, finding a soundness bug in a live circuit and the affected team coordinating a privacy-preserving fix within five days of receiving the report. The pattern is unlikely to be the last one.

Sources:

Related stories