SonarX

Indexed BitcoinBlockchain Data

Bitcoin has produced a block roughly every ten minutes since 2009, holding value in unspent outputs rather than accounts, with BTC capped at 21 million and mined under proof of work.

Bitcoin logo

How to query Bitcoin data with SonarX

Instant Data Share

Available today

Snowflake, and file dumps to your object storage

Query Bitcoin 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

Used for:

  • Analytics teams already on Snowflake that want Bitcoin 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 Bitcoin 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

Available today

Event stream

Consume Bitcoin 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 Bitcoin activity within seconds
  • Fraud and anomaly detection that has to fire before settlement
  • Live dashboards and alerting on Bitcoin 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

Balances

Enabled on request

Tables and REST

Read what a Bitcoin address held, either as it stands now or exactly as it stood at a past block or timestamp.

  • Point-in-time balance tables, as at any block or timestamp

Used for:

  • Reconstructing Bitcoin portfolios and NAV as at a reporting date
  • Audit and reconciliation work that has to be repeatable months later
  • Wallet and portfolio products that render Bitcoin balances on page load
  • Compliance checks that read one Bitcoin address at one block height
  • Refreshing holdings for a whole book of accounts on a schedule
  • Tax and cost-basis workflows that need holdings at each event

Realtime API

Enabled on request

REST over the indexed dataset

Query indexed Bitcoin 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 Bitcoin data behind their own API layer

Bitcoin data: frequently asked questions

What is Bitcoin?

Bitcoin has produced blocks continuously since its genesis block on 3 January 2009. Blocks are mined under Nakamoto consensus with SHA-256 proof of work, targeting one block every ten minutes, and the difficulty target is recalculated every 2,016 blocks so that the interval holds as hashrate changes. There are no accounts. Value is held in unspent transaction outputs, and an address’s balance exists only as the sum of the outputs its keys are able to spend, which is the single fact that shapes everything about indexing this chain. The native asset is BTC, capped at 21 million and divisible into 100 million satoshis, with the block subsidy halving every 210,000 blocks. Ownership has been expressed through four generations of script over the chain’s life, from the original pay-to-public-key-hash and pay-to-script-hash forms to SegWit addresses in 2017 and Taproot in 2021, and the same owner often holds funds across several of them. Litecoin and the other UTXO chains inherited this design nearly unchanged.

Bitcoin data on SonarX

SonarX indexes blocks and headers, transactions, inputs and outputs, the scripts that lock them, the derived UTXO set and address-level positions built from it. The same normalized model is used on every chain SonarX covers, so Bitcoin can be joined to other networks in one query rather than reconciled between two pipelines afterwards.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery keeps the same dataset current to chain tip. Point-in-time balance tables can be enabled for Bitcoin on request. Kafka streaming carries the same records as a live topic today.

How SonarX indexes Bitcoin

The protocol keeps no balances, so an address-level view has to be constructed rather than read. SonarX replays every output creation and spend to maintain the UTXO set, then derives positions from it, resolving the four script generations that put one owner behind several address forms. Inputs reference outputs by transaction hash, so a transfer view is a join across blocks rather than a lookup of a transfer record. Reorgs are shallow but real, and outputs spent in an orphaned block have to be returned to the set rather than left consumed. Inscriptions have also pushed large payloads into witness data since 2023, which changes the size profile of a backfill without changing its shape.

What teams build with Bitcoin data

Bitcoin is the chain institutions ask for first, and the work is rarely about smart contracts. Custody and treasury reconciliation needs holdings restated as at a date, across address formats and change outputs, which is a UTXO join rather than a balance lookup. Supply-side research uses the outputs themselves: UTXO age cohorts, realized cost basis, coin-days-destroyed and similar measures are only computable when the whole output history is present. Miner and flow analysis reads coinbase transactions and the movement out of mining addresses. And Bitcoin’s role as collateral elsewhere means BTC data increasingly gets joined to another chain, most often through Babylon.

Wallet analytics covers the address-level side of this work across chains, including the change-output problem that makes a Bitcoin wallet harder to follow than an account.

Getting Bitcoin 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. Bitcoin history is available now, and streaming is provisioned on request. 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 Bitcoin data API?

APIs over indexed Bitcoin 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 Bitcoin 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 Bitcoin coverage go?

The historical data-share and file delivery cover Bitcoin's full recorded history, from the genesis block of 3 January 2009 forward, and are available today. Real-time delivery keeps the same dataset current to chain tip.

How does SonarX handle Bitcoin's UTXO model?

By rebuilding the state the protocol does not store. Bitcoin records outputs and the spending of outputs, not balances, so SonarX replays every creation and spend to maintain the UTXO set and derives address-level positions from it. That is also why a transfer view means joining inputs back to the outputs they reference, across blocks, rather than reading a transfer record.

Is SonarX a Bitcoin block explorer?

No. An explorer answers one lookup at a time in a browser. SonarX delivers the whole indexed Bitcoin history, every block and transaction, normalized, into your own Snowflake account, S3 bucket or Kafka topic, so you can query it with SQL. If you need a single transaction, use a public explorer. If you need all of them, that is us.

Does SonarX provide Bitcoin hashrate data?

Not as a published metric. Network hashrate is an estimate, not a value recorded in a block. What the indexed data does carry is the inputs that estimate is built from: block timestamps, the difficulty target in force at each height, and coinbase transactions. Teams that model hashrate do it from those records rather than from a series SonarX asserts.

Can SonarX support Bitcoin staking analysis?

Bitcoin itself has no staking mechanism, so any staking analysis spans chains: the BTC side lives here, and the staking side lives on a protocol like Babylon, Core or Stacks, each of which SonarX indexes separately. Tell us which protocols are in scope and we will confirm coverage on both sides.

How do I start with Bitcoin data?

Tell SonarX the delivery target, the history depth and the refresh cadence you need, and the share is scoped against that. There is no self-serve signup: every engagement is provisioned, so the first conversation is about scope rather than credentials.

Bitcoin logo

Get Bitcoin data from SonarX