Zcash's shielded pools held 26.05% of indexed chain value at the latest observation. Over the 30-day window, Orchard gained 67.87K ZEC, Sapling lost 34.39K ZEC, and total shielded value rose 33.48K ZEC. That is a useful migration signal, but it is not a user count, payment-volume estimate, or privacy score.
Key Facts
- The observed shielded share rose from 25.94% to 26.05%, a change of 0.12 percentage points over the sampled 30-day window.
- Orchard gained 67.87K ZEC while Sapling declined by 34.39K ZEC, shifting more of the shielded pool mix toward Orchard.
- Total shielded chain value increased by 33.48K ZEC, or about 0.77%, between the first and last observations.
- The lockbox is included in chain-value reconciliation but is not a user privacy pool and is never counted as shielded supply.
- Pool balances describe where value sits at observation time. They cannot reveal owners, user counts, payment volume, or the privacy quality of individual behavior.
This month's read in one sentence
The cleanest interpretation is that ZEC continued moving toward Orchard inside the shielded side of the network, while the overall share of chain value held in shielded pools changed only slightly. That is real evidence of pool composition and a weak signal of broader privacy adoption. It is not proof of a user boom.
Crypto dashboards routinely turn one visible number into a story it cannot support. House of Zcash takes the opposite position: the number gets narrower as the claim gets stronger. Aggregate chain-value pools are observable. The people, reasons, counterparties, and protected amounts inside shielded activity are not.
What changed between June 19 and July 18
The first sampled observation held about 4.35 million ZEC across Orchard, Sapling, and Sprout. The final observation held about 4.38 million ZEC. That 33.48K ZEC increase lifted shielded share from 25.94% to 26.05% of the reconciled chain total. A 0.12 percentage-point move is directionally positive, but it is not large enough to justify breathless adoption language.
The more interesting change happened inside the shielded total. Orchard added 67.87K ZEC while Sapling lost 34.39K ZEC. Orchard's share of shielded value therefore moved from 85.05% to 85.95%. Sapling's share fell from 14.36% to 13.47%. Sprout stayed effectively flat at 25.41K ZEC.
Those figures fit a migration story better than a simple inflow story. Some value entered the shielded side of Zcash, but a larger gross shift occurred between generations of shielded pools. Wallet support, receiver selection, user maintenance, and protocol changes can all influence that composition. The chain data alone does not identify which cause dominated.
Why Orchard's gain matters
Orchard is the modern Zcash shielded protocol introduced with NU5. It uses a separate shielded pool, Halo 2 proofs, and Unified Address integration. Value moving from Sapling toward Orchard can indicate that wallets and users are relying more heavily on the current shielded path rather than leaving balances in the previous generation.
That does not make Orchard a universal privacy score. Orchard and Sapling have separate privacy sets, and the practical protection of a payment still depends on its full path. Transparent inputs or outputs remain public. Timing, amount boundaries, wallet servers, exchanges, devices, and counterparties can add context outside the protected payment fields.
The useful conclusion is narrower: Orchard is carrying a larger share of shielded chain value than it did at the start of the window. The watch records that migration and leaves the unsupported claims alone.
The lockbox belongs in reconciliation, not privacy adoption
The protocol lockbox holds deferred development-fund value under ZIP 2001. It is part of indexed chain value and therefore belongs in the reconciliation that checks whether all pools add back to total supply. It is not controlled like a normal transparent address or shielded note pool, and it is not evidence that more people are using private payments.
House of Zcash keeps the lockbox visible because silently dropping a growing balance would distort the denominator. It is shown separately because counting it as shielded would be worse. This distinction sounds fussy until a dashboard turns protocol accounting into a fake adoption headline.
What this watch cannot tell you
A pool balance is a stock measurement. Payment volume is a flow measurement. The same shielded ZEC can move many times during a month without changing the final balance, while a large balance can remain untouched. End-of-window chain value therefore cannot be converted into transaction volume.
The metric cannot count people either. One person can control many notes and accounts; many people can interact through custodial infrastructure; and shielded ownership is deliberately not exposed as a public address list. Dividing pool value by an invented average balance would manufacture a user estimate from assumptions, not evidence.
It also cannot certify privacy quality. A fully shielded Orchard payment protects core payment fields on-chain, but privacy can still be weakened by transparent boundaries, repeated amounts, network metadata, exchange records, wallet behavior, or voluntary disclosure. The chain-value ledger is one layer of the system, not the whole threat model.
How Ironwood changes the future reading
The current Zcash ZIP index lists Ironwood-related work among the NU6.3 candidate set, including a proposed recoverability design and reserved migration and transfer-restriction ZIPs. Candidate does not mean activated. This edition therefore reports Orchard, Sapling, Sprout, transparent, and lockbox values exactly as the validated provider snapshot exposes them.
If Ironwood activates, this watch must not hide the migration inside a generic shielded total. A new pool changes the composition, the operational meaning of wallet behavior, and the interpretation of historical comparisons. The instrument is structured around separate pool series so a future Ironwood row can be added without rewriting old Orchard data or pretending the pools are interchangeable.
The editorial rule is simple: show proposed protocol state as proposed, activated chain state as activated, and never use a future pool label before the source data and consensus status support it.
Methodology and review contract
The source pipeline fetches ZcashInfo's one-month coin-pool history on the server, validates each height, timestamp, and zatoshi balance, sorts the records, and samples eight observations across the window. It separately fetches the current dashboard balances. Transparent, Orchard, Sapling, Sprout, and lockbox values must reconcile to indexed total supply within a strict tolerance before the snapshot can be written.
The page then derives three views from the same validated points. Shielded Share divides Orchard plus Sapling plus Sprout by all reconciled chain value. Pool Migration shows each shielded pool as a share of shielded total. Balance Ledger indexes each pool to 100 at the first observation so relative change remains visible across balances of very different size.
The report is intentionally time-bounded. A production build rejects a snapshot older than six hours, while the article itself carries a 30-day editorial review window. A source failure cannot quietly become a new data point, and an old narrative should not survive a changed pool trend without human review.
FAQ
Is shielded pool balance the same as Zcash adoption?
No. It is one adoption-related signal showing where ZEC sits. It does not count users, wallets, payments, or off-chain activity.
Why did Orchard rise while Sapling fell?
The chain data proves the balance shift but not its cause. Wallet receiver selection, user migration, protocol support, and other flows may contribute.
Does a higher shielded balance guarantee better privacy?
No. Larger shielded pools can support broader privacy sets, but practical privacy still depends on the complete transaction path, wallet behavior, network metadata, and counterparties.
Why is the lockbox shown if it is not shielded?
It belongs in total chain-value reconciliation. Showing it separately prevents the denominator from being understated without falsely counting it as a user privacy pool.
Is Ironwood active in this report?
No. The cited ZIP index describes Ironwood work in the NU6.3 candidate set. This report only adds an Ironwood pool after consensus status and validated chain data show that it is active.