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.
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.
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.
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.
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.
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).
(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:
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.
It indicates whether the market, on average, is in a state of unrealized gain (positive) or loss (negative), reflecting investor sentiment and potential market phases.
Long-Term and Short-Term Holder SOPR metrics segment the traditional SOPR calculation based on the age of the UTXOs being spent. These metrics separate profit/loss realization behavior between holders who have held their positions for different time periods, providing deeper insights into market dynamics by distinguishing between committed long-term investors and more active short-term traders.
There are two versions of this metric, one weighted by the value of each output and the other unweighted.
Name
MetricID
Unit
Interval
Spent Output Profit Ratio (SOPR) 30 day Long-Term Holder / Short-Term Holder
SOPRLth30d / SOPRSth30d
Dimensionless
1 day
Spent Output Profit Ratio (SOPR) 90 day Long-Term Holder / Short-Term Holder
SOPRLth90d /
SOPRSth90d
Dimensionless
1 day
Spent Output Profit Ratio (SOPR) 155 day Long-Term Holder / Short-Term Holder
SOPRLth155d /
SOPRSth155d
Dimensionless
1 day
Spent Output Profit Ratio (SOPR) 1 year Long-Term Holder / Short-Term Holder
SOPRLth1y /
SOPRSth1y
Dimensionless
1 day
Spent Output Profit Ratio (SOPR) 5 years Long-Term Holder / Short-Term Holder
SOPRLth5y /
SOPRSth5y
Dimensionless
1 day
Spent Output Profit Ratio Unweighted (SOPR Out) 30 day Long-Term Holder / Short-Term Holder
SOPRLthOut30d /
SOPRSthOut30d
Dimensionless
1 day
Spent Output Profit Ratio Unweighted (SOPR Out) 90 day Long-Term Holder / Short-Term Holder
SOPRLthOut90d /
SOPRSthOut90d
Dimensionless
1 day
Spent Output Profit Ratio Unweighted (SOPR Out) 155 day Long-Term Holder / Short-Term Holder
SOPRLthOut155d /
SOPRSthOut155d
Dimensionless
1 day
Spent Output Profit Ratio Unweighted (SOPR Out) 1 year Long-Term Holder / Short-Term Holder
SOPRLthOut1y /
SOPRSthOut1y
Dimensionless
1 day
Spent Output Profit Ratio Unweighted (SOPR Out) 5 years Long-Term Holder / Short-Term Holder
SOPRLthOut5y /
SOPRSthOut5y
Dimensionless
1 day
Details
The Long-Term and Short-Term Holder SOPR metrics use the same fundamental calculation as the traditional SOPR but apply filters based on the age of UTXOs:
For SOPRLth (Long-Term Holders):
Only includes UTXOs that were created more than X days/years ago
Calculation: (Sum of spent value of old UTXOs) / (Sum of creation value of old UTXOs)
For SOPRSth (Short-Term Holders):
Only includes UTXOs that were created X days/years ago or less
Calculation: (Sum of spent value of recent UTXOs) / (Sum of creation value of recent UTXOs)
Weighted vs Unweighted Versions:
Like the traditional SOPR, these metrics come in two variants:
Weighted (SOPR): Value-weighted by the size of each output
Unweighted (SOPROut): Each output is treated equally regardless of size
The unweighted versions are denoted with "Out" suffix (e.g., SOPRLthOut155d, SOPRSthOut155d).
Both versions oscillate around 1:
Values > 1 indicate holders are realizing gains on average
Values < 1 indicate holders are realizing losses on average
Values = 1 indicate break-even realization
Example
Using data from October 15, 2023, with a 155-day threshold:
SOPR Out (All): 0.9732 - Unweighted average shows slight losses
SOPR Out Long-Term Holders (155d): 0.9133 - Most long-term holder transactions at loss
SOPR Out Short-Term Holders (155d): 1.0064 - Most short-term holder transactions slightly profitable
This example demonstrates how the weighted vs unweighted versions can tell different stories. While large long-term holders were realizing substantial profits (SOPRLth155d = 1.0953), the majority of long-term holder transactions by count were actually at a loss (SOPRLthOut155d = 0.9133), suggesting that smaller holders were selling at losses while larger holders captured gains.
Interpretation
Long-Term and Short-Term Holder SOPR metrics provide nuanced insights into market behavior:
Long-Term Holder SOPR Patterns:
High values often coincide with market tops, as committed holders finally take profits
Sharp increases can signal capitulation events where even long-term holders sell
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
/timeseries/asset-metrics
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
api_keystringRequired
Coin Metrics API key can be specified as ?api_key= query parameter.
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.
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: allPossible values:
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.
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.
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: endPossible values:
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: assetPossible values:
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: jsonPossible values:
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
200
Time series of metrics for an asset.
400
Asset not found.
application/json
401
Requested resource requires authorization.
application/json
403
Requested resource is not available with supplied credentials.
application/json
414
Provided URI is too long. It must not be greater than 10000 symbols.
