I’m launching a structured sub-series of Zcash Engineering Office Hours: a guided reading of the full Zcash Protocol Specification PDF.
The goal is for it to be a study group, not a lecture. Each session covers specific spec sections, with space to unpack the implications, dig into history, and take questions. Accessible enough for a motivated newcomer, but technical enough to be useful to people who are actually building.
Session 1: What Problem Does Zcash Actually Solve?
Tuesday, April 21 @ 11:00 AM EDT
Co-host: @shielded-nate (Nate Wilcox)
Spec: §1.1 Caution + §1.2 High-level Overview (p. 8–9)
The first 30 mins will be a guided read of the spec text: Notes, nullifiers, chain value pools, the traceability set argument.
The second 30 mins: open conversation with Nate on what these sections mean in practice, how the design decisions have held up across four protocol eras, and what questions are still worth asking.
Session 2 of the Zcash Protocol Study, a 12-session guided reading of the Zcash Protocol Specification.
Topic: §3.1 - Payment Addresses and Keys. The “privacy onion.”
A single spending authority in Zcash decomposes into a tree of derived keys: full viewing key, incoming viewing key, outgoing viewing key, diversifier. Each key revealing a different slice of metadata to a different audience. §3.1 is where this is all defined, and nothing downstream in the spec makes sense without it.
We’ll walk Sapling and Orchard side by side: what Orchard cleaned up, where the proof system forced cleaner separation between IVK and OVK, and why “many addresses, one viewing key” is the design that makes diversified addresses work.
Format: 50/50 structured study and open conversation with space to riff on implications, history, and connections. Think of it like a study group instead of a lecture. We aim to be accessible enough for a motivated newcomer and technical enough to be useful to people who are actually building.
Session 2 (Addresses, Keys, and the Privacy Onion) is complete, and we’re back on schedule. Thanks to everyone who showed up live and to @ZcashBrazil for the recording.
Next up: Notes, Commitments, and Nullifiers (spec §3.2, §3.8, §3.9)
Session 3 covers the lifecycle of how a note is born (commitment), recorded (Merkle path), and spent (nullifier).
When: Tuesday May 19, 11 AM ET
Note that this breaks our typical two-week cadence to recover the original biweekly calendar. We will resume biweekly after this session.
Just a quick update: Trying to get through three foundational sections of the protocol was perhaps a bit too ambitious, so we will do Part 2 of Notes, Commitments, and Nullifiers in 2 weeks on June 2
We now have the note primitives: a commitment goes into a tree, a nullifier is revealed on spend, a zk-SNARK proves the link. Session 4 threads them into the thing that actually moves value, the transaction, and follows how the shape of a shielded transfer changed across three eras of Zcash.
The whole session hangs on one question asked three times: how does a transfer prove it created exactly as much value as it destroyed?
Sprout answers it inside one bundled JoinSplit.
Sapling splits the transfer apart and answers across the whole transaction.
Session 4 (Transactions Unpacked: JoinSplit to Actions) is in the can. Thanks to everyone who joined live and to @ZcashBrazil for the recording.
Session 5 is Tuesday, June 30, 11 AM ET.
Topic: Merkle Trees and How the Chain Remembers (spec §3.8 Note Commitment Trees, §4.9 Merkle Path Validity).
Session 4 kept leaning on one word: the anchor, the Merkle root a shielded spend proves its note sits under. Session 5 opens that root up. A single ~32-byte root stands in for every shielded note that has ever existed. We read how a commitment becomes a leaf, how the tree hashes up to that root, and how a Merkle path proves your note is in there without revealing which one. Plus why the tree hash changed three times: SHA-256 (Sprout), Pedersen (Sapling), Sinsemilla (Orchard).
Live on the Zcash Discord stage. Recorded by @ZcashBrazil.
Update: Jet lagged and a little unwell after the Prague summit. Didn’t party hard, just fell under the weather. Great trip otherwise. I want to push back the scheduled session for this week one more week.
Session 6 (Proving Without Revealing: zk-SNARKs in Zcash) is over, and I gotta say: the audience discussion was the best of the series so far. Thanks to everyone who joined live and to @ZcashBrazil for the recording.
Announcing Session 7: Sending, Receiving, and Scanning
Session 6 explained what a shielded transaction convinces the chain of without revealing anything. Session 7 is the wallet’s-eye view of the same transaction. How does a note actually get built and sent? How does the recipient, whom nobody notified, ever find it?
Protocol sections:
§4.7 Sending Notes
§4.8 Dummy Notes
§4.19-4.20 In-band Secret Distribution
§4.21-4.22 Block Chain Scanning
Live on the Zcash Discord stage. Recorded by @ZcashBrazil.
