Two windows in Zcash's history cannot be proven sound, and 731,462 ZEC still sits inside the pools they touched.
Sprout's proving system was unsound for five years and Orchard's for four. Neither window can be closed by argument - only by emptying the pools. Until then nobody, including this site, can prove that nothing was minted. What follows is the evidence, then the working.
no feed no live mempool feed is configured for this deployment
0 unconfirmed transactions drawn
the feed publishes no rate, so how many transactions this endpoint affords is not known here
These marks are unconfirmed. An unconfirmed crossing ends in a hollow ring in its own pool's colour, and never in gold. Gold is where a crossing lands, and nothing here has landed. A mark leaves when its transaction leaves the mempool, which is not always a confirmation. Direction is read from the transaction's class; where the class does not carry one, no direction is drawn.
- transparent not measured - no crossing source for this boundary
- orchard 1,284 out / 0 in
- sprout not measured - no crossing source for this boundary
- sapling not measured - no crossing source for this boundary
- ironwood 0 out / 1,284 in
One mark per counted crossing, uniform weight. Amounts, ordering and confirmation state are not carried per crossing in this document, so arc thickness means nothing here and the plane draws no pending arcs. Line colour is the origin ledger; the gold arrowhead is where the crossing landed. Perspective is composition, never a measurement. An empty plane is the normal state: value moving inside a pool crosses nothing.
the board holds 42 marks and the window counted 1,284 crossings, so what is drawn is a sample of them - the count above is the measurement, the marks are not
statsconfidence: medverified 2026-08-22cite - 5 sources
- claim
- stats
- canonical
- https://zecreveal.vercel.app/#pools
- last verified
- 2026-08-22
- confidence
- med
- CipherScan — Ironwood migration tracker CipherScan · 2026-08-22 · accessed 2026-08-22
- ZEC Stats (zecstats.com) ZEC Stats · accessed 2026-08-22
- CoinGecko — Zcash CoinGecko · accessed 2026-08-22
- Coinglass ZEC derivatives coinglass.com · accessed 2026-08-22
- Coin Metrics, State of the Network #338 Coin Metrics · 2025-11-08 · accessed 2026-08-22
The two windows
31 May 2022 to 1 Jun 2026 (4 years, 1 day)
| Interval | Sound | Approximate days | What happened |
|---|---|---|---|
| Sprout, BCTV14 | no | 731 | 28 Oct 2016 to 28 Oct 2018, about 730 days. Fixed silently at Sapling; disclosed 341 days after that. |
| Sapling era | yes | 1308 | 28 Oct 2018 to 31 May 2022. Sound as far as anyone knows. |
| Orchard, halo2 | no | 1465 | 31 May 2022 to 1 Jun 2026, 1,462 days. One missing copy constraint in the double-and-add loop. |
| NU6.2 to Ironwood | yes | 84 | 1 Jun 2026 to the tip. Fixed circuit, and a new pool that starts empty. |
About 61 per cent of the chain's life to date falls inside a window in which the property that would rule out counterfeiting did not hold. That is not an allegation that counterfeiting occurred: no one can show that it did, and - this is the whole point - no one can show that it did not. A soundness bug leaves no trace, which is what soundness means.
two-windowsconfidence: highverified 2026-08-22cite - 7 sources
- claim
- two-windows
- last verified
- 2026-08-22
- confidence
- high
- ECC — Zcash Counterfeiting Vulnerability Successfully Remediated (5 Feb 2019) Electric Coin Company · 2018-03-01 · accessed 2026-08-22
- ZF — Concerning the Sprout Vulnerability CVE-2019-7167 Zcash Foundation · accessed 2026-08-22
- ZIP 209, Prohibit Out-of-Range Chain Value Pool Balances Zcash Improvement Proposals · accessed 2026-08-22
- GHSA-ww9q-8r59-xv46 / CVE-2026-54496 (Orchard soundness, CVSS 9.3) GitHub · accessed 2026-08-22
- ZODL — Orchard Vulnerability Successfully Remediated (2 Jun 2026) ZODL · 2026-05-29 · accessed 2026-08-22
- Zcash Community Forum — The Orchard Counterfeiting Vulnerability—And Next Steps (4 Jun 2026) Zcash Community Forum · 2026-06-04 · accessed 2026-08-22
- Schneier on Security — Critical Zcash Vulnerability Found and Fixed (Jun 2026) Schneier on Security · accessed 2026-08-22
The pools, at the tip
HANDOFF-11 wires the live snapshot
| Pool | ZEC | Share of supply |
|---|---|---|
| Transparent | 12,500,223 | 74.0% |
| Sprout | 22,621 | 0.1% |
| Sapling | 529,015 | 3.1% |
| Orchard | 708,841 | 4.2% |
| Ironwood | 3,129,287 | 18.5% |
- Transparent - 12,500,223
- Sprout - 22,621
- Sapling - 529,015
- Orchard - 708,841
- Ironwood - 3,129,287
16,889,987 ZEC accounted for across five buckets. Transparent is not a pool - it is the absence of one - but supply accounting needs all five on one axis. ZEC ~$790.76, market cap ~$13.34 B, circulating 16.89 M / 21 M (80.4%). Shielded: roughly 26-27% (CipherScan: 25.9% at block 3,456,227; ZECStats: 26.8%) (4,530,445 ZEC). Ironwood migration 80.6% complete; ~708,841 ZEC still stranded in Orchard NU6.3 "Ironwood" — block 3,428,143. New formally verified (Lean) shielded pool; v6 tx format (ZIP 229); quantum recoverability (ZIP 2005); Orchard restricted to withdrawals only (ZIP 2006), creating the supply-verification turnstile
T2026-08-22T2026-07-28What the chain publishes6 fields, all public
These are the fields this site reads. Every number above is derived from them and nothing else. None of them is an identity.
- nullifiers
- one per spent note
- valueBalance
- every boundary amount
- anchors
- tree root at spend time
- commitments
- one per output note
- t-addresses
- every shield and unshield endpoint
- migration amounts
- quantised, since NU6.3
What is hidden, on a shielded-to-shielded spend: sender, recipient and note value. That is the whole of it, and it is the reason every shielded figure on this site is a bound rather than a total.
How the residual is derivedTRACKING-MATH 3.2, 2 terms
U = Sprout balance + Orchard balance, which is 22,621 + 708,841 = 731,462 ZEC. Both circuits were unsound during their lifetime, so value still inside them cannot be shown to have been legitimately created. The verified share is 1 - U / supply, which is 95.7%. It rises only as the two pools empty, never by argument. The lockbox is carried separately and is not netted here.
What this instrument cannot do4 limits, stated
- It cannot name a wallet.
- It cannot show a shielded balance without your own viewing key.
- It cannot prove nothing was minted.
- It cannot tell you a bound is tight - only that it holds.
Two halves, one identity
A — the Record
Static, citable, zero-motion. The exploit ledger, the contradictions, the timeline and the promotion lattice - every entry carrying a source URL, a confidence and a last-verified date. Claim identifiers are permalinks, so a statement can be argued with rather than merely read.
B — the Instrument
Live, deterministic, chain-seeded. Turnstile balances, the Orchard drain, the ZIP 318 migration lens and the Ironwood birth curve. Transparent values are exact; shielded values are bounds on a candidate set. The page renders from the last good snapshot when the feed is down, and says how old it is.