Build a working model of Zcash from the privacy goal and shared chain to private notes, wallet behavior, proofs, settlement, privacy boundaries, and future protocol work.
Interactive guide: Reader or Reading mode may omit diagrams, controls, and demonstrations. Open this page normally or exit Reader mode to use them.
A transparent chain lets everyone verify by exposing the transaction history. Its addresses are pseudonymous, not automatically anonymous: they omit names, but their public payment graph can be followed and may later be connected to real identities. Zcash keeps public verification and replaces the exposed facts with cryptographic evidence. The network can reject counterfeits and double-spends without receiving the sender, recipient, or shielded amount.
Plain language A public address does not show your name, but anyone can follow its payment history and may later connect that address to you. Zcash lets the network confirm that a payment is legitimate without publishing who paid whom or how much.
The comparison above asks what the ledger reveals after a payment is made. Before building that payment, the wallet must choose which Zcash transaction system to use. Transparent value and shielded value live in separate pools, and the recipient’s address tells the wallet which receiver types that destination accepts.
A pool is a protocol-defined way of representing and moving the same ZEC. Each pool has its own transaction format, receiver type, and on-chain data structures. It is not a separate coin, account, or wallet.
Move ZEC from the transparent pool into a shielded pool. The net value crossing the boundary is public; the new shielded note is private.
Move ZEC from a shielded pool into the transparent pool. The net value crossing the boundary becomes public along with the transparent destination.
Moving between two shielded pools—such as Orchard → Ironwood—is a shielded-pool migration, not shielding or deshielding.
Ironwood is now the destination for new Orchard-protocol shielded payments. It activated with NU6.3 at block 3,428,143 on July 28, 2026. Ironwood reuses Orchard’s receiver, paired Action structure, and Halo 2 proving system, but it is a separate pool with its own commitment tree, nullifier set, and value balance. It also launches with machine-checked supply assurance: more than 2,700 Lean theorems connect the deployed verifier, Action circuit, and ledger rules to a formal balance-integrity claim under named cryptographic assumptions.
Orchard balances were not moved automatically, do not expire, and remain under their owners’ control. But existing Orchard value must leave that pool—normally through a wallet-managed migration to Ironwood—before it can participate in ordinary cross-address shielded payments. No new value may enter Orchard, and cross-address transfers within it are disabled. The net amount crossing pools is public; senders, recipients, addresses, and note contents stay cryptographically hidden on-chain, although amount, timing, or network metadata can still create correlation risk.
The wallet compares the destination’s receiver types with the transaction systems it supports.
A single encoded address can contain multiple receiver options.
Private notes, commitments, nullifiers, ciphertexts, and validity proofs.
Individual note values and ownership links are hidden. Proofs enforce balance for each state transition.
Value crossing between transparent and shielded pools contributes to a public net-flow tally—the “turnstile”—while transfers within the shielded pool remain private.
Transactions propagate to nodes, wait in local mempools, and become settled history when miners include them in blocks. Each block points to the previous block. Its height is its position in the one agreed sequence; later blocks add confirmations and make reversal harder.
Plain language Zcash transactions wait to be added to a block. Miners put blocks in order, and each new block strengthens the record of the blocks before it.
height 3,500,004
Not yet included.
Wallets do not update a private “account balance” on-chain. They control discrete notes. Think of a shielded note as a private Bitcoin unspent transaction output (UTXO): a discrete chunk of value consumed whole and replaced by new notes for the recipient and change, but with its value and owner hidden on-chain rather than published. Your displayed balance is a wallet-side sum of the unspent notes it can decrypt.
Plain language A private Zcash balance is made of separate pieces called notes. A note works a little like a private Bitcoin UTXO: the wallet uses it whole and creates new notes for the recipient and change, while the public cannot see the notes’ amounts or owners.
Click notes until inputs cover 5 ZEC + a 0.001 ZEC illustrative fee.
Nothing is carved out of an old note. New private records replace it.
A note contains an address, value, and randomness. The chain records a binding commitment to those contents and an encrypted payload for the recipient—not the plaintext note. Alice encrypts that payload using the public receiving key in Bob’s shielded receiver. Bob later combines the incoming viewing key (IVK) introduced above with the transaction’s public ephemeral key to decrypt it. The commitment and encryption do different jobs. The next section opens that encrypted delivery to show where an optional memo fits.
Plain language The blockchain gets a locked fingerprint of each private note and an encrypted package that only the recipient’s wallet can open. The fingerprint proves the note has not changed; encryption hides what is inside it.
u1bob…4r9k5.00000000 ZEC7ab94c…e112cf29d1…0a7epk_d · 91ab42…7e03cmx. Change either one → a different
commitment, while the original private fields remain unrecoverable from the new fingerprint.
Press “Seal note” to derive an illustrative commitment and ciphertext.
pk_d · 91ab42…7e03
Alice uses this public key to derive a one-time shared secret and encrypt the note.
epk · waiting
These public bytes let the intended recipient derive the same secret—not an observer.
ivk_Bob · 84ac…991e
Bob combines this private key with the ephemeralKey to decrypt and recover the note.
After Alice creates Bob’s note, her wallet can place up to 512 bytes of text or application data in that output’s memo field. The memo is encrypted with the note, stored on-chain as ciphertext, and recovered when Bob’s wallet decrypts the output. It belongs to one shielded output—not to the transaction as a whole—and it does not change the note’s value, commitment, or tree position. Transparent outputs do not have this shielded memo field.
Plain language A shielded payment can include a private message or app data. It is encrypted for the recipient and stored with that one payment output, so the public blockchain cannot read it.
Nodes append note commitments in chain order and hash upward to a compact root. A wallet can prove one commitment belongs to that tree using only its Merkle path. The root used by a transaction is its anchor: a public fingerprint of a particular tree state, not an identifier for the hidden note.
Plain language Every new private note leaves a fingerprint in a shared tree. A wallet can later prove its note is somewhere in that tree without pointing out which entry belongs to it.
The same append-only tree sits below every block. Leaves are note commitments; each internal node hashes an ordered left/right pair in a level-specific domain. Empty regions use protocol-defined empty roots.
root · waiting
Click a block above to reconstruct the tree state at that height.
Choose “Show Merkle path” to highlight the minimum sibling data needed.
To spend a shielded note, its owner proves authorization and derives that note’s unique nullifier with a keyed pseudo-random function: secret nullifier key material plus note-specific data produces a deterministic, one-time-looking serial. It is not a raw public hash of the commitment. The spend publishes the nullifier, so accepting it marks the note as spent without removing—or publicly identifying—its commitment in the tree. Nodes reject any later transaction that publishes the same nullifier, while observers cannot reverse the nullifier to discover which commitment was spent. The chain exposes commitments when notes are created and nullifiers when notes are spent, but no public field joins a nullifier back to the earlier commitment it consumes.
Plain language When a private note is spent, Zcash publishes a unique “spent” marker. The network can reject the same note if someone tries to spend it again, but the marker does not reveal which private note was used. Creating the note and later spending it both leave public records; their connection stays private.
Zcash key material is a hierarchy of capabilities. A spending key authorizes value movement. Viewing keys are wallet secrets by default: they reveal selected transaction information but never authorize spending. An owner can voluntarily disclose a viewing key when they want another party to receive that key’s read-only access. Diversified addresses let one wallet receive at many unlinkable-looking destinations.
Plain language Different Zcash keys grant different powers. An address lets someone pay you, viewing keys let someone see limited wallet activity, and only the spending key can move your money.
Someone can pay this destination. It does not give them a view of your wallet.
| Capability | Allowed? |
|---|
Shielded outputs contain no searchable plaintext address. A wallet downloads compact chain data and attempts trial decryption with its incoming viewing key. Almost every attempt fails. A success reveals the private note, which the wallet verifies against the public commitment and records with its position for a future Merkle path. Full output decryption also recovers that output’s memo; a light wallet may first detect the compact note data and fetch the full transaction afterward.
Plain language Private payments do not show the recipient’s address, so a wallet checks new encrypted outputs until it finds one it can open. That is how it discovers incoming money and private memos.
ivk_bob · 84ac…991e
0 decryption attempts
No owned note found yet.
The wallet’s secret inputs—notes, keys, Merkle paths, and randomness—are collectively called the witness. Zcash checks them with a circuit: not electronic hardware, but a fixed mathematical rulebook for a valid shielded transaction. That rulebook checks that inputs exist, the spender controls them, nullifiers are correct, and value balances. A compact proof convinces nodes that a valid witness exists while the witness itself stays private.
Plain language Your wallet proves that the payment follows Zcash’s rules without showing the private information it checked. The network sees the proof—not your notes, keys, or payment details.
Nodes learn nothing until a valid proof is produced.
An Ironwood transaction uses the Orchard Action shape: each Action pairs one spend side with one output side. When the real counts differ, dummy components fill the shape. The pairing does not mean one input “became” one output; value conservation is enforced across the whole transaction. The public package contains opaque commitments, nullifiers, randomized authorization data, note and memo ciphertexts, an anchor, a proof, and a binding signature.
Plain language Ironwood gives private inputs and outputs a standard public shape. Extra placeholders help hide the real counts, while a proof shows that the whole payment still balances.
Opaque fields prove and deliver the transaction without publishing its note values or addresses.
Most of the work happens inside the wallet: select notes, fetch paths, derive nullifiers, create outputs, encrypt, and prove. The network never repeats those private computations. It checks the public proof and state rules, orders the transaction, then publishes new commitments and nullifiers for wallets to scan.
Plain language Your wallet does the private work: choosing funds, creating new notes, encrypting them, and making a proof. The network only checks the public proof and records the result.
Proving is private local computation. Broadcasting sends the finished public transaction to a node. Nodes check it before holding and relaying it; a miner later includes it in a block. Inclusion updates the commitment tree and nullifier set. Confirmations describe how much chain has accumulated above that state change.
Plain language Making a proof does not send a payment. The wallet first builds it privately, then broadcasts it, a miner adds it to a block, and later blocks add confirmations.
The protocol hides shielded senders, recipients, note values, and the link between a spent note’s commitment and nullifier. The chain still shows that a transaction exists, when it was mined, its public fee, and its opaque fields. Network observers may see traffic outside the cryptographic protocol. Optional viewing keys support selective accountability without making everyone’s ledger public.
Plain language Shielded Zcash hides important payment details, but not everything. People can still see that a transaction happened and may learn clues from its timing, fee, or internet traffic.
The Rust verifier’s final multi-scalar multiplication is represented as a symbolic fingerprint. Captured one- and multi-Action executions are checked against that formal object so the proof is about the deployed verification path, not merely a similar protocol sketched on paper.
Part of a public Lean development containing more than 2,700 theorems.
Zcash moved from research proposals to Sprout, Sapling, Orchard, and now Ironwood as proving became faster, mobile-friendly, and free of trusted setup. Upgrades can change pools, circuits, formats, and proof systems. The durable idea is unchanged: private notes, public commitments, unlinkable nullifiers, encrypted delivery, and proofs of valid state transitions.
Plain language Zcash has upgraded its privacy technology several times. The machinery changes, but the basic pattern stays the same: private value, public fingerprints, spent markers, encrypted delivery, and proofs that the rules were followed.
Scaling a private payment system is not one line on a chart. Wallets must create proofs and find their funds, blocks must carry and verify transactions, and validators must retain enough state to reject double-spends. Earlier upgrades made shielded payments practical on ordinary devices and removed trusted setup, but today’s protocol still makes every wallet scan public output data and every validator retain revealed nullifiers. The graph below shows qualitative scaling headroom across those separate constraints; it is a sourced direction map, not a synthetic benchmark score.
Plain language Zcash cannot scale by improving just one number. Wallet work, block space, wallet scanning, and the data that network nodes must keep all need separate improvements.
A draft NU7 analysis estimates the theoretical ceiling for two-Action Orchard-format transactions under today’s 75-second, 2 MB block parameters.
The same draft proposes 25-second blocks plus action limits. This is a separate consensus-capacity step, not Tachyon and not active today.
Project Tachyon describes two orders of magnitude less transaction data and a path to throughput in the thousands, pending implementation and review.
These anchors are intentionally not plotted as one continuous TPS series: the first two are block-parameter capacity estimates for the current protocol, while Tachyon is a proposed protocol redesign without a production benchmark or final consensus parameters.
Tachyon is a proposed new Zcash shielded pool, independent of today’s Ironwood pool—not a feature running on mainnet today. It keeps the durable model of private notes and public validity proofs, but redesigns the protocol around proof-carrying data so prior verified work can be compressed and carried forward. The reason is scale: today’s shielded transactions are large and costly to verify, while every revealed nullifier adds to validator state that grows with the chain. Tachyon targets smaller marginal transaction data, aggregated validation work, and bounded active state without weakening shielded privacy.
Plain language Tachyon is a proposed future design for much more Zcash activity. It aims to make private payments smaller and cheaper to check while stopping the data every node must keep from growing forever.
Project Tachyon describes a proposed two-orders-of-magnitude reduction in transaction data, horizontally scalable proof aggregation, and removal of unbounded nullifier-state growth. Together those changes are intended to make throughput in the thousands plausible. The final rate will depend on implementation performance, consensus parameters, network capacity, and review; no production Tachyon network exists yet.
As of July 29, 2026, Ragu and the Tachyon protocol are under construction. Testnet work, optimization, security review, a Zcash Improvement Proposal, and community consensus are gates before any mainnet activation.
Fold prior validity into a carried proof instead of repeating independent proof overhead.
Let block producers aggregate shielded transactions without requiring wallets to coordinate.
Use evolving nullifiers and oblivious synchronization so old nullifier history can be pruned.
Separate payment delivery from the on-chain pool and explore scalable, post-quantum-private options.
Conceptual demonstration only: it shows the direction of proof aggregation, not final transaction encoding, proof size, throughput, or a production benchmark.
The wallet’s actual nullifier remains secret while its synchronization handle changes over time.
handle · waiting
An untrusted service updates proof work without learning the wallet’s note or eventual on-chain nullifier.
ledger delta · waiting
The wallet receives a succinct proof that the private funds remain valid through a checkpoint.
unspent proof · waiting
A later spend carries proof-backed state, allowing old nullifier history to leave the active set.
pruning · waiting
This animation uses checkpoints and state bars as teaching aids. They are not Tachyon parameters or claims about exact retention windows.
Zcash is not an invisible ledger. It is a public ledger of cryptographic state transitions whose private facts remain with the participants. A note’s creation and later spend are both public state changes, but their connection is not published.
Keys let a wallet receive, see, disclose, or spend.
Spends create fresh notes; their outputs may also carry encrypted memos.
A public fingerprint represents a new private note without revealing its contents.
The spent marker stops replay without revealing which earlier commitment it closes.
Existence, control, correctness, and balance—without the witness.
New commitments and nullifiers become shared state for the next send.
Maxime Desalle · technical overview used for protocol mechanics and the end-to-end transaction walkthrough.
Open the PDFFrank Michael Porter · historical and conceptual account used for motivation, proof intuition, protocol lineage, and selective disclosure.
Open the PDFVersion v2026.7.0-82-g91698b [NU6.2] · the supplied pre-Ironwood specification used to ground the inherited Orchard-protocol mechanics. NU6.3 additions are cited separately from current sources.
Open the PDFCurrent NU6.3 sources for activation, formal balance-integrity assurance, wallet routing, pool state, and migration from the now-restricted Orchard pool.
Open the dashboard Read the launch note Migration guide Formal verification reportPrimary project material used only for the forward-looking Tachyon chapter; roadmap claims are labeled as proposed rather than deployed.
Open the overview Open The Ragu Book