Skip to main content
API v2 On-chain Data serves network activity, exchange and mining pool flows, on-chain indicators, and supply metrics for Bitcoin and for Ethereum — native ETH, ERC-20 tokens, and the stablecoins issued on it. It uses the same status/result envelope, Bearer authentication, and window/from/to time convention as the rest of the API.
Beta since October 8, 2026. The 95 endpoints in this section are open to every API key — 62 for Ethereum, of which 22 also serve asset=btc, plus 33 Bitcoin-only endpoints. Endpoint paths, parameters, and response fields are final; historical values may still be corrected during the beta, and every correction is listed in the changelog.

​
Endpoints at a glance

95 endpoints. Classes are the asset classes an endpoint serves (btc, eth, erc20, stablecoin); windows are the union across those classes — the endpoint page has the exact table per class. Credits are charged per 100 rows returned.

​
Network (54)

​
Flows (18)

​
Indicator (22)

​
Market (1)

​
How much history each window keeps

This is the v2-wide rule (see API v2 Overview); it applies to every on-chain endpoint. A from older than the window keeps returns 400 — 'from' is outside the block retention window (3 months). Use window=day for full history. — so use day for long-range history and the finer windows for recent detail. Bitcoin series are refreshed hourly, so for asset=btc the latest block rows can trail the chain tip by up to about an hour, and the latest completed hour row typically appears within the following hour.

​
The asset is a parameter, not a path

This is the one structural change from v1. Where v1 had a separate path per asset family, v2 has one path per metric and takes the asset as a query parameter:
Two consequences worth knowing before you write any code:
  • asset takes the plain alias, with no chain suffix. v1’s usdt_eth is asset=usdt in v2, and v1’s /btc/... paths are asset=btc. Add chain=ethereum or chain=bitcoin when the same alias exists on more than one chain; it is optional otherwise.
  • What comes back depends on the asset. One path serves several asset classes, and the available windows and response fields differ between them. Each endpoint page has a table for both.

​
Asset classes

“Up to” because the list is per endpoint, not global. A balance-style metric such as supply, velocity, or reserve excludes rebasing and reflection tokens, whose balances cannot be derived from transfer events alone; a volume-style metric such as inflow has no such exclusion. The endpoint page carries the count that applies to it. Not every path serves every class either — gas, for example, exists only for eth, the mining pool flows and most indicators only for btc, and a token such as steth is accepted by inflow but excluded from supply. Asking for an asset the endpoint does not serve returns 400 with a message naming the problem. Each endpoint page lists the classes and assets it accepts, and /v2/discovery/endpoints returns the live list.

​
Windows differ by asset class

The same path can accept a window for one asset and reject it for another, because each asset class is built from its own tables.
The error names the windows that asset does support, so a 400 here is a usable answer rather than a dead end. The default window is day for every endpoint in this section except Estimated Leverage Ratio, Exchange Shutdown Index, Exchange Whale Ratio, Fund Flow Ratio, Mining Pool Supply Ratio, which default to block. The default is applied per endpoint, not per asset class, so on a shared endpoint it can name a window one class does not serve:
  • Exchange Supply Ratio — /v2/indicator/selling-activity/exchange-supply-ratio has no default window for btc: day is not served for that class, so omit window and the request returns 400. Pass window=block.
Treat the endpoint page’s asset-class table as the authority on what a given asset supports. /v2/discovery/endpoints returns the union across an endpoint’s assets, so a value listed there is a candidate, not a guarantee for every asset.

​
Time keys

Which time field comes back depends on the window. Unlike v1, every v2 window uses datetime; there is no date field. All timestamps are UTC. Requests use a different, compact format: from and to take YYYYMMDDTHHMMSS (UTC), and YYYYMMDD is also accepted when window=day. Copying a response value such as 2026-09-01 into from returns 400.

​
Response envelope

​
Entity flows take an entity parameter

Flow endpoints and the entity-based indicators additionally take the entity they are about: Pass the aggregate value for the total across every entity CryptoQuant tracks, or a single entity name such as binance or f2pool. The accepted names come from /v2/discovery/endpoints — they are resolved from the live entity registry, so a newly labelled exchange or mining pool appears without a docs change.

​
Coming from v1

Almost every endpoint below has a v1 counterpart. The metric definitions are unchanged; what changed is the path shape and the token → asset parameter. In-House Flow is the exception on the Ethereum side — it existed only for Bitcoin in v1, and this is its first release for Ethereum. Bitcoin’s v1 groups were regrouped by meaning rather than by data source. The metrics and their fields are unchanged; only the path moved: Not every v1 window carried over at launch: the Bitcoin exchange and mining pool indicators (whale ratio, fund flow ratio, shutdown index, mining pool supply ratio, exchange supply ratio) and the estimated leverage ratio serve block only in v2 where v1 also had day and hour. The endpoint page’s asset-class table is authoritative. Two request-side differences trip up code ported from v1:
  • limit caps at 10,000 rows (v1 accepted up to 100,000). A larger value returns 400; page with from/to instead.
  • from/to are YYYYMMDDTHHMMSS (or YYYYMMDD with window=day), as described under Time keys.
v1 remains fully supported. Any future deprecation will be announced in the changelog well in advance.