Reference Rate Metrics

Overview

The Coin Metrics Reference Rates give the price of one unit of an asset in a quoted currency, calculated from observable transactions on a vetted set of constituent markets rather than taken from any single venue. The methodology is rules-based, published, and designed to be resistant to manipulation, so the rate answers "what is this asset worth right now" in a way that can be audited and reproduced.

The rates are published at frequencies from once a day down to every 200 milliseconds, in U.S. dollars, euros, Bitcoin, and Ethereum. Fund administrators use them to strike net asset value, index providers and derivatives issuers use them as settlement and closing prices, on-chain oracles republish them, and research and risk teams use them as the price series underlying volatility, basis, and valuation work.

At a Glance

Data type	Entities	Frequency / cadence	Unit	Primary endpoint	Coverage
Metric	Assets	1d, 1d-ny-close, 1h, 1m, 1s (HTTP); 1s, 200ms (websocket)	USD, EUR, BTC, ETH	/timeseries/asset-metrics	🔗

Metrics

The family is one calculation published against four quote currencies. The metric ID carries the quote currency as a suffix, and every metric supports the same set of frequencies.

Metric	Description	Frequency	Coverage
ReferenceRate	The price of an asset quoted in U.S. dollars using a framework to select high quality constituent markets and a methodology that is resistant to manipulation.	1d, 1d-ny-close, 1h, 1m, 1s	🔗
ReferenceRateUSD	The price of an asset quoted in U.S. dollars using a framework to select high quality constituent markets and a methodology that is resistant to manipulation.	1d, 1d-ny-close, 1h, 1m, 1s	🔗
ReferenceRateEUR	The price of an asset quoted in euros using a framework to select high quality constituent markets and a methodology that is resistant to manipulation.	1d, 1d-ny-close, 1h, 1m, 1s	🔗
ReferenceRateBTC	The price of an asset quoted in Bitcoin using a framework to select high quality constituent markets and a methodology that is resistant to manipulation.	1d, 1d-ny-close, 1h, 1m, 1s	🔗
ReferenceRateETH	The price of an asset quoted in Ethereum using a framework to select high quality constituent markets and a methodology that is resistant to manipulation.	1d, 1d-ny-close, 1h, 1m, 1s	🔗

ReferenceRate and ReferenceRateUSD are the same series under two names. They read from the same underlying data and always return identical values, so pick one and use it consistently. ReferenceRate is the older name, kept for backwards compatibility.

The 200ms frequency is available only over the websocket endpoint. See Frequencies and how each one is produced.

Conventions. Decimals are returned as JSON strings to preserve precision. Timestamps are UTC ISO-8601 with nanosecond resolution, and time is the Calculation Time of the rate, meaning the instant the value describes rather than the instant it was published. These metric IDs use camel case rather than the snake case used elsewhere in the API, for historical reasons. An asset is never quoted in its own unit, so ReferenceRateETH is not published for Ethereum and ReferenceRateBTC is not published for Bitcoin.

Methodology

The rate is produced in three stages: select the constituent markets for an asset, collect every observable transaction on those markets, and reduce those transactions to a single price at the Calculation Time. Two distinct calculation algorithms are used, one for the daily and hourly frequencies and one for the real-time frequencies, and which one a request receives depends on the frequency asked for.

The authoritative statement of the methodology is the Coin Metrics Prices Methodology, which governs the rates as a benchmark. The subsections below describe how that methodology behaves in practice.

Constituent markets and trade collection

Each asset is priced from its own set of constituent markets, selected by a rules-based process set out under Data Inputs in the methodology. That process runs in three steps. Exchange trustworthiness is quantified by the Talos Exchange Scorecard. A universe of candidate markets is then generated for the asset, based on which quote assets are conventional for it. Those candidates are finally narrowed to constituent markets by excluding markets below a volume market share threshold, excluding markets whose volume-weighted average price sits more than 3 percent from the median across candidates, and ranking what remains by quote asset and then by exchange score.

The selected set is refreshed quarterly, and in between when market conditions warrant. Constituent markets are centralized exchange spot markets and, where relevant, decentralized exchange pools, so an asset that trades mostly on-chain can still be priced.

Trades on those markets are collected continuously from exchange websocket and REST interfaces, normalized into a common trade record, and made available to the calculation. Only executed transactions are used. Quotes, order book levels, and indicative prices are never inputs.

A constituent market that cannot be collected during a given calculation, because of a technical problem at the exchange, is left out of that instance of the rate rather than stalling it.

Converting to the quote currency

Not every constituent market quotes the asset directly in the target currency. A transaction priced in another currency is converted using the Coin Metrics Reference Rate for that currency, so an XRP/BTC trade contributes to the XRP rate in U.S. dollars by way of the BTC rate in U.S. dollars. The conversion currencies are Bitcoin, Ethereum, USD Coin, and Tether.

This creates a deliberate ordering. Bitcoin and Ethereum are priced first, and their rates then feed the assets that depend on them. Where a market is quoted the other way round from the target pair, the price is inverted and the trade size is restated in the other unit so the volume weighting stays correct.

The euro rate is handled as its own case, since a euro-quoted market prices the asset in euros directly rather than needing conversion.

Calculation algorithm for daily and hourly frequencies

The daily and hourly rates use a volume-weighted median within one-minute intervals, followed by a time-weighted average across those intervals.

The Observation Window spans 61 minutes: it opens 60 minutes before the Calculation Time and closes one minute after it, and is partitioned into 61 one-minute intervals. Every observable transaction from the constituent markets in that window is converted to the quote currency and assigned to the interval it falls in.

For each interval, the volume-weighted median price is taken. Transactions are ordered from lowest to highest price, volumes are accumulated in that order, and the price of the transaction at the 50th percentile of volume is the interval's price.

The published rate is the weighted sum of those interval prices:

$$R=\sum_{i=1}^{61} w_i \cdot P_i$$

where $P_i$ is the volume-weighted median price of interval $i$ and $w_i$ is its weight. The first interval is assigned a weight of zero. The remaining weights increase linearly across the window so that intervals nearer the Calculation Time count for more, and the final two intervals are each assigned 5 percent. The weights sum to 100 percent. The full weight schedule is published in Appendix B of the methodology.

Because the window extends one minute past the Calculation Time, the value cannot be computed at the Calculation Time itself. The calculation is deliberately deferred further: it begins five minutes after the Calculation Time, which gives trades from the constituent markets time to arrive and settle before the window is read. The value is written as soon as the computation finishes. The methodology defines the Publication Time as within five minutes of the Calculation Time. In practice, expect a new hourly value to become queryable a few minutes past the hour rather than at the top of it, so a job that polls at exactly HH:00 for the HH:00 rate will find nothing.

Three contingency rules cover gaps in the window. An interval with no transactions borrows the next interval's price, applied recursively. A final interval with no transactions borrows the previous interval's price, again recursively. If the entire window contains no transactions at all, the rate carries forward the most recent hourly rate that did have trades in its window.

Calculation algorithm for real-time frequencies

The real-time rates use a different construction. Rather than averaging over a window, they take the most recent trade from each constituent market and reduce those to a single price by a weighted median, with the weights recalculated continuously from a trailing 60-minute view of the market.

Each constituent market maintains a rolling 60-minute buffer of trades. At each calculation instant:

1. Inactive markets are dropped. The mean interval between consecutive trades is computed across the combined trade stream of all constituent markets over the trailing 60 minutes, and multiplied by 100 to give an active-market cutoff. Any market whose time since last trade exceeds that cutoff is excluded. If this would exclude every market, the exclusion is overridden and all markets are treated as active, so the rate never goes stale purely from a quiet period.
2. A volume weight is computed. Each active market's trailing 60-minute volume in native units is divided by the total across all active markets.
3. An inverse price variance weight is computed. For each active market, the variance of its converted trade prices over the trailing 60 minutes is taken around the global mean price across all constituent markets, and inverted. That figure is scaled by the fraction of the last 60 minutes in which the market traded at all, so a market that traded in 12 of the last 60 minutes has its inverse variance multiplied by 0.2. A market with infinite or undefined inverse variance is assigned zero. The scaled figures are then normalized to sum to one. This weighting favors markets that trade tightly around the consensus price and consistently over time.
4. The two weights are averaged. The final weight for each market is the arithmetic mean of its volume weight and its inverse price variance weight.
5. The weighted median is taken. The most recent trade price from each active market, converted to the quote currency, is ordered from lowest to highest. Weights are accumulated in that order, and the price at the 50th percentile of total weight is the published rate.

Written out, the final weight applied to market $m$ is:

$$w_m=\frac{1}{2}\left(\frac{V_m}{\sum_k V_k}+\frac{\tilde{I}_m}{\sum_k \tilde{I}_k}\right)$$

where $V_m$ is the trailing 60-minute volume of market $m$ and $\tilde{I}_m$ is its scaled inverse price variance.

Averaging the volume and variance weights is what makes the result hard to move. A market would need both a large share of volume and prices that sit tightly around the consensus to pull the median, and a venue printing an outlier price gets a high variance and therefore a small weight precisely when it would do the most damage.

If no constituent market has any trade in the trailing 60 minutes, the rate carries forward the value from the previous calculation instant.

Frequencies and how each one is produced

The two algorithms above produce two underlying series, and every frequency the API exposes is a view onto one of them.

• 1h returns the hourly series directly, one value per hour on the hour.
• 1d returns the hourly series sampled once per day, at midnight in the requested timezone. That parameter defaults to UTC, so the default daily observation is 00:00 UTC. Setting timezone=Asia/Tokyo returns the 15:00 UTC observation instead, which is midnight in Tokyo.
• 1d-ny-close returns the daily observation at 16:00 America/New_York, the standard close reference for U.S. financial products. That lands at 20:00 UTC during daylight saving time and 21:00 UTC outside it.
• A custom daily offset of the form 1d-HH:MM returns the daily observation at that time of day. An offset on the hour, such as 1d-16:00, comes from the hourly series. An offset off the hour, such as 1d-10:30, comes from the real-time series instead, because the hourly series has no observation at that minute.
• 1m returns the real-time series sampled on minute boundaries.
• 1s returns the real-time series at one value per second.
• 200ms returns the real-time series at five values per second and is available only over the websocket endpoint.

The practical consequence is that 1h, 1d, and 1d-ny-close come from the 61-minute time-weighted average, while 1m, 1s, and 200ms come from the weighted median of last trades. Values at the same timestamp from the two groups will not agree exactly, and they are not meant to. The real-time series also carries fewer decimal places, since it publishes an observed trade price rather than a computed average.

Accessing the Data

The metrics are served through one HTTP endpoint and one websocket endpoint:

• /timeseries/asset-metrics
• /timeseries-stream/asset-metrics

The HTTP endpoint supports the 1d, 1d-ny-close, 1h, 1m, and 1s frequencies plus custom 1d-HH:MM offsets. The websocket endpoint supports 1s and 200ms. The tabs below pull hourly U.S. dollar rates for BTC.

Python Client

from coinmetrics.api_client import CoinMetricsClient
from datetime import timedelta
import os

client = CoinMetricsClient(os.environ["CM_API_KEY"])

df = client.get_asset_metrics(
    assets=["btc"],
    metrics=["ReferenceRateUSD"],
    frequency="1h",
    start_time="2026-01-01",
    end_time="2026-08-01",
    format="json_stream",
).parallel(time_increment=timedelta(days=7)).to_dataframe()

Shell

curl --compressed "https://api.coinmetrics.io/v4/timeseries/asset-metrics?assets=btc&metrics=ReferenceRateUSD&frequency=1h&start_time=2026-01-01&end_time=2026-08-01&page_size=10000&api_key=$CM_API_KEY"

Python

import os
import requests

response = requests.get(
    "https://api.coinmetrics.io/v4/timeseries/asset-metrics",
    params={
        "assets": "btc",
        "metrics": "ReferenceRateUSD",
        "frequency": "1h",
        "start_time": "2026-01-01",
        "end_time": "2026-08-01",
        "page_size": 10000,
        "api_key": os.environ["CM_API_KEY"],
    },
).json()

For the real-time frequencies, the websocket endpoint delivers each value as it is produced instead of requiring a poll:

from coinmetrics.api_client import CoinMetricsClient
import os

client = CoinMetricsClient(os.environ["CM_API_KEY"])

client.get_stream_asset_metrics(
    assets=["btc"],
    metrics=["ReferenceRateUSD"],
    frequency="200ms",
).run()

Full parameter reference: see the API Reference for /timeseries/asset-metrics and /timeseries-stream/asset-metrics.

Examples

Example: hourly reference rate

Hourly U.S. dollar rates for BTC, from the 61-minute time-weighted average. Open in browser ↗

{
  "data": [
    {
      "asset": "btc",
      "time": "2026-08-08T01:00:00.000000000Z",
      "ReferenceRateUSD": "64862.0554628872"
    },
    {
      "asset": "btc",
      "time": "2026-08-08T02:00:00.000000000Z",
      "ReferenceRateUSD": "64883.3592022209"
    },
    {
      "asset": "btc",
      "time": "2026-08-08T03:00:00.000000000Z",
      "ReferenceRateUSD": "64883.69814436"
    }
  ]
}

Example: one asset in several quote currencies

Hourly rates for ETH in U.S. dollars, euros, and Bitcoin. ReferenceRateETH was requested as well but is absent, because Ethereum is not quoted in its own unit. Open in browser ↗

{
  "data": [
    {
      "asset": "eth",
      "time": "2026-08-08T01:00:00.000000000Z",
      "ReferenceRateBTC": "0.0294996517001456",
      "ReferenceRateEUR": "1655.83386732905",
      "ReferenceRateUSD": "1913.4080447107"
    },
    {
      "asset": "eth",
      "time": "2026-08-08T02:00:00.000000000Z",
      "ReferenceRateBTC": "0.0294994901784939",
      "ReferenceRateEUR": "1656.36069549971",
      "ReferenceRateUSD": "1914.02601753361"
    },
    {
      "asset": "eth",
      "time": "2026-08-08T03:00:00.000000000Z",
      "ReferenceRateBTC": "0.0294754147122712",
      "ReferenceRateEUR": "1655.00397194623",
      "ReferenceRateUSD": "1912.47391087084"
    }
  ]
}

Example: daily rate at New York close

The same series sampled at 16:00 America/New_York, which is 20:00 UTC during daylight saving time. Open in browser ↗

{
  "data": [
    {
      "asset": "btc",
      "time": "2026-08-05T20:00:00.000000000Z",
      "ReferenceRateUSD": "64850.4965818235"
    },
    {
      "asset": "btc",
      "time": "2026-08-06T20:00:00.000000000Z",
      "ReferenceRateUSD": "64376.5489567504"
    },
    {
      "asset": "btc",
      "time": "2026-08-07T20:00:00.000000000Z",
      "ReferenceRateUSD": "64915.6701426067"
    }
  ]
}

Example: 200 millisecond stream

Messages from the websocket endpoint at the fastest published frequency. cm_sequence_id increments per message on the connection and lets a consumer detect a gap.

{"time":"2026-08-08T03:34:21.200000000Z","asset":"btc","ReferenceRateUSD":"65018.65","cm_sequence_id":"0"}
{"time":"2026-08-08T03:34:21.400000000Z","asset":"btc","ReferenceRateUSD":"65018.65","cm_sequence_id":"1"}
{"time":"2026-08-08T03:34:21.600000000Z","asset":"btc","ReferenceRateUSD":"65018.66","cm_sequence_id":"2"}
{"time":"2026-08-08T03:34:21.800000000Z","asset":"btc","ReferenceRateUSD":"65018.66","cm_sequence_id":"3"}
{"time":"2026-08-08T03:34:22.000000000Z","asset":"btc","ReferenceRateUSD":"65018.66","cm_sequence_id":"4"}

Coverage

Coverage lists every asset with a reference rate, the quote currencies published for each, and the available time range.

Coin Metrics CoverageCoin Metrics Coverage

Usage

The right frequency and the right algorithm depend on what the number is being used for.

• Strike net asset value or a closing price. Use 1d-ny-close, or a custom 1d-HH:MM offset on the hour to match a fund's own valuation point. These come from the 61-minute time-weighted average, the construction designed for a benchmark fixing and the one that resists a burst of trading at the valuation instant.
• Settle a derivative or fix an index level. Same construction, same reasoning. The averaging window and the published weight schedule are what make the fixing auditable and hard to influence.
• Mark a book intraday or drive a risk system. Use 1s over HTTP, or 1s and 200ms over the websocket. These track the market as it moves rather than smoothing across an hour.
• Feed an on-chain oracle. The rates are published to Pyth Network, so an on-chain or off-chain application can consume them through that route rather than through the API.
• Backtest or research. History runs back to each asset's earliest covered trading, at every frequency rather than only the coarse ones, so a one-second series is available over roughly the same span as the daily one. Check that the frequency used in a backtest matches the frequency a live system would consume, since the two algorithms do not produce identical values.
• Convert between assets. ReferenceRateBTC and ReferenceRateETH give a direct crypto-denominated rate without composing two U.S. dollar rates yourself.

Limitations

• Two algorithms in one family. The daily and hourly frequencies and the real-time frequencies are produced by different calculations. A 1h value and a 1m value stamped the same minute will differ, and neither is a resampling of the other. Do not build a single series that crosses between them.
• The value is not available at its own timestamp. The daily and hourly Observation Window extends one minute past the Calculation Time, and the calculation itself does not begin until five minutes after it. A system that needs a value at the instant it is stamped needs a real-time frequency instead, and any scheduled job pulling the HH:00 hourly rate should run several minutes past the hour. The real-time frequencies carry no such delay.
• Stale-market carry-forward. When no constituent market trades in the relevant window, the rate repeats its previous value rather than going null. A flat series during a quiet period may reflect the contingency rule rather than a genuinely unchanged market.
• Conversion dependency. Assets without a direct market in the quote currency are priced through the Bitcoin, Ethereum, USD Coin, or Tether rate. Error or dislocation in a conversion rate propagates to everything priced through it.
• Constituent markets change. The market set is reselected as venues and liquidity change, so the inputs behind a rate are not fixed across history.
• Not quoted in its own unit. ReferenceRateBTC is not published for Bitcoin and ReferenceRateETH is not published for Ethereum. Requesting them returns no field rather than a value of 1.
• Camel case metric IDs. These IDs predate the snake case convention used elsewhere in the API. Code that constructs metric names programmatically needs to special-case them.

FAQ

Is ReferenceRate the same as ReferenceRateUSD?

Yes. They resolve to the same underlying series and always return the same value. ReferenceRate is the older name and is kept for backwards compatibility.

Why do the 1h and 1s values disagree?

They are produced by different algorithms. The hourly value is a time-weighted average of volume-weighted medians across a 61-minute window, while the one-second value is a weighted median of the most recent trade on each active constituent market. The first is a smoothed benchmark fixing and the second tracks the market instant by instant.

How do I get a daily rate at a time other than midnight UTC?

Use a frequency offset. 1d-ny-close gives 16:00 America/New_York, and a custom 1d-HH:MM gives any time of day. An offset on the hour is served from the hourly series, and an offset off the hour is served from the real-time series.

When does a new hourly or daily value become available?

Not at the timestamp it carries. The Observation Window runs one minute past the Calculation Time, and the calculation is then deliberately held a further five minutes so that trades from the constituent markets have time to arrive. Schedule any job that pulls the HH:00 rate to run several minutes past the hour. The real-time frequencies have no such delay and publish continuously.

Why does the real-time rate have fewer decimal places?

Because it publishes an observed trade price, selected as the weighted median of the last trades across constituent markets, rather than a figure computed by averaging. The daily and hourly rates are the result of arithmetic and carry more digits.

Can I get the 200ms frequency over HTTP?

No. 200ms is available only on /timeseries-stream/asset-metrics. The HTTP endpoint's fastest frequency is 1s.

What is cm_sequence_id in the websocket messages?

A counter that increments with each message on a connection. Comparing it across consecutive messages tells a consumer whether anything was missed.

Which assets have a reference rate?

The coverage page is the authoritative list, with the quote currencies and time range available for each asset.

Related

• Coin Metrics Prices: the overview of the Coin Metrics price products.
• Principal Market Price Metrics: the alternative price construction, taken from a single principal market for fair value measurement under IFRS 13 and ASC 820, along with the identity of that market.
• Coin Metrics Prices Methodology: the governing methodology document, including constituent market selection and the full weight schedule.
• Coin Metrics Prices Policies: administration, oversight, recalculation, and material change policies for the rates.
• Talos Exchange Scorecard: the exchange evaluation that feeds candidate market selection.
• Pair Candles: OHLCV candles built from the reference rate for a pair.
• Realized Volatility Metrics: volatility measured on the reference rate series.