SonarX

Indexed ZcashBlockchain Data

Zcash keeps two ledgers at once: a transparent UTXO chain mined with Equihash, and shielded pools where amounts and parties are encrypted and only commitments, nullifiers and proofs are published.

Zcash logo

How to query Zcash data with SonarX

Instant Data Share

Available today

Snowflake, and file dumps to your object storage

Query Zcash blockchain data with plain SQL from a live database inside your own Snowflake account, populated with the indexed chain dataset. There is no pipeline to build and no second copy to store. The same dataset ships as file dumps to your own object storage for lakes and warehouses that are not Snowflake.

  • Full history as a Snowflake data-share
  • File dumps to S3 or your own object storage
  • Real-time delivery, current to chain tip — on request

Used for:

  • Analytics teams already on Snowflake that want Zcash data beside their existing tables
  • Fund accounting and treasury reporting that reconciles against a fixed history
  • Cross-chain questions answered in one SQL statement instead of one query per chain
  • Loading Zcash history into BigQuery, Databricks, Redshift or a Spark lake
  • Replacing a self-hosted indexer and the engineering time that keeps it running
  • Serving one governed dataset to several desks without copying it per team

Kafka Streaming

Enabled on request

Event stream

Consume Zcash activity as a continuous stream of normalized records, produced as the chain is indexed instead of polled for.

Used for:

  • Trading and execution systems that act on Zcash activity within seconds
  • Fraud and anomaly detection that has to fire before settlement
  • Live dashboards and alerting on Zcash wallet or protocol activity
  • Feeding a stream processor that already reads from Kafka
  • Keeping an internal store hot without waiting for a batch window
  • Event-driven services that would otherwise poll on a timer

Realtime API

Enabled on request

REST over the indexed dataset

Query indexed Zcash records over REST, reading the same dataset the share reads, with no warehouse in the path.

Used for:

  • Applications that need one answer rather than a table scan
  • Customer-facing screens where query latency is visible to a user
  • Services that have no data warehouse and do not want to run one
  • Prototyping against production data before committing to a share
  • Backend checks that run per request instead of per batch
  • Teams that want indexed Zcash data behind their own API layer

Zcash data: frequently asked questions

What is Zcash?

Zcash launched on 28 October 2016 as the first production chain to ship zero-knowledge shielded payments. It descends from Bitcoin’s codebase, so the transparent side is a UTXO ledger with the same 21 million cap, mined with Equihash proof of work. Two things diverge. Blocks target 75 seconds rather than ten minutes, halved from 150 by the Blossom upgrade of December 2019, and the subsidy has halved every 840,000 blocks since Canopy in November 2020. The larger difference is the second ledger. Alongside transparent outputs, ZEC can sit in a shielded pool where amounts and parties are encrypted and the chain publishes only note commitments, nullifiers and proofs. Three pool generations have shipped: Sprout at launch, Sapling in October 2018, and Orchard with the network upgrade of May 2022, which also introduced unified addresses that bundle several receiver types into one string.

Zcash data on SonarX

SonarX indexes blocks and headers, transparent transactions with their inputs, outputs and locking scripts, the derived output set and the positions built from it, and the shielded components each transaction carries, including the value it moves across a pool boundary. The same normalized model covers every network SonarX indexes, so the transparent side of this chain answers the same questions as any other UTXO ledger.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. Kafka streaming can be enabled for Zcash on request.

How SonarX indexes Zcash

The interesting work is at the boundary. The transparent ledger is a UTXO walk, so positions are derived from creations and spends in the ordinary way. Inside a pool there is nothing to attribute: commitments and nullifiers prove that a note existed and was spent without saying by whom or for how much. What the protocol cannot hide is net flow, since a shield or a deshield changes transparent value and has to balance, so the indexed history carries value in and value out per pool generation. Coverage therefore marks where a trail stops instead of guessing a path through it, and the three note formats are kept apart rather than summed.

What teams build with Zcash data

Monetary research is the first workload and the one this chain is unusual for: how much ZEC sits transparently versus in each pool, and how that split moves after a protocol change, is a question almost no other network poses. Exchange and custody reconciliation is the second, and it is harder than on a plain UTXO chain, because a deposit can arrive from a shielded address with no sender to record, so internal attribution has to carry the weight. Compliance work is the third, and its value lies in stating precisely what the chain does and does not publish rather than inferring links that were never recorded. Miner and issuance accounting is a fourth, spanning a block target that changed and a halving schedule that was reset. Wallet analytics covers the address-level side across chains, and Dash is the usual comparison when the question is about optional confidentiality.

Getting Zcash data from SonarX

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Zcash history is available now, and streaming is provisioned on request. Say whether shielded pool flow is in scope, since that determines how much of the chain a position can account for. The published coverage matrix for every network SonarX indexes lives in the data documentation, and the rest of the catalogue is at all indexed chains.

Is there a Zcash data API?

APIs over indexed Zcash data are enabled on request: the same indexed dataset the Snowflake share reads, served over REST once provisioned. Tell us the lookup pattern you need.

How do I get Zcash data into Snowflake?

SonarX provisions a data-share into your own Snowflake account. The share appears as a database you query with SQL, so there is no pipeline to build and no second copy to store, and it stays current as SonarX advances the indexing pipeline.

How far back does Zcash coverage go?

The historical data-share and file delivery cover the chain's full recorded history from the 28 October 2016 launch forward, and are available today. Block cadence changed partway through, from 150 seconds to 75, so block height is not a linear proxy for elapsed time across the whole run. Real-time delivery keeps the same dataset current to chain tip and is enabled on request.

Can SonarX index shielded Zcash transactions?

The parts the protocol publishes, and no more. A shielded transaction records note commitments, nullifiers and encrypted ciphertexts, so there is no sender, recipient or amount to index inside the pool, and no provider can produce one. What is recorded and indexed is the transaction itself, the proofs it carries, and the value it moves into or out of a pool, because that side has to balance against the transparent ledger.

What do Zcash addresses look like in the data?

There are two families and a wrapper. Transparent addresses behave like Bitcoin's and appear on inputs and outputs as you would expect. Shielded addresses never appear on chain at all, since only commitments are published. Unified addresses, added with the 2022 network upgrade, bundle several receiver types under one string, so the same recipient can be reached transparently or privately without changing what they publish.

How is ZEC supply tracked across the shielded pools?

By watching the boundary rather than the contents. Every transfer into a pool reduces transparent value and every exit increases it, so the aggregate held in each pool is a running total that the chain forces to reconcile. Zcash has run three pool generations with different note formats, and a single transaction can spend from one and pay into another, which is why pool balances are derived per generation rather than as one figure.

Zcash logo

Get Zcash data from SonarX