BitcoinDatabase.com

Query the chain · Realized price

Bitcoin realized price API for realized cap and MVRV

Realized price is the average price at which every bitcoin in circulation last moved on-chain, and realized cap is the same idea summed across the whole supply: instead of valuing every coin at today's spot price, each coin is valued at the price on the day it last changed hands. The Bitcoin realized price API computes both from the fully-indexed chain. BitcoinDatabase timestamps every UTXO to the block it was created in, values it against historical market data, and rolls the result up into realized cap, realized price, and the MVRV ratio (market cap divided by realized cap).

or try it below ↓

REST API · SQL · dashboards · indexed from genesis

Query Console
btc
try:

Hit Run to query the fully-indexed Bitcoin blockchain.

BTC

30-day trend

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Querying the indexed Bitcoin blockchain ...

Pull the current figures over REST for a dashboard, or run SQL to reconstruct the whole series, band the supply by acquisition price, or join realized price against any other metric you already query here. Because the UTXOs, their timestamps and the price series live in one schema, you can trace any aggregate back to the coins behind it rather than trust a black box. This is informational on-chain data and analytics for research, not a trading signal, a valuation, or investment advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

Indexed from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with Realized price

Realized price and realized cap

Every coin is valued at the price on the day it last moved, then summed into realized cap and divided by supply for realized price, all computed from timestamped UTXOs on the indexed chain rather than pulled from a third party.

MVRV out of the box

Market value to realized value (MVRV) is market cap divided by realized cap. Because both sides come from the same indexed data plus historical prices, you get the ratio and its inputs in one call instead of stitching two feeds together.

Rebuild the whole series in SQL

Realized price is not just a single number. In SQL you can reconstruct the full daily series, band the supply into cost-basis cohorts, or join it against exchange flows and other metrics you already query here.

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.

  • Query current realized price and realized cap
  • Compute the MVRV ratio from indexed data
  • Reconstruct the full historical realized-price series
  • Band supply into cost-basis cohorts
  • Join realized price against other on-chain metrics
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 Realized price

Realized price is the average price at which all bitcoin in circulation last moved on-chain. It is realized cap divided by circulating supply, where each coin is valued at its price on the day it last changed hands rather than at today's spot price. BitcoinDatabase computes it from timestamped UTXOs on the indexed chain.
No. MVRV (market cap divided by realized cap) is an informational on-chain metric that describes how spot price compares to the aggregate cost basis of the supply. BitcoinDatabase provides the data and the calculation only; it is not a trading signal, a valuation, or financial advice.
Realized capitalization values every unspent output at the price when it was created rather than at spot, then sums them. In SQL here that is a single aggregate over the outputs table, multiplying value_btc by price_at_creation_usd for rows where spent is false, because the creation price is stored on the output rather than joined in afterwards.
Because the creation price of each coin has to come from somewhere, and there is no canonical series. We measured this directly on 3 September 2026 by running one metric over one identical set of spent outputs with three defensible daily close series, and got three different answers. Realized cap has the same exposure, compounded over the whole UTXO set.
Most published implementations use a daily close, which is why a coin created and spent inside the same day carries an identical price on both sides. That convention is rarely stated by vendors. Here the price stored on each output is the value we attach at creation, so you can inspect it per row rather than infer the convention from a chart.
They are the same idea at different scopes. Realized price is the cost basis of the entire circulating supply, realized cap divided by supply. Average cost basis usually means the same calculation restricted to a cohort, an entity or an address set. Because the outputs carry their own creation price here, you can compute either by changing the WHERE clause.
Yes, and that is the main argument for holding the outputs rather than a published series. Restrict the aggregate to the addresses, age band, script type or size bucket you care about and you get a realized price for that slice alone. A vendor endpoint returning one daily number for the whole supply cannot be sliced after the fact.
For finished metrics, generally not. The vendors that curate realized cap, NUPL and percent supply in profit put programmatic access behind a paid tier, with free plans limited to charts. The raw material is free from public explorers, but rebuilding it means resolving the creation price of every output back to 2009, which is the actual cost.
Compare each unspent output against current spot: count an output as in profit when its price_at_creation_usd is below the current price, then take the share of supply that satisfies it. Because the creation price sits on the output row, this is a single aggregate rather than a reconstruction, and you can weight it by coin count or by value depending on which question you are asking.

Explore more

More ways to query Bitcoin with BitcoinDatabase

Stop running a node. Just query Bitcoin.

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

See pricing

Indexed from genesis · REST · SQL · dashboards · addresses, transactions, UTXOs, metrics