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 UTC1 week resolution: runs once every Monday at
2:30 UTC1 day resolution: runs daily at
00:00 UTC1 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 |
|---|---|---|
1000 | 00:55:00 | 00:50:00 |
1001 | 00:56:00 | 00:50:00 |
1002 | 01:01:00 | 01:00:00 |
1003 | 01:25:00 | 01:20:00 |
1004 | 01:35:00 | 01:30:00 |
1005 | 01:36:00 | 01:30:00 |
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 |
|---|---|---|
1000 | 00:55:00 | 01:00:00 |
1001 | 00:56:00 | 01:10:00 |
1002 | 01:01:00 | 01:30:00 |
1003 | 01:25:00 | 01:40:00 |
1004 | 01:35:00 | 01:40:00 |
1005 | 01:36:00 | - |
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 |
|---|---|---|
00:50:00 | 01:00:00 | 00:10:00 |
01:00:00 | 01:30:00 | 00:30:00 |
01:10:00 | 01:40:00 | 00:30:00 |
01:20:00 | 01:40:00 | 00:20:00 |
01:30:00 | 01:40:00 | 00:10:00 |
Last updated