Zcash Data: Index Transparent Flows and Shielded Pool Movement
Index Zcash transparent transactions, shielded pool value changes, and Sapling, Orchard, and Ironwood activity in one pipeline, delivered to your own database. Real-time and complete history, no node to run.
Zcash describes itself as encrypted electronic cash: a proof-of-work chain where users can hold and send ZEC either transparently, on a Bitcoin-style UTXO ledger, or inside shielded pools protected by zero-knowledge proofs. On July 28, 2026, at block 3,428,143, the NU6.3 network upgrade activated the new Ironwood shielded pool and restricted the original Orchard pool, so funds leaving Orchard now pass through a turnstile into Ironwood. You can read how the project frames it at z.cash.
That split defines what Zcash data can tell you. Transparent inputs and outputs are public. Shielded amounts and addresses are encrypted, by design. What every block does expose is the net value moving in and out of each pool and the shape of every shielded bundle. Indexing Co delivers both sides in each block, and you choose what to index, delivered to your own PostgreSQL, warehouse, or webhook.
Why Zcash data is hard
What Indexing Co delivers for Zcash
Run a full node and keep up with every upgrade.
- Operate a Zcash full node and track each network upgrade as it ships.
- Parse version 4, 5, and 6 transactions and their Sapling, Orchard, and Ironwood bundles.
- Compute per-pool value changes yourself to follow shielding and unshielding.
- Build backfill, reorg handling, and real-time delivery from scratch.
Transparent flows and pool movement, in your store.
- Transparent inputs and outputs with decoded t-addresses and values in zatoshis.
- Per-block value pools: balance and delta for transparent, Sprout, Sapling, Orchard, Ironwood, and lockbox.
- Per-transaction shielded structure: spend, output, and action counts with net value balances.
- Real-time delivery plus complete backfilled history, to PostgreSQL, BigQuery, a warehouse, or a webhook.
What you can index
| Zcash data type | What it gives you |
|---|---|
| Transparent outputs | Receiving t-address, value in ZEC and zatoshis, and script type |
| Value pools | Balance and per-block delta for each pool, including Ironwood and the lockbox |
| Shielded bundle structure | Sapling spends and outputs, Orchard and Ironwood action counts |
| Net shielded value balances | How much value each transaction moved into or out of each shielded pool |
| Block headers and supply | Height, time, difficulty, total chain supply, and note commitment tree sizes |
A transform, not a subgraph
You write the transform in JavaScript, not AssemblyScript, and change it without re-indexing from block zero. Indexing Co runs your function over each block server-side. This one emits a row per value pool with its delta, and a row per transaction with its transparent flows and shielded value balances. A negative shielded balance means value entered that pool.
// Indexing Co transform: transparent flows and shielded pool movement on Zcash
function transform(block) {
const rows = [];
// Per-block change in each value pool: transparent, sprout, sapling, orchard, ironwood, lockbox
for (const pool of block.valuePools || []) {
rows.push({
chain: block._network,
block: block.height,
kind: 'pool',
pool: pool.id,
pool_value_zat: pool.chainValueZat,
delta_zat: pool.valueDeltaZat,
});
}
for (const tx of block.tx || []) {
rows.push({
chain: block._network,
block: block.height,
kind: 'tx',
txid: tx.txid,
version: tx.version,
transparent_inputs: (tx.vin || []).filter((input) => input.txid).length,
transparent_out_zat: (tx.vout || []).reduce((sum, out) => sum + (out.valueZat || 0), 0),
to_addresses: (tx.vout || []).flatMap((out) => out.scriptPubKey?.addresses || []),
// Shielded side: only counts and net value balances are public
sapling_spends: (tx.vShieldedSpend || []).length,
sapling_outputs: (tx.vShieldedOutput || []).length,
sapling_balance_zat: tx.valueBalanceZat ?? 0,
orchard_actions: (tx.orchard?.actions || []).length,
orchard_balance_zat: tx.orchard?.valueBalanceZat ?? 0,
ironwood_actions: (tx.ironwood?.actions || []).length,
ironwood_balance_zat: tx.ironwood?.valueBalanceZat ?? 0,
});
}
return rows;
}
Zcash with Indexing Co
You want full control of node infrastructure and have the team to run a Zcash full node, track every network upgrade and transaction version, and build backfill and reorg handling in-house.
You want Zcash transparent flows and shielded pool movement delivered to your own database, on the same schema as your other chains, with real-time plus complete history and no infrastructure to run.
Related Reading
FAQ
Can Indexing Co see shielded Zcash amounts or addresses?
No. Shielded notes are encrypted, and that is the point of Zcash. Indexing Co delivers what the chain makes public: transparent inputs and outputs, the net value each transaction moves into or out of each shielded pool, the number of spends, outputs, and actions, and the per-block balance of every pool.
Does Indexing Co support the Ironwood pool?
Yes. Ironwood bundles are in the block data as they appear on chain, and Ironwood is one of the value pools reported every block, so you can track value migrating out of Orchard and into Ironwood after NU6.3.
How do I track shielding and unshielding?
Use the value pool deltas. Each block reports how much the transparent, Sprout, Sapling, Orchard, Ironwood, and lockbox pools changed. Value leaving the transparent pool and entering a shielded pool is shielding; the reverse is unshielding.
Do Zcash transparent inputs include the sender address?
Not directly. Each transparent input carries the transaction id and output index it spends. Because Indexing Co delivers every output, you can join inputs to the outputs they spend in your own database.
Do I need to run a Zcash node?
No. Indexing Co sources Zcash blocks, including full history, so you never operate a node or chase network upgrades yourself.
Get Started
Index Zcash in minutes. Set up your first transparent flow or value pool pipeline without running a node.