Zcash work in one place: the pinned primary texts behind the shielded-payment rules (the protocol specification and the ZIPs), the in-tree pages that already cover Zcash topics, and the verify-only browser surfaces as they land. Protocol features are described here, not promoted. Every computation the estate ships is deterministic, client-side, and runs on data the reader pastes; nothing is submitted, stored, or checked against the live chain.
Every card points at a page on the site today. Nothing here is a summary of another page's argument; each link goes to the page that carries it.
How a hash-linked record graph and a chain solve the same problems differently: succinct proofs, trusted setup, and independent verification, with Ethereum and Zcash as the worked comparisons.
Open the explainer →One key across many holders: FROST signing under RFC 9591 and distributed key generation, including the Zcash Foundation construction.
Open the explainer →How a claimed verification is graded, what each rung of the ladder proves, and where judgment still comes in.
Open the explainer →The sibling-chain hub: standards, account abstraction, and payment workflows, with the same verify-only discipline.
Open the hub →The hub for the EU's Markets in Crypto-Assets Regulation; the regulatory classification leg of the Zcash surface reads its requirements from primary texts and points here.
Open the hub →The tool surfaces for this hub land one node at a time and are linked from this page once they are live in the catalog: fee arithmetic per ZIP 317, unified address decoding per ZIP 316, a shielded-supply recomputation over pasted pool balances, and a regulatory treatment classifier tied to the MiCA hub. Until a surface is live, this page carries the texts and the in-tree pages only.
Last reviewed: November 2026 · guides · Zcash Hub · v1.0
Context lines on this page come from the pinned texts below, paraphrased rather than quoted. The page makes no claim about what any wallet, node, or exchange accepts at a given time, and nothing on it is financial advice.
The shielded pools carry transaction details in zero-knowledge proofs rather than in the clear. Sprout and Sapling use the Groth16 proving system, whose circuit parameters are a structured reference string with hidden structure: a holder of that structure could create fake proofs and counterfeit funds. The parameters are generated by multiparty computation, where the hidden structure stays unrecoverable as long as at least one participant was not compromised; the ZIP's own rationale records that generating these parameters remains a point of risk in the protocol, and that an earlier proving system's flaw was resolved only by changing systems and rerunning the ceremony.
Source: ZIP 224, Motivation
Orchard, the newer shielded pool, changes both the curves and the proving system: the Pallas and Vesta cycle replaces BLS12-381 and its embedded curve Jubjub (Pallas carries the application, Vesta the circuit), and the Halo 2 proving system with PLONKish arithmetization replaces Groth16 and R1CS. The stated motivation is a proving system that supports recursion and needs no structured reference string.
Source: ZIP 224, Curves and Proving system
The chain's value pools (transparent, Sprout, Sapling, Orchard, and the lockbox) are tracked as explicit balances, and the specification makes a negative pool balance an invalid-block condition. That is the arithmetic the planned supply surface recomputes: published pool balances pasted by the reader, checked for internal consistency, with no chain query of any kind.
Source: Zcash Protocol Specification, Chain Value Pool Balances
Every rule a Zcash surface here implements is read from one of these texts. They are the only external documents this page links out to.
The normative protocol text: the Sapling and Orchard sections, the Groth16 statements, and the chain value pool balances the supply arithmetic reads.
Open the text →Hierarchical deterministic key derivation for the shielded pools, Sapling and Orchard.
Open the text →The Orchard upgrade: the Pallas and Vesta curves and the Halo 2 proving system, with the trusted-setup rationale.
Open the text →The Orchard transaction format: value balances and the action structure.
Open the text →Unified addresses and viewing keys, including the F4Jumble encoding.
Open the text →The conventional fee rule: marginal fee, grace actions, and logical actions per declared transaction shape.
Open the text →Pinned 2026-11-03: each text above was snapshotted verbatim at retrieval with its SHA-256 recorded; the links are the rendered public forms of those snapshots. Statements on this page are paraphrases of the pinned texts, not quotations.
Readers checking what a shielded-payment claim does and does not assert, and which published rule each computation follows.
Implementers of fee, address, and supply arithmetic who need the pinned text and its parameters rather than a summary.
Readers tracing where each verification guarantee is graded across the estate's explainers and pages.
Part of the web3 hub family: the full directory lives at web3-hub.html.