BitcoinDatabase.com
How it works
Bitcoin API Block explorer API Address lookup Historical data API Transaction API Bitcoin data API On-chain metrics Rich list Query with SQL Crypto AML API UTXO data Node API Webhook API Price API Transaction monitoring xpub balance API See all →
Glassnode alternative Blockchair alternative BlockCypher alternative Mempool.space alternative Xverse alternative BigQuery alternative Bitquery alternative TimechainIndex alternative CryptoQuant alternative Alchemy alternative QuickNode alternative Hiro alternative Amberdata alternative Elliptic alternative Merkle Science alternative Coin Metrics alternative CoinGlass alternative Crypto APIs alternative Tatum alternative NOWNodes alternative GetBlock alternative Arkham Intelligence alternative Santiment alternative Nansen alternative Allium alternative Flipside alternative SonarX alternative GoldRush alternative Scorechain alternative AMLBot alternative
Docs Pricing Blog Contact Sign in

Query the chain · Realized price

Bitcoin realized price API with MVRV, SOPR and URPD data

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 · address history from genesis

Query Console
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 ...

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

History 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.
The MVRV ratio is market cap divided by realized cap. Market cap prices every coin at spot, while realized cap prices each unspent output at the price on the day it was created, which approximates the aggregate cost basis of the supply. An MVRV of 1 means spot equals that cost basis. The hard input is realized cap, which needs every UTXO, its timestamp and a price series.
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.
Cost basis distribution, also called the UTXO realized price distribution or URPD, buckets the whole bitcoin supply by the price each coin last moved at on-chain. It shows how much supply was acquired at each price level. BitcoinDatabase computes it from timestamped UTXOs on the fully-indexed chain and lets you trace any band to the coins behind it.
Each unspent output is valued at the market price on the day it was created, which approximates the price its holder last acquired it at on-chain. Summing and bucketing those values across the supply gives the cost basis distribution. BitcoinDatabase provides this as informational on-chain data, not a valuation or investment advice.
You can compute acquisition value per output, which is the hard part. The outputs table carries address, value_btc, script_type, a spent flag and price_at_creation_usd, and inputs join back to the output they spend on prev_txid and prev_vout. That gives you full lot lineage. Matching disposals to lots under a chosen method stays your accounting logic.
SOPR, the spent output profit ratio, measures whether spent coins moved at a profit or a loss. For each spent output it divides the price at spend by the price at creation, then averages across a window. Above 1 means coins moved in aggregate profit, below 1 means loss. BitcoinDatabase computes it from spent outputs on the indexed chain.
Adjusted SOPR, or aSOPR, is SOPR with very short-lived outputs removed, typically coins spent within about an hour, because those often reflect internal moves rather than real economic selling. BitcoinDatabase can compute both, as informational on-chain data and analytics, not a trading signal or investment advice.
Almost always because they price the coins differently. The formula is not in dispute, but it needs a USD price for a coin created at an arbitrary past moment, and there is no canonical source for that. We ran one formula over one identical set of 643 spent outputs with three daily close series on 3 September 2026 and got 0.977672, 0.978207 and 0.978806. Vendors rarely publish which series they use.
Far more than most people expect. In our sample of block 965,140, taken on 3 September 2026, 555 of 658 spendable inputs, or 84.3 percent, had a lifespan under one hour. Those are mostly change and relay outputs rather than economic sales, which is exactly the noise adjusted SOPR is designed to remove.
It depends on the implementation, and the two can point in different directions on the same data. In our block 965,140 sample the 20 inputs aged between one and seven days were 3.0 percent of the input count but 66.3 percent of the realized dollars. A count-weighted and a value-weighted reading of that block tell different stories, and neither is wrong. Ask any provider which one you are looking at.
Whatever series the implementation picked, which is the whole problem. Most use a daily close, so a coin created and spent within the same day is priced identically on both sides and contributes exactly 1.000000. Here every output row carries price_at_creation_usd, so the denominator is a stored column you can inspect rather than a join you have to reproduce.
For every output spent in your window, take its value, multiply by the USD price when it was spent, and divide the total by the same values multiplied by the USD price when each output was created. The arithmetic is trivial. The work is resolving the creation time and price of every spent output, which for a single block in our test required 645 extra lookups before any maths could start.
Yes, and this is the main reason to hold the underlying outputs rather than a published series. Because spent outputs, their addresses, their creation prices and their spend times share one schema, you can restrict the ratio to a cohort of addresses, an age band, a script type or a size bucket, and get a SOPR for that slice alone. A vendor endpoint that returns one daily number cannot be sliced after the fact.
Read every Bitcoin API question

Explore more

More ways to query Bitcoin with BitcoinDatabase

Bitcoin price API

Historical and on-chain market data: OHLCV, realized price and cost basis by the chain.

Learn more

Crypto tax API

The on-chain data and price layer that powers Bitcoin tax software and cost-basis calculators.

Learn more

Bitcoin API

Query addresses, transactions and balances across the whole indexed chain in one call.

Learn more

Bitcoin node API

JSON-RPC style access to blocks, transactions and balances, with no Bitcoin Core to run.

Learn more

Bitcoin address labels

Attach exchange, miner and service labels to addresses, so raw hashes read as entities.

Learn more

Bitcoin Network Stats API

Query hashrate, difficulty, block times and network health from the indexed chain.

Learn more

Buyer guides and measurements on this topic

Best Bitcoin SOPR and On-Chain Metrics API for Quant Research Teams We rebuilt SOPR from raw chain data for one Bitcoin block on 3 September 2026 and got three different answers from the same formula and the same 643 s... Best Bitcoin API for Crypto Tax Software and Cost Basis Crypto tax software needs the USD value of every transaction at the moment it confirmed, and the Bitcoin chain does not contain it. On 8 September 202... 1099-DA Reconciliation Software for Bitcoin CPAs 1099-DA reconciliation for bitcoin turns on the transferred-in lots the broker leaves without basis. On 28 September 2026, 1,709 deposits swept into o...
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