Data Availability

Glassnode metric updaters are triggered at the end of the resolution interval:

1 month resolution: runs once on the first day of the calendar month at 2:30 UTC
1 week resolution: runs once every Monday at 2:30 UTC
1 day resolution: runs daily at 00:00 UTC
1 hour resolution: runs once every hour at minute :00 (e.g. 9:00, 10:00, 11:00, ...)
10 minute resolution: runs at every 10th minute (e.g. 09:00, 09:10, 09:20, 09:30, ...)

Currently, the computation of a metric usually takes between 1 and 6 minutes. Therefore requesting the data 10 minutes after the updaters run, should be safe to make sure the latest datatpoint is included.

There are exceptions to the the above:

Daily computation of ERC20 distribution metrics takes up to 30 minutes.
Daily computation of entity-related metrics (exchange metrics, miner metrics, entity-adjusted metrics) uses advanced clustering algorithms that can take up to 2 hours.

Example: When are new data points added to BTC on-chain metrics?

For simplicity, we assume that broadcasting of new blocks across the globe and any processing (exporting to databases, computing the metrics) happens instantaneously.

Consider the following blocks and their block timestamps. The latter defines to which aggregation interval in the metrics the block contributes to.

Block

Block Timestamp

Corresponding metric aggregation interval

What happens during the different updater runs?

01:00:00: Blocks are available up to incl. 1001, but due to our one block confirmation period we process blocks up to 1000 only. The last block is part of the 00:50:00 aggregation interval, therefore that's the maximum timestamp for which the metric is computed.
01:10:00: Blocks are available up to incl. 1002, the latter one being ignored for now due to the confirmation interval. Block 1001 is in the 00:50:00 aggregation interval, therefore this data point is updated and values can change.
01:20:00: No new blocks available. Therefore, we don't yet append an extra data point to the metrics.
01:30:00: Blocks are available up to incl. 1003, we process blocks up to incl. 1002. Therefore the last data point in the metrics is 01:00:00, as this is the aggregation interval to which block 1002 contributes.
01:40:00: Blocks are available up to incl. 1005, we process blocks up to incl. 1004. We have a contribution to aggregation intervals 01:20:00 (block 1003) and 01:30:00 (block 1004). Since there is no block for interval 01:10:00 we forward fill the last known value (from 01:00:00) or set the value to zero (depending on what makes most sense for the particular metric). In total, this adds 3 new data points at once.

The blocks’ first contribution to the metric

Based on this, we can see when a block affects the released metrics for the first time:

First release of a new timestamp

Similar, we can derive when a metric timestamp is published for the first time:

PreviousTimestamps and Resolutions NextData Finalization

Last updated 1 year ago

Example: When are new data points added to BTC on-chain metrics?

For simplicity, we assume that broadcasting of new blocks across the globe and any processing (exporting to databases, computing the metrics) happens instantaneously.

Consider the following blocks and their block timestamps. The latter defines to which aggregation interval in the metrics the block contributes to.

Block

Block Timestamp

Corresponding metric aggregation interval

What happens during the different updater runs?

01:00:00: Blocks are available up to incl. 1001, but due to our one block confirmation period we process blocks up to 1000 only. The last block is part of the 00:50:00 aggregation interval, therefore that's the maximum timestamp for which the metric is computed.

01:10:00: Blocks are available up to incl. 1002, the latter one being ignored for now due to the confirmation interval. Block 1001 is in the 00:50:00 aggregation interval, therefore this data point is updated and values can change.

01:20:00: No new blocks available. Therefore, we don't yet append an extra data point to the metrics.

01:30:00: Blocks are available up to incl. 1003, we process blocks up to incl. 1002. Therefore the last data point in the metrics is 01:00:00, as this is the aggregation interval to which block 1002 contributes.

01:40:00: Blocks are available up to incl. 1005, we process blocks up to incl. 1004. We have a contribution to aggregation intervals 01:20:00 (block 1003) and 01:30:00 (block 1004). Since there is no block for interval 01:10:00 we forward fill the last known value (from 01:00:00) or set the value to zero (depending on what makes most sense for the particular metric). In total, this adds 3 new data points at once.

The blocks’ first contribution to the metric

Based on this, we can see when a block affects the released metrics for the first time:

Block

Block Timestamp

First contribution

First release of a new timestamp

Similar, we can derive when a metric timestamp is published for the first time:

Metric timestamp

First published

Delay