Zcash Privacy Mistakes: 9 Ways Shielded Users Leak (and How to Avoid Each)

A fully shielded Zcash transaction hides the sender, the receiver and the amount from everyone reading the blockchain. Most privacy failures happen around that transaction, not inside it. These are the usual culprits:

• amounts that cross between pools and are public by design;
• transparent addresses that link together;
• coins that go in and straight back out at the same value;
• timing patterns;
• the IP address your wallet connects from;
• viewing keys and screenshots shared too freely.

Researchers found back in 2018 that "while it is possible to use Zcash in a private way, it is also possible to shrink its anonymity set considerably by developing simple heuristics based on identifiable patterns of usage" (Kappos et al., USENIX Security 2018). This page lists nine such patterns, explains what each one reveals, and gives the fix, quoting the Zcash wallet standards (ZIP 315, ZIP 316, ZIP 318) and wallet makers' own guidance wherever possible.

What is public and what is not

Before the mistakes, the baseline:

The last row matters more than ever since July 2026. ZIP 2006 says moving funds out of Orchard reveals "the net amount leaving the pool on-chain, regardless of its destination". The turnstile (ZIP 209) works by counting exactly those amounts.

Some things leak even in a fully shielded transaction. ZIP 315 lists them: the transaction version, the expiry height and anchor position, the fee, and "Numbers of JoinSplits, Spends, Outputs, and Actions". Usually these are harmless. Several of the mistakes below are about making them harmful.

Mistake 1: using the shielded pool as a pass-through

What people do: receive ZEC from an exchange at a transparent address, shield it, then send the same amount out again soon after, perhaps to another exchange.

What it reveals: the shielded hop hides almost nothing. Zodl's support page gives exactly this example: "if you received 1.234 ZEC at your transparent address, then shielded it, and only a short time afterwards, sent 1.234 ZEC to someone's transparent address; that pattern is easily discernible" (Zodl support). The amount going in and the amount coming out match, the times are close, and both ends are public.

This is the kind of "simple heuristic" the 2018 USENIX paper used to shrink Zcash's anonymity set.

The fix:

• Keep funds shielded "at rest". Zodl quotes Zooko: "privacy comes from shielded money at rest. The longer you keep your funds shielded, the greater assurance you have of its privacy." It adds: "do not treat shielded Zcash as a temporary pass-through, but rather, the default state of a certain portion of savings."
• If you must move funds through, change the amount and wait. Splitting, combining and spending some in between all help.
• Pay shielded-to-shielded wherever the recipient supports it.

Mistake 2: crossing pools with an amount that identifies you

What people do: migrate their whole Orchard balance to Ironwood in one transaction, or move an oddly specific amount like 12.3467 ZEC between pools.

What it reveals: every pool crossing publishes its amount. ZIP 318, the wallet guide for the Orchard-to-Ironwood migration, warns: "If a wallet migrates a user's entire balance in a single transaction, that amount, its timing, and (via network-layer metadata) potentially the user's IP address are all exposed at once." Zodl's self-migration guide calls a one-shot move "the most identifying number you could put on the blockchain" (Zodl support).

The fix:

• Use your wallet's private migration. ZIP 318 recommends splitting balances "into notes with values drawn from a fixed set of denominations" and sending them "as multiple transactions submitted to the chain over time". Cake Wallet does this with "standard denominations (i.e. 10 ZEC, 1 ZEC, 0.1 ZEC, etc.)" (Cake Wallet).
• If you move funds by hand, use round amounts. Zodl: "Plenty of people will send 10 ZEC, but few will send exactly 10.3467 ZEC."
• Avoid amounts that already appear in public. Zodl: "If you withdrew a specific sum from an exchange, sending that same sum across the shielded pools connects the two actions."
• Minimise pool crossing in general. ZIP 315: "We want to minimize pool crossing."

Wallet-by-wallet migration steps are in how to migrate Orchard funds to Ironwood.

Mistake 3: shielding many transparent addresses at once

What people do: collect ZEC at several transparent addresses (exchange withdrawals, mining payouts, old wallets) and then press "Shield all".

What it reveals: every address spent in one transaction is publicly linked to the others. ZIP 315: "A shielding transaction is always linked to the transparent addresses it spends from… if the inputs to the transaction are associated with multiple transparent addresses, those addresses will be linked to each other." ZecHub puts it simply: "Shielding several addresses in one transaction publicly links them as belonging to the same person" (ZecHub).

The fix:

• Shield one address per transaction. ZIP 315: "UTXOs received on different transparent receivers SHOULD NOT be shielded in the same transaction." Zkool's quick start describes its "Shield One" button as one that "restricts to using one transparent address to prevent linkability" (Zkool).
• Space those shielding transactions out. ZIP 315 again: "Ideally, when they are shielded in separate transactions, this should be done in such a way that the timing of those transactions is not linkable."
• Several payments to the same address can be shielded together safely: ZIP 315 says that is "not leaking additional information".

More on shielding flows: how to shield Zcash.

Mistake 4: reusing addresses, or publishing one address everywhere

What people do: give the same address to every exchange, client and friend, or post one donation address on several profiles.

What it reveals: anyone who sees the same address in two places knows both belong to one wallet. For transparent addresses it is worse: every payment, balance and spend is public. Ywallet's documentation adds that "chain analysis tools use powerful heuristics that defeat one-time addresses. Often, they can link transactions based on other characteristics such as time and amount" (Ywallet).

The fix:

• Use a fresh shielded address for each counterparty. Zodl does this automatically: "the shielded address changes whenever you load the Receive screen". It explains why: "Giving out a new shielded address each time ensures that you are not linked across multiple services for having provided the same address" (Zodl support).
• Diversified shielded addresses are unlinkable; transparent ones are not. ZIP 316: unlinkability "is only partially achieved if the UA contains a Transparent P2PKH Address, since the on-chain transaction graph can potentially be used to link transparent addresses".
• For a public donation address, use a shielded-only address and accept that everyone knows it is yours. Never post a transparent one if you care about your balance being visible.

Mistake 5: handing out a unified address with a transparent receiver

What people do: give a u1… unified address to an exchange or wallet that can only pay transparent addresses, and assume the payment arrived privately.

What it reveals: a sender must use "the most preferred Receiver Type that it supports" (ZIP 316). A transparent-only sender pays the transparent receiver inside your UA, publicly. ZIP 316's own rationale admits the problem: "there was no way for a user to visually distinguish a Unified Address that allowed the receipt of transparent funds from one that did not."

The fix:

• Use a shielded-only address for shielded senders. Cake's Receive screen defaults to "Shielded (Ironwood)" and offers "Unified" separately (Cake Wallet).
• Give transparent-only services a dedicated transparent address, so you know that payment will be public and can shield it on its own (see mistake 3).
• Watch for ZIP 316 Revision 2 (Draft): a zu… address "MUST NOT contain any transparent Items", so the prefix alone tells you it cannot be paid transparently.

Details in Zcash unified addresses in depth.

Mistake 6: ignoring the network layer

What people do: use a light wallet over an ordinary internet connection and assume shielding covers everything.

What it reveals: your wallet's server sees your IP address and the transactions you broadcast. Zooko explained it during the Ironwood migration: your "server/endpoint/lightwalletd sees your IP address that you are connecting from when you make that transaction, which means that server will be able to link your IP address with the amount of your Orchard funds" (Zcash Community Forum). Zingolib's documentation lists the same limits: "the server can learn what blocks contain your shielded transactions" and "also learns other metadata about you like your ip address" (Zingolib). Zodl calls this "the largest single thing you control" (Zodl support).

The fix:

• Turn Tor on and leave it on. Zodl: "switch it on once and leave it on rather than turning it on just before a transfer." Turning it on only for sensitive transfers marks those transfers out.
• A VPN is a fallback, not a cure. Zodl: "A VPN moves the observer from your wallet's server to your VPN provider, rather than removing the observer entirely."
• ZIP 318 asks wallets to give users "an informed choice about network-layer privacy options (Tor, VPN, or Nym)" before migrating.

Mistake 7: predictable timing

What people do: make related transactions minutes apart, at the same time every day, or right after a public event (an exchange withdrawal, an announced payment).

What it reveals: timing is the main signal that links otherwise hidden actions. NU7's faster blocks make it slightly sharper. ZIP 218: "More frequent blocks give observers finer timing information, which may be combined with network-layer or application-layer observations." ZIP 315 lists "How should wallet developers time transactions to avoid linkability?" as an open question. There is no complete answer yet.

The fix: Zodl's advice (Zodl support):

• "Leave days between transfers, not minutes."
• "Vary the time of day you send. Sending every evening at nine is a pattern in itself."
• "Do not pair a transfer with anything else that identifies you, such as a payment you have announced publicly."

ZIP 318's migration design goes further, with "behavioural de-correlation": broadcasts that "reveal neither when the user opens the application nor when the wallet has synchronized". This is one reason to let a wallet's built-in migration schedule transfers rather than doing it yourself in one sitting.

Mistake 8: deshielding carelessly to exchanges and TEX addresses

What people do: send from a shielded balance straight to an exchange's transparent deposit address, or pay a TEX (tex1…) address, without thinking about what becomes visible.

What it reveals: deshielding publishes the amount leaving the pool and the receiving address. Paying a TEX address is designed to leave a public trail. ZIP 320 requires that only transparent funds pay a TEX address, so a wallet paying one from shielded funds "MUST create two transactions: one that unshields the funds to an ephemeral transparent address, and one that spends from that ephemeral address to the destination TEX Address". The exchange can then see which transparent address paid it.

The fix:

• Withdraw from exchanges to shielded addresses where the exchange supports it; see which exchanges support shielded withdrawals.
• When you deposit to an exchange, accept that it knows who you are anyway (KYC). What you can protect is the link between that deposit and the rest of your shielded history. Use an amount that is not your whole balance, and do not deposit right after receiving the same amount.
• Never send to a transparent address from mixed sources. ZIP 315: "A wallet MUST NOT send funds to a transparent address unless all of the source funds come from shielded pools, and this SHOULD be a single shielded pool."
• Avoid "opportunistic shielding". ZIP 315 asks wallets not to mix earlier transparent receipts into a payment you are making, because the link "will be visible to the recipient(s)". If your wallet asks whether to include transparent funds in a send, say no and shield them separately.

Mistake 9: oversharing keys, screenshots and lookups

What people do: paste a viewing key into a website, post a screenshot of their wallet, share a full address in a support chat, or look up their own addresses on public explorers from their home IP.

What it reveals:

• A viewing key reveals your history. ZIP 316 explains that viewing keys "allow observation of transaction activity across all pools, including transparent". A full viewing key cannot spend, but it shows everything you did.
• Screenshots and copied text travel. Zingo blocks "Screenshots and screen recording… on the seed and key screens" and clears a copied seed or viewing key "from the clipboard after 60 seconds" (Zingo). These protections exist because these leaks are common.
• Explorer lookups link you to addresses. The explorer's server sees your IP and the address or transaction you searched for.

The fix:

• Share a viewing key only with someone you would show your bank statements to, such as an accountant or auditor, and import it on your own device for view-only use. See set up a view-only Zcash wallet.
• When asking for help, share only an address prefix or a transaction ID, never a seed, never a spending key.
• Look up sensitive addresses over Tor or a VPN, or use your own node.
• Use your wallet's "hide balances" option in public. Zingo offers "Hide sensitive values from the header".

Bonus leaks the standards warn about

Dusting

ZIP 315 describes a "dusting attack" in which "the adversary sends a victim lots of small-valued notes (or notes with strategically chosen values), increasing the probability that the victim's transactions will have a larger number of spends than other transactions". It admits the countermeasures "have not been implemented yet". If you receive many tiny unsolicited payments, consolidating them in a transaction to yourself, separately from your real payments, keeps them from shaping those payments.

Expired transactions

If a shielded transaction is broadcast and then becomes invalid, for example because it expired or the chain rolled back past its anchor, "the nullifiers of spent shielded notes will have been revealed, linking this transaction to any future transactions that spend those notes" (ZIP 315). ZIP 218 repeats this for the shorter post-NU7 anchor window. Keep your wallet updated so it uses current expiry settings (120 blocks after NU7, per ZIP 218), and avoid broadcasting from a badly out-of-date wallet.

Old pools

Staying in an old pool makes you part of a shrinking crowd. On 21 October 2026, ZecBlock figures quoted in ZIP 218 put about 83.0% of shielded ZEC in Ironwood, 9.6% in Sapling, 7.0% in Orchard and 0.4% in Sprout. The smaller the pool, the smaller the crowd you hide in. Our shielded pool page shows current figures.

Three worked examples: the leak and the fix

The exchange round trip

Leak: Alice withdraws 5.000 ZEC from Exchange A to her transparent address at 14:02, shields it at 14:05, and at 14:20 sends 4.999 ZEC from her shielded balance to Exchange B's deposit address. Anyone can see 5.000 ZEC leaving A, 5.000 ZEC entering the pool from her address, and 4.999 ZEC leaving the pool to B a quarter of an hour later. With the fee accounted for, the link is obvious (mistakes 1, 7 and 8).

Fix: withdraw from A directly to a shielded address if A supports it. If not, shield, then wait days, not minutes. Send B a different, rounder amount, from a balance that has been shielded for a while, with Tor on.

The tidy-up

Leak: Bob has old transparent ZEC at four addresses: two exchange withdrawals, a mining payout and a gift. He presses "Shield all". One transaction now proves all four addresses are his, and since the mining payout address is on a pool's public payout list, his exchange withdrawals are now linked to his mining (mistake 3).

Fix: shield each address in its own transaction, a day or more apart, starting with the one he cares least about.

The migration

Leak: Carol has 37.42 ZEC in Orchard. Right after Ironwood launches, she sends all 37.42 ZEC to her own Ironwood address from her home connection. The chain shows 37.42 ZEC leaving Orchard at a specific block, and her wallet's server saw her IP broadcast it (mistakes 2 and 6).

Fix: use her wallet's private migration, or move 10, 10, 10, 5, 1, 1 and the remainder as separate transfers over several days, with Tor on throughout. Zodl adds a trap specific to its wallet: because it spends Ironwood funds first, "each transfer has to be larger than your current Ironwood balance, or it will spend the funds you already moved instead of drawing on Orchard" (Zodl support). So with Zodl, the order of amounts matters too.

A self-check before you send

How much does each mistake cost?

Not all leaks are equal. This is our judgement, not a measurement:

The common thread: shielding protects data on the chain; habits protect everything else.

Choosing tools that avoid these mistakes for you

Some wallets prevent several mistakes by design:

• Zodl requires that "ZEC must be shielded before spending" (Zodl support), rotates addresses, offers Tor, and has a private Ironwood migration.
• Cake Wallet shields automatically and migrates in standard denominations.
• Zingo sends over a mixnet that fails closed.
• Zkool offers Shield One, coin control and Tor or Nym, but no automatic shielding.

None prevents all nine. Comparisons are in best Zcash wallets and our wallet directory.

What shielding does not protect against

To set expectations:

• Exchanges with KYC know who deposits and withdraws.
• The person you pay knows they were paid, and by which address if you tell them.
• Your device holds your keys and history; malware on it defeats everything.
• Metadata outside Zcash, such as emails, invoices and chat messages, can link payments to people.

Zcash makes the blockchain itself private. The rest is up to how you use it.

Our recommendation: For privacy-focused crypto research and news, the team's Telegram channels @cryptoresearch and @OnlyFinance_Pro cover privacy coins and personal-finance security. Never share keys or seed words in any Telegram chat.

FAQ

Is a shielded Zcash transaction traceable?

A fully shielded transaction within one pool hides sender, receiver and amount on the chain. Linking usually happens through transparent ends, pool-crossing amounts, timing and network data, as described above.

Does shielding my ZEC make my past private?

No. Shielding hides what happens after the coins enter the pool. The transparent history before that, including the shielding transaction itself, stays public.

Why is my Orchard-to-Ironwood migration amount visible?

Every pool crossing publishes its net amount, so the network can verify supply (ZIP 2006). Use standard amounts spread over time.

Is Tor necessary for Zcash privacy?

It is not required, but without Tor or a mixnet your wallet's server sees your IP address and what you broadcast. Zodl calls this "the largest single thing you control".

Is it safe to reuse a shielded address?

Shielded payments to the same address do not show up on the chain, but anyone you gave the address to can tell it is the same wallet. Use a fresh address per counterparty.

Should I shield all my transparent addresses in one go?

No. That links them all publicly. Shield each address in its own transaction, spaced out.

Can an exchange see my shielded balance?

No, unless you give it a viewing key. It sees what you deposit and what it sends you.

Are viewing keys dangerous?

They cannot spend, but a full viewing key reveals your transaction history. Treat it like a bank statement.

Does NU7 make Zcash less private?

It does not change what a transaction reveals. ZIP 218 notes finer timing information and a shorter anchor window, both minor.

What is the single most important habit?

Keep funds shielded at rest, in the newest pool, and spend shielded-to-shielded. Then add network privacy.

Are Sapling funds less private than Ironwood?

Both are shielded. A smaller pool is a smaller crowd, and moving between them publishes the amount, so keep funds where most other users are once you have moved.

Sources

• Kappos, Yousaf, Maller, Meiklejohn: An Empirical Analysis of Anonymity in Zcash (USENIX Security 2018)
• ZIP 315: Best Practices for Wallet Implementations
• ZIP 316: Unified Addresses and Unified Viewing Keys
• ZIP 318: Orchard to Ironwood Migration
• ZIP 2006: Restricting Transfers into the Orchard Pool
• ZIP 209: Prohibit Out-of-Range Chain Value Pool Balances
• ZIP 218: 25-second Block Target Spacing
• ZIP 320: TEX addresses
• Zodl support: Shielding transparent ZEC
• Zodl support: Migrating to Ironwood (self-migration)
• Zodl support: Why does my receiving address change?
• Zodl support: Enabling Tor protection
• Cake Wallet: Zcash
• Cake Wallet: Ironwood migration
• Zkool README
• Zkool quick start
• Zingo mobile README
• Zingolib README
• Ywallet: One time transparent address
• ZecHub: Zcash Wallet Fund Recovery
• Zcash Community Forum: Ironwood update for users