Address Balances
Last updated
Was this helpful?
Last updated
Was this helpful?
Addresses that hold a balance of X amount for a given asset.
The sum count of unique addresses holding at least one in Xth of the current supply of native units as of the end of that day. Only native units are considered (e.g., an address with less than one ten-billionth ETH but with ERC-20 tokens would not be considered).
Addr Cnt with ≥ 0.00000001% Supply
Addresses
1 day
Addr Cnt with ≥ 0.0000001% Supply
Addresses
1 day
Addr Cnt with ≥ 0.000001% Supply
Addresses
1 day
Addr Cnt with ≥ 0.00001% Supply
Addresses
1 day
Addr Cnt with ≥ 0.0001% Supply
Addresses
1 day
Addr Cnt with ≥ 0.001% Supply
Addresses
1 day
Addr Cnt with ≥ 0.01% Supply
Addresses
1 day
Addr Cnt with ≥ 0.1% Supply
Addresses
1 day
These metrics are a breakdown of the addresses with balance by relative ownership of the total current supply
In this unadjusted version, the total current supply is used.
The state of the ledger is the one at the last available block for that day.
Only the native units balance is considered, L2 tokens (ERC-20, etc..) are not taken into account.
The computation uses greater than or equal comparison: owning exactly 1 billionth of the current supply qualifies an address for AdrBal1in1BCnt
For XRP, escrowed amounts are not taken into account for balances but are counted towards total current supply.
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 shielded balances are taken into account for the supply component of the metric.
If the total current supply of the token is 10,000,000,000 units (10 billion units):
Addresses with less than 1 native unit (or 0.00000001% of supply) don't appear in any of these metrics
Addresses with a balance of 1 native unit (or 0.00000001% of supply) are counted only in AdrBal1in10BCnt
Addresses with a balance of 10 native units (or 0.0000001% of supply) are counted in AdrBal1in10BCnt and AdrBal1in1BCnt
Addresses with 10,000,000 native units (0.1% of supply) are counted in all of these metrics
All but AdrBal1in10KCnt and AdrBal1in1KCnt were released in the 4.0 release of NDP
AdrBal1in10KCnt and AdrBal1in1KCnt were released in the 4.2 release of NDP
In contrast with Addresses, with balance, greater than X native units, count, this metric seeks to facilitate direct comparisons between blockchains, even if they have widely varying supply counts. This metric allows you to determine how many addresses own a given fraction of supply, rather than a given number of units of supply. Keep in mind that in blockchains where transacting is cheap or free, this metric can be gamed.
The sum count of unique addresses holding at least X native units as of the end of that day. Only native units are considered (e.g., an address with less than X ETH but with more than X in ERC-20 tokens would not be considered).
Addr Cnt of Bal ≥ 0.001 (native units)
Addresses
1 day
Addr Cnt of Bal ≥ 0.01 (native units)
Addresses
1 day
Addr Cnt of Bal ≥ 0.1 (native units)
Addresses
1 day
Addr Cnt of Bal ≥ 1 (native units)
Addresses
1 day
Addr Cnt of Bal ≥ 10 (native units)
Addresses
1 day
Addr Cnt of Bal ≥ 100 (native units)
Addresses
1 day
Addr Cnt of Bal ≥ 1K (native units)
Addresses
1 day
Addr Cnt of Bal ≥ 10K (native units)
Addresses
1 day
Addr Cnt of Bal ≥ 100K (native units)
Addresses
1 day
Addr Cnt of Bal ≥ 1M (native units)
Addresses
1 day
These metrics provide a count of addresses with balance by equal or higher than a native unit threshold.
The state of the ledger is the one at the last available block for that day.
Only the native units balance is considered, L2 tokens (ERC-20, etc..) are not taken into account.
The computation uses greater than or equal comparison: owning exactly 1 native unit qualifies an address for AdrBalNtv1Cnt.
For XRP, escrowed amounts are not taken into account.
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 activities into account.
Released in the 4.0 release of NDP
This is a potent set of metrics which can elucidate the dispersion of ownership of the address space in a cryptocurrency. The trend can demonstrate whether or not a cryptocurrency is in a concentrative or distributive phase. It should be noted that supply is arbitrary, and for large-cap assets varies between tens of millions to hundreds of billions; so unit dispersion is often not directly comparable between chains. Put otherwise: it is cheaper to accumulate addresses with 100 XRP than 100 BTC since those are so different in fiat terms. This metric can also be gamed to a degree by adding dust to many thousands of addresses.
The sum count of unique addresses holding at least X dollar's worth of native units as of the end of that day. Only native units are considered (e.g., an address with less than X dollar's worth of ETH but with more than X dollar's worth of ERC-20 tokens would not be considered).
Address Cnt of Bal ≥ $1
Addresses
1 day
Address Cnt of Bal ≥ $10
Addresses
1 day
Address Cnt of Bal ≥ $100
Addresses
1 day
Address Cnt of Bal ≥ $1K
Addresses
1 day
Address Cnt of Bal ≥ $10K
Addresses
1 day
Address Cnt of Bal ≥ $100K
Addresses
1 day
Address Cnt of Bal ≥ $1M
Addresses
1 day
Address Cnt of Bal ≥ $10M
Addresses
1 day
These metrics are a breakdown of the addresses with balance count with USD balance thresholds.
The state of the ledger is the one at the last available block for that day.
The price used is the daily close price.
Only the native units balance is considered, L2 tokens (ERC-20, etc..) are not taken into account.
The computation uses greater than or equal comparison: owning exactly $1 qualifies an address for AdrBalUSD1Cnt.
For XRP, escrowed amounts are not taken into account.
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 activities into account.
Released in the 4.0 release of NDP
This metric standardizes wealth cohorts across multiple blockchains for easy comparison, although differences in address creation must be taken into account. Some wallets in UTXO chains tend to fragment user balances into multiple addresses to preserve privacy. Note that this metric is sensitive to changes in unit price; common address sizes combined with price changes can lead to large numbers of addresses hitting a new threshold at the same time. This can lead to sharp discontinuities in the metric. For a purer measure of holder dispersion (albeit not as directly comparable), see addresses, with balance, greater than X native units, count.
Address Balances can be accessed using these endpoints:
timeseries/asset-metrics
and by passing in the metric IDs in the metrics
parameter.
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.
1d
Example: 1b
Which metric values do you want to see. Applicable only for "reviewable" metrics. You can find them in the /catalog/metrics
endpoint.
all
Available 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.
true
Inclusive or exclusive corresponding end_*
parameters.
true
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).
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.
UTC
Example: America/New_York
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
.
100
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
.
end
Available 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.
asset
Available 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.
false
Format of the response.
json
Available options: Nulls are represented as zeros in the response.
false
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" errors for the items you currently don't have access to.
false
Ignore "unsupported" errors for not currently supported by Coin Metrics items.
false
Time series of asset metrics.