Zcash Address Types: What to Hand a Swap in 2026
Six value pools, four prefixes, 873 transparent outputs parsed out of 100 blocks — plus a measured answer to what a swap desk actually does when you hand it t1, t3, zs1 or u1.
Zcash stopped being a two-address coin, and the old one-liner still works only because it ignores the map. The standard advice — swap into a t-address, then shield — is what we still recommend, but the thing you are choosing between is no longer two options. At 18:00 UTC on 1 November 2026, block 3,538,406 carried value across six accounting pools (transparent, Sprout, Sapling, Orchard, Ironwood and a lockbox), and the chain wrote value out under four prefixes. We measured three things in the same window: where the coins actually sit, how the last 100 blocks were constructed, and what a payout desk does when you hand it each prefix. Prices move, so read every figure as a snapshot of that afternoon, not a standing quote. (Zcash vs Monero 2026)
The money is not where the privacy advice points. Chain value at that block: transparent 11,973,671.27 ZEC (70.36% of 17,018,392.35 total), Ironwood 4,188,492.90 (24.61%), Sapling 428,815.25 (2.52%), Orchard 340,741.89 (2.00%), a lockbox at 73,501.31 (0.43%) and Sprout at 13,169.73 (0.08%). Two readings matter. First, Orchard — the pool that was the destination of choice when it launched — now holds less than Sapling, 2.00% against 2.52%; wallet defaults moved. Second, 24.6% of supply sits in Ironwood, a pool that most address-type explainers written in 2024 do not mention at all. A z-address is therefore not one thing: zs1 pays into Sapling, a u1 carries whichever receiver the sender prefers, and the newest generation of shielded receivers lives in Ironwood. If your mental model is transparent versus shielded, you are one pool behind on every transaction you send. (Zcash vs Monero 2026)
What the chain actually wrote in the last 100 blocks. From block 3,538,300 to 3,538,410 we pulled all 595 transactions: 111 were coinbase, leaving 484 real ones. Of those, 284 were transparent to transparent (58.7%), 80 were fully shielded with no transparent input or output (16.5%), 75 moved value out of a shielded pool into a transparent output (15.5%) and 45 did the reverse (9.3%). In other words 41.3% of real transactions touched a shielded pool — the privacy machinery is not theoretical. The transparent side is where the addresses show: 873 outputs, of which 724 were t1 (82.9%), 146 were t3 (16.7%) and 3 were OP_RETURN data carriers. The size gap is the other half of the story: median transparent transaction 245 bytes, median fully shielded transaction 9,166 bytes, 37.4 times larger, with the largest in the sample at 53,350 bytes. Shielded privacy is bought in bytes, and bytes are paid for in fees. (how Monero fees work)
Four prefixes, three different objects. t1 is a P2PKH address: a two-byte version prefix, a 20-byte hash and a four-byte checksum in base58, 35 characters, and it behaves like a Bitcoin address. t3 is P2SH at the same length — the script side, which is why multisig and some escrow flows show up as t3 rather than t1. zs1 is the Sapling encoding: bech32, 78 characters in our sample, one key, one pool, no receiver choice. u1 is not an address in the old sense but a container: per ZIP-316 it concatenates (typecode, length, receiver) items in ascending typecode order, where 0x00 is P2PKH, 0x01 P2SH, 0x02 Sapling and 0x03 Orchard. A Revision 0 u1 must contain at least one shielded receiver; Revision 2 (still Draft in the ZIP) adds zu, which forbids transparent receivers entirely, and tu. So the length of the string you paste is not cosmetic — it encodes which pools a sender is allowed to pay into, and a wallet that follows the spec must pick Orchard when the UA offers it. (Zcash vs Monero 2026)
What a payout desk actually needs is one string, and it is stricter than your wallet. An order needs an address and an amount; nothing else about Zcash crosses the wire. So we tested it directly at 18:05 UTC on 1 November 2026 with a 100 USDT order in each direction of the address zoo. The t1 control (taken from a real transparent output in the block we parsed) returned order bfa4f400-a0b0-442f-82ea-1f11c01a1490, deposit address TV4RmcZEe5B6u3gYivM8HNt1gk2DcWibE4, payout 0.08021900 ZEC, status waiting_deposit. The u1 string — a 106-character unified address from the zcash_address encoder test vectors — came back 400 with provider rejected: ff create 301: Invalid address. The Sapling zs1 got the identical error. Read that carefully: those two strings are format-valid encodings but nobody holds their keys, so this proves the desk will not take those strings today, not that no unified address will ever work. The cheap way to settle it for your own wallet is a 27 USDT order before you move size. (XMR to USDT exit)
Where a typo gets caught depends on the prefix, and we tested that too. Our own form verifies t1 and t3 fully: base58check, so changing the last character of either returns address checksum mismatch — a character was likely mistyped. For zs1 and u1 the check is shallower: the string must match the shape and land between 51 and 111 characters. We mutated one character in the valid u1 and in the valid zs1 and both were accepted; a 45-character truncated u1 was rejected. A Revision 2 address starting zu1 was rejected outright as not a Zcash address, which is a forward-compatibility gap worth knowing once that draft ships. The practical consequence: for transparent destinations your typo dies in the form, for shielded and unified destinations it dies at the pool, where the error is the uninformative Invalid address rather than a pointer to the bad character. Copy-paste discipline matters more on the prefixes the form cannot verify. (Zcash vs Monero 2026)
The price does not care which prefix you pick, the footprint does. Quotes at 18:05 UTC: 100 USDT bought 0.080219 ZEC, which is 1,246.59 USD per ZEC against a 1,234.11 market print, 1.01% over; 1,000 USDT bought 0.8053821 ZEC at 1,241.65, 0.61% over. The floor was 26.458586 USDT (about 0.0212 ZEC) and the ceiling 74,057.97 USDT (about 59.41 ZEC). Coming back the other way, 1 ZEC sold for 1,191.75 USDT, 3.43% under the market print, or 1.99518944 XMR; 0.01 BTC bought 0.6273111 ZEC, or 62.73 ZEC per BTC, which implies about 77,417 USD per BTC at that moment. None of that changes because you chose zs1 over t1 — the quote engine never sees the address type. What changes is everything after settlement: a 245-byte transparent receipt versus a 9,166-byte shielded one, a published amount versus an encrypted one, one more long-lived address versus none. You are paying the same price for two very different footprints, so choose the footprint deliberately. (XMR to USDT exit)
A five-line decision list beats a paragraph of theory. One: hand a t1 unless you have personally confirmed your wallet's u1 works on a small order — the table above is the reason. Two: test with 26 to 30 USDT first; the floor we measured was 26.458586 USDT, so a 27 USDT order is the cheapest possible probe. Three: shield the same day you receive, and spend from the pool rather than from the transparent address. Four: never reuse the payout address — one fresh address per order is the only cheap link-breaker you control. Five: refundAddress must be a wallet you hold, on the network you are sending from, because a refund is a new transaction to that address and nothing else. The three mistakes we see most: treating u1 as universally accepted because a wallet generated it, treating a t-address receipt as anonymous because ZEC is a privacy coin, and assuming the form caught your typo when all it checked was the shape of the string. (XMR to USDT exit)