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.
