Best Bitcoin SOPR and On-Chain Metrics API for Quant Research Teams

If you are buying a Bitcoin on-chain metrics API for a research desk, the pitch you will hear is coverage: hundreds of metrics, decades of history, one endpoint each. That is the wrong axis to choose on. Every serious metric is a small formula applied to a very large amount of chain data, and almost all of the disagreement between vendors comes from decisions that never appear in the metric definition.

So we did the thing a buyer rarely gets to do. We computed SOPR ourselves, from raw outputs, and watched where the number moved.

What we measured, and how

We sampled Bitcoin block 965,140, which contains 6,534 transactions and carries a header timestamp of 2 September 2026 at 07:51:40 UTC. We pulled 600 transactions from 24 evenly spaced pages across the block so the sample was not just the front of it, which gave 661 spendable inputs. For each one we fetched the transaction that created the coin to get its confirmation time, and all 645 distinct prior transactions resolved.

Then we priced every coin twice, once at creation and once at spend, and took the ratio. That is SOPR: realized value divided by value at creation. Above 1 means the coins moved in aggregate profit, below 1 means loss. The formula is not in dispute and Glassnode publishes it in its own metric documentation.

What is in dispute, silently, is the price series.

Why do two providers report different SOPR values?

Because the formula needs a USD price for a coin created at an arbitrary moment years ago, and there is no canonical answer to that. We ran the identical calculation over the identical 643 spent outputs with three defensible daily close series.

The full spread is 0.001134 on SOPR and 0.001550 on aSOPR. That sounds tiny until you remember what SOPR is used for. Nobody reads the level; they read the distance from 1.00 and which side of it the line is on. Our aSOPR sits 0.030 below breakeven, so the choice of price series moved roughly 5 percent of the entire quantity being measured. On a day when the metric is hovering near 1.00, which is exactly when people act on it, that is not a rounding difference.

Note which two rows differ most. It is not two different exchanges. It is one exchange against itself. OKX returns a daily candle whose day starts at 16:00 UTC by default, and only returns a real UTC day if you ask for bar=1Dutc. Both calls return HTTP 200 and a field named close. We found four venues that do this when we compared eighteen candle endpoints for our Bitcoin OHLC API page, and the correct parameter is spelled three different ways across them. A metrics pipeline that quietly picked the default on any of those four is off by a 16 hour phase shift on every coin it ever priced.

What is the difference between SOPR and adjusted SOPR?

Adjusted SOPR is the same ratio with coins younger than one hour thrown out. Glassnode's documentation gives the reason plainly: very short lived outputs usually are not a sale or a purchase at all, they are relay transactions and change, and counting them adds noise. That is a claim about real chain data, so we measured how much of a block it actually is.

555 of 658 inputs, 84.3 percent of the block sample, were under an hour old. At daily price resolution those coins were created and spent inside the same candle, so they are priced identically on both sides of the ratio and contribute exactly 1.000000 by construction. They cannot say anything about profit or loss. They can only dilute whatever the rest of the block is saying, which is precisely why the adjusted variant exists.

Now look at the third row, because it reverses the story. The 20 inputs aged between one and seven days are 3.0 percent of the count and 66.3 percent of the realized dollars. Count weighted and value weighted views of the same block point in different directions, and neither is wrong. Ask any vendor which one their metric uses before you build a thesis on it.

The measurement error nobody warns you about

Fifteen of our 658 inputs produced a negative coin lifespan. Not a small age, a negative one. The coins appeared to have been spent 264 seconds before they were created.

The cause is not a bug in the data. It is Bitcoin. A block header timestamp only has to exceed the median of the previous eleven blocks and stay within a couple of hours of network time, so block timestamps are not monotonic. Block 965,140 carries a timestamp of 07:51:40 UTC while its parent, block 965,139, carries 07:56:04 UTC. Anyone can check those two headers. Fifteen inputs in the child spent outputs created in the parent, so a naive subtraction of creation time from spend time returns minus 264 seconds.

For SOPR this happens to be harmless, because a negative lifespan is under an hour and the adjusted variant discards it anyway. For anything that buckets coins by age it is not harmless at all. HODL waves, coin days destroyed, dormancy and realized cap by age cohort all subtract two timestamps. Depending on how the pipeline was written that value lands in a nonsense bucket, gets silently clamped to zero, throws on an unsigned type, or quietly shifts a cohort. Use block height as your clock and only convert to time at the edges. If your vendor cannot tell you which they use, that is a real answer about how the number was built.

Which Bitcoin on-chain metrics API is best for a quant research team?

Match the tool to how much you need to defend the number, because the honest split is not about quality.

If you need a chart and a documented series, buy the metric. Glassnode and CryptoQuant have spent years curating definitions, and reproducing that catalogue yourself is a bad use of a quant team. Our comparisons of what each actually costs and includes are on the Glassnode alternative page and the CryptoQuant alternative page. Read the API access tier carefully in both cases; on more than one of these vendors the cheap plan does not include API access at all.

If you need derivatives, options and many chains, buy breadth. Amberdata is the standard answer and it is a good one, though as of June 2026 it belongs to Kaiko, which is worth knowing before you sign a multi-year contract. We wrote up what we measured of its pricing and auth surface on the Amberdata alternative page.

If you need to rebuild and audit the metric, buy the data. This is the case for a desk that has to explain a number to a risk committee, or that wants a variant nobody sells. What you need then is not a metrics endpoint but the outputs themselves with a price already attached, which is what our Bitcoin SOPR API and Bitcoin realized price API are built on: every output row carries its value, its address and the USD price at creation, so the denominator of SOPR is a column rather than a join you have to get right.

Whichever way you go, keep the lineage. A published metric is a chain of upstream choices, and six months later nobody remembers which price series produced the chart in the deck. Teams that trace a number back to the source series it was built from catch a vendor changing a definition; teams that do not, discover it when the backtest stops reproducing.

Is there a free Bitcoin on-chain metrics API?

For finished metrics, essentially no. The vendors that curate SOPR, NUPL, realized cap and percent supply in profit put API access behind a paid tier, and the free plans are usually chart access rather than programmatic access. For the raw material, yes: public explorer APIs will serve you blocks, transactions and outputs without a key, and exchange candle endpoints will serve you daily closes. That is exactly what we used for this measurement, and it cost nothing but time.

The catch is what that time actually is. Our sample of 661 inputs from one block needed 645 additional transaction fetches just to learn when the coins were created. Doing that for every input in every block, back to 2009, is the entire product. It is a few hundred lines of logic and a very large amount of storage and patience, and the reason people buy an indexed chain rather than build one is the second part, not the first.

What we did not measure

Being explicit about the limits, because a number without its caveats is worth less than no number.

This is one block, sampled, not a daily series. 600 of 6,534 transactions, 661 inputs. Real SOPR is computed over every spent output in a full day, and a single block will not match a vendor's daily print. Our band level figures rest on very small counts at the older end, four inputs over 180 days, so read those rows as illustration rather than as an estimate of anything. We used daily closes for both sides of the ratio because that is the common convention and it makes the venue comparison clean, but a vendor using hourly or trade level pricing will land somewhere else again, probably further from 1.000000 on the short lived coins. We did not test whether the specific vendors named here use daily or intraday pricing, because none of them publish it. And we compared three price series, not all of them; there are dozens, and we have separately found daily candle endpoints that disagree with each other by 9 basis points on the same UTC day.

If you want to reproduce any of it, every input is public. The block hash is 000000000000000000019fe168ffd57bfdf1a07de5597eaf00b48c72d0ce7b2a, the price series are open endpoints, and the two block headers that produce the negative lifespan are 965,139 and 965,140. That is the standard we would apply to a vendor, so it is the one we apply to ourselves. If you want the underlying chain data with prices already attached, that is what our historical Bitcoin data API serves, and there is a plain language walkthrough of the metric family in on-chain metrics explained.

All figures measured on 3 September 2026 from a single US machine. Informational on-chain data and analytics only, not investment, financial or legal advice.