Zcash Turnstiles: What a Pool Crossing Costs You

Every Zcash transaction hides almost everything: who sent it, who received it, how much moved. Almost. One number survives the encryption — the value balance, the net amount that entered or left each shielded pool in that transaction. Zcash calls a transfer that moves value across a pool boundary a pool-crossing transfer, and the practice of doing it deliberately a turnstile. The metaphor is literal: you pass through a gate one at a time, and the gate counts you. Here is what the counter shows, why the designers made it public on purpose, and what changed in 2026 when Orchard was switched off and Ironwood opened in its place. (Zcash vs Monero 2026)

Why the counter exists at all. A shielded pool is a cryptographic ledger that hides individual entries but still carries a balance. If the mathematics enforcing that balance broke, someone could counterfeit value inside the pool and no observer could tell, because every record is ciphertext. Catching that needs a place where the pool's books meet the public chain. ZIP-209 supplies the rule: the chain value pool balance of every pool must never go negative, and the total across all pools must never exceed MAX_MONEY, 21 million ZEC. A turnstile is what makes the rule bite — to spend counterfeit value outside the pool you must cross a boundary, and at the moment of crossing the amount becomes a public number. (Zcash vs Monero 2026)

2026 turned the theory into an incident report. On 2026-05-29 the security researcher Taylor Hornby, working on an AI-assisted audit of the Orchard protocol, reported a soundness vulnerability in the Orchard Action circuit implementation, tracked as GHSA-ww9q-8r59-xv46. Per ZIP-257 it could have allowed a balance violation and theft of funds. The response was to stop Orchard outright: from block 3,364,326, mined 2026-06-02 03:30:07 UTC, every version-5-and-later transaction had to carry zero Orchard actions. Emergency hotfixes shipped as zcashd v6.12.5 and zebra v4.5.3; an earlier attempt 60 blocks sooner failed because some mining pools did not upgrade in time. Orchard returned at height 3,364,600 on 2026-06-03 04:03:08 UTC under NU6.2 — 274 blocks and 24 hours 33 minutes later — with the faulty variable-base scalar multiplication gadget corrected in halo2_gadgets 0.5.0 and orchard 0.14.0, a new verifying key, and a canonical proof-length rule.

Then the pool itself was replaced. NU6.3 activated on 2026-07-28 14:07:23 UTC at height 3,428,143, consensus branch 0x37A5165B, and introduced the Ironwood pool: an Orchard-protocol successor whose notes are quantum-recoverable by construction (ZIP-2005) and whose supply integrity was formally verified before launch. From that block the Orchard pool is exit-only. Coinbase transactions may carry no Orchard actions, every Orchard action must be built with cross-address transfers disabled, and valueBalanceOrchard must be non-negative, which is the consensus way of saying no new value may enter. Value may still leave freely, including across the turnstile into Ironwood. ZIP-326 adds the wallet-side rule: after activation, do not send funds to any Orchard receiver. An Orchard-only address became an address you can spend from and cannot pay into.

What a crossing looks like in raw bytes. We decoded version-6 transactions from block 3,531,339, mined at 13:57 UTC on 2026-10-26, to watch the gate work. Transaction 73909deb carries four Ironwood actions in 15,512 bytes and declares valueBalanceIronwood of +2,546,022,971 zats: 25.45999971 ZEC leaving the pool into a single transparent t1 output, with 25,000 zats retained as the fee. Transaction 512a113d is 9,166 bytes with two Ironwood actions and a value balance of exactly +10,000 zats — a transfer whose only visible movement is the fee. Inside those bytes the receivers, memos and note values stay ciphertext. Public is the balance: a crossing announces how much moved, not who moved it. (how Monero fees work)

Fees, and a trap for block explorers. ZIP-317 charges 5,000 zats per logical action with a grace floor of two: conventional fee equals 5,000 times the larger of 2 and the logical action count. Ironwood actions count one each since Revision 1 took effect at NU6.3; transparent inputs and outputs count in units of 150 and 34 bytes. A two-action shielded transfer therefore pays 10,000 zats, which is 0.0001 ZEC or about 12 cents at a ZEC price of $1,217.56, and four actions plus one transparent output pay 25,000 zats, about 31 cents. One caveat from verifying this: the explorer we queried reported a fee of 0 for exactly those transactions, because it has no concept of a value balance. Read valueBalanceOrchard and valueBalanceIronwood out of the raw bytes; the labels will otherwise mislead you. (how Monero fees work)

Why migrations look so mechanical. ZIP-318, the Orchard-to-Ironwood migration design, is the most instructive document here because it prices privacy explicitly. The net value of every crossing is public, so a naive migration would publish your whole balance in one lump. The draft instead groups migration transactions into cohorts that share an anchor block boundary every 144 blocks — about three hours at the 75-second target — so that yours sits among everyone else's. It uses canonical denominations of the form n times 10 to the k with n in {1, 2, 5}, spends exactly one Orchard note per transaction, creates exactly one Ironwood output, and deliberately leaves a small residual unmigrated so an odd remainder cannot fingerprint you. Because each part is independent, a whole schedule can be pre-signed and broadcast without waiting for change to confirm.

The network is not the constraint. We pulled 600 consecutive blocks, heights 3,530,741 to 3,531,340, spanning 12.45 hours. Median block size was 14,133 bytes against a 2 MB cap, the largest was 889,107 bytes, and 181 of the 600 blocks, 30.2 percent, held one transaction or none. Mean inter-block time was 74.8 seconds. Since NU6.3 the chain has added 103,197 blocks in 89 days 23 hours 53 minutes, averaging 75.35 seconds against a 75-second target. Migration traffic competes with nothing: a crossing costs cents and the queue is empty.

What this means when you actually swap. First, receive ZEC at an address your wallet generated after NU6.3 — ideally the unified address of a current wallet — because an Orchard-only string can no longer be funded. Second, the amount is public in a way the address is not: pay from a transparent t1 address and the deposit is fully visible on chain; pay from Ironwood and the address stays private while the crossing amount is still published as a value balance. Shielded source does not mean invisible number. Third, price the order before committing. Between 14:02 and 14:06 UTC on 2026-10-26 our ZEC quotes read 26.797546 USDT as the minimum, 100 USDT to 0.06616125 ZEC, 5,000 to 4.00967624, and 20,000 to 16.08030112 ZEC. Those imply 1,511.46 USDT per ZEC at the 100-USDT size and 1,243.76 at the 20,000-USDT size, against a spot price of 1,217.56 — the gap at small sizes is a fixed billing cost of roughly 15 to 18 USDT per order, not the network fee. ZEC to XMR quoted 2.0254 and XMR to ZEC 0.47483, a 3.8 percent round trip. Rates move; the quote page is the only source of truth. (XMR to USDT exit)

What you are trusting, stated plainly. That the circuit does what the audit says — which is why the May 2026 report and the corrected verifying key matter more than any marketing claim. That the ZIP-209 invariant is enforced by every node, not just published on a dashboard. And that whoever holds your keys is competent, because none of this protects a note that a compromised wallet leaks. A turnstile does not hide the amount of a crossing, make a transparent hop private, or let you skip the migration. It keeps a shielded pool's books honest without publishing a balance sheet — and in 2026 that property was tested twice in twelve weeks. (Zcash vs Monero 2026)