Your ZEC arrived from an exchange and it landed on the transparent side of Zcash, where everyone can see it. Moving it into a shielded pool is 1 transaction, and it is the most useful thing most holders will ever do with this asset.
It is also less powerful than it sounds, in a specific and checkable way. Shielding hides what happens next. It does not hide what already happened, and the transaction that does the shielding publishes the amount.
Three different searches for how to do this return nothing at all. So here is the operation, described from the reference implementation, then exactly what it leaves behind.
Why the coins arrive transparent in the first place
Almost every withdrawal from an exchange lands at a transparent address, and that is a fact about how venues are built rather than a limitation of Zcash. Sending to a shielded address requires a wallet that can construct a shielded output, which is meaningfully more work than sending an ordinary transaction.
So the common path looks like this. You buy on a venue. You withdraw, and the coins appear at an address that behaves exactly like a Bitcoin address: the amount and both addresses are in public view, permanently.
Nothing has gone wrong at that point. It is simply that the coins are sitting in the part of Zcash that offers no privacy at all, which is the part that exists so the asset can interoperate with everything built for transparent chains.
How much this matters to venues is visible in the protocol itself. There is a whole specification devoted to an address encoding that accepts deposits only from the transparent side, written so a venue can refuse what it cannot account for (source: ZIP 320).
That specification exists because the transparent side is where venues operate, and it is the clearest available evidence that a transparent arrival is the normal case rather than an accident of your particular withdrawal.
Our guide to how exchange custody works covers what the venue held before it sent anything, and our guide to Zcash wallets compares the software that can receive shielded funds directly. If yours can, the whole problem below is avoidable by never landing transparent at all.
This article is for the case where that already happened.
What shielding actually is, as an operation
Shielding is a transaction rather than a setting or a mode you switch on, and describing what that transaction contains is the clearest way to understand what it achieves and what it cannot. Everything the operation does and fails to do follows directly from its contents, so the contents are where this section starts rather than ends.
The reference wallet implementation describes the operation precisely. It "constructs a transaction that consumes available transparent UTXOs belonging to the specified secret key, and sends them to the most-preferred receiver of the default internal address for the provided Unified Spending Key" (source: zcash_client_backend).
Unpack that and the whole thing follows. The transaction spends transparent outputs. Those are public, and it creates a shielded output, which is not. So the transaction has a public half and a private half by construction, and the boundary between them is exactly where the information leaks.
Note also where the funds go: an internal address belonging to the same wallet. Shielding is a transfer to yourself. Nothing changes hands and nobody else needs to be involved.
One more detail from that description is worth pulling out. The transaction consumes outputs "belonging to the specified secret key", which means shielding operates on the funds one key controls rather than on a wallet's whole balance. A wallet holding transparent funds under several keys may need more than one such transaction.
That is invisible in most software and it explains an otherwise-confusing outcome, where shielding appears to work and part of a transparent balance stays put.
Our guide to how transaction outputs work covers the accounting model both sides share, and our guide to Zcash address types defines transparent and shielded addresses properly.
For the general shape of the problem this operation addresses, our guide to crypto privacy basics is the starting point, with Bitcoin privacy basics covering a chain that has no shielded side to move to.
The fee rule that surprises people
One condition in the reference implementation catches people out regularly, and knowing it beforehand saves the confusion of watching a wallet appear to do nothing at all. The behavior is a documented rule rather than a bug, and it follows from the fact that moving value on any chain costs something.
The same documentation quoted above states the condition: the procedure "will not attempt to shield transparent funds if the total amount being shielded is less than the default fee to send the transaction", and "fees will be paid only from the transparent UTXOs being consumed".
Two consequences follow. Very small transparent balances cannot be shielded at all, because moving them would cost more than they are worth, and a wallet that refuses to act on a dust balance is behaving correctly rather than failing.
And the fee comes out of the transparent side, not from shielded funds you might already hold. The amount that lands in the pool is what was there minus the fee, which is worth expecting so the arriving balance does not look wrong.
The same library treats this as a general problem rather than a special case. Its fee module carries a dust-output policy, described as "a policy describing how a ChangeStrategy should treat potentially dust-valued change outputs (outputs that are likely to be without economic value due to fee rules)", alongside change strategies implementing the network's fee rules (source: zcash_client_backend fees). The shielding interface itself has changed repeatedly across releases of that library (source: librustzcash changelog), which is one more reason to take the concept rather than the call signature from any written description.
The wider point is that shielding has a floor. Below some amount the operation is not economic, and that floor moves with fees rather than being a fixed number, which is why no figure appears here.
It also means the answer to "should I shield this" is partly arithmetic rather than entirely a privacy judgment. A balance small enough to be near the floor is a balance whose privacy is worth less than the fee to protect it.
What shielding leaves on the record
This is the section the node exists for, and it needs to be exact rather than reassuring. Two things survive a shielding transaction, both of them permanent and both of them checkable by anyone with a block explorer, and neither is a subtle cryptographic caveat. They are plain facts about what the transaction contains.
The transparent inputs stay visible forever. The shielding transaction spends outputs that arrived at your address from somewhere, and that arrival is a permanent public record. Shielding adds a later event; it does not remove an earlier one. Anyone who knew the coins were yours before still knows it.
The amount is published in plaintext. This is the part almost nobody mentions. The value crossing between the transparent side and a shielded pool is carried in an ordinary integer field in the transaction. The protocol specification describes valueBalanceSapling as an int64 holding "the net value of Sapling-pool spends minus outputs", and carries an equivalent field for the Orchard pool (source: Zcash protocol specification).
Which of the two applies depends on which pool your wallet shields into, and it makes no difference to the point: whichever pool receives the value, the amount crossing the boundary is a plain number in the transaction.
So a shielding transaction announces, in the clear, that a specific transparent address moved a specific amount into a shielded pool at a specific time. What happens to that value afterwards is genuinely private. The act of putting it there is not.
Put those two together and the honest description is this: shielding creates a clean starting point, and it leaves a signpost at the entrance. The value inside the pool is protected. The fact that you put it there, and how much, is on the chain.
Our guide to Zcash traceable takes up what an analyst builds from that signpost. Read it before deciding this operation solves a problem it does not.
Both of those facts are checkable rather than taken on trust. Our guide to reading a block explorer covers how to look at your own shielding transaction, and our guide to address reuse covers what happens when the transparent address involved is one you have used before.
What the network can still see
The observability described above is not incidental and it is not a wallet's failing. It is built into a consensus rule, which is about as strong as evidence gets: a rule the network enforces on every block is a rule the network must be able to evaluate, and evaluating this one requires seeing the flows.
The proposal that defines that rule says so in its own motivation. "It is possible for nodes to monitor the total value of notes that are shielded to, or unshielded from, each of the Sprout, Sapling, Orchard, and Ironwood chain value pools" (source: ZIP 209).
The rule itself prohibits blocks that produce negative shielded pool balances, which is how the network guarantees that no more value leaves a pool than entered it. That guarantee is valuable and it has a cost, and the cost is exactly this visibility.
At the aggregate level this means anyone can watch value flowing into and out of each pool over time. At the individual level it means your shielding transaction is one of the contributions to that flow, with its amount stated.
None of that breaks the privacy of what happens inside the pool. Payments between shielded addresses reveal neither amounts nor participants, and that property is untouched by any of this.
What it does mean is that the entrance and the exit are both lit. Value crossing into a pool is announced, value crossing out is announced, and only the middle is dark. Our guide to Zcash privacy leaks and metadata handles the other surfaces that stay visible around a shielded payment.
Limits of this procedure
Four limits, and together they are why what follows describes an operation rather than recommending one. Each is a thing a reader could reasonably believe shielding delivers, each is something it does not, and none of them is a criticism of the design. They are consequences of what the transaction contains.
It is not retroactive privacy. Nothing you do after a public transaction makes that transaction private. If the concern is a record that already exists, shielding does not address it and no operation in Zcash does.
It is not a step-by-step you should run from a web page. The description above comes from a reference implementation, and every wallet exposes it differently. The software itself is moving too: the node wallet most documentation still describes is being replaced by a rewrite whose own README says its crates are "under development and have not been fully reviewed" (source: Zallet). Take the concept to whatever software you use rather than taking commands from an article.
It is not a substitute for landing shielded in the first place. If your wallet can receive a shielded withdrawal directly, that path avoids the public arrival entirely and there is nothing to clean up afterwards.
It is also not only a retail operation. A separate shielding call exists for mined outputs, documented for "Miners, Mining pools, Online wallets" (source: Zcash documentation), which is a reminder that transparent-to-shielded movement is a routine part of how this chain works rather than a privacy trick.
And it is not the end of the privacy question. Network-level metadata and the venue that verified your identity are both untouched by this operation, and our guide to Zcash privacy leaks and metadata handles both.
Our guide to what self-custody means covers the decision that sits underneath all of this.
BloFin earns on trading activity rather than on what you do after a withdrawal, which is why what follows describes the operation and its limits instead of selling either.
A worked sequence, with the timing decisions in it
The operation is short and the decisions around it are what matter, so here is the whole thing in order.
Funds arrive at a transparent address you control. The chain records the amount, the sending address, and the receiving address, and that record is permanent regardless of what happens next.
You wait. This is the step people skip and it is the one that does most of the work. A crossing into the private side that follows the arrival immediately, for the same amount, is the easiest pattern on the chain to link. Time and a difference in amount both break that link, and neither costs anything.
You shield some or all of it. The chain records that value crossed from the public side into the private side, with the amount, because pool balances are tracked openly. What it does not record is anything about what happens inside.
You wait again before spending. The same reasoning that applies to the crossing in applies to the first payment out, for the same reason.
Then you transact inside the private side. From here the guarantee is the strong one: nothing about sender, recipient or amount is published, and each further transaction adds nothing to the public record.
The pattern worth noticing is that the cryptography is doing its job at every step, and the entire quality of the outcome is decided by the timing and the amounts, which are yours.
What the exchange knows either way
Three things, and none of them changes when you shield.
It knows your identity, because you verified it to open the account. That link exists before any transaction and no later action removes it.
It knows the withdrawal: the amount, the time, and the address it sent to. That is its own record and it keeps it independently of the chain.
And it can see, on the public chain, whatever that address does afterwards while the funds remain transparent. Shielding ends that visibility going forward and does nothing about what came before.
The practical implication is that shielding protects the future rather than the past, and that the strength of the protection depends on how much of the past you hand it. Withdrawing a round number and shielding it whole tells a different story from withdrawing over time and shielding in unequal pieces.
That is also the reason the operation is worth describing rather than recommending. Whether shielding is worth doing at all depends on what you intend to do next, and for someone who plans to sell back to the same venue shortly, the crossing in and the crossing out simply add two more recorded events to the picture. The value is in what happens between them, and if nothing happens between them there is little to protect.
Frequently asked questions
Does shielding my ZEC hide where it came from?
No, and this is the most important thing to understand before doing it. A shielding transaction spends transparent outputs, and those outputs and their history remain permanently visible on the chain. What shielding protects is what happens to the value afterwards. The arrival from an exchange, the address it landed at, and the shielding event itself all stay public. Shielding gives you a private future, not a private past.
Is the amount I shield visible?
Yes. The value moving between the transparent side and a shielded pool is carried in a plain integer field in the transaction, which the protocol specification describes as the net value of pool spends minus outputs. So the chain records that a particular transparent address moved a particular amount into a pool at a particular time. Amounts moving between two shielded addresses are encrypted; the amount crossing the boundary is not.
Why did my wallet refuse to shield a small balance?
Because shielding it would cost more than it is worth. The reference implementation will not attempt to shield transparent funds if the total being shielded is less than the default fee for the transaction, and fees are paid only from the transparent outputs being consumed. A wallet declining to act on a dust balance is following that rule rather than malfunctioning. The floor moves with fees, so no fixed figure applies.
Should I shield immediately after withdrawing?
That is a judgment the coverage here deliberately does not make for you. Waiting does not make the eventual shielding transaction more revealing, and acting immediately does not make it less so, since the arrival is already recorded either way. What changes with timing is how much other activity sits between the two events. Our guide to Zcash traceable covers what patterns that creates.
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, and the reference wallet backend's published API documentation. All facts independently verified against cited documentation current as of August 2026. what follows describes an operation and does not give commands to run, and it makes no claim that shielding makes past activity private.
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.