BitcoinDatabase.com
How it works
Bitcoin API Block explorer API Address lookup Historical data API On-chain data Transaction API Bitcoin data API Wallet tracker On-chain metrics Rich list Address balance API Query with SQL Crypto AML API UTXO data Blockchain API Flow analysis Node API Webhook API Price API Transaction monitoring Mempool API RPC API xpub balance API See all →
Glassnode alternative Dune alternative Blockchair alternative Chainalysis alternative BlockCypher alternative Chainstack alternative Blockchain.com API alternative Mempool.space alternative CoinAPI alternative TRM Labs alternative Whale Alert alternative CoinGecko alternative CoinMarketCap alternative Blockdaemon alternative Xverse alternative BigQuery alternative Bitquery alternative TimechainIndex alternative CryptoQuant alternative Alchemy alternative QuickNode alternative Hiro alternative Amberdata alternative
Docs Pricing Blog Contact

Query the chain · SOPR

Bitcoin SOPR API for the spent output profit ratio

SOPR, the spent output profit ratio, measures whether the coins moving on-chain are being spent at a profit or a loss. For every spent output it compares the price when the coin was created to the price when it was spent: value realized divided by value at creation. Average that across all spent outputs in a window and a reading above 1 means coins are moving in aggregate profit, below 1 means loss, and 1 is breakeven. The Bitcoin SOPR API computes it from the fully-indexed chain, valuing each spent output against historical market data so you get SOPR, adjusted SOPR, and the realized profit and loss behind it.

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 figure over REST for a dashboard, or run SQL to rebuild the whole series, compute adjusted SOPR that filters very short-lived outputs, or split profit-taking from loss-taking. Because spent outputs, their timestamps and the price series share one schema, every SOPR reading traces back to the transactions that produced it rather than a black-box number. 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 SOPR

SOPR and adjusted SOPR

Get the spent output profit ratio for any window, plus adjusted SOPR that filters outputs spent within about an hour to strip out coins that barely moved, both computed from spent outputs valued at creation and spend on the indexed chain.

Realized profit and loss

SOPR is a ratio; the dollars behind it are realized profit and loss. Split value spent in profit from value spent in loss, so you can see not just whether coins moved in the money but how much profit or loss was realized.

Rebuild and slice in SQL

In SQL you can reconstruct the full daily SOPR series, compute it for a subset of the supply, or join it against realized price, exchange flows and other metrics you already query here, then trace any reading back to its spent outputs.

What a SOPR reading is actually sensitive to

On 3 September 2026 we rebuilt SOPR from raw chain data for block 965,140, using 661 sampled spent outputs, and ran the identical formula over three defensible daily close series. We got 0.977672, 0.978207 and 0.978806. The only thing that changed was the price source. That spread of 0.001134 is roughly 5 percent of the distance the reading sat from breakeven, and the two furthest apart were not two exchanges but one exchange against itself, because OKX returns a daily candle starting at 16:00 UTC unless you explicitly ask for bar=1Dutc. The same sample also showed why the adjusted variant exists: 555 of 658 inputs were under an hour old, and at daily price resolution those coins are priced identically on both sides of the ratio, so they contribute exactly 1.000000 by construction. This is the reason we expose the spent outputs and their prices rather than only a finished number. You can see which convention produced a reading, and change it.

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 SOPR and adjusted SOPR for any window
  • Split realized profit from realized loss
  • Reconstruct the full historical SOPR series in SQL
  • Compute SOPR for a cohort or address set
  • Trace any SOPR reading to its spent outputs
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 SOPR

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.
By naive arithmetic, yes, and it happens in real blocks. Block timestamps are not monotonic, since a header only has to exceed the median of the previous eleven blocks. Block 965,140 carries a timestamp 264 seconds earlier than its parent, so 15 inputs in our sample appeared to be spent before they were created. Use block height as the clock for age cohorts and convert to time only at the edges.
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 realized price API

Pull realized price, realized cap and the MVRV ratio from the indexed chain.

Learn more

Bitcoin Supply Metrics API

Query supply in profit and loss, HODL waves and exchange supply from the indexed chain.

Learn more

Bitcoin flow analysis

Trace how funds move between addresses, clusters and entities.

Learn more

Bitcoin transaction volume

Raw, change-adjusted and entity-adjusted on-chain volume series from the indexed chain.

Learn more

Bitcoin active addresses

Daily active address counts, historical series and entity-adjusted numbers from the indexed chain.

Learn more

Bitcoin API

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

Learn 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, 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