How to Verify Zcash Network Statistics Yourself

Every on-chain figure on zeczcash.com comes from data any Zcash full node reports, so you can check it. There are three ways: redo the arithmetic with our CSV files, compare block data on a public explorer, or read the same values from your own Zebra node. This guide shows the exact calls, the sums and a worked example for October 15, 2026.

What you need

• Our data files. Shielded supply CSV (one row per UTC day since October 29, 2018, with block height, block hash and every pool balance) and activity CSV (one row per UTC day since August 25, 2026). The data page lists every download.
• A public explorer to compare block hashes, times and difficulty at a given height.
• Optional: your own node. Our Zebra guide explains the setup. Zebra's documentation lists 16 GB of RAM and 300 GB of free disk space, and a first sync takes days. The RPC server is off by default; you switch it on with a listen address in the config file:

[rpc]
listen_addr = '127.0.0.1:8232'

Keep the RPC port on your own machine: Zebra's documentation warns that anyone who can reach it can send transactions through your node. Zebra uses cookie authentication by default; its documentation explains how to log in. The older zcashd node stopped before the Ironwood upgrade and knows no Ironwood pool, so use Zebra for current data.

Check the shielded supply and every pool

A pool balance is a running total that the protocol keeps. ZIP 209 defines each one; the Ironwood balance, for example, "is the negation of the sum of all valueBalanceIronwood fields for transactions in the block chain". A node reports these balances in the valuePools array. What each of the six pools is and since when it exists is in Zcash value pools explained.

1. Pick the block. For each UTC day we use the last block whose timestamp is at or before 23:59:59 UTC. The CSV gives its height and hash. For October 15, 2026 that is block 3,519,197 with this hash:

000000000021f0f9d160b9666b943305beefe11f0207d42b6748cd2f75caf2e5

2. Confirm you are on the same block. Ask your node for it, or open it on an explorer, and compare the hash:

curl --data-binary '{"jsonrpc":"1.0","id":"check","method":"getblock","params":["3519197",1]}' \
  -H 'content-type: text/plain;' http://127.0.0.1:8232/

3. Read the pools. In the same answer, valuePools holds one entry per pool with an id and chainValueZat, the balance in zatoshi (100,000,000 zatoshi = 1 ZEC). Use chainValueZat, not the rounded decimal field chainValue.
4. Add them up.

The share is 4,962,083.26 / 16,988,378.29 = 29.2087 %. Our shielded supply page and the CSV cut the share after two decimals instead of rounding, so they show 29.20 %. Two other choices change the result: without the lockbox in the total the share is 29.33 %, and divided by the 21 million maximum supply it is 23.63 %. Our guide Why Zcash shielded statistics differ compares published figures on that basis.

A second check: from October 14 to October 15 the total grew by 1,793.75 ZEC. That is exactly 1,148 blocks × 1.5625 ZEC, the block subsidy per block. Fees do not change the total, because they move coins that already exist.

Check the daily transaction counts

Our activity page sorts every transaction of a UTC day into three groups that always add up to the total:

1. Take the day's first and last block from the CSV: 3,518,050 to 3,519,197, 1,148 blocks.
2. For each block call getblock with verbosity 2. It returns every transaction with its parts.
3. For each transaction: it has a transparent part if vin or vout is not empty, and a shielded part if vjoinsplit, vShieldedSpend, vShieldedOutput, orchard.actions or ironwood.actions is not empty. A coinbase transaction has a coinbase field in its first input.
4. Count and compare. Three rules must hold: 4,442 + 1,486 + 2,276 = 8,204; shielded only plus mixed (3,762) equals all transactions with a shielded part; and there is one coinbase per block.

Each block has one coinbase transaction, which pays the block reward. It counts as transparent only when it pays only transparent outputs. Since the Ironwood upgrade some mining pools pay the reward into the Ironwood pool, and such a coinbase counts as mixed. Other datasets often leave coinbase transactions out: on October 15, 2026 that leaves 8,204 − 1,148 = 7,056 transactions.

Check block height, difficulty and block time

• Height: getblockcount returns the height of the newest block. Any explorer shows the same number within a block or two.
• Difficulty: getblock <height> 1 returns the difficulty of that block. Always compare at the same height: the value changes with every block. Block 3,519,197 shows 274,841,551.26 on the explorers we checked.
• Block time: the protocol targets 75 seconds per block. You can measure the real average from the CSV: 86,400 seconds / 1,148 blocks = 75.26 seconds on October 15, 2026.

Check the lockbox balance

The lockbox is a separate pool for development funds that ZIP 1015 created: "12% of the block subsidy is to be distributed to the lockbox", and "No disbursement mechanism is currently defined". Since block 3,146,400 every block adds 0.1875 ZEC, so:

lockbox = (height − 3,146,400 + 1) × 0.1875 ZEC

For block 3,519,197: 372,798 × 0.1875 = 69,899.625 ZEC, the value in our CSV and in the node's lockbox pool. The formula applies to the rules in force on October 16, 2026; a later network upgrade can change it. Why the lockbox is counted in the total but not as shielded is explained in our lockbox guide.

What you can and cannot check about ZCSH ETF flows

The daily flows on our ZCSH page are not on the blockchain. They come from SoSoValue, are settled one trading day later, and SoSoValue does not publish how it calculates them. What you can do:

• Check our file. In the ETF CSV the cumulative column must equal the running sum of the daily column. Sum weeks with a script, not by hand.
• Check the fund's filings. Shares outstanding and net asset value appear in the fund's reports on SEC EDGAR, which are not daily. A 3-for-1 share split took effect on September 30, 2026, so share counts before and after that date need adjusting.

A single day's flow cannot be checked against a primary source, because no public filing gives daily share counts.

Public tools and what they can check

We checked each tool on October 16, 2026. They can change at any time.

Why your number may differ from ours

1. A different block. Our figures are the state at the end of a UTC day; live dashboards show the newest block. Compare at the same height.
2. A replaced block. Blocks near the newest one can still be replaced. If getblockhash at our height no longer returns our hash, the row was computed on a block that is no longer part of the chain.
3. Rounding. Pool balances are exact to the zatoshi. Our share is cut after two decimals (29.2087 % becomes 29.20 %).
4. A different denominator. With or without the lockbox, or the 21 million cap instead of the issued supply.
5. Coinbase transactions. Included in our counts, left out by some other datasets.
6. Missing pools. A tool that does not know Ironwood undercounts shielded ZEC by about 83 %.
7. Timestamps. Miners set block timestamps, so another rule for "the last block of the day" can pick a different block.

If you find a figure on this site that does not match the blockchain, write to us via the contact page. We correct mistakes and say so.

Sources

• ZIP 209: pool balance definitions, including Ironwood.
• ZIP 1015 and ZIP 2001: the lockbox and its place in the issued supply.
• ZIP 258: the Ironwood upgrade (NU6.3), activated at block 3,428,143.
• Zcash RPC reference for getblock and getblockchaininfo (field names); the Zebra source code adds the ironwood pool and transaction field.
• Zebra documentation: install, requirements, run.
• Our data: shielded supply CSV, activity CSV. All figures in this guide are the rows for October 15, 2026, read on October 16, 2026.