Ethereum’s past outflow charts can change when more exchange wallets are identified

Coin Metrics has recalculated Ethereum’s historical Standard Flow Metrics, creating timing challenges for backtests that rely on exchange outflows as trading indicators.

According to an Oct. 1 notice from the digital asset data provider, ETH Standard Flow Metrics from the network’s inception block onward have been recomputed using the latest available intelligence as part of the Ethereum Point-in-Time release. The update encompasses daily and hourly ETH Flow Metrics, with revised historical records accessible for backfilling.

This introduces an essential distinction for financial research. A chart downloaded today illustrates past flows using insights gathered at a later date. Conversely, a backtest—which simulates a trading strategy across historical data—requires strictly the information that was accessible at the exact moment each decision would have been made. These represent distinct datasets, even when corresponding to the exact same calendar dates.

The notification omits specific revision figures and does not evaluate ETH strategy comparisons. Consequently, analysts must now identify their data vintage—the specific version of the data utilized in testing—while the actual impact on returns remains to be measured.

Why the same historical date can tell a different story

Coin Metrics clarifies this distinction through its flow methodology. Standard metrics incorporate all wallet addresses currently identified as belonging to an exchange or monitored entity, with each address tracking from its initial nonzero balance. Historical figures are subject to restatement whenever newly discovered entity addresses are linked.

Conversely, its Point-in-Time (PIT) series relies exclusively on addresses recognized as belonging to the entity during the specific historical timeframe in question. An address contributes data starting only from its discovery date, meaning subsequent discoveries do not alter past PIT periods. Daily and hourly PIT variants of Standard exchange-flow metrics are provided by the platform.

The core challenge stems from attribution. Transfers can be retrospectively linked to an exchange once analytics providers identify the associated wallet. While this comprehensive reconstruction helps analyze historical supply dynamics using contemporary address coverage, determining what a market participant could have realistically known requires the exact address data and metrics available at that prior point in time.

Coin Metrics initially previewed this recalculation on Sept. 28 to preserve this methodological distinction, anticipating completion by Sept. 30. The final notice was published on Oct. 1 at 17:04 UTC; however, the notification time alone does not establish when each impacted data point became accessible.

Furthermore, analysts must avoid confusing two separate comparisons. Evaluating Standard versus PIT involves different address-knowledge criteria, whereas comparing retained Standard history from before and after the rebuild is necessary to measure this specific revision. PIT functions as an independent attribution framework, meaning that saving a copy of pre-rebuild Standard values preserves a specific iteration of the Standard dataset.

Documentation for CryptoQuant’s ETH Exchange Flows explicitly notes that its endpoint does not support PIT accuracy. The provider warns that historical figures are subject to modification as exchange wallets are discovered, incorporated, and verified via periodic clustering updates.

CryptoQuant operates automated weekly updates every Tuesday at 00:00 UTC, pointing out that figures can experience minor adjustments, particularly for recent observations. Each provider’s data revisions demand independent tracking and measurement.

Consequently, simply referencing an old query date is insufficient for analysts if historical values are repeatedly pulled from a mutable API endpoint. The observation dates may stay identical while the underlying information used to build them changes.

Interpreting outflows also demands caution. A withdrawal merely indicates asset movement relative to labeled exchange wallets; asserting that it signifies buying activity or profitable trading requires additional corroborating evidence.

Glassnode’s BTC illustration isolates data-vintage risk

Glassnode highlighted this exact challenge in a hypothetical backtest published on March 13, 2026. The test utilized Binance’s BTC exchange balances to execute market entries when a five-day moving average dropped below a 14-day average, and exits when the shorter average surpassed the longer one.

Running from Jan. 1, 2024, through March 9, 2026, the simulation started with an allocation of $1,000 and incorporated a 0.1% transaction fee per trade. Glassnode repeated the simulation utilizing PIT balances while keeping trading rules, parameters, timeline, and fee structures completely constant. The results showed diminished performance when utilizing PIT data compared to revised balances.

The key takeaway is that the trading rule remained constant while the data variant shifted. Historical balance configurations reconstructed with retrospective knowledge can trigger different trading decisions than patterns compiled strictly from contemporaneous information.

While Glassnode provided this Bitcoin balance outcome, this particular test has not been independently replicated in this analysis. Its value for Ethereum research lies in the testing methodology: maintaining a fixed rule while evaluating different data vintages. Assessing the impact on ETH signals and performance requires dedicated experimentation.

The timeline of data availability introduces an additional layer of constraint. Glassnode’s PIT documentation outlines two primary limitations regarding the simulation of historical events.

First, PIT history is available solely from the inception date of tracking for each respective metric. Prior to July 2025, data coverage was restricted to Bitcoin, Ethereum, and a curated set of tokens and metrics, with platform-wide tracking expanding across all metrics starting in July 2025. A metric introduced at that time does not gain retroactive PIT observations simply because standard historical data exists.

Second, the timestamp assigned to a data point does not necessarily reflect when a trader could have retrieved it. Glassnode notes it has tracked specific computed_at timestamps since September 2024—omitting the parameter when unavailable—and emphasizes that API distribution occurs with a lag following computation.

While an unchanging historical value accounts for subsequent data revisions, accurately replaying a trading decision also requires positioning the data input after its genuine publication timestamp. A backtest that acts upon information before it was genuinely accessible inadvertently relies on future data.

For Coin Metrics’ Ethereum series, researchers must verify each metric’s initial tracking date alongside its historical customer availability. Similarly, Glassnode’s coverage timelines and publication disclosures apply strictly to its own platform offerings.

The evidence needed to measure an ETH trading effect

Quantifying this database rebuild necessitates paired observations from the identical provider and metric, featuring matching exchange parameters, intervals, and dates. For revision analysis, this requires pairing preserved pre-rebuild Standard values alongside post-rebuild Standard history. For strategy analysis, it mandates utilizing an information set proven to have been accessible at each decision point.

Strategy rules must stay consistent throughout the comparison, utilizing identical entry/exit triggers, parameters, and testing windows. Execution delays, availability cutoffs, and trading costs must be integrated into the testing framework. Failing to do so—such as modifying strategy parameters alongside data inputs—makes it impossible to isolate the root cause of any performance variance.

Consequently, analytical comparisons must differentiate between modified data inputs, altered trading signals, executed trades, and resulting returns. A data revision can alter a dataset without necessarily changing the decisions produced by a specific trading rule.

Ultimately, rigorous validation requires a paired Ethereum dataset alongside a fixed-rule backtest that successfully separates data updates from trading execution changes. While revised history can accurately map supply metrics using modern wallet intelligence, claims that exchange outflows offered a reliable trading edge demand reproducible inputs, verified publication schedules, and realistic trading execution.

?Frequently Asked Questions

01What caused Coin Metrics to recompute its Ethereum flow metrics?

Coin Metrics updated its historical Standard Flow Metrics using its most up-to-date information as part of its Ethereum Point-in-Time release, which incorporates newly identified exchange wallets and addresses.

02What is the difference between Standard and Point-in-Time (PIT) metrics?

Standard metrics use all addresses currently known to belong to an exchange, meaning past values can be restated when new addresses are discovered. PIT metrics only use addresses known to belong to the entity during the specific historical interval, preventing retroactive rewrites of past data.

03Why do historical data revisions matter for crypto backtesting?

Backtests rely on historical data to simulate trading strategies. If a dataset uses information acquired after the fact (such as newly discovered exchange wallets), the backtest may utilize future knowledge that was unavailable to traders at the time, leading to unrealistic performance results.

04Do other providers experience similar data revision issues?

Yes. Providers like CryptoQuant warn that historical values on their endpoints can change as exchange wallets are continually discovered, added, and validated through periodic clustering updates.