Explanations of Zcash privacy tend to stop at 1 phrase: zero-knowledge proofs. That names the tool and leaves the machine undescribed, which is why it rarely satisfies anyone who asks a second question. A proof establishes that some statement is true. The obvious follow-up is which statement.
Answering that means describing the objects a shielded transaction is actually built from, because the proof is a claim about those objects and nothing else.
There are three of them: a note and a commitment, plus a nullifier. Together they solve a problem that looks impossible when you first state it, and each one exists to preserve a check that hiding the data would otherwise destroy.
Why hiding the data in the clear fails
Begin with the problem rather than the solution, because the solution is unintelligible without it. A blockchain is a validation system before it is anything else, and Zcash had to keep validating while removing the very data that validation reads.
A public blockchain validates a payment by looking at it. Every node checks that the inputs exist and have not already been spent, then that the outputs do not exceed them. Our guide to how unspent outputs track value describes that model, and on a transparent Zcash transaction it applies unchanged: sender, receiver and amount are visible on-chain, as they are on Bitcoin (source: CoolWallet).
Now hide all three. The network still has to reject a transaction that spends money the sender does not have, and still has to reject one that spends the same money twice. Both checks were performed by reading the exact values that are now hidden.
Encryption alone does not rescue this. If the amounts are encrypted, nodes cannot add them up. If the sender is encrypted, nodes cannot tell which prior payment is being consumed, so they cannot tell whether it was consumed already. A chain that cannot detect a double-spend is not a currency.
So the design cannot simply conceal the old data. It has to replace the objects being validated with different objects that support the same checks while revealing less. That replacement is what everything below describes, and every piece of it exists to preserve one of those two checks.
The starting point is the unit of value itself.
The note
On the shielded side, value is held in an object called a note. A note records an amount belonging to a particular recipient, and it is the shielded counterpart to an unspent output on a transparent chain. Nothing about it is exotic; what changes is where it lives and what the chain records in its place.
The important property is that a note is discrete rather than a balance that rises and falls. It is created once, at a specific value, then later consumed whole. Spending part of a note means consuming it entirely and creating two new ones, one for the recipient and one returning the remainder to the sender.
That structure is inherited rather than invented. Bitcoin works the same way, which is why the model transfers: the append-only ledger our guide to how a blockchain is structured describes records creations and consumptions rather than account balances.
Other privacy designs solve the amount problem without adopting this shape at all. Monero's documentation describes RingCT as the feature "introduced to obfuscate transaction amounts" (source: Monero Project), working over a different set of objects. The point of the comparison is that hiding an amount and hiding which coin moved are separable problems, and Zcash's note is where its answers to both meet.
What differs is where a note lives. A transparent output sits on the chain in readable form. A shielded note never appears on the chain, arriving instead in encrypted form and living in the recipient's wallet, while the chain records something else in its place.
That something else is the second object.
The commitment: publishing without revealing
For the network to reason about a note it has never seen, the note has to leave a trace. That trace is a note commitment: a short value derived from the note that identifies it without disclosing what it contains.
The relationship runs one way. Given the note you can produce the commitment. Given the commitment you cannot recover the note. This is the same asymmetry that makes public-key cryptography work, and our guide to public keys versus private keys covers the general property.
Commitments form part of the transaction's own format rather than sitting alongside it: the version 5 transaction specification defines a field carrying "the note commitment for the output note" on each shielded output (source: Zcash Improvement Proposals). Every shielded note ever created puts one on the chain.
Those commitments accumulate into a note commitment tree, one per shielded pool. Those trees are public.
The tree is not a list; it is a structure that lets you prove membership in it. That property is what the whole design rests on. A spender can demonstrate that some commitment in the tree corresponds to a note they control, without indicating which position they are pointing at.
So the first check survives. The network can confirm that the value being spent exists, because its commitment is in the public tree, without learning which entry it is.
It is worth being clear about what an observer gets from all this. They get the tree, in full, and they can watch it grow. Every commitment ever created is visible to them as an opaque value. What they cannot do is invert any of those values into the note behind it, or tell which of them a given spend refers to. The public record is complete and useless at the same time, which is an unusual property for a ledger and the reason the design needed a second object rather than one.
Which leaves the harder check.
The nullifier: spending without pointing
Preventing a double-spend on a transparent chain is trivial, and the triviality is instructive. Each output carries an identifier. The chain records which identifiers have been consumed, and any transaction naming a consumed one is rejected on sight. The check is a lookup and it costs almost nothing.
That cannot work here, because naming the output is exactly what must not happen. Point at a specific commitment and the anonymity of the spend collapses.
The nullifier resolves this, and it is the cleverest object in the design. The protocol specification defines it as "a value unique to the note that is used to prevent double-spends", records that a mined note "is associated with a fixed note position in a tree of note commitments, and with a nullifier unique to that note", and states the consequence for spending directly: "attempting to spend a note twice would reveal the nullifier twice, which would cause the second transaction to be rejected" (source: Zcash Protocol Specification, NU5 revision). It is derived from the note and from key material the owner holds, so nobody without that material can compute it or connect it back to a commitment.
When a note is spent, its nullifier is published, and the chain keeps every nullifier it has ever seen.
Read that carefully, because the whole design turns on it. Nodes detect a double-spend by looking for a repeated value, and repetition is detectable without understanding what the value means. Our guide to who actually validates transactions covers who performs that check; here the point is that they can perform it while learning nothing.
Two public sets, then, and neither reveals a link. Commitments accumulate as notes are created. Nullifiers accumulate as notes are spent. An observer sees both grow and cannot pair any entry in one with any entry in the other.
The economy of that arrangement is worth appreciating. A double-spend check needs exactly one capability: detecting that a value has appeared before. It does not need to know what the value represents or which earlier record it corresponds to. The nullifier supplies that one capability and withholds everything else, which keeps the check itself a simple lookup, whatever the set it has to be looked up in.
What binds them is the third component.
What the proof actually asserts
The proof is where most explanations begin, and putting it first is why so many of them fail to land. It belongs at the end, because until the objects above exist there is nothing for a proof to be a proof about.
A spender constructs a proof and the network verifies it. What the proof asserts is a list, and the list is narrower than most summaries suggest:
- that a commitment for the note being spent exists in the tree, reachable by a valid path
- that the spender holds the authority to spend that note
- that the published nullifier is the one correctly derived from that note
- that the hidden value is a number in the permitted range rather than something absurd
- that the value commitment published alongside it genuinely commits to that value
The specification describes that first claim in the phrasing that captures the entire mechanism: when a note is spent, the spender "only proves that some commitment for it had been revealed, without revealing which one" (source: Zcash Protocol Specification).
Notice what is absent from that list. The proof does not assert that the transaction balances. It does something narrower that the balance check then depends on, tying each hidden value to a published commitment, and the balance itself is settled elsewhere.
Each of those four assertions maps to a named condition in the specification's statement of what a Spend or an Action must prove, and none of them mentions the transaction's totals. That omission is deliberate rather than an oversight, and it is why the design needs a second device.
That device is the other half of the machine.
How the amounts add up
A proof that every note is real and properly spent still leaves the most basic question open: does the money come out even? On a transparent chain a node reads the figures and adds them. Here there are no figures to read.
The answer is a device called a binding signature, and it works on the commitments rather than on the values behind them. The specification states that consistency of the pool balance "with the value commitments in Spend descriptions and Output descriptions is enforced by the Sapling binding signature", and says the same of the Orchard pool and its own binding signature. Validators compute a value from the transaction's value commitments and check the signature against it, which is arithmetic they perform rather than a claim they accept.
Three devices, then, each with one job. The proof establishes that a note is real and that the spender is entitled to it. The nullifier lookup establishes that it has not been spent before. The binding signature establishes that the amounts add up. Summaries that fold all three into "zero-knowledge proofs" are describing a simpler system than the one that exists, and the simplification is where most misunderstandings of Zcash start.
Some commitment. Not that one. That distinction is the privacy.
How the proof achieves this is a separate subject and this article does not open it. The mathematics of zero-knowledge proving systems has its own literature, its own tradeoffs and its own article; the project's own explainer is the standard starting point (source: Zcash), and our guide to Zcash and zk-SNARKs goes further. Introductions to the proving system tend to stop at the proof itself and never reach the note commitment or the nullifier (source: Consensys), which is why the mechanism half of this subject stays so thinly covered. Note also that the word proof carries a different meaning elsewhere in crypto: our guide to proof of work describes a mechanism with nothing in common with this one beyond the word, and other chains solve related problems differently, as our guide to Monero's range proofs shows.
For present purposes the proof is a component with a specification: it takes a transaction and returns true or false, and it is false unless every claim above holds. Nodes verify it without the note, without the amount and without the sender.
Worth sitting with how unusual that is. The verifier reaches a definite answer about objects it never sees, using a procedure that would produce the same answer for any spender in the same position. That property is why the list above can be short: each item is a precise obligation rather than a summary, and anything not on the list is genuinely not being claimed.
That is the mechanism, end to end. What it does not accomplish is a separate list.
One payment, end to end
The components are easier to hold together once the sequence has run once. What follows is a single shielded payment, traced in the order the machinery touches it, with each step naming the object it operates on.
You hold a note. The note records an amount and the key authorized to spend it, while the chain holds only its commitment, which discloses neither of those fields to an observer.
You decide to spend it. Your wallet derives the nullifier for that note from the note itself and from your spending key, a derivation nobody can reproduce without possessing both inputs.
Your wallet constructs the outputs. One new note is created for the recipient at the amount you are paying, and a second is usually returned to you carrying the remainder, because a note is consumed in its entirety and change is expressed as a fresh note rather than as a reduction.
Your wallet then constructs the proof. It asserts that the note being consumed appears among the commitments the chain already holds, that you control the key authorizing it, that the nullifier was derived correctly, and that the values on both sides of the transaction balance to zero (source: Electric Coin Co.).
The network validates it. Nodes verify the proof, compare the nullifier against every nullifier already recorded, and reject the transaction outright if it duplicates one. They never learn which commitment that nullifier corresponds to, because the derivation runs in one direction only.
The chain records the outcome. It appends the new commitments, appends the nullifier, and publishes nothing further. An observer establishes that a valid payment occurred and recovers neither an amount nor a counterparty.
The recipient locates their note. Their wallet trial-decrypts candidate outputs with its own viewing key, identifies this one, and credits an amount to a balance that exists only inside their software rather than anywhere on the chain. Our guide to Zcash viewing keys covers what that key does and does not expose.
No step in that sequence requires trusting a participant, and no step publishes a value. Holding both properties simultaneously is the entire design objective, and most of the protocol's remaining complexity exists to keep them true as the chain grows. Our page on what the shielded pools contain covers where those commitments accumulate.
What still leaks after a proof
The mechanism is precise about its scope, and reading guarantees into it that it does not make is the most common error in this subject. Five things sit outside what the design covers, and each of them is public or knowable by other means.
Value moving between the two sides. A transaction that moves value from the transparent side into the shielded side, or out of it, records the amount crossing. That figure is not inside the shielded machinery at all; it is an input to it, and it is public.
The count of shielded components. A transaction reveals how many shielded descriptions it carries, even though it reveals nothing about their contents. That is not quite a count of real notes, since the format allows padding entries, but it is a public number and nodes need it to process the transaction.
When anything happened. Every commitment and every nullifier is timestamped by the block containing it. Timing is not concealed by any part of this design.
Whether you are alone. The mechanism hides which commitment a spend refers to, among all the commitments in the tree. That is a statement about a set, and the protection it buys scales with how many members of that set are plausible. Peer-reviewed analysis presented at USENIX Security in 2018 built its conclusion on exactly this point, showing that ordinary "patterns of usage" narrow the field without touching any of the cryptography described above (source: USENIX). Our guide to whether Zcash transactions can be traced carries that argument in full. Here it is a boundary condition on the mechanism rather than the subject.
Anything outside the chain. The mechanism governs what a ledger records. It has no jurisdiction over what a service knows about you, and our guide to privacy on a public ledger covers the wider surface.
From where BloFin sits, one implication is worth stating plainly. A withdrawal to a shielded address puts the amount on the chain as it crosses, and the mechanism described here begins operating after that crossing rather than before it. Knowing which part of the journey is covered is more useful than any assurance about the cryptography.
Frequently asked questions
If nodes cannot see the amounts, how do they know money was not created?
By checking a proof rather than by reading amounts, and not from the proof either. Balance is enforced by a separate device, the binding signature. Each shielded value carries a commitment, validators combine those commitments arithmetically across the whole transaction, and the signature verifies only if the combination comes out consistent. So nodes do perform arithmetic here; they perform it on commitments rather than on amounts. That is the part people find counterintuitive, because it means a sum can be checked without any term in it being known.
What happens if I lose the note data but keep my keys?
Wallet recovery on the shielded side is harder than on a transparent chain, because your notes are not sitting on the chain in readable form waiting to be found. A wallet rebuilding from a seed generally has to scan the chain and attempt to decrypt candidate notes to discover which ones belong to you, which takes time proportional to how much chain there is. Your funds remain yours throughout, since the notes exist and your keys still open them. Recovery is simply a slower operation, and some wallets provide tools to speed it up.
Can a nullifier be linked back to a commitment by anyone?
No, and the reason is worth separating from the mechanism. Linking would require deriving the nullifier, and the derivation takes a secret held by whoever can spend the note. But that secret is not always held only by the owner: the same material that permits linking can be delegated, which is how selective disclosure to an auditor or an accountant works on this chain, and our guide to Zcash viewing keys covers what can and cannot be handed over. Absent such a disclosure, the link cannot be derived at all, which is a stronger property than being hard to find.
Does this mean shielded transactions are anonymous?
Not as a property of the mechanism alone. The mechanism hides which note is being spent among the candidates in the tree, so the protection it offers depends on how many plausible candidates exist. It also does not touch amounts crossing between the two sides, the timing of anything, or information held off the chain entirely. Treat it as a strong guarantee with a stated scope rather than a blanket one, and read the scope before relying on it.
Why does the chain keep every nullifier forever?
Because the double-spend check is a search for repetition, and a repetition can occur at any distance in time. A note created years ago can be spent today, so the set of spent nullifiers has to remain complete for the check to be sound. That set grows permanently, which is a real cost in storage and in validation time, and it is one of the tradeoffs of a design that verifies by comparing opaque values rather than by reading them.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include the Zcash Protocol Specification and peer-reviewed research published at USENIX Security. All facts independently verified against cited documentation current as of August 2026. Mechanism descriptions here are deliberately scoped to what the specification states; the proving system that underpins them is a separate subject with its own literature.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Regulatory treatment of privacy assets differs by jurisdiction and changes over time. Do your own research before making any decision.