Glassnode Docs
WebsiteStudioInsightsTwitter
  • Welcome to Glassnode
    • Introduction
      • Studio
  • 📊Data
    • General Information
      • Timestamps and Resolutions
      • Data Availability
      • Data Finalization
    • Metric Catalog
    • Supported Blockchains
    • Supported Assets
      • Market Metrics Coverage
      • On-chain Metrics Coverage
    • Point-in-Time Metrics
  • 📖Guides & Tutorials
    • Getting Started
      • Use-Case Tutorials
        • Tutorial 1 - Navigating Market Tops and Bottoms
        • Tutorial 2 - Introduction to On-chain Activity
        • Tutorial 3 - Fundamentals of Proof-of-Work Mining
        • Tutorial 4 - Introduction to Supply Dynamics
      • Get started with Glassnode Metrics
      • Granular Cohorts for Key On-Chain Metrics
    • Metric Guides
      • Market Capitalization
      • Realized Capitalization
      • MVRV
        • LTH-MVRV
        • MVRV Ratio
        • MVRV-Z Score
        • STH-MVRV
      • SOPR
        • SOPR (Spent Output Profit Ratio)
        • aSOPR (Adjusted SOPR)
        • LTH-SOPR
        • STH-SOPR
      • Unrealized Profit/Loss
        • NUPL (Net Unrealized Profit/Loss)
        • Unrealized Profit
        • Unrealized Loss
        • LTH-NUPL
        • STH-NUPL
      • Realized Profit/Loss
        • Net Realized Profit/Loss
        • Realized Profit
        • Realized Loss
      • Coin Issuance
        • Puell Multiple
      • Stablecoin
        • SSR (Stablecoin Supply Ratio)
      • Coin Days Destroyed
        • CDD (Coin Days Destroyed)
        • Supply-Adjusted CDD
        • Binary CDD
        • CYD (Coin Years Destroyed)
        • Supply-Adjusted CYD
        • Reserve Risk
      • Liveliness
      • Dormancy
        • Average Coin Dormancy
        • Supply-Adjusted Dormancy
      • Lifespan
        • Spent Output Age Bands (SOAB)
        • Average Spent Output Lifespan (ASOL)
        • Median Spent Output Lifespan (MSOL)
      • NVT
        • NVT Ratio
        • NVT Signal
        • Velocity
      • Stock to Flow
        • Stock to Flow Ratio
        • Stock to Flow Deflection
      • Price Distribution
        • URPD (UTXO Realized Price Distribution)
        • SOPD (Spent Output Price Distribution)
      • Accumulation Trend Score
      • Long and Short-Term Holder Supply
        • Supply Held by Long and Short-Term Holders
      • Profit/Loss (Supply)
        • Percent Supply in Profit
        • Supply in Profit
        • Supply in Loss
      • Age Distribution
        • HODL Waves
        • Realized Cap HODL Waves
      • Profit/Loss (UTXO)
        • Percent UTXOs in Profit
        • UTXOs in Profit
        • UTXOs in Loss
    • On-Chain Concepts
      • Entity-Adjusted Metrics
      • On-chain Glossary
      • Understanding UTXOs - The Gold Coin Analogy
      • UTXO vs. Account-Based Chains
    • Workbench Guide
  • ⚙️API
    • Introduction
    • API Key
    • API Credits
    • Metadata
    • Bulk metrics (beta)
    • Endpoints
      • Addresses
      • Bridges
      • Blockchain
      • Breakdowns
      • DeFi
      • Derivatives
      • Distribution
      • Entities
      • ETH 2.0
      • Fees
      • Indicators
      • Institutions
      • Lightning
      • Market
      • Mempool
      • Mining
      • Point-In-Time
      • Protocols
      • Signals
      • Supply
      • Transactions
  • ℹ️Further Information
    • Changelog
      • 2025
      • 2024
      • 2023
      • 2022
      • 2021
      • 2020
    • Support FAQ
    • Affiliate FAQs
    • Exchange Data: Transparency Notice
Powered by GitBook
On this page
  • Example: When are new data points added to BTC on-chain metrics?
  • What happens during the different updater runs?
  • The blocks’ first contribution to the metric
  • First release of a new timestamp
  1. Data
  2. General Information

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

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

PreviousTimestamps and ResolutionsNextData Finalization

Last updated 2 years ago

📊