Zcash mainnet · public protocol data
Zcash network data you can query in one request.
Fordnet reads a Zcash node, keeps what it serves at most a minute old, and exposes blocks, transactions, transparent addresses and value-pool history through a dashboard and a versioned REST API. It never infers anything about shielded activity.
The problem
Simple questions about Zcash are harder to answer than they should be.
01
Basic facts need a node
Answering “is the chain moving and how fast” means syncing zcashd or Zebra (hundreds of GB) and parsing JSON-RPC output by hand.
02
Explorers aren’t APIs
Block explorers are built for people. Scraping them breaks on every redesign, and few offer a documented, versioned interface with clear limits.
03
Pool supply has no simple history
How much ZEC sits in Sapling or Orchard is in every block’s valuePools, but there is no easy daily series to chart or download.
04
Tooling can leak privacy
Analytics tools that guess shielded senders, recipients or amounts undermine the reason Zcash exists. Users can’t always tell which tools do this.
What Fordnet does
One answer for each of those problems.
Solves problem 01
Open dashboardHosted node reads
An ingest job refreshes from the node whenever stored data is more than a minute old, keeping the last 100 blocks and a status snapshot. You read the result, not the raw RPC.
Solves problem 02
Read the API docsVersioned REST API
Six read-only /api/v1 endpoints with one response shape, zod-validated input, clear 400/404/429 errors and 200 free requests a day per key.
Solves problem 03
See pool historyDaily value-pool series
One snapshot per UTC day, read from each block’s valuePools. Chart it per pool or stacked, view it as a table, or fetch it as JSON.
Solves problem 04
Privacy commitmentPublic data only, by design
Shielded transactions are shown as component counts. Fordnet stores no shielded amounts or parties and never attempts to infer them.
Try it
A real request, a real response.
Create a key on the developers page, export it as FORDNET_KEY, and run this. Every endpoint returns the same { data, meta, error } shape.
How it works
Four parts, no hidden steps.
01
Zcash node
Zebra or zcashd, JSON-RPC
02
Ingest
Refresh if > 60 s old · 5 s timeout, 1 retry
03
Postgres
Blocks, snapshots, key hashes
04
API + dashboard
Same data, two interfaces
If the node stops answering, pages and the API fall back to the last stored snapshot and show its timestamp. Fields a node doesn't report are shown as “not reported”, never estimated.
Privacy commitment
Fordnet reports only public protocol data.
What we show
Block headers, transparent inputs and outputs, transparent balances, and pool totals the protocol publishes in every block.
What we count
The number of Sapling spends and outputs, Orchard actions and Sprout JoinSplits in a transaction. Counts only.
What we never do
Store, estimate or link shielded amounts, senders or recipients. Shielded addresses can't be searched.
Built for
People who need chain data, not another node to maintain.
Wallet developers
Check chain tip and sync state before broadcasting, or show a transparent balance without running an indexer.
Researchers
Pull the daily pool series into a notebook to study shielded adoption, using only data the protocol already publishes.
Bot and alert builders
Poll status and recent blocks on a predictable schema with documented rate limits and Retry-After.
Roadmap
What comes next.
These are planned, not shipped.
- PlannedAlways-on ingest worker alongside the scheduled job
- Plannedlightwalletd as an additional data source
- PlannedWebhooks for new blocks and pool thresholds
- PlannedPer-key usage view on the developers page
- PlannedNetwork-upgrade and ZSA tracking
- PlannedOpenAPI spec and a TypeScript SDK