How Zcash Actually Works: From Zerocash to Ironwood

Zcash is a cryptocurrency network built around a difficult idea: a public blockchain should be able to verify that money moved correctly without publishing who paid whom or how much they paid.

Its coin is ZEC. Its ledger is descended from Bitcoin's code, but Zcash is a separate blockchain with its own genesis block and transaction history. It still uses proof of work, miners and a capped monetary supply. The major difference is that it can represent coins as encrypted shielded notes and validate them with zero-knowledge proofs.

That does not make every Zcash payment private. The network supports both transparent Bitcoin-like transfers and shielded transfers. Privacy depends on which receivers are used, which pool holds the funds and how the wallet behaves.

This guide explains where Zcash came from, how the cryptography works, what changed from Sprout to Sapling, Orchard and Ironwood, and what the system still cannot hide. Network details are current as of 26 August 2026.

The origin: Zerocoin, Zerocash, then Zcash

Zcash did not begin with one founder inventing a privacy coin in isolation. It grew out of several years of academic research, then a larger engineering effort that converted that research into a production network.

In 2013, Ian Miers, Christina Garman, Matthew Green and Aviel Rubin published Zerocoin: Anonymous Distributed E-Cash from Bitcoin. Zerocoin proposed a decentralized mint-and-redeem system for Bitcoin. A user could convert a visible bitcoin into a special coin and later redeem it without revealing which mint event it came from.

This was a meaningful advance, but it behaved more like a cryptographic mixer than a complete private-payment system. It hid the link to a coin's origin, while destinations and amounts remained visible and denominations were constrained.

The 2014 Zerocash paper, written by Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer and Madars Virza, went further. It described direct anonymous payments that could hide the source, destination and amount. The key tool was a zk-SNARK: a compact proof that a hidden transaction followed all the rules.

The academic protocol was then turned into an operating cryptocurrency. The Zerocoin Electric Coin Company, now Electric Coin Co., was formed in 2015. Zooko Wilcox organized the production effort alongside researchers, cryptographers and engineers. Zcash was announced publicly in January 2016 and mainnet launched on 28 October 2016.

The original Sprout proof system required a setup ceremony. Six people created public parameters through a multiparty computation. Security required at least one participant to destroy their secret contribution, often called "toxic waste." If every participant had colluded and retained it, they might have been able to forge coins without detection. The secret would not have let them decrypt ordinary private transactions. The ceremony design was intended to make universal collusion unlikely and leave an auditable transcript.

Zcash began with no conventional premine, but it did include a Founders' Reward. During the first four-year reward era, 20 percent of each block subsidy went to designated recipients and 80 percent went to miners. Because this applied only during the first half of scheduled issuance, it was designed to equal 10 percent of the eventual monetary base. The network also used a slow-start period for mining rewards.

Two ledgers living on one chain

The easiest way to understand Zcash is to imagine two accounting models sharing the same blockchain.

The transparent side works much like Bitcoin. Coins sit in unspent transaction outputs. Addresses, amounts and transaction links are public.

The shielded side stores private coins as notes. A note contains a recipient component, a value, randomness and other fields needed by its pool. The chain does not publish the note in plain text. It publishes a commitment to the note, an encrypted copy for the recipient and a proof that the hidden data obeys consensus.

Transactions can stay transparent, enter a shielded pool, leave one, or move entirely within a shielded pool.

This is why "Zcash is private" is too broad. A fully shielded payment can hide the economic graph, but a transparent payment cannot. A transfer that crosses a pool boundary exposes the net amount crossing that boundary, even when the notes inside the pool remain hidden.

The five pieces behind a shielded coin

A shielded payment uses several cryptographic tools with different jobs. Zero knowledge is only one of them.

1. The note commitment

A note commitment is a hiding, binding fingerprint of a private note.

Hiding means an observer cannot recover the recipient, value or randomness from the commitment. Binding means the sender cannot later claim that the same commitment represented different data.

When a wallet creates a new shielded note, its commitment is added to that pool's public commitment tree. The note itself stays encrypted.

2. The Merkle commitment tree

Each shielded pool maintains an append-only Merkle tree of note commitments. A compact root summarizes every note commitment added up to that point. Zcash calls a root used by a transaction an anchor.

To spend a note, the wallet privately supplies its Merkle authentication path inside the proof. Validators learn that a valid note exists beneath the anchor, but not which commitment is being spent.

Bitcoin removes a spent output from the set of spendable outputs. A Zcash shielded tree never visibly removes a commitment, because doing so would reveal which note was spent. It uses nullifiers for that job.

3. The nullifier

A nullifier is a unique, deterministic, pseudorandom-looking tag derived from a note and secret key material. It is revealed when the note is spent.

Validators maintain a public set of seen nullifiers. If the same nullifier appears twice, the second spend is rejected. Under the intended cryptographic assumptions, an outside observer cannot connect that nullifier to the earlier note commitment.

This separation is the heart of the design:

• The Merkle proof says, "I control a valid note somewhere in this pool."
• The nullifier says, "This note has not already been spent."
• Neither statement identifies the note on the public chain.

4. Encryption

The proof does not deliver the new note to its recipient. Encryption does.

For each output, the sender creates a fresh ephemeral key and encrypts the note plaintext to the recipient. Wallets scan new outputs and try to decrypt them with an incoming viewing key. A successful decryption tells the wallet that it received a note and reveals the note value, randomness, diversifier and memo.

The memo field is encrypted and currently holds 512 bytes. It can carry payment context, but it should not be mistaken for an anonymous messaging system. The recipient, sender and anyone given suitable viewing data may be able to read it.

5. The zero-knowledge proof and signatures

The zk-SNARK proves the transaction rules over private inputs. Signatures separately prove spending authority and bind the transaction together.

For a typical shielded spend, the private witness includes the old note, its opening randomness, its location and Merkle path, secret key material, input and output values, and randomness for value commitments. The public statement includes an anchor, nullifier, new note commitment, value commitment and randomized authorization key.

The proof establishes that:

1. The old note commitment was formed correctly.
2. That commitment exists under the stated anchor.
3. The spender has the required secret key material.
4. The nullifier is correctly derived.
5. The new output commitment is correctly formed.
6. Hidden values are within the permitted range.
7. Inputs, outputs, fees and public value balance without creating money.

The Zcash protocol specification defines the exact statements for each shielded protocol.

What zk-SNARK actually means

The name is compressed jargon, but each word carries a useful promise.

There is an important boundary here. A zero-knowledge proof only proves the rules encoded in its circuit. It does not hide the sender's IP address, protect a compromised phone, prevent an exchange from knowing its customer, or fix a missing constraint in the circuit itself.

How hidden amounts still balance

If values are secret, validators cannot add visible inputs and outputs as they do in Bitcoin. Zcash uses value commitments.

Conceptually, an Orchard value commitment has the form:

cv = v·V + r·R

Here v is the value, r is random blinding, and V and R are independent curve generators. These commitments are homomorphic, which means validators can combine them without learning the values inside them.

A binding signature proves knowledge of the aggregate commitment randomness and makes a hidden imbalance computationally infeasible. A separate randomized spend-authorization signature proves ownership without exposing a stable public key that would link payments.

Proof of work and zero-knowledge proofs therefore solve different problems. Mining chooses and secures the canonical transaction history. The shielded proof shows that a private transaction is valid. A miner with majority hash power could censor or reorganize transactions, but could not forge a valid shielded spend without breaking the keys or proof system.

A shielded payment from start to finish

After confirmation, the recipient's wallet finds the payment by scanning the encrypted outputs. It does not look up a visible address balance. It reconstructs its private balance from notes it can decrypt, then tracks which of those notes have corresponding nullifiers on-chain.

Sprout, Sapling, Orchard and Ironwood

Zcash has replaced or refined its shielded machinery several times. These pools have separate commitment trees and nullifier sets, so their anonymity is not one shared bucket.

Sprout

Sprout closely followed the original Zerocash design. A JoinSplit consumed up to two notes and created up to two notes, with zero-valued dummy slots when necessary. Producing a shielded transaction was demanding on ordinary hardware. Electric Coin Co. reported roughly 1.5 GB of memory and about 40 seconds on then-current machines.

Sapling

Sapling separated spends and outputs, adopted Groth16 and redesigned its keys. Electric Coin Co. reported more than a 90 percent reduction in construction time and more than a 97 percent reduction in memory, bringing proving down to a few seconds and roughly 40 MB. That made shielded use practical on a much wider range of devices. Sapling still depended on a trusted setup, but its multiparty ceremony had nearly 200 contributions.

Orchard and Halo 2

Orchard arrived with NU5 on 31 May 2022. Each Orchard Action pairs one spend and one output, either of which can be a dummy. One Halo 2 proof covers the Action bundle.

Halo 2 uses a PLONK-like arithmetization and inner-product polynomial commitments. At a high level, the circuit becomes a table of private witness columns, public input columns and fixed selector columns. Polynomial constraints and lookup arguments enforce the transaction program. Transcript-derived challenges make the proof non-interactive.

The major operational benefit is that Orchard does not require a secret setup ceremony. That does not mean it has no public parameters, no hardness assumptions or no software risk. It still depends on elliptic-curve assumptions and correct circuit implementation. Also, despite Halo's origins in recursive proof composition, Orchard's deployed transaction proof does not currently use recursion.

Ironwood

NU6.3, called Ironwood, activated on 28 July 2026 at block height 3,428,143. It created a new shielded pool that reuses the Orchard protocol and Halo 2 machinery but keeps an independent note-commitment tree, nullifier set, anchor set and value balance.

The original Orchard pool is now restricted. New value cannot enter it and cross-address transfers inside it are disabled, while existing funds can leave or migrate. Current wallets route new payments for an Orchard-protocol receiver into Ironwood. This preserved Unified Address compatibility while creating a clean accounting boundary. The transition is specified in ZIP 229 and the NU6.3 deployment specification.

Ironwood is described as quantum recoverable, not post-quantum secure. Its note data is structured so that a future recovery protocol could move funds if quantum computers threaten today's elliptic-curve keys. That recovery protocol is not active, and ordinary Ironwood spending still relies on discrete-log security. ZIP 2005 explains the distinction.

Keys, viewing rights and Unified Addresses

Zcash separates the power to spend from the power to observe. That is useful for wallets, businesses, auditors and selective disclosure.

A Unified Address is a compatibility tool, not a privacy guarantee. A sending wallet chooses the best receiver type it supports. If it falls back to a transparent receiver, the resulting payment is public. ZIP 316 defines the format and receiver-selection rules.

Viewing keys also create deliberate asymmetry. An organization can keep activity private from the public while sharing viewing access with an internal accounting system or another authorized party. Sharing a full viewing key is a major disclosure, however, because it can expose extensive account history and spend status.

What the public can still see

Even a fully shielded transaction leaves data on a public network. Observers can see:

• That a transaction exists, its transaction ID, block height and approximate timing
• Its byte size, fee and the number and type of shielded components
• Which transparent and shielded pools it touches
• The net value crossing between a shielded pool and transparent value, or between shielded pools
• Anchors, note commitments, nullifiers, proofs, ciphertexts and ephemeral keys
• Network metadata outside consensus, potentially including the broadcasting IP address

The practical anonymity set is also pool-specific. A note in Sapling does not automatically blend with Ironwood notes. Migrations split activity across pools and publish the net value crossing each boundary.

Wallet behaviour can reduce privacy further. An identifiable amount that enters a pool and soon leaves in almost the same amount creates a strong timing and value clue. Nonstandard fees, unusual transaction shapes, distinctive anchor choices and dust payments can fingerprint a wallet or spending pattern. Light-wallet servers can observe synchronization and transaction-fetch behaviour. Exchanges and merchants can connect deposits, withdrawals, customer records, memos or shared transaction IDs to real identities.

The wallet privacy best practices in ZIP 315 are therefore part of the security model in practice. Strong cryptography can hide the ledger graph, but it cannot repair careless endpoint or network behaviour.

The 2026 Orchard incident and the turnstile

The most important recent security event is also the clearest lesson in how zero-knowledge systems can fail.

On 29 May 2026, researchers reported a missing constraint in a variable-base scalar-multiplication gadget used by the pre-NU6.2 Orchard Action circuit. A malicious prover could potentially exploit the mismatch between the intended rule and the encoded circuit to create balance violations or steal a note when its plaintext was known.

Orchard was temporarily disabled through an emergency soft fork on 1 June. NU6.2 activated on 3 June 2026 with a corrected circuit and new verifying key. The Zebra security advisory says there is no evidence of exploitation. Because a balance-violation proof would not necessarily carry a distinctive public marker, "no evidence" is not the same as a cryptographic proof that the flaw was never used.

The incident illustrates a critical rule:

A proof can perfectly verify the circuit that was encoded. If the circuit omits a necessary constraint, it may not prove the rule its designers intended.

Zcash limits the system-wide damage of a shielded counterfeiting bug through value-pool turnstiles. The chain tracks how much legitimate value entered each shielded pool. It cannot allow more net value to leave than the pool contains. Counterfeit notes hidden inside a compromised pool could create unfair claims on that pool's real balance, but they cannot push the public pool balance below zero and expand the overall ZEC supply through the exit.

Ironwood created a fresh, independently accounted pool and forced Orchard exits through this boundary. That decision was less about new proving speed and more about restoring a clean supply-assurance domain.

Zcash had faced a related class of risk before. A counterfeiting flaw in the original Sprout proof system, CVE-2019-7167, was fixed before public disclosure. The project reported no evidence that it had been exploited. Both incidents show why circuit review, independent implementations, upgrade mechanisms and visible pool accounting matter alongside elegant mathematics.

The network and monetary policy today

Zcash still uses Nakamoto-style proof of work. Its Equihash parameters are n = 200 and k = 9, and mining is now performed with specialized hardware. The target block interval has been 75 seconds since the Blossom upgrade. Difficulty adjusts every block, and the consensus block-size limit is 2 MB.

The monetary ceiling is 21 million ZEC, expressed in consensus as MAX_MONEY. Scheduled issuance is slightly below exactly 21 million because of the launch slow start and integer rounding. The current block subsidy is 1.5625 ZEC:

The deferred pool is a protocol-accounted funding lockbox, not an ordinary payment address whose ongoing balance can already be spent directly by a token vote. The current allocation and subsidy are described in the Zcash economics overview and NU6.1 specification.

Protocol changes are proposed through Zcash Improvement Proposals, discussed socially and technically, implemented in node software and ultimately accepted when network participants adopt the new consensus branch. Zcash is not governed by a simple on-chain token vote.

The legacy zcashd node reached end of life in July 2026. Zebra, maintained by the Zcash Foundation, is the current full validation node. Zcash remains proof of work; proposed hybrid finality or proof-of-stake ideas are not active mainnet rules.

What Zcash gets right, and what remains hard

Zcash's strongest idea is that privacy can be a property of normal ledger validation rather than a separate mixer. A validator can reject theft, double-spending and inflation without learning the private payment graph. Commitments hide notes, encryption delivers them, nullifiers stop reuse, signatures prove authority and zk-SNARKs tie the hidden rules together.

The design also supports selective disclosure. A user can reveal specific transaction information or share viewing authority without handing over the spending key. Halo 2 removes the historical toxic-waste ceremony from the newest shielded protocol.

The trade-off is complexity. Zcash relies on sophisticated circuits, wallet scanning, multiple generations of shielded pools and correct behaviour at many layers. Optional transparency and pool migrations fragment anonymity. Boundary amounts and network metadata remain visible. Proof systems can be mathematically sound while an implementation encodes the wrong constraint. Proof of work adds its own energy, hardware-concentration, censorship and reorganization risks.

The right conclusion is neither "perfect privacy" nor "privacy theatre." Zcash is one of the most ambitious attempts to make private digital cash verifiable on a public blockchain. Its cryptography can hide information that transparent ledgers expose by design, but the privacy a person receives is the product of the pool, wallet, network path, counterparty and operating habits around that cryptography.

Primary sources and further reading

• Zerocoin paper, IEEE Security and Privacy 2013
• Zerocash extended paper, IACR 2014
• Zcash Protocol Specification
• Sapling network upgrade
• Orchard protocol, ZIP 224
• NU5 and Halo 2 activation
• Orchard circuit repair, ZIP 257
• Ironwood activation, NU6.3
• Transaction version 6 and Ironwood, ZIP 229
• Wallet privacy best practices, ZIP 315