Valuation
Last updated
Was this helpful?
Last updated
Was this helpful?
The ratio of the network value (or market capitalization, current supply) divided by the adjusted transfer value. Also referred to as NVT.
NVT
Dimensionless
1 day
NVT 90-day Moving Avg
Dimensionless
1 day
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. 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.
Released in the 1.0 release of NDP
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 free float network value (or market capitalization, free float) divided by the adjusted transfer value. Also referred to as FFNVT.
Free Float NVT
Dimensionless
1 day
Free Float NVT 90-day Moving Avg
Dimensionless
1 day
This metric provides an important adjustment to the Network Value to Transaction (NVT) Ratio using Free Float Supply (SplyFF)
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 Version: NDP-EOD 4.8 (Nov, 2020)
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.
Realized Cap to Thermo Cap (RCTC)
Dimensionless
1 day
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.
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.
Only applicable to assets for which we have RevAllTimeUSD and CapRealUSD.
Release Version: NDP 5.0 (August, 2021)
The ratio of the network's realized value to its adjusted transfer value. Also referred to as RVT.
RVT
Dimensionless
1 day
RVT 90-day Moving Avg
Dimensionless
90 days
Computed as realized value (aka realized market cap) over adjusted transfer value.
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 Version: NDP-EOD 4.8 (Nov, 2020)
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).
SOPR
Dimensionless
1 day
SOPR Out
Dimensionless
1 day
(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.
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.
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.
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
Released in the 5.0 release of NDP
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.
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.
For more details on the significance of this improvement, please refer to the following .
The ratio of the Realized Cap over Thermo Cap at the end of that interval. (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 , 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).
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.
Spent Output Profit Ratio (SOPR) gives another vantage point into bitcoin market cycles. Introduced , SOPR can act as a proxy for gauging whether holders are selling at a profit or at a loss.
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:
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.
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.
["AdrActCnt","BlkHgt"]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.
1dExample: 1bWhich metric values do you want to see. Applicable only for "reviewable" metrics. You can find them in the /catalog/metrics endpoint.
allAvailable options: 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 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.
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.
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.
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.
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.
Inclusive or exclusive corresponding start_* parameters.
trueInclusive or exclusive corresponding end_* parameters.
trueSpecifies 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).
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.
UTCExample: America/New_YorkNumber 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.
100Where 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.
endAvailable options: 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.
assetAvailable options: 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.
Human-readable formatting of JSON responses.
falseFormat of the response.
jsonAvailable options: Nulls are represented as zeros in the response.
falseToken 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" errors for the items you currently don't have access to.
falseIgnore "unsupported" errors for not currently supported by Coin Metrics items.
falseTime series of asset metrics.