Verify · ZecTools

Endpoints

Everything ZecTools reads, and nothing it writes. There are no ZecTools contracts, because ZecTools has no contracts.

What	Where
Chain	Zcash mainnet, consensus branch `37a5165b`
lightwalletd	`zec.rocks:443` (gRPC, TLS; ECC LightWalletD v0.5.3 over Zebra:6.3.0)
Full node	`mainnet.zcashexplorer.app`
Protocol	walletrpc/service.proto, bundled with the CLI
ZecTools contracts	none

Recompute the numbers

Five commands. Between them they reproduce every figure published on this site from public endpoints, with no dependency on this site. If any of them disagrees with what is published, what is published is wrong.

1. The height and the consensus branch

expect a height near 3,492,480 and branch 37a5165b

grpcurl -import-path cli/proto -proto service.proto \
  zec.rocks:443 cash.z.wallet.sdk.rpc.CompactTxStreamer/GetLightdInfo \
  | jq '{blockHeight, consensusBranchId, upgradeName, upgradeHeight}'

No grpcurl? The CLI is the same call: zec info --json. And the full node says the same thing by a different road, below.

2. The tree sizes on one block

expect sapling 73,971,813, orchard 50,466,384, ironwood 554,487 at 3,492,480

grpcurl -import-path cli/proto -proto service.proto \
  -d '{"height": 3492480}' \
  zec.rocks:443 cash.z.wallet.sdk.rpc.CompactTxStreamer/GetBlock \
  | jq '.chainMetadata'

3. The replay check, by hand

expect 35,680 for ironwood over 3,491,329..3,492,480

grpcurl -import-path cli/proto -proto service.proto \
  -d '{"start":{"height":3491329},"end":{"height":3492480},"poolTypes":["TRANSPARENT","SAPLING","ORCHARD","IRONWOOD"]}' \
  zec.rocks:443 cash.z.wallet.sdk.rpc.CompactTxStreamer/GetBlockRange \
  | jq -s '[.[].vtx[]?.ironwoodActions? // [] | length] | add'

# and the same number from the trees alone:
# ironwood tree at 3,492,480 minus ironwood tree at 3,491,328 = 35,680

4. Pool balances and supply, from a full node

expect ironwood near 3,994,347.17 ZEC and chain supply near 16,946,632.97

curl -s -X POST https://zcash-mainnet.gateway.tatum.io/ \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"1.0","id":1,"method":"getblockchaininfo","params":[]}' \
  | jq '.result | {blocks, consensus, chainSupply: .chainSupply.chainValue,
        pools: [.valuePools[] | {id, chainValue}]}'

5. Issuance, from the height alone

expect 16,947,001.56 ZEC at 3,492,480

python3 -c '
h = 3492480
def subsidy(n):
    if n < 10000: return 1250000000 * n // 20000
    if n < 20000: return 1250000000 * (n + 1) // 20000
    if n < 653600: return 1250000000 >> ((n - 10000) // 840000)
    halvings = ((653600 - 10000) * 1680000 + (n - 653600) * 840000) // (840000 * 1680000)
    return 625000000 >> halvings
print(sum(subsidy(n) for n in range(h + 1)) / 1e8)
'

The CLI reads the network itself and shares no read code with the indexer that produced /api/pools. If the two agree, the published feed is what the network says. zec pools --window 1152 --json against curl https://zectools.org/api/pools is the diff to run.

What is not verified

There is no audit. There is nothing to audit: ZecTools holds no funds and deploys no code to any chain. What could still be wrong is a name: the branch id is what the network reports, and the upgrade it is labelled with is a lookup in a table that ships with this build. If the network moves first, every page and every command says the branch is unknown rather than guessing.

Pool balances come from a third party's full node, not from lightwalletd, and the site names which one answered. The note counts do not have that dependency: they are the chain's own commitment trees, read from the same compact blocks a wallet syncs.

Read at height 3,492,480 on 2026-09-22 16:57Z.

Check the numbers