Point-in-Time Metrics
Point-in-Time (PIT) metrics provide a consistent, immutable view of data as it was known at a specific moment in the past. This is critical for building robust and reliable systematic strategies, research, and backtesting. Unlike traditional mutable metrics that may change retroactively, PIT metrics preserve historical data without applying any future knowledge or corrections that emerged later.
Why Point-in-Time?
Many datasets evolve over time due to late-arriving information, retrospective corrections, or refined methodologies. If not handled carefully, this can introduce look-ahead bias, where a model or analysis unintentionally uses information that wasn't actually available at the time — leading to misleading results.
PIT metrics solve this by freezing data as it was known at the time, avoiding hindsight adjustments and ensuring results are reproducible and free from future information leaks.
📖 Further Reading: Your Backtest Is Lying: Why You Must Use Point-in-Time Data
📌 Recommendation: All systematic use cases (e.g., algorithmic trading, quantitative models, historical backtesting) should rely on PIT metrics for historical data.
Common Reasons for Data Mutations
Even in a blockchain context, some data can change post-factum due to:
Clustering for Entity Adjustment: As more heuristics or address linkages are discovered, historical metrics may be adjusted to reflect refined entity-level data (e.g., exchange wallets).
Late-Reported Data: Off-chain or external data sources may deliver information with a delay (e.g. perpetual futures positions of a single exchange, or blockchain data that requires additional confirmations).
Data Corrections: Improvements in off-chain datasets can lead to retroactive corrections.
PIT metrics eliminate the impact of such updates by recording and serving data exactly as it appeared at that time.
Response format
PIT metric responses are the same as the regular variant, with one additional field per datapoint: computed_at. This field indicates at what time the datapoint was added into our system. We started tracking this data since 2024, the computed_at field is omitted from earlier PIT datapoints.
Simple PIT timeseries metrics look like this:
Multi-timeseries PIT metrics look like this:
Bulk PIT responses look like this:
Computed At
Since September 2024, we have been recording a computed_at timestamp for relevant data points. This field is included in API responses when available and omitted otherwise.
Please note that there is a delay between the computed_at timestamp and when the data becomes available (published) in our API. The table below summarizes the observed lag t (time from computation to publication):
Lag t
Median
15 s
90th percentile
1:07 min
95th percentile
2:15 min
99th percentile
9:42 min
Metrics coverage
Please note that historical PIT data is only available from the exact date we began tracking it for a given metric.
Before July 2025: PIT tracking was limited to BTC, ETH, and select tokens, and was only supported for the specific metrics listed below. They rely on address labeling and clustering, which makes them prone to mutations.
July 2025 to Present: We expanded our coverage to track PIT data for all metrics across the platform.
Important: Because PIT history only exists from the moment tracking begins, any metrics that had PIT enabled in July 2025 will not contain historical PIT data prior to that date.
Learn More
Last updated