The Zcash Orchard bug — and why view-key payment monitoring keeps working

Published 2026-06-05 · by the Seneschal operator · ~5 min read

TL;DR. On 2026-06-05 Zcash disclosed and emergency-fixed a critical soundness bug in the Orchard shielded pool that could, in principle, have minted counterfeit ZEC. It was a supply bug, not a privacy bug: nobody’s view key leaked and shielded transactions stayed private. If you run a node, upgrade to Zebra 5.0.0 (NU6.2). If you accept ZEC and watch payments with a read-only view key — the way Seneschal Private Watch does — your detection pipeline is unaffected; keep waiting for confirmations and you’re fine.

What actually happened

Zcash’s newest shielded pool, Orchard, proves transaction validity with a zero-knowledge circuit (Halo 2). On 29 May 2026, security researcher Taylor Hornby — working on an audit for Shielded Labs, and notably with the help of an AI model — found that the verifier would accept Orchard proofs of a non-canonical size. That gap (tracked as advisory GHSA-jfw5-j458-pfv6) was enough to forge a valid-looking proof and, in a local test, generate unlimited, undetectable counterfeit ZEC inside the pool. The flaw had been latent since Orchard activated in 2022.

The response was a rare two-step emergency upgrade:

The Zcash Foundation reported no evidence of exploitation and no impact on user privacy, though it’s candid that — by the very nature of a shielded pool — counterfeiting can’t be cryptographically ruled out after the fact. Sources: Zcash Foundation, Cointelegraph, The Block.

If you run a Zcash node: upgrade and verify

Make sure you’re on the fixed software and following the post-fork chain — otherwise you’re stranded on a dead pre-NU6.2 fork:

Our own nodes. Seneschal’s Zcash node was upgraded to Zebra 5.0.0 around the activation and is following the canonical chain (NU6.2 active, tip in sync), so Private Watch’s Zcash detection has been running against the corrected network throughout.

Why view-key payment monitoring is unaffected

This is the part that matters if you accept privacy-coin payments. Private Watch detects incoming payments using your read-only view key (a Zcash Unified Full Viewing Key, or a Monero secret view key). Two reasons the Orchard bug doesn’t touch that:

In other words: the mechanism Private Watch sells — “hold a read-only key, get a signed webhook when money lands, never touch a spend key” — sat behind the same confirmation discipline that protects you here. Nothing about it needed to change.

The bigger pattern — and Monero

The Orchard bug belongs to a recurring privacy-coin failure mode: a verifier accepting a non-canonical encoding. Monero uses different cryptography (RingCT: CLSAG ring signatures + Bulletproofs+ range proofs, not Halo 2), so this exact bug can’t exist there — but the class absolutely has precedent:

The lesson for anyone receiving privacy-coin payments is the same regardless of chain: run patched nodes, and don’t consider a payment final until it has the confirmations you require.

How Seneschal Private Watch fits

Private Watch is a payment-webhook service for Monero and Zcash. You give us a receiving address and its read-only view key; we watch the chain on our own full nodes and POST you a signed (HMAC-SHA256) webhook when a payment lands and clears your confirmation threshold. No spend key ever leaves your hands, and you don’t have to run a node.