Shielded vs Transparent Zcash for Gambling

By zcashcasinos editorial desk · updated 2026-10-23 · facts checked 2026-10-23

table of contents

1. The pools: transparent, shielded - and the new Ironwood pool
2. Unified addresses: a container, not a promise
3. TEX: when a service demands transparent sources
4. What this means for choosing a casino
5. The honest limits

The pools: transparent, shielded - and the new Ironwood pool

Zcash runs a transparent pool and shielded pools side by side [1]:

• Transparent addresses (t1...) work like Bitcoin: every transaction is fully public. Anyone - including analytics firms and anyone else running a chain scan - can see the amount, the sender and the receiver.
• Shielded addresses encrypt sender, receiver and amount using zero-knowledge proofs. The transaction exists on-chain, and observers can see it happened, but not who paid whom or how much [1].

For gambling, the difference is concrete: a transparent casino wallet and your transparent payout address together build a permanent public record of how much you cashed out and when. A shielded payout breaks that link at the chain level.

The pool map changed in 2026 and the old "Sapling or Orchard" framing is now incomplete [4] [5]:

• Ironwood is the current shielded pool. The Ironwood network upgrade activated on July 28, 2026 at block 3,428,143 and permanently closed Orchard to new deposits - existing Orchard notes migrate one-way into Ironwood through a public turnstile, while the individual notes stay shielded [4] [5] [6]. Three weeks in, over 3.1 million ZEC had crossed the turnstile and supply verification stood at about 95.7 percent [4]; the migration is still running, with roughly 348K ZEC left in the sealed Orchard pool as of late October [1].
• Sapling still exists and shielded wallets still use it, but it is a minority of shielded value today. Of the roughly 17 million ZEC in circulation, 4.96 million - 29.2 percent of supply - sits in the shielded pools, and the bulk of that (4.12M) is already in Ironwood [1].
• The migration hop is public by design. A turnstile transfer reveals the amount crossing and the block height - the sender, receiver and individual notes stay shielded [1] [6]. Wallet vendors therefore recommend migrating in common, denominated amounts rather than one lump transfer; Zodl ships a guided gradual-migration mode for exactly this reason [5], and how each wallet handles the flow was still being coordinated across the ecosystem in July 2026 [8].

The practical consequence for a gambler: your wallet manages the pool mechanics, but the pool you are in changes what is observable. A shielded balance is private; a migration transaction publishes its amount while staying private about who owns it.

Unified addresses: a container, not a promise

Unified addresses (starting u1...) bundle multiple receiver types into one string [2]: typically a transparent receiver, a Sapling receiver and an Orchard receiver. The sender's wallet picks which receiver to pay - and the ZIP is explicit that a sender "MUST use the Receiver of the most preferred Receiver Type that it supports" [2].

This is where the most common misunderstanding lives - documented repeatedly by users in the Zcash community:

1. A u... address can carry a transparent receiver. Paying it via the transparent receiver is a public payment even though the address "looks shielded".
2. The receiver you assume was used is not always the one your wallet actually used.
3. Services receiving a unified address may process it transparent-only on their side.

So the practical rule: never treat an address prefix as a privacy guarantee. What matters is which receiver the payment used - and for payouts from a casino, the only reliable evidence is what the operator documents. Our review pages carry a dedicated "Shielded payouts" fact per casino for exactly this reason: it is the difference between "takes ZEC" and "pays you privately".

One genuine bright spot from the same standard: modern shielded-by-default wallets make the sending side private regardless of the receiver's type - when you pay from a unified address, your address is shielded whatever the recipient uses [2]. The weak leg is almost always the operator's payout path, not your wallet.

TEX: when a service demands transparent sources

In 2024, Binance began rejecting Zcash deposits sent from shielded addresses to its transparent deposit system, and affected users reported frozen credits [7]. The Zcash ecosystem's answer was ZIP-320: TEX addresses - a transparent address type that explicitly requires transparent-source payments, letting supporting wallets manage the two-step flow from shielded funds [3].

For gamblers the takeaway is not the mechanism but the pattern:

• "Accepts ZEC" never means "accepts every ZEC payment path." An operator can accept your transparent deposit while refusing shielded sources, or the reverse.
• Deposit pages that demand TEX addresses are telling you the payment must come from transparent sources. Supporting wallets (Zkool documents TEX sends; others handle the flow transparently in the background) do the unshield-then-pay dance for you, and the destination side of that payment is public [3].
• A plain t-address alone does not force your wallet to spend transparent inputs: sending shielded funds to a t-address hides the source while exposing the destination and amount. TEX is the stricter variant - it exists so the receiver can refuse shielded sources at all.
• Check the cashier and the terms before funding. The wrong path does not lose the money, but it can freeze it for weeks and expose the route [7].

What this means for choosing a casino

Three questions, in order of importance:

1. Which deposit address type does the cashier generate? (t / zs / u - our reviews record it per operator where documented.)
2. Which payout address types does the operator send to? This is the fact that actually protects you. Many operators default to transparent sends even for customers who deposited shielded - if the terms or support cannot confirm shielded payouts, assume transparent.
3. Does anything in the route force a transparent hop? A swap provider that converts your ZEC before it reaches the casino, a TEX-only deposit, a pool-migration hop that publishes its amount, or a payout back to an exchange that rejects shielded sources - each hop re-publishes part of your route.

The payment-route facts behind these questions are documented per operator: the comparison table carries deposit-address type, shielded payouts and swap detours as route chips under the ZEC badge, and the shielded-payout hub filters for operators that document paying out to shielded or unified addresses (none do yet - the honest state of this niche today).

The honest limits

Shielded ZEC is strong chain-level privacy - but it is not magic:

• The casino still knows its own books. Account history, login patterns and payout records exist on their side regardless of pool. Shielded payouts protect you from the public chain and from the casino's wallet being mapped - not from the casino itself.
• Each transparent hop leaks. Depositing from an exchange account to a shielded casino wallet still shows the exchange's send on-chain.
• Some Ironwood migration details are public. Amounts crossing the turnstile and the block heights of migrations are visible [1] [6]. If you migrate, do it in boring denominations - not one distinctive lump that matches a casino payout.
• Wallet behavior varies. Which receiver your wallet picks, and whether it defaults to shielding, differs per wallet - the wallet guide covers the practical differences.

Used deliberately - shielded or unified in, shielded out, no unnecessary hops - Zcash remains the most controllable privacy option in the casino market. Used carelessly, it is Bitcoin with extra steps. The controls are yours; this guide is the checklist.

FAQ

Is a unified address (u...) private?

Not automatically. A unified address is a container that can hold transparent, Sapling and Orchard receivers at once - the privacy depends on which receiver is actually used, not the u prefix.

What is a TEX address?

A TEX address is a transparent address that explicitly requires transparent-source payments; ZIP-320 lets wallets handle the two-step flow from shielded funds for the sender. Services that require it reject shielded-source deposits - a plain t-address makes no such demand.

What happened to the Orchard pool?

Orchard closed to new deposits when the Ironwood upgrade activated on July 28, 2026. Existing Orchard notes migrate one-way into the new Ironwood pool - same shielded technology, fresh state. Wallets handle the migration; balances keep working.

Can I see whether a casino paid out shielded?

For transparent payouts, yes - an explorer shows the send. For shielded payouts there is nothing public to see by design; your wallet's own record is the evidence. Our reviews list what each operator documents.

Does Zcash hide the fact that I gambled?

Shielded ZEC hides amounts and counterparts on-chain, but the casino knows its own books about you, and any transparent hop in your route is public. Privacy depends on the whole route, not one shielded leg.

If my wallet shows a u... address, do casinos accept it for withdrawals?

Many do, but some send only to transparent addresses even when you deposit shielded. Ask support which address types they pay out to before a large withdrawal - the answer is documented per operator in our reviews.

Where can I watch the Orchard to Ironwood migration?

ironwood.live counts what has crossed the turnstile, and ZecStats keeps live per-pool balances and boundary flows - both built from chain data, so you can verify the numbers in this guide yourself [1] [6].

Which pool does a fresh shielded deposit land in?

Whichever receiver the sender's wallet picks for the address you hand over. On Ironwood-era wallets, new shielded activity lands in Ironwood; Sapling still works but holds a small minority of shielded value today [1] [4].

Sources

1. ZecStats: Zcash shielded pools - live balances, boundary flows, and the honesty section on what observers can and cannot see - accessed 2026-10-23
2. ZIP 316: Unified Addresses and Unified Viewing Keys - receiver priority rule - accessed 2026-10-23
3. ZIP 320: An address type that can only be sent to from transparent addresses (TEX) - accessed 2026-10-23
4. Zcash forum: Ironwood is here - updated wallets/libraries (Aug 2026) - turnstile progress and supply verification - accessed 2026-10-23
5. Zodl blog: Ironwood - a new shielded pool for Zcash (2026-06-06) - pool mechanics and the turnstile - accessed 2026-10-23
6. ironwood.live: the Orchard turnstile and what migration reveals - accessed 2026-10-23
7. Zcash forum: Binance rejecting deposits from shielded addresses (2024) - accessed 2026-10-23
8. Zcash forum: Migration from Orchard to Ironwood in Zcash wallets (2026-07-23) - accessed 2026-10-23

Further reading

• ironwood.live - Orchard to Ironwood migration tracker - live counter of what has crossed the turnstile, straight from the chain
• ZecStats - shielded pool dashboard - live pool balances and boundary flows, with an honest 'what we cannot see' section
• ZecHub wallet tracker - pick a wallet that actually reads the Ironwood pool before you rely on it
• Zcash community forum - wallet developers answer migration and receiver-questions directly
• ZIP 316: Unified Addresses - the standard behind the u1 prefix, including the receiver priority rule

Keep reading