On-chain metrics · UTXO data

Bitcoin UTXO data from the fully-indexed chain

Bitcoin works in unspent transaction outputs, and the UTXO set is where the real on-chain state lives. BitcoinDatabase exposes the full UTXO set from the fully-indexed chain: every unspent output with its value to the satoshi, the address and script type that controls it, the block and age since it was created, and which transaction created it.

or try it below ↓

REST API · SQL · dashboards · address history from genesis

Query Console

BTC address or sample query

btc

try:

Hit Run to query the Bitcoin blockchain.

Live from the chain for .

BTC

Balance trail

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Reading the chain ...

Query a single address's UTXOs, aggregate the set by age band to build UTXO age distribution and supply-by-age metrics, or analyze coin movement in SQL. It is the raw material for HODL waves, realized cap and coin-age research. Informational on-chain data only, not investment advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

History from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with UTXO data

The full UTXO set

Every unspent output is available with its value, controlling address, script type, creating transaction and the block it was minted in.

Age and distribution

Aggregate UTXOs by age band to build UTXO age distribution, supply-by-age and HODL-wave style views straight from the raw set.

Foundation for metrics

Coin age underpins realized cap, SOPR and coin-day analysis, and you can compute them from the indexed UTXO data on your own terms.

Side by side

The UTXO response schema, field by field

This is what GET /v1/address/{addr}/utxos returns for each unspent output, and how each field maps onto the names other Bitcoin APIs use for the same thing. Field names differ across providers far more than the underlying data does, and most of the time lost porting a UTXO integration goes into working that out. An unspent output in our schema is simply a row in outputs where spent is false, so the UTXO set is a view over the chain rather than a separate product.

Field	Type	What it holds	Called elsewhere
txid	string	The transaction that created this output	txid, tx_hash, transaction_hash
vout	integer	The output index inside that transaction, zero based	vout, n, output_index, outputIndex
address	string	The address that controls the output	address, scriptpubkey_address
value_btc	decimal	The amount, carried to eight decimal places so nothing rounds	value, satoshi, value_satoshi, amount
script_type	string	p2pkh, p2sh, v0_p2wpkh, v0_p2wsh, v1_p2tr or op_return	scriptpubkey_type, scriptPk, script_type
spent	boolean	False for every UTXO, by definition	spent, is_spent, spent_by_txid
created_at	timestamp	When the creating block confirmed	block_time, status.block_time
block_height	integer	The height of the creating block, on the transaction	height, block_height, status.block_height
price_at_creation_usd	decimal	The USD price when the output was created, so acquisition value travels with the lot	No equivalent on public explorers

Two practical notes. First, units: we return value_btc as a decimal with eight places rather than an integer satoshi count. Most explorers, and UniSat in particular, return an integer named satoshi or value instead, so multiply by 100,000,000 when you port a query across and never let a float round the result. Second, script_type is on the output itself. We checked this across the public address endpoints on 22 August 2026 and none of them returns a script type on an address lookup; the type only appears on the transaction endpoint, inside the vout object. If you are grouping a wallet by address type, that difference decides whether the job is one query or a full transaction crawl. On one block, 963,670, the split across 9,784 outputs was 56.91 percent v0_p2wpkh, 18.90 percent op_return, 12.54 percent v1_p2tr, 4.60 percent p2pkh, 4.26 percent p2sh and 2.26 percent v0_p2wsh.

What it handles

The indexed Bitcoin chain, queryable your way

Look up an address, a transaction, a UTXO, the rich list or an on-chain metric, by REST API, SQL or dashboard. The same authoritative data, reconciled block-by-block against the canonical chain, without running a node.

List UTXOs for any address
Read value, script type and creating tx
Build UTXO age distribution and supply by age
Analyze coin movement and dormancy
Query the UTXO set via API, SQL or dashboard

GET /v1/address/{addr} query result

200 · JSON

{
  "address": "bc1qxy2k…l0wdv8",
  "balance_btc": 68432.10,
  "balance_usd": 4612165420,
  "tx_count": 1284,
  "unspent_outputs": 37,
  "first_seen": "2014-02-09"
}

indexed from genesis · to the satoshi ✓ reconciled block-by-block

Why BitcoinDatabase

One platform, queryable three ways

Not a raw node to sync, not an indexer to build, and not five vendors to stitch together. The fully-indexed Bitcoin blockchain, available as a REST API, as SQL, and as dashboards, on one authoritative dataset.

REST API

Typed JSON for addresses, transactions, balances, UTXOs and metrics. Drop it into apps, wallets, explorers and agents with curl, Python or any HTTP client.

SQL access

Run SQL directly against the indexed Bitcoin dataset for ad-hoc analysis, cohorts and exports, the same data the API and dashboards read from.

Compliance-first

Informational on-chain data and analytics only. Entity labels and flow tracing are framed as tooling to support a regulated team's own review, not accusations.

Good questions

Questions about UTXO data

Every unspent output from the indexed chain: value to the satoshi, controlling address and script type, the transaction that created it, and the block and age. You can query a single address or aggregate the whole set.

Nine per unspent output: txid and vout identify it, address and script_type say what controls it, value_btc carries the amount to eight decimal places, spent is false by definition, created_at and block_height date it, and price_at_creation_usd carries the USD value at creation. The first eight have equivalents on public explorers under different names. The last one does not.

We return value_btc as a decimal with eight places. Most public explorers return an integer instead, named value on Esplora and mempool.space and satoshi on UniSat, which is the same quantity multiplied by 100,000,000. Convert with integer arithmetic rather than floating point, because a float cannot represent every satoshi amount exactly and the error shows up in totals rather than in single rows.

Ours does. Public ones generally do not. We tested the common address endpoints on 22 August 2026 and none returned a script type on an address lookup: the type is only present on the transaction endpoint, inside the vout object as scriptpubkey_type. So grouping a wallet by address type against a public API means crawling every transaction, while against an indexed outputs table with script_type on the row it is a single GROUP BY.

Filter the outputs table on the creating height and on whether the output had been spent by that height, which is an ordinary query when the chain is indexed. It is not available from most public APIs at all. We tested this: an Esplora address call ignores a height parameter and returns a byte-identical response, and BlockCypher returned every numeric field as zero when asked for a state before block 300,000. Both fail without raising an error.

An output worth less than it costs to spend, which depends on the fee rate and the input size rather than on a fixed number. The relay policy threshold most nodes apply is 546 satoshis for a P2PKH output. Dust matters for UTXO management because a wallet full of tiny outputs has a balance it cannot economically move, and because dust is sprayed at high-value addresses deliberately.

Tens of millions of unspent outputs, and it grows and shrinks with usage rather than trending in one direction, since every spend consumes outputs and creates new ones. The useful question is usually not its size but its shape: how the set distributes across value bands, ages and script types. Those are aggregations over the same rows, which is why we expose the set rather than a summary of it.

Yes. The UTXO set with creation ages is the raw material for UTXO age distribution, supply by age, HODL waves and realized cap. It is informational analytics data, not financial or investment advice.

Each unspent output carries the txid that created it, its output index (vout), its value in satoshis, the locking script as scriptPubKey hex plus a decoded script type and address where one can be derived, and the block height it was mined in. Confirmations follow from the height against the current tip.

Because satoshis are integers and BTC amounts are not. A value like 0.1 has no exact binary floating point representation, so summing BTC-denominated amounts accumulates rounding error that eventually shows up as a balance that is off by a few hundred satoshis. Bitcoin Core, every serious indexer and this API all move integers and let the client format them.

Request the unspent outputs for that address and you get every one it currently controls, each with its value, creating transaction, output index and block height. Summing their values gives the exact confirmed balance, which is why a balance and a UTXO list should never disagree if both come from the same indexed source.

A balance is a total; a UTXO is one of the discrete coins that add up to it. Bitcoin has no account balances at the protocol level, only unspent outputs. An address holding 1 BTC across 40 small outputs and one holding 1 BTC in a single output show the same balance but behave very differently, because spending the first costs far more in fees.

The set holds well over a hundred million unspent outputs and the total moves with every block, rising when wallets fragment coins and falling when they consolidate. Because the count is a live figure rather than a fixed one, query it against the current tip instead of quoting a number from a chart, and read it next to the total value those outputs hold.

Read every Bitcoin API question

Explore more

See every use case See pricing Back to the Bitcoin API

Stop running a node. Just query Bitcoin.

Run your first query now and get on-chain data back by REST API, SQL or dashboard, with address history back to the genesis block over REST. Informational on-chain data only, not financial advice.

See pricing

History from genesis over REST · SQL · dashboards · addresses, transactions, UTXOs, metrics

Bitcoin UTXO data from the fully-indexed chain

What you get with UTXO data

The full UTXO set

Age and distribution

Foundation for metrics

The UTXO response schema, field by field

The indexed Bitcoin chain, queryable your way

One platform, queryable three ways

REST API

SQL access

Compliance-first

Questions about UTXO data

More ways to query Bitcoin with BitcoinDatabase

Bitcoin address types

Bitcoin dust attack detection

Bitcoin address lookup

Bitcoin broadcast transaction API

Bitcoin transaction decoder

BTC address balance API

Stop running a node. Just query Bitcoin.