Zcash's shielded transactions do what they claim. The amounts and the addresses are encrypted, and the proof system has spent roughly 10 years under academic attention aimed squarely at breaking it, and the flaws that surfaced in that decade were disclosed and then fixed.
Our guide to whether Zcash is safe covers that record properly. It is not the subject here, and everything below assumes it rather than arguing with it.
What is in question is the space around it. There are 4 places a shielded payment can leak information, and none of them involves breaking the cryptography. They sit outside it, in the network you broadcast on, the server your wallet asks, the transparent addresses on either side, and the account that knows your name.
The protocol's own specification says as much, in a footnote most readers never reach.
What shielding actually covers, so the rest is read correctly
Start with the claim itself, because the leaks below only make sense against a precise version of it. A vague sense that Zcash is private turns every item here into evidence that it is not, which is the wrong conclusion and the easiest one to reach.
The specification is careful about scope. Its privacy claim carries a footnote reading "We make this claim only for fully shielded transactions", and the same footnote says it "does not exclude the possibility that an adversary may use data present in the cleartext of a transaction such as the number of inputs and outputs, or metadata-based heuristics such as timing, to make probabilistic inferences about transaction linkage" (source: Zcash protocol specification).
Read that twice, because it is the whole article in one sentence. The cryptographic guarantee is real and it is bounded, and the project drew the boundary itself rather than being caught at it.
It is also worth noticing what kind of statement that footnote is. It is not a disclaimer bolted onto marketing copy. It is a scoping note inside a consensus specification, written for people implementing the protocol, which is the audience least served by overstatement.
Two things follow. A fully shielded transaction gets the strong claim. A transaction with any transparent part gets a weaker one, and the specification points readers at three separate references for what that weakness looks like in practice, one of which is the project's own blog.
Our guide to how Zcash privacy works covers the proof system this section is conceding, and our guide to whether Zcash is traceable covers the pattern analysis that reads the cleartext the footnote mentions. Neither is re-taught here; this node is about the surface those two leave over.
The network you broadcast on
The first leak happens before your transaction is anywhere near a block. Sending it means announcing it to peers over the internet, and an announcement carries the address it came from. This is true of every chain and it is not a Zcash flaw, which is exactly why it is easy to forget.
The project's own wallet threat model states the consequence without hedging: "The adversary knows the user's IP address, which could lead them to the user's real identity" (source: Zcash wallet threat model).
Notice what that does and does not say. It does not say the transaction contents are exposed. The amounts stay encrypted and the addresses stay hidden. What escapes is the fact that a particular internet connection submitted a shielded transaction at a particular moment, which is a different piece of information and sometimes a more useful one.
Combine it with the timing heuristics the specification's footnote mentions and the shape of the problem is clear. An observer who cannot read your payment may still know you made one, when, and from where.
There is a second-order version worth naming. Because the leak is about connections rather than contents, it scales with how often you transact rather than with how much you move, and it accumulates: one broadcast is a data point, a hundred from the same connection is a pattern.
Our guide to crypto privacy basics covers the general form of network-level exposure across chains, and our guide to Bitcoin privacy basics covers the same layer on a chain with no shielded mode at all.
The server your wallet asks
The second leak is the one most people have never considered, and it applies to nearly every wallet on a phone. A phone cannot hold the whole chain, so it asks a server, and asking is itself an act that reveals something.
The architecture is specified. A light client system has a node, a wallet, and in between "a proxy server that extracts block chain data from zcashd to store and serve it in a lower-bandwidth format", and the design document names the goal plainly: "the proxy should not learn which transactions (received from the block chain) are addressed to a given light wallet" (source: ZIP 307).
That the goal has to be stated tells you it is not free. A design goal is a thing the system is trying to achieve, not a thing that is automatically true of every deployment. ZIP 307 carries the status Draft, so it is the design document rather than a description of what every wallet in the world actually does.
The practical version is simple. The server you query is a party to your privacy in a way the blockchain is not, and which server that is depends on which wallet you chose, which is a decision most users make without ever seeing this trade-off.
Worth stating precisely, because the distinction gets lost: the server does not learn what your transaction says. The encrypted contents stay encrypted whoever is serving them. What a server is positioned to observe is the pattern of a client's requests, which is a metadata question rather than a cryptographic one, and it is the same category as the network leak above.
Our guide to Zcash wallets compared covers what the available clients are, and the coverage here deliberately stops short of telling you which to use.
The transparent side, on both ends
The third leak is not in the protocol at all. It sits in how people use it, and by volume it is the largest of the four. Nothing here is a flaw in the shielded design; it is what happens when a two-mode system meets an ecosystem that mostly speaks the other mode.
The result is that value spends much of its life on the public side of Zcash, and the crossings are visible even when the middle is not.
Zcash keeps two kinds of address. The project has described the pairing as an advantage that gives users flexibility, while noting that "the dynamic between transparent and shielded addresses, however, presents a level of increased complexity for transactions containing both types" (source: Electric Coin Company).
The measured version of that complexity is blunter, and it belongs in the next section because of where those coins end up.
The mechanism is simple enough to state here. Value that enters the shielded side from a transparent address, and leaves to another one, is bracketed by two public events. The middle is genuinely private. The entry and the exit are not, and an observer with both ends has a much smaller problem than one with neither.
Our guide to whether Zcash is traceable covers what an analyst can do with those brackets, which is a separate question this article routes rather than answers. Our guide to address reuse covers the general version of the same failure.
For the mechanics of how the public side gets inspected at all, our guide to reading a block explorer is the starting point.
The account that already knows your name
The fourth leak has nothing to do with cryptography, and it is the strongest of the four. It is the exchange, and it applies to BloFin exactly as it applies to every other venue, which is worth saying plainly on a page an exchange publishes rather than leaving as an exercise for the reader.
Start with where the value goes. A 2017 analysis of shielded usage found that "most coins sent to shielded addresses are later sent back to transparent addresses" (source: Quesnelle 2017). That study pre-dates Sapling and the pools have changed several times since, so read it as a statement about behavior at the time rather than a current measurement. What has not changed is that the transparent side is where identified venues operate, so a return trip usually ends somewhere that knows who you are.
An exchange that lets you buy or sell ZEC knows who you are, because it collected that information to open the account. It also knows every deposit and withdrawal you make through it, including the addresses on the other side. Nothing about a shielded transaction changes either fact.
What that produces is an identity anchor at the boundary. The chain may not reveal that a shielded payment was yours; the venue's records may show that ZEC left your account to a specific address a few minutes earlier.
This is the leak readers most often assume away, because it feels like a different topic from privacy technology. It is the one place here where the counterparty holds the information rather than an observer having to infer it, which makes it categorically stronger than the other three.
Being specific about the limit matters here too. The venue knows what passed through it. It does not know what happened to value after it left, and it cannot read a shielded transaction any better than anyone else can. The anchor is at the boundary, not inside the pool.
Our guide to KYC and AML covers why the collection happens, and our guide to what self-custody means covers the structural alternative.
Underneath both sits the question of who holds the keys at all, which our guide to public and private keys answers.
What none of these leaks means
Four things this is not saying, and they matter as much as the four things it does say. A list of leaks reads as an indictment unless somebody states the limits of the list, so here they are, one for each of the sections above and in the same order.
Each is a conclusion a reader could reasonably draw from a list of leaks, and each would be wrong. The whole shape of this article depends on the difference between a claim that is bounded and a claim that is broken, so it is worth closing the loop explicitly rather than trusting the tone to carry it.
It is not saying the cryptography is broken. Every leak above sits outside the proof system, and none of them recovers an encrypted amount or a hidden address. The specification's footnote concedes exactly this surface and no more.
It is not saying the project hides these limits. The opposite: the light wallet server's own documentation tells developers to read the threat model, "since it contains important information about the security and privacy limitations of light wallets that use lightwalletd" (source: lightwalletd). The limitations are documented by the people who built the thing.
It is not saying every user faces all four. They stack differently depending on how value enters and leaves, and a fully shielded transaction between two self-custodied wallets faces a different set from a round trip through a venue.
And it is not advice. What to do about any of this is generic privacy hygiene, which lives on the security pages rather than here. the job here is to describe the surface accurately, and the honest description is that the strong claim is real, narrow, and surrounded by ordinary infrastructure that was never part of the claim.
Which leaks you can close, and how much each one buys
The four surfaces above differ enormously in how much they cost to close and how much closing them achieves. Ranking them prevents the common outcome, which is effort spent on the cheapest surface and none on the largest.
The account that knows your name is the largest and the hardest. It exists before any transaction and it is created by design rather than by carelessness. Nothing you do afterwards removes it, and the only levers are choosing where that relationship exists and understanding what it covers. Our page on venue and custody risk covers the consequences.
The transparent side is the second largest and it is the one you control most directly. Every crossing between the two sides is recorded with its amount, so the choices that matter are how much crosses, when, and in how many pieces. This is where most of the achievable improvement actually lives.
The server your wallet talks to is third. It sees what your software asks for and when, which is a real surface, and it is closed by running your own or by choosing software that fetches more than it needs. Both are available and both cost convenience.
The network you broadcast on is fourth and the cheapest to address. Broadcasting through a privacy-preserving transport removes it, the tooling is mature and the cost is a small amount of latency.
The ranking matters because effort is finite. Someone who routes their traffic carefully and then withdraws a round number from a verified account straight into a shielded address, immediately, has closed the smallest surface and left the largest wide open.
Why the leaks compound rather than add
Each surface above is manageable alone, and the reason the combined picture is worse than the list suggests is that they intersect.
An observer with two weak signals often has more than an observer with one strong one, because the second narrows the candidates the first produced. A timing correlation that would be meaningless on its own becomes decisive once the amount matches, and an amount match that could be coincidence stops being coincidental once the timing agrees.
This is why the honest description of the risk is behavioral rather than cryptographic. Nothing in the proofs weakens. What happens is that the context around a strong guarantee accumulates until the guarantee has fewer possibilities left to hide among.
It is also why advice of the form "just do X" fails here. There is no single action that closes the combined surface, and the useful posture is to understand which signals you are producing rather than to look for one setting that stops producing them.
There is one more property of the combined picture worth stating, because it changes how the risk should be weighed rather than merely described. Every signal above is permanent once produced. A network observation, a server query, a crossing recorded on the chain and an account record all persist independently of anything you do afterwards, and they can be combined by somebody who acquires them years apart. That is why the honest framing is forward-looking: the question is never whether past activity can be made private, which it cannot, but what the next transaction adds to the record.
Frequently asked questions
Does a shielded transaction hide my IP address?
No, and it was never designed to. Shielding encrypts the amounts and addresses inside the transaction. Broadcasting that transaction is a separate act that happens over the internet, and the Zcash wallet threat model states directly that an adversary knowing a user's IP address could be led to their real identity. The transaction contents and the network layer are two different surfaces, and shielding covers only the first.
Can the server my wallet connects to see my transactions?
It should not be able to link them to you, and that is stated as a design goal rather than as a guarantee. The light client specification says the proxy should not learn which transactions are addressed to a given light wallet, and that specification carries the status Draft. What the server does see is that a particular client is querying it. Which server you use depends on which wallet you chose.
Does moving coins in and out of the shielded pool undo the privacy?
It does not break the encryption, and it does narrow things. A transparent deposit and a transparent withdrawal are both public events, so an observer sees value entering and value leaving even though the shielded portion between them is private. A 2017 study found most coins sent to shielded addresses were later sent back to transparent ones, which is a statement about how people used it then rather than about how the protocol works.
Does using an exchange defeat Zcash privacy?
It does not defeat the cryptography, and it does add an identity anchor the chain does not have. Any venue that verified your identity knows who you are and knows the addresses you deposited from and withdrew to. That is true of BloFin and of every other venue that lists the asset. Whether it matters depends entirely on what you were trying to keep private and from whom.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include the Zcash protocol specification, the Zcash Improvement Proposals repository, the Zcash wallet threat model and peer-reviewed research cited by the specification itself. All facts independently verified against cited documentation current as of August 2026. what follows contains no price figure and no advice about how to configure any wallet.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Do your own research before making any decision.