You’ve learned how Zcash hides things. Now the hard part: actually staying hidden.
Privacy isn’t a checkbox you tick once. It’s a habit. The cryptography is flawless — but you can absolutely leak yourself with one lazy click. This lesson is the practical playbook: how to send a genuinely anonymous payment, the mistakes that quietly undo it, and the honest trade-offs nobody puts on the marketing page.
Do it right: z→z, end to end
Before you read — take a guess
Guess: a fully shielded z→z transfer hides how many of these — sender, receiver, amount, memo?
The gold standard is a fully shielded z→z transaction — shielded address in, shielded address out, ideally through the modern Orchard pool.
A z→z transfer hides four things at once: the sender, the receiver, the amount, and the memo. Bitcoin can’t hide any of those. That’s the whole game.
The rule that matters most: keep your funds inside the shielded pool the entire time. Receive shielded, hold shielded, spend shielded. The moment money crosses out to a transparent address, you’ve punched a window in the wall.
Use a Unified Address
A Unified Address (it starts with u1…) is one address that auto-routes incoming funds to the best shielded pool (Orchard). One address, less to think about, fewer chances to accidentally expose a transparent receiver.
u1qq2fpu5jfd9k0xkq4d2vj3m7r0n8q5l6t8w2hx7p4c9v3b1m6s0z5y8x2w4q7e9r3t1y6u8i0o2p4a6s8d0f2g4h6j8k0l(That’s a placeholder — real UAs are longer and uglier. Never reuse one you found in a tutorial.)
Wallets that speak shielded
- Zashi (built by ECC) — now makes shielded the default, so you have to go out of your way to not be private. That’s exactly the right design.
- Ywallet — flexible, supports shielded pools.
- zcashd /
zcash-cli— the full-node route. Note thatzcashdis being superseded; Zebra is the modern node going forward.
A conceptual shielded send from the command line looks like this — note the source and destination are both shielded:
zcash-cli z_sendmany "u1youraddr..." '[{"address":"u1recipient...","amount":0.5,"memo":"48656c6c6f"}]' 1 null 'AllowRevealedSenders'The memo is encrypted and only the recipient can read it. It’s hex-encoded here (48656c6c6f = “Hello”). Think of it as a sealed note inside a sealed envelope — the chain just sees ciphertext.
Lock in the golden rule of staying private.
Pick the right option for each blank, then check.
The gold standard is a fully shielded transaction, which hides the sender, receiver, amount, and . A Address (starting u1…) auto-routes incoming funds to the pool.
Why mixing shielded and transparent leaks
Before you read — take a guess
Guess: when does a Zcash transaction become an 'exposure point'?
Here’s where good intentions go to die. A transaction that touches both pools — shielding or deshielding — is an exposure point.
When you cross the boundary, the transparent side reveals its amount and address. And worse: amount correlation can re-link the shielded side. If you shield exactly 7.31 ZEC and later deshield exactly 7.31 ZEC, an observer doesn’t need to break the cryptography — they just match the numbers.
Treat every shield and deshield as a moment you briefly step into the spotlight.
When you cross the transparent ↔ shielded boundary, what becomes visible and what stays hidden?
Place each item in the right group.
- The transparent amount
- The transparent address
- An exact distinctive amount that can be matched across the boundary
- The contents of an encrypted memo on the shielded side
- The shielded counterparty inside a pure z→z transfer
Mistakes that de-anonymize people
Before you read — take a guess
Guess: which of these is a privacy-killing mistake?
These are the classics. Each one has put real users on a public, clusterable map.
Privacy-killing mistakes — avoid every one:
- Living in t-addrs. Transparent addresses are Bitcoin-like: public, permanent, clusterable.
- Amount correlation. Deshielding the same distinctive amount you shielded (shield
7.31, later deshield7.31). The number is a fingerprint. - Timing correlation. Shield, then immediately deshield. A tight time gap links the two ends.
- Deshielding straight to a KYC exchange. This anchors your real identity to that flow — the exchange knows who you are.
- Address reuse. Reusing any address builds a history that links activity together.
- Consolidating transparent + shielded funds in one move, or spending a UA’s transparent receiver out of habit.
The throughline: anonymity comes from blending into a crowd. Every distinctive amount, predictable timing, or reused address is a way of stepping out of the crowd and waving.
Match each privacy mistake to why it leaks.
Pick a term, then click its definition.
Bitcoin vs Zcash: same goal, different tools
Before you read — take a guess
Guess: how does Bitcoin's CoinJoin compare to a Zcash shielded transfer?
Both want to keep your money your business. They get there very differently.
In Bitcoin, there is no z→z equivalent. Every amount and address is public forever. The closest privacy tool is CoinJoin — many people pool inputs to muddy who-paid-whom. But CoinJoin is obfuscation, not concealment: amounts are still visible, and change outputs are often linkable with enough analysis.
Zcash shielded transactions don’t obfuscate the data — they hide it cryptographically and prove validity with a zero-knowledge proof. Nothing to untangle, because nothing leaked.
Active recall: the core distinction, in your own words.
Pick the right option for each blank, then check.
Bitcoin's CoinJoin is , not concealment — the amounts stay visible. Zcash hides the data cryptographically and proves the transaction is valid with a proof.
You want a genuinely private payment. Which action LEAKS your privacy?
A private payment, done right
Before you read — take a guess
Guess: in the safe workflow, where do your funds spend most of their life?
Here’s the workflow that actually keeps you anonymous — four sequential stages.
- Receive to a shielded UA. Ask to be paid at your Unified Address (u1…). Funds land in the Orchard shielded pool — sender, amount, and memo are encrypted from the start.
- Hold shielded. Leave the funds inside the shielded pool. No detours to a transparent address — every crossing is an exposure point you don’t need.
- Pay z→z with an encrypted memo. Spend shielded-to-shielded. Attach an encrypted memo if you need to say something (an invoice number, a note). Only the recipient can read it; the chain sees ciphertext.
- If you must cash out, do it carefully. Deshielding is sometimes unavoidable. When it is: vary the amount (don’t deshield the exact figure you shielded), vary the timing (don’t do it back-to-back), and avoid deshielding straight into a KYC exchange that links it to your name.
Sort each action into the safe workflow or the leaky one.
Place each item in the right group.
- Receive to a shielded Unified Address
- Hold funds inside the shielded pool
- Pay z→z with an encrypted memo
- Deshield the exact amount you shielded, back-to-back
- Deshield straight into a KYC exchange
Selective disclosure: privacy isn’t all-or-nothing
Before you read — take a guess
Guess: if everything is hidden, how do you prove a payment to an auditor?
A common fear: “If everything’s hidden, how do I ever prove a payment to an auditor, a merchant, or a regulator?”
Zcash’s answer is viewing keys — read-only keys you hand out on purpose.
- Incoming Viewing Key (IVK) — lets someone see incoming payments to an address. Perfect for a merchant terminal or donation tracking.
- Full Viewing Key (FVK) — sees incoming and outgoing activity, plus memos. Useful for auditors or checking a cold-storage balance.
The crucial part: neither key can spend. The spending key stays offline, in your hands, always.
Unified Viewing Keys (UFVK / UIVK, defined in ZIP 316) bundle these across pools. And payment disclosure (ZIP 302) lets you prove one specific payment to one chosen party — say, for the Travel Rule or an audit — without exposing your whole wallet.
Think of an FVK like read-only access to a shared document. Your accountant can see everything; they can’t move a cent. Revoke their access by rotating to a new key — the spending power was never theirs to begin with.
Match each key or mechanism to what it lets someone do.
Pick a term, then click its definition.
They’re the opposite of a backdoor. A backdoor is access someone takes from you. Viewing keys are opt-in, holder-granted, and cannot spend. You decide who sees what, and you can stop sharing. No one — not ECC, not a government, not the protocol — can read your shielded data unless you hand them a key.
The honest trade-offs
Before you read — take a guess
Guess: which of these honest caveats are true? (Select all that apply.)
Good lessons don’t sell. Here’s the balanced picture.
Privacy is opt-in. Because shielding is a choice, historically most ZEC moved transparently. That’s changing fast: shielded supply rose from roughly 8% in early 2024 to ~30% (≈4.9M ZEC) by late 2025, and the shielded-transaction share hit an all-time high of about 59% in February 2026. The catch: much of that growth is partially shielded (shield/deshield) flows — not fully private z→z. The pool is filling, but not everyone inside it is actually anonymous.
Trusted setup. Early Zcash (Sprout and Sapling) needed a trusted setup ceremony — if the secret “toxic waste” leaked, someone could have forged coins (not de-anonymized them, but still bad). Orchard, built on Halo 2, removes the trusted setup entirely. Going forward, there’s no ceremony to trust.
Regulation. Privacy coins — Zcash included — have faced exchange delistings in some jurisdictions. The counter-argument is built in: viewing keys and payment disclosure offer selective auditability and Travel Rule compliance, so you can prove what you need to prove without surrendering everything.
Performance. Shielded proving was once heavy and slow. Sapling (~40 MB, mobile-capable) and later Halo 2 work made it practical on phones — but shielded transactions are still heavier than transparent ones. Privacy isn’t free; it’s just worth it.
Spaced recall — the trust and history caveats.
Pick the right option for each blank, then check.
Sprout and Sapling needed a ceremony whose secret toxic waste could have forged coins. Orchard, built on , removes it. But shielding new funds does nothing for the past: every transaction you ever made stays public forever.
No. Shielding new funds does nothing for the past. Every transparent transaction you ever made stays public on the chain forever. A bigger anonymity set protects your future shielded activity, not your recorded history. You can start being private today, but you can’t un-publish yesterday.
Big picture
Big picture
Staying anonymous on Zcash, in one picture
- Anonymous Zcash
- Do it right
- z to z, end to end
- Unified Address to Orchard
- Stay in the shielded pool
- Where it leaks
- Shield or deshield is an exposure point
- Amount correlation
- Timing correlation
- KYC exchange anchors identity
- Selective disclosure
- IVK sees incoming
- FVK sees in and out, never spends
- Payment disclosure proves one payment
- Honest trade-offs
- Privacy is opt-in
- Orchard removes trusted setup
- Old transparent history stays public
- Do it right
Quick gut-check
What's the best practice for a genuinely private Zcash payment?
Check your answer to continue.
Wrapping up the topic
So where does this leave us?
Bitcoin is a public ledger written in pen-names. Everyone can see every payment; the only thing hidden is which human sits behind which address — and that’s often guessable.
Zcash, used right, is verify-without-revealing. A shielded z→z transaction proves to the entire network that it’s valid — the coins exist, nobody double-spent — while hiding the sender, the receiver, the amount, and the memo. And when you do need to prove something, viewing keys and payment disclosure let you reveal exactly one slice, to exactly one party, on your terms.
The cryptography gives you a vault. Whether you actually live in it is up to you. Receive shielded, hold shielded, spend z→z — and stay in the crowd.