Point-in-Time Flows

Overview

Point-in-time exchange flow metrics measure the same on-chain deposit, withdrawal, net-flow, and transfer-count activity as the standard exchange flow metrics, but attribute that activity using only the addresses Talos had identified as belonging to the entity at the time. They are designed for historical analysis and backtesting where restating past intervals with newly discovered addresses would introduce look-ahead bias.

Every standard exchange flow metric has a point-in-time equivalent. Insert Pit immediately before the unit suffix (Ntv, USD, or Cnt) in the metric name. For example, Coinbase deposits in native units map from FlowInCBSNtv to FlowInCBSPitNtv. Point-in-time flow metrics are available at 1d and 1h frequency.

At a Glance

Data type	Entities	Frequency / cadence	Unit	Primary endpoint
Metric	Assets	1d, 1h	Native units, USD, transfer count	/timeseries/asset-metrics

Metrics

Each standard exchange flow metric has a point-in-time counterpart, named by inserting Pit immediately before the unit suffix (Ntv, USD, or Cnt):

Standard metric	Point-in-time metric	Description
FlowIn{Entity}Ntv / FlowIn{Entity}USD	FlowIn{Entity}PitNtv / FlowIn{Entity}PitUSD	Deposits to the entity. See Deposits.
FlowOut{Entity}Ntv / FlowOut{Entity}USD	FlowOut{Entity}PitNtv / FlowOut{Entity}PitUSD	Withdrawals from the entity. See Withdrawals.
FlowNet{Entity}Ntv / FlowNet{Entity}USD	FlowNet{Entity}PitNtv / FlowNet{Entity}PitUSD	Net flows for the entity. See Net Flows.
FlowTfrIn{Entity}Cnt	FlowTfrIn{Entity}PitCnt	Deposit transfer count for the entity.
FlowTfrOut{Entity}Cnt	FlowTfrOut{Entity}PitCnt	Withdrawal transfer count for the entity.
Sply{Entity}Ntv / Sply{Entity}USD	Sply{Entity}PitNtv / Sply{Entity}PitUSD	Supply held by the entity. See Exchange Supply.
TxExCnt	TxExPitCnt	Transaction count for exchanges. See Transaction Count.

Replace {Entity} with the entity short code from the exchange coverage table. For example, Coinbase deposits in native units are FlowInCBSPitNtv, Binance withdrawals in native units are FlowOutBNBPitNtv, and Kraken net flows in native units are FlowNetKRKPitNtv. USD variants follow the same pattern (FlowInCBSPitUSD, FlowOutBNBPitUSD, and so on).

Aggregate metrics use Ex for all exchanges in place of {Entity} — for example, FlowInExNtv maps to FlowInExPitNtv, and SplyExUSD maps to SplyExPitUSD. Transfer-count aggregates follow the same rule (FlowTfrFromExCnt → FlowTfrFromExPitCnt, FlowTfrToExCnt → FlowTfrToExPitCnt).

Metrics whose names include Incl — the variants that include exchange-to-exchange transfers — place Pit before Incl rather than before the unit suffix. For example, FlowInExInclNtv maps to FlowInExPitInclNtv, and FlowTfrFromExInclCnt maps to FlowTfrFromExPitInclCnt.

Methodology

Standard and point-in-time exchange flow metrics answer the same question — how much value is held, and how much value moved into or out of an entity over an interval — but they differ in when an address counts as belonging to the entity.

Standard vs. point-in-time

	Standard metrics	Point-in-time metrics
Address set	All addresses currently known to belong to the entity. For example, a metric value for the date 2021-01-01 would include all addresses known at the current date, including addresses that had been discovered after 2021-01-01.	Only addresses known to belong to the entity at the time of the interval. For example, a metric value for the date 2021-01-01 would only include addresses that had been discovered on or prior to 2021-01-01.
History start	From each address's first non-zero balance	From each address's date of discovery as an entity address
Restatement	Past values can change when new entity addresses are discovered later. This is done on an ad hoc basis and customers will be informed as and when any changes are made.	Past values are fixed; newly discovered addresses affect only intervals on or after their discovery date
Best for	Current monitoring and analysis using the fullest available address coverage	Point-in-time-correct backtests, research, and any workflow that must not inherit future address discoveries

For example, compare Coinbase exchange supply in native units:

Metric	Description
SplyCBSNtv	The sum in native units held by Coinbase at the end of that interval. Metric values reflect activity of addresses currently known to belong to the entity, from each address's first non-zero balance.
SplyCBSPitNtv	The sum in native units held by Coinbase at the end of that interval. Metric values reflect activity of addresses known to belong to the entity at the time, from each address's date of discovery as an entity address.

Exchange flow metrics follow the same attribution logic. A deposit to an address that Talos later tags as belonging to Coinbase appears in FlowInCBSNtv for all historical intervals back to that address's first activity, but in FlowInCBSPitNtv only from the interval when the address was first identified as Coinbase.

Accessing the Data

Python Client

from coinmetrics.api_client import CoinMetricsClient

api_key = "<API_KEY>"
client = CoinMetricsClient(api_key)

print(
    client.get_asset_metrics(
        assets="btc",
        metrics=["FlowInCBSNtv", "FlowInCBSPitNtv"],
        frequency="1d",
    ).to_dataframe()
)

Shell

curl --compressed "https://api.coinmetrics.io/v4/timeseries/asset-metrics?assets=btc&metrics=FlowInCBSNtv,FlowInCBSPitNtv&frequency=1d&api_key=<your_key>"

Python

import requests

response = requests.get(
    "https://api.coinmetrics.io/v4/timeseries/asset-metrics",
    params={
        "assets": "btc",
        "metrics": "FlowInCBSNtv,FlowInCBSPitNtv",
        "frequency": "1d",
        "api_key": "YOUR_API_KEY",
    },
).json()

Full parameter reference: see the API Reference for /timeseries/asset-metrics.