When a service won't accept your Zcash shielded or unified address
You paste a Zcash unified address (u1…) into a withdrawal form and it comes back "invalid address". The address is usually fine. The service simply does not support sending to that receiver type, and rather than saying so it fails validation.
Support varies a great deal between services, so this is not a statement about every exchange — some do support shielded withdrawals. But it is common enough that it is worth knowing what is happening and what to do about it.
Why a service might only support transparent addresses
Transparent addresses (t1…, t3…) behave like Bitcoin: the sender can see the payment on-chain afterwards, confirm it landed and reconcile against a public ledger.
Shielded output changes that. The Zcash documentation is explicit that for a shielded transaction, value "is not revealed on the blockchain." For a service, that affects several practical things at once:
- Monitoring — no public record of the outbound payment it can inspect later.
- Tooling — most chain-analysis tooling reads transparent ledgers and has nothing to read here.
- Implementation — shielded sending requires wallet support that a transparent-only integration does not have.
Some services implement shielded sending; many implement transparent support and stop there. Where they stop, a u1… may be rejected outright, or the shielded receiver may simply be ignored.
What a unified address does when the sender supports only part of it
This is the part that surprises people, and it is specified behaviour rather than a bug.
A unified address bundles several receivers — Orchard, Sapling, and optionally a transparent one. Under ZIP 316, the sender "MUST use the Receiver of the most preferred Receiver Type that it supports." Orchard is preferred, then Sapling, then transparent.
So if the sending wallet supports only transparent output and your unified address includes a transparent receiver, the payment is made to that transparent receiver. The withdrawal succeeds and the funds arrive transparent, even though you supplied a u1….
Worth noting: ZIP 316 revision 2 introduced variants, including addresses that permit no transparent receiver at all. An address without a transparent receiver cannot be paid by a transparent-only sender — it will fail rather than quietly arrive unshielded.
Telling the types apart
| Prefix | Type | What an explorer shows |
|---|---|---|
t1… / t3… |
Transparent | Addresses and amounts, like Bitcoin |
zs… |
Sapling shielded | That a transaction exists; not amounts or parties |
u1… |
Unified | Depends which receiver the sender paid |
Unified addresses explained covers what is packed inside the u1… string.
The workflow that works regardless
When a service will not send to a shielded receiver, the established pattern is two steps:
- Withdraw to a transparent address you control (
t1…) in your own Zcash wallet. - Shield the funds yourself — a shielding transaction moves them from the transparent side into the shielded pool.
Your funds end up shielded; the shielding step simply happens under your control.
One caveat. The Zcash documentation notes that for a shielding transaction, value "is revealed on the sender end." So the fact that you shielded some ZEC, and how much, is publicly visible. What you do with it afterwards is not.
There is also a limit worth being honest about: if a service sent you transparent ZEC and you then shield it, that service still knows it sent you that ZEC. Shielding protects what happens next, not what already happened.
Receiving shielded directly instead
The two-step workflow exists because the sender does not support shielded output. Where the sender does, the step disappears.
SwapToZec pays out to the Zcash address you provide and accepts transparent (t1…, t3…) and unified (u1…) formats. Supply a unified address and there is no separate shielding step to perform afterwards.
Common variants of the same problem
"The address is invalid." Often means the shielded receiver is unsupported rather than that the string is malformed. Try a t1… address from the same wallet — if that is accepted, the address format was never the problem.
"It arrived but my wallet shows it as transparent." The sender used the transparent receiver inside your unified address, exactly as ZIP 316 specifies. Shield it yourself in the wallet.
"My wallet gave me a u1… but the form wants a t." Most Zcash wallets can show a transparent receiving address alongside the unified one. Use that, then shield.
Timing
A shielding transaction is an ordinary Zcash transaction and settles like any other. How on-chain confirmations work covers why you wait for confirmations, and Zcash transaction fees and confirmation times covers what it costs.
The short version
A rejected u1… usually reflects what the sending service supports, not a problem with your address. If a unified address includes a transparent receiver, a transparent-only sender will pay that receiver and the funds arrive unshielded. Withdraw transparent and shield yourself, or receive from a sender that supports shielded output directly.