The Zcash network has successfully completed the NU6.2 hard fork upgrade, re-enabling the Orchard shielded pool with a corrected zero-knowledge proof circuit after a critical vulnerability forced an emergency suspension earlier this week.
According to an announcement from the Zcash Foundation, NU6.2 activated at block height 3,364,600 on Mainnet at approximately 00:05 EDT on Wednesday, June 3. The upgrade closes a soundness vulnerability that, if exploited, could have allowed double-spending within Orchard — Zcash’s privacy-focused transaction pool that holds a substantial portion of the network’s shielded ZEC.
The successful activation marks only the second security-driven protocol upgrade in Zcash’s history since the network launched in 2016, and concludes a five-day emergency response that ran from initial disclosure on May 29 to full resolution on June 3.
What the Bug Could Have Done
The Zcash Foundation has now publicly disclosed the technical nature of the vulnerability that triggered the emergency response. The issue was a soundness bug in the implementation of the Orchard zero-knowledge proof circuit in the halo2_gadgets crate.
In zero-knowledge proof systems, “soundness” is the property that ensures only valid transactions and state transitions are accepted by the network. A soundness vulnerability means the system could be tricked into accepting something it should have rejected. In this case, the bug could have allowed the Orchard pool to accept invalid state transitions — which the Foundation says could potentially have enabled double-spending of funds within Orchard.
Critically, the Foundation emphasized that the vulnerability could not have been used to inflate the total ZEC supply. Zcash’s turnstile mechanism, which tracks the total ZEC balance across all value pools (Sprout, Sapling, Orchard, transparent, and lockbox), enforces invariants on how value can flow between them. That mechanism provided what the Foundation called “a ground truth that ecosystem participants could use to confirm the supply cap remained intact, even while the Orchard circuit fix was being developed.”
The vulnerability was caught before any known exploitation occurred. There is no evidence of unauthorized value creation, and user privacy was not affected throughout the incident. Sapling and transparent transactions continued operating normally.
The Five-Day Response Timeline
The response began on Friday, May 29, when independent security researcher Taylor Hornby — conducting an ongoing protocol audit on behalf of Shielded Labs — discovered the vulnerability and responsibly disclosed it to ZODL core engineers that evening.
Within hours, ZODL engineers Daira-Emma Hopwood, Kris Nuttycombe, and Jack Grigg confirmed the issue and began evaluating remediation options. Private coordination with miners and exchanges began the evening of Sunday, May 31, while details of the flaw were kept private to minimize the risk of exploitation before a fix could be deployed.
A first soft-fork activation attempt encountered coordination challenges during patch deployment. ZODL engineers responded by producing a second patch targeting block height 3,363,426, which successfully activated at approximately 02:00 UTC on June 2. This soft fork — implemented through Zebra 4.5.3 — temporarily rejected all Orchard-containing transactions and blocks while the proper circuit fix was being finalized.
The Foundation explained the indirect approach: “A direct patch would have revealed too much about the nature of the flaw to anyone with access to the updated code. Disabling Orchard as a first step limited the disclosure of vulnerability details while the circuit fix was finalized.”
Initial estimates suggested Orchard could be re-enabled by 14:00 EDT on June 2, but the actual NU6.2 hard fork activation occurred approximately 10 hours later than initially anticipated, at 00:05 EDT on June 3.
Why a Hard Fork Was Required
The choice between a soft fork and a hard fork was not arbitrary. NU6.2 required a hard fork because remediating a zero-knowledge proof circuit bug involves updating the pinned verifying key — a change that cannot be made through a node software patch alone.
Zebra 5.0.0 implements the NU6.2 upgrade and routes Orchard proofs to a per-circuit verifying key (InsecurePreNu6_2 and FixedPostNu6_2), permanently closing the vulnerability that the 4.5.3 soft fork temporarily mitigated. The Foundation has strongly urged all node operators to upgrade to Zebra 5.0.0, warning that nodes that did not upgrade before the mainnet activation height will need to either sync from scratch or restore from a backed-up state taken before the activation height.
The vulnerability affected a wide range of versions: all versions of halo2_gadgets prior to v0.5.0, all versions of orchard prior to v0.14.0, all versions of zcash_primitives prior to v0.28.0, zcashd v5.0.0 through v6.12.3, and zebrad versions below v4.5.1.
The Coordinated Response Model
The Foundation framed the incident as a demonstration of the security model that has evolved around Zcash since launch. “This upgrade succeeded because the necessary pieces were already in place: ongoing security review by independent researchers, established responsible disclosure procedures, experienced protocol engineers, and a network of independent participants who acted quickly when required.”
The response required voluntary cooperation from miners, node operators, infrastructure operators, exchanges, wallet providers, and other network participants — all acting independently around the shared goal of protecting users and preserving network integrity. Cake Wallet, which had only added shielded Zcash support in January 2026 with Orchard transactions enabled by default, was among the wallet providers affected; ZEC functionality within Cake Wallet was temporarily frozen during the upgrade window.
“Unlike contentious forks sometimes seen across the industry, this was a security response,” the Foundation wrote. “The issue was discovered, responsibly disclosed, confirmed, remediated, and resolved in a few days.”
The Foundation specifically thanked Hornby for the disclosure, Shielded Labs for supporting the independent security research, and ZODL engineers Hopwood, Nuttycombe, and Grigg for their remediation work. Arya Solhi of the Zcash Foundation was credited with developing the Zebra patches that enabled the network upgrade.
A Sensitive Moment for Zcash
The NU6.2 activation arrives during a particularly significant stretch for the Zcash ecosystem. The privacy coin has been one of the standout performers of 2026, with ZEC having rallied over 1,200% since its 2024 lows on the back of post-quantum security roadmaps, the closure of an SEC investigation, and Grayscale’s filing to convert its existing Zcash Trust into a U.S.-listed spot ETF — the first such filing for any privacy-focused cryptocurrency.
The Orchard pool itself, introduced with the NU5 network upgrade in May 2022, has grown rapidly to hold over 4.5 million ZEC. It is built on the Halo 2 proving system and was the first Zcash pool to eliminate the trusted setup requirement that had long been a criticism of the network’s older Sprout and Sapling pools. The Foundation described Orchard as “the centerpiece of Zcash’s privacy architecture.”
The successful NU6.2 activation now closes a significant security exposure in that infrastructure without any user funds lost, any privacy compromised, or any inflation of the ZEC supply. For an ecosystem positioning itself as a serious institutional privacy primitive—backed by an active ETF application, a post-quantum roadmap, and a recent treasury position of $36.69 million held by the Zcash Foundation—the demonstrated ability to respond to a critical bug within five days without exploitation is itself a meaningful signal.
The next major protocol milestone for Zcash remains the FCMP++ upgrade, which focuses on transaction throughput and privacy composability. With NU6.2 now in place, that roadmap can continue forward.
Also Read: Zcash Block Halt Rumor Debunked After Faulty Node Confusion
