The full account of how Zcash patched a critical Orchard pool vulnerability in 50 hours has been published by Josh Swihart, an executive at ZODL (Zcash Open Development Lab), in a post titled “Subduing the World. Zcash Update.”
The post fills in operational details that were not visible in the technical disclosures previously released by the Zcash Foundation. The response was successful — no exploit occurred, no funds were lost, and Orchard transactions resumed normally after NU6.2 activated on June 3. But Swihart’s account reveals that several moments during the response could have gone differently.
The Signal Call
The response began at exactly 10 a.m. Eastern Time on Saturday, May 30, when Swihart received a Signal call from Daira-Emma Hopwood, the head of ZODL protocol R&D.
“At exactly 10 am Eastern Time last Saturday, I received a Signal call from Daira-Emma, the head of ZODL protocol R&D,” Swihart wrote. “An issue had been discovered, and I would need to be read in.”
Fifteen minutes later, after moving to a secure location, Swihart joined a video call with Daira-Emma Hopwood, Kris Nuttycombe, and Str4d (the alias of another ZODL engineer). The four-person group reviewed what would become “the remediation of the Orchard vulnerability and the rapid coordination of the most consequential network upgrade in Zcash history.”
Independent security researcher Taylor Hornby had disclosed the vulnerability — a soundness bug in the Orchard zero-knowledge proof circuit that could have enabled double-spending within the pool — to a small subset of cryptographically skilled engineers the previous day. By the time Swihart received the Saturday morning call, the fix was already in place.
A Deliberate Two-Step Strategy
The decision to deploy an emergency soft fork before the eventual NU6.2 hard fork was strategic, not improvised.
“The plan was to use a two-step process to first coordinate a soft fork to exclude Orchard transactions from blocks,” Swihart wrote. “This fork immediately mitigated the risk of an exploit without revealing the full scope of the issue before responsible disclosure. Immediately following the soft fork, we would again coordinate a hard fork to remedy the underlying issue and re-enable Orchard transactions.”
The logic was specific: a direct patch to the Orchard circuit would have revealed too much about the nature of the vulnerability to anyone with access to the updated code. The soft fork, which simply rejected Orchard transactions outright, mitigated exploit risk without telegraphing exactly what was being fixed. The hard fork — implementing the actual circuit correction via NU6.2 — could then follow once the disclosure window was safely closed.
The four-person group set timelines designed to minimize disruption, targeting a soft fork activation on Monday evening US time so that most network users would wake up on Tuesday morning with the issue resolved. “It didn’t quite work out that way,” Swihart wrote, “but it was pretty close.”
The 25-Block Reorganization
The most tense moment of the response came in the early morning hours of June 2.
The soft fork had been scheduled for 8:00 p.m. Eastern Time on Monday, June 1, but the two-hour window between code distribution and activation proved too short. Mining pools were working directly with ZODL in real time, but the deployment ran longer than expected.
“It wasn’t until after 2:00 a.m. Eastern Time, and some anxiety on my part during a 25-block reorg, on the morning of the 2nd, that we confirmed the soft fork was the winning chain,” Swihart wrote.
A 25-block reorganization is a significant event on any proof-of-work chain. It means that 25 blocks of one version of the network’s history were replaced by an alternative chain considered more authoritative. For a coordinated emergency soft fork, a long reorg creates real uncertainty about whether the patched version of the network will become canonical. In Swihart’s account, the team did not have confidence the soft fork had succeeded until the reorg resolved in their favor.
Once confirmation came, ZODL immediately posted the public announcement that the soft fork was live and Orchard transactions had been temporarily disabled.
Mining Pool Coordination — and Why It Worked
The success of the response depended heavily on coordination with mining pools that needed to apply the patch in time for the soft fork activation. According to Swihart, that coordination worked because of relationships he had built at industry events in the preceding weeks.
“Over the previous few weeks, I spent time with the heads of a couple of the mining pools at various events, which was fortuitous,” Swihart wrote. “The relationships were fresh.”
The point matters because mining pools did not simply trust the patch and deploy it. Despite the urgency, pools wanted to review the code and compile it themselves rather than running pre-built binaries from ZODL. That review process took multiple chat threads and, in some cases, video meetings to confirm that the ZODL team was who they claimed to be and that the disclosed vulnerability was as described.
“After long chat threads and, in some cases, video meetings to prove I wasn’t compromised, we believed we were ready for the soft fork on Monday at 8:00 p.m. Eastern Time, for the pools to apply the patch.”
Swihart specifically thanked two mining pools by name: ViaBTC and Foundry, “who coordinated with us around the clock during the upgrade.” For a protocol where mining decentralization is a core property, the willingness of major pools to drop other priorities and coordinate intensively for 50 hours straight was operationally critical.
The Hard Fork Window Was Too Short
Once the soft fork was confirmed at approximately 2:00 a.m. ET on Tuesday, June 2, the team coordinated the NU6.2 hard fork that would re-enable Orchard with the corrected circuit. The original two-hour window between code distribution and hard fork activation proved insufficient — even with mining pools working directly with ZODL in real time.
“We extended the hard fork window and followed up with node operators about what to expect,” Swihart wrote. “We subsequently agreed to extend it further at the request of one of the pools.”
The team rested in two-nap intervals as they prepared. The hard fork itself activated at 00:05 Eastern Time on June 3, approximately 24 hours after the soft fork. NU6.2 fully closed the vulnerability and resumed normal Orchard operations.
A human detail Swihart included that he got food poisoning during the hard fork window. “And in the middle, as fate would have it, I got food poisoning. Lovely.”
The Ironwood Acknowledgment
The most analytically interesting line in Swihart’s post is about the future, not the past.
“Yes, we are building a hardened protocol with a long-term view, but the solution to hardening and the subsequent proposal for a new shielded pool, Ironwood, were parochial.”
Swihart frames the entire episode through David Deutsch’s quote from a 2017 thread: “All problems are parochial; solutions can be universal — but rarely are. Rick found solutions and escaped, but all of them were parochial.” (The reference is to Rick and Morty’s pickle episode, which Swihart includes as a metaphor for technical problem-solving under constraint.)
Calling Ironwood — Zcash’s proposed next-generation shielded pool — a “parochial” solution rather than a universal one is a notable framing choice. For a ZODL executive to publicly characterize the upcoming pool design as another constrained solution, rather than as the final answer to Zcash’s privacy architecture, signals philosophical alignment with the Deutsch framing: every fix introduces its own future limitations. It also implicitly acknowledges that even Ironwood will require future hardening as the threat surface evolves.
This framing is consistent with the broader trajectory of Zcash’s protocol development. As TCT previously reported in coverage of Ripple’s post-quantum roadmap, the most mature blockchain protocols are increasingly framing security work as continuous rather than terminal. Swihart’s “parochial” characterization places Zcash in that same posture.
Operational Updates From the Same Post
Beyond the NU6.2 response, Swihart’s post also covered the weekly ZODL product updates.
ZodI (formerly Zashi):
- Coinholder Polling 3.5.0 went live on Android on Monday, completing the cross-platform launch of the first in-wallet shielded coinholder voting flow on a Zcash mobile wallet.
- A three-release Android stabilization wave (3.5.0, 3.5.2, 3.5.3) and a two-release iOS wave shipped within the single week. Updates include Auto and Manual server-selection redesign, keep-screen-on fix during ballot submission, and removal of decommissioning lightclient endpoints ahead of the June 7 cutoff.
- Default lightclient server moved to zec.rocks on both platforms after a 50-country benchmark of nearly 9,000 RPC calls.
- Memory Tagging on Android FOSS builds reached QA.
Zcash Core:
- Shipped the emergency NU6.2 network upgrade (zcashd v6.20.0) at mainnet block 3364600, remediating the privately disclosed Orchard circuit flaw in halo2_gadgets.
- Shipped a parallel time-critical zcashd v6.12.5 in coordination with the June 2 soft fork at block 3363426, fixing a coinbase value-balance desync that could node-crash on a single valid proof-of-work block and temporarily turning off Orchard actions until NU6.2 activated.
- Cleared the Zallet RPC review queue in a single Tuesday-evening pass.
- halo2_gadgets backports filed across the cryptography surface as part of the post NU6.2 cleanup arc.
What This Means for Zcash
The response is being treated within ZODL as a model for future emergency coordination, not just a one-time crisis. “We resolved the issue, battle-tested our incident support processes, built stronger relationships with others who support the network, tested our own resilience, and unified as a community of builders to agree on a path forward. Zcash is stronger than it has ever been,” Swihart wrote.
The framing matters strategically. Zcash is currently navigating a sensitive period: ZEC has rallied over 1,200% since its 2024 lows on the back of post-quantum security narratives and Grayscale’s pending ETF filing. The ability to demonstrate that a critical privacy infrastructure bug was caught, disclosed responsibly, and remediated within 50 hours — without any exploitation or fund loss — is the kind of operational signal that institutional allocators evaluating privacy coin exposure pay attention to.
For Swihart and ZODL, the post is both a public-facing transparency exercise and an internal recognition document — naming individuals (Hornby, Hopwood, Nuttycombe, Str4d, the Pacu and Pili teams, Aria, Peacemonger, Neal) and mining pools (ViaBTC, Foundry) whose work was previously invisible to the wider Zcash community.
The next public milestone for Zcash remains the FCMP++ upgrade and the Ironwood shielded pool proposal. With NU6.2 now in place and the operational response thoroughly documented, that roadmap can continue forward — with the team’s framing being that even the next-generation pool will, in time, require its own hardening response.
Also Read: Zcash vs. Monero: The 2026 Privacy Coin War Just Got Decided in One Week
