Valuation

Contents

• Network Value to Transactions (NVTAdj)

• Network Value to Transactions Free Float (NVTAdjFF)

• Realized Cap to Thermo Cap (RCTC)

• RVT Ratio (RVT)

• Spent Output Price Ratio (SOPR)

Network Value to Transactions

Definition

The ratio of the network value (or market capitalization, current supply) divided by the adjusted transfer value. Also referred to as NVT.

Name	MetricID	Unit	Interval
NVT	NVTAdj	Dimensionless	1 day
NVT 90-day Moving Avg	NVTAdj90	Dimensionless	1 day

Details

• This metric uses the native units network value and adjusted transaction volume. It is therefore available at the asset’s genesis, unlike if it was using USD values.

• It can be thought of as a rough P/E (price to earnings) ratio proxy for crypto assets.

• First conceptualized by Willy Woo (2017) with the introduction of the network value to transactions (NVT) ratio, calculated as a cryptoasset’s market capitalization divided by its daily value transacted over the network. The logic behind the ratio is that value transacted over an asset’s network represents the utility of a cryptoasset. High values of the NVT ratio have detected bubbles and low values have indicated attractive entry points in the past.

• NVTAdj90 is computed as the current market cap over the 90-day moving average of USD adjusted transfer volume.

• Inspired by Kalichkin’s work. Kalichkin (2018a) extended the idea behind the NVT ratio by introducing additional smoothing to correct for certain shortcomings in the original formulation that prevent it from being used as a real-time trading indicator.

Release History

• Released in the 1.0 release of NDP

Interpretation

NVT has been much discussed; in short, it compares market capitalization to on-chain transactional usage. Blockchains with low usage relative to market cap have a higher NVT. In this sense it can be understood as the opposite of velocity. Due to structural dissimilarities in blockchain usage modes, NVTs among all assets are not directly comparable. Our formulation employs adjusted transaction volume, as we understand this to be a purer measure of the actual usage of the chain.

Availability for Assets

Coin Metrics CoverageCoin Metrics Coverage

Coin Metrics CoverageCoin Metrics Coverage

Network Value to Transactions Free Float

Definition

The ratio of the free float network value (or market capitalization, free float) divided by the adjusted transfer value. Also referred to as FFNVT.

Name	MetricID	Unit	Interval
Free Float NVT	NVTAdjFF	Dimensionless	1 day
Free Float NVT 90-day Moving Avg	NVTAdjFF90	Dimensionless	1 day

Details

• This metric provides an important adjustment to the Network Value to Transaction (NVT) Ratio using Free Float Supply (SplyFF)

• For more details on the significance of this improvement, please refer to the following blog post.

• This metric uses the native units network value and adjusted transaction volume. It is therefore available at the asset’s genesis, unlike if it was using USD values.

• It can be thought of as a rough P/E (price to earnings) ratio proxy for crypto assets.

• NVT was first conceptualized by Willy Woo (2017) with the introduction of the network value to transactions (NVT) ratio, calculated as a cryptoasset’s market capitalization divided by its daily value transacted over the network. The logic behind the ratio is that value transacted over an asset’s network represents the utility of a cryptoasset. High values of the NVT ratio have detected bubbles and low values have indicated attractive entry points in the past.

Release History

• Release Version: NDP-EOD 4.8 (Nov, 2020)

Interpretation

NVT has been much discussed; in short, it compares market capitalization to on-chain transactional usage. Blockchains with low usage relative to market cap have a higher NVT. In this sense it can be understood as the opposite of velocity. Due to structural dissimilarities in blockchain usage modes, NVTs among all assets are not directly comparable. Our formulation employs adjusted transaction volume, as we understand this to be a purer measure of the actual usage of the chain.

See Also

• NVT

• Free Float NVT 90-day Moving Avg

Availability for Assets

Coin Metrics CoverageCoin Metrics Coverage

Realized Cap to Thermo Cap (RCTC)

Definition

The ratio of the Realized Cap over Thermo Cap at the end of that interval. Realized Cap (CapRealUSD) is defined as the sum USD value based on the USD closing price on the day that a native unit last moved (i.e., last transacted) for all native units. Thermo Cap is calculated as RevAllTimeUSD and it represents the USD value of all funds disbursed to miners at the time of issuance.

Name	IMetricD	Unit	Interval
Realized Cap to Thermo Cap (RCTC)	RCTC	Dimensionless	1 day

Details

• Like MVRV, RCTC can be used to better understand the market cycle as it identifies the ralationship between the network's overall cost basis (CapRealUSD) relative to the USD amount issued to miners by the protocol (RevAllTimeUSD).

• When evaluating market tops, RCTC provides a view on the realization of profits relative to the liquidity that is being issued to miners.

• Miners are speculators as they are naturally exposed to the price of the currency they are mining. As such, they collectively make buy or sell decisions that ultimately impact the market.

Chart

Interpretation

• This metric fundamentally showcases the impact of miner liquity in the overall market. When the USD value of miner income is low relative to what is being realized on-chain, this could be interpreted as a sign of market tops.

• This metric could also be interpreted as the profit margin that might be realized by miners as it showcases the gap between profit taking.

• Historically, a threshold of 10 has been indicative of market tops as a wide profit margins are being realized relative to the USD value being issued to miners.

Asset-Specific Details

Only applicable to assets for which we have RevAllTimeUSD and CapRealUSD.

Release History

• Release Version: NDP 5.0 (August, 2021)

See Also:

• MCRC (Market Cap / Realized Cap)

• MVRV (Market Cap / Realized Market Cap)

Availability for Assets

https://docs.coinmetrics.io/info/metrics/CapMVRVFFdocs.coinmetrics.io

RVT

Definition

The ratio of the network's realized value to its adjusted transfer value. Also referred to as RVT.

Name	MetricID	Unit	Interval
RVT	RVT	Dimensionless	1 day
RVT 90-day Moving Avg	RVTAdj90	Dimensionless	90 days

Details

• Computed as realized value (aka realized market cap) over adjusted transfer value.

• Checkmate (2019) formulates the realized capitalization to transaction value (RVT) ratio which uses the same fundamental principles behind the NVT ratio but uses realized capitalization instead of market capitalization in the numerator of the ratio.

• RVTAdj90 is computed as the network's realized value (aka realized market cap) over the 90-day moving average of USD adjusted transfer volume.

Release History

• Release Version: NDP-EOD 4.8 (Nov, 2020)

Interpretation

RVT is based on the same principles as NVT but uses Realized Cap in the numerator. Realized Cap can be a smoother measure of network valuation than the Market Cap as it is concerned with the price at which the coin was last moved on-chain. As a result, both Realized Cap and the RVT are shielded from day-to-day market sentiment and speculation that are reflected in Market Cap.

RVT can be a slower moving, higher conviction signal tuned to the macro sentiment of HODLers.

See Also

• Realized Market Cap (USD)

• RVT 90-day Moving Avg

Availability for Assets

Coin Metrics CoverageCoin Metrics Coverage

Spent Output Profit Ratio (SOPR)

Definition

The ratio of the sum of spent value over the sum of creation value of all spent and created outputs for that interval. There are two versions of this metric. For this version, a spent output’s “spent value” is the market value of the sum of all native units of that output (i.e., price multiplied by the sum of native units). A created output’s “creation value” is the market value of the sum of all native units of that output (i.e., price multiplied by the sum of native units).

Name	MetricID	Unit	Interval
SOPR	SOPR	Dimensionless	1 day
SOPR Out	SOPROut	Dimensionless	1 day

Details

• (Sum of spent value) / (Sum of creation value) of all spent and created outputs for that interval)

• Sum of creation value = Sum of all transactional outputs that interval multiplied by the closing price for that interval

• SOPR was introduced by Renato Shirakashi.

• It oscillates around 1, if below it, people spending are realizing losses, above it, realizing gains.

• SOPROut is our first implementation of SOPR which doesn’t weight outputs by their value.

• SOPROut oscillates around 1, if it is below 1, people spending are realizing losses, above 1, realizing gains.

Asset-Specific Details

• This metric is not available for assets that have full privacy, like Monero, Grin.

• For assets that have opt-in privacy features, like ZCash, it only takes the non-private balances into account.

Chart

The chart above shows the combined SOPR ratio of all UTXOs spent, aggregated on a daily basis. The metric is also smoothed with a 7-day rolling average as SOPR tends to be relatively volatile.

On January 8th 2021, as BTC price topped $40K, BTC SOPR (7-day average) reached 1.048, its highest level since December 2017. The following day BTC price began to decline, and SOPR bottomed out at 1.004 on January 26th with BTC price at $32.6K. It has since rebounded to about 1.015.

Example

• If in a given day, 3 outputs are spent:

  • ** Output A, value 10 BTC, created when BTC was worth $10

  • ** Output B, value 1 BTC, created when BTC was worth $500

  • ** Output C, value 2 BTC, created when BTC was worth $20,000

• If market price is $7,500, SOPR for that day is computed as:

  • ** Sum creation values: $10 * 10 BTC + $500 * 1 BTC + $20,000 * 2 BTC = $40,600

  • ** Sum spent values: $7,500 * 10 BTC + $7,500 * 1 BTC + $7,500 * 2 BTC = $97,500

  • ** SOPR = $97,500 /$40,600 = 2.4014

Release History

• Released in the 5.0 release of NDP

Interpretation

Spent Output Profit Ratio (SOPR) gives another vantage point into bitcoin market cycles. Introduced by Renato Shirakashi in 2019, SOPR can act as a proxy for gauging whether holders are selling at a profit or at a loss.

SOPR is a ratio of bitcoin’s price at the time UTXOs are spent to its price at the time they were created. In other words, it’s a proxy for price sold divided by price paid. Every time a transaction occurs, we can compare bitcoin’s price at the time the UTXOs in that transaction were created to the price at which they were spent. Creating a ratio of the two gives a simple way to estimate whether the bitcoin in the UTXO was sold at a profit or loss.

SOPR can be computed for individual UTXOs, but it can also be computed for a group of UTXOs.

Historically, a high SOPR has signaled that bitcoin price is reaching a local maximum. Conversely, a low SOPR theoretically signals that holders are selling at a loss, which has historically indicated a good time to buy. A SOPR of 1 is also particularly important to watch, as it signals the tipping point from selling in profit to selling at a loss.

Availability for Assets

Coin Metrics CoverageCoin Metrics Coverage

API Endpoints

Address Balances can be accessed using these endpoints:

• timeseries/asset-metrics

and by passing in the metric ID's NVT* , RVT* and SOPR* in the metrics parameter.

Asset metrics

get

Returns requested metrics for specified assets. Results for block by block metrics (1b frequency) are ordered by tuple (asset, height, block_hash), all other metrics are ordered by tuple (asset, time). You can change the sorting using sort query parameter. Supported output formats are json (default) and csv, use format query parameter to override it. To fetch the next page of results use next_page_url JSON response field or x-next-page-url CSV HTTP header if present. If multiple metrics are requested in the same time the strict policy for partially available metrics among requested ones is applied:

Authorizations

Query parameters

assetsstring[]required

Comma separated list of assets. Use the /catalog-all/assets endpoint for the full list of supported assets or specify asterisk (*) in order to get metrics for all supported assets.

metricsstring[]required

Comma separated metrics to request time series data for. Information on all available metrics can be found on page https://coverage.coinmetrics.io/asset-metrics-v2. Use the /catalog-all/metrics or /catalog-all/assets endpoint for the full list of supported metrics per asset.

Example: ["AdrActCnt","BlkHgt"]

frequencystringoptional

Frequency of the metrics. Supported values are 1b (block by block), 1s (one second), 1m (one minute), 5m (five minutes), 10m (ten minutes), 1h (one hour), 1d (one day), 1d-ny-close (one day at New York close time). Please refer to the /catalog/metrics endpoint for the full list. Use the /catalog-all/assets endpoint for the full list of supported frequencies per asset-metric pair.

Default: 1dExample: 1b

statusstring · enumoptional

Which metric values do you want to see. Applicable only for "reviewable" metrics. You can find them in the /catalog/metrics endpoint.

Default: allAvailable options:

start_timestringoptional

Start of the time interval. This field refers to the time field in the response. Multiple formats of ISO 8601 are supported: 2006-01-20T00:00:00Z, 2006-01-20T00:00:00.000Z, 2006-01-20T00:00:00.123456Z, 2006-01-20T00:00:00.123456789Z, 2006-01-20, 20060120. Inclusive by default. Mutually exclusive with start_height and start_hash. UTC timezone by default. Z suffix is optional and timezone parameter has a priority over it. If start_time is omitted, response will include time series from the earliest time available.

end_timestringoptional

End of the time interval. This field refers to the time field in the response. Multiple formats of ISO 8601 are supported: 2006-01-20T00:00:00Z, 2006-01-20T00:00:00.000Z, 2006-01-20T00:00:00.123456Z, 2006-01-20T00:00:00.123456789Z, 2006-01-20, 20060120. Inclusive by default. Mutually exclusive with end_height and end_hash. UTC timezone by default. Z suffix is optional and timezone parameter has a priority over it. If end_time is omitted, response will include time series up to the latest time available.

start_heightinteger · int64optional

The start height indicates the beginning block height for the set of data that are returned. Inclusive by default. Mutually exclusive with start_time and start_hash.

end_heightinteger · int64optional

The end height indicates the ending block height for the set of data that are returned. Inclusive by default. Mutually exclusive with end_time and end_hash. This parameter is disabled for Community users.

start_hashstringoptional

The start hash indicates the beginning block height for the set of data that are returned. Inclusive by default. Mutually exclusive with start_time and start_height.

end_hashstringoptional

The end hash indicates the ending block height for the set of data that are returned. Inclusive by default. Mutually exclusive with end_time and end_height.

start_inclusivebooleanoptional

Inclusive or exclusive corresponding start_* parameters.

Default: true

end_inclusivebooleanoptional

Inclusive or exclusive corresponding end_* parameters.

Default: true

min_confirmationsinteger · int32 · max: 99optional

Specifies how many blocks behind the chain tip block by block metrics (1b frequency) are based on. Default for btc is 2 and 99 for eth. For example, a min_confirmations of 0 means metrics are being calculated for the block at the tip of the chain (the latest block received by our node) whereas a min_confirmations of 6 means that metrics are being applied to the block that is 6 blocks behind the chain tip (i.e., the 7th block if the chain tip is block 1).

timezonestringoptional

Timezone name for start_time and end_time timestamps. This parameter does not modify the output times, which are always UTC. Format is defined by TZ database.

Default: UTCExample: America/New_York

page_sizeinteger · int32 · min: 1 · max: 10000optional

Number of items per single page of results. The value of this parameter is ignored if the endpoint supports the format parameter and its value is set to json_stream.

Default: 100

paging_fromstring · enumoptional

Where does the first page start, at the start of the interval or at the end. The value of this parameter is ignored if the endpoint supports the format parameter and its value is set to json_stream.

Default: endAvailable options:

sortstring · enumoptional

How results will be sorted. Metrics with 1b frequency are sorted by (asset, height, block_hash) tuples by default. Metrics with other frequencies are sorted by (asset, time) by default. If you want to sort 1d metrics by (time, asset) you should choose time as value for the sort parameter. Sorting by time is useful if you request metrics for a set of assets.

Default: assetAvailable options:

limit_per_assetinteger · int32optional

How many entries per asset result should contain. For example, this combination of parameters assets=btc,eth&metrics=ReferenceRate&limit_per_asset=1 returns the latest ReferenceRate values for btc and eth.

prettybooleanoptional

Human-readable formatting of JSON responses.

Default: false

formatstring · enumoptional

Format of the response.

Default: jsonAvailable options:

null_as_zerobooleanoptional

Nulls are represented as zeros in the response.

Default: false

next_page_tokenstringoptional

Token for receiving the results from the next page of a query. Should not be used directly. To iterate through pages just use next_page_url response field.

ignore_forbidden_errorsbooleanoptional

Ignore "forbidden" errors for the items you currently don't have access to.

Default: false

ignore_unsupported_errorsbooleanoptional

Ignore "unsupported" errors for not currently supported by Coin Metrics items.

Default: false

Responses

application/jsontext/csv

application/json

application/json

application/json

cURL

JavaScript

Python

HTTP

cURL

curl -L \
  --url 'https://api.coinmetrics.io/v4/timeseries/asset-metrics?assets=text&metrics=AdrActCnt'

200

400

401

403

414

200

application/json

text/csv

application/json

Example of a message with daily metrics.

Example of a message with block by block metrics.

Example of a message with 1s metrics.

Example of a message with daily metrics.

{
  "data": [
    {
      "asset": "btc",
      "time": "2020-02-29T00:00:00.000000000Z",
      "PriceUSD": "8582.09029964933",
      "SplyBMXNtv": "283220.10827406",
      "SplyBMXNtv-status": "reviewed",
      "SplyBMXNtv-status-time": "2020-03-01T09:59:13.847251000Z"
    },
    {
      "asset": "btc",
      "time": "2020-03-01T00:00:00.000000000Z",
      "PriceUSD": "8541.77389392169",
      "SplyBMXNtv": "284691.32323907",
      "SplyBMXNtv-status": "reviewed",
      "SplyBMXNtv-status-time": "2020-03-02T14:00:02.622168000Z"
    }
  ],
  "next_page_token": "0.MjAyMC0wNi0wN1QwMDowMDowMFo,MjAyMC0wNi0wN1QwMDowMDowMFo",
  "next_page_url": "https://api.coinmetrics.io/v4/timeseries/asset-metrics?api_key=<your_key>&pretty=true&assets=btc&metrics=SplyBMXNtv,PriceUSD&page_size=2&next_page_token=0.MjAyMC0wNi0wN1QwMDowMDowMFo,MjAyMC0wNi0wN1QwMDowMDowMFo"
}

Time series of metrics for an asset.

Shell

curl --compressed "https://api.coinmetrics.io/v4/timeseries/asset-metrics?metrics=MCRC&assets=btc&pretty=true&api_key=<your_key>"

Python

import requests
response = requests.get('https://api.coinmetrics.io/v4/timeseries/asset-metrics?metrics=MCRC&assets=btc&pretty=true&api_key=<your_key>').json()
print(response)

Python Client

from coinmetrics.api_client import CoinMetricsClient

api_key = "<API_KEY>"
client = CoinMetricsClient(api_key)

print(
    client.get_asset_metrics(
        metrics="NVTAdj", 
        assets='btc',
    ).to_dataframe()
)