What are Exchange Flows? definition, context and sources

01What are Exchange Flows?

Exchange Flows are metrics of incoming and outgoing on-chain transfers for a selected exchange or group of exchanges over a given interval. Exchange Netflow is incoming volume minus outgoing volume with the same asset, scope and methodology. This is not a complete record of exchange trades, client identities or an exchange’s liabilities.

02Incoming and outgoing volume need a defined boundary

CryptoQuant defines inflow as the amount of coins deposited into exchange wallets and outflow as the amount withdrawn from them. Our use first specifies the exchange or group, asset and interval being tracked. A transfer crosses a particular selected boundary; a result for one exchange is therefore not automatically a result for the whole market. [1]

03Netflow is a difference, not gross activity

CryptoQuant states netflow as inflow minus outflow. In our interpretation, a positive value means greater incoming volume and a negative value greater outgoing volume under the same methodology. A zero difference does not rule out large movements in both directions; a sum of differences alone does not show the size of both gross flows. [1]

04Address labels are an inferred layer above the chain

Glassnode combines verified addresses, external labels and heuristic clustering. Our interpretation separates an observed transfer from assigning an address to an exchange. An unknown address need not belong to a customer, and a new exchange wallet may not be recognized immediately; the labeled set cannot simply be assumed complete. [3]

05An internal transfer can look like a withdrawal

Glassnode describes cases where an apparent outflow was later recognized as an internal transfer. In our example, we therefore exclude transfers between wallets of the same exchange from both external inflow and outflow. For transfers between different exchanges, check whether the series tracks individual exchanges, their combined boundary or gross inter-exchange flows. [3]

06A balance is not a flow over an interval

Glassnode warns that discovering additional addresses can retrospectively change a reported balance. Our accounting check therefore compares flow with a change in balance only for the same set of addresses and compatible treatment of fees and other movements. A jump after changing address labels does not by itself establish a new deposit at that moment. [4]

07Transfer volume is neither trading volume nor a count of people

Glassnode distinguishes transfer counts, total volume and mean size; its notice separates on-chain metrics from exchange spot or futures volume. Our use does not conflate these quantities. Batched withdrawals or multiple addresses for one entity prevent converting transaction counts into a count of people; a deposit alone does not prove a completed sale. [2] [4]

08Historical decisions depend on the version then available

Glassnode Point-in-Time preserves values based on information known at a particular moment and distinguishes them from later corrections. Our reproduction records the provider, methodology, version and availability time. We must not treat a retrospectively assigned address as information known earlier; using a Point-in-Time series alone does not fix errors in other inputs or test timing. [5]

09A flow confirms neither solvency nor a future price

Glassnode explicitly excludes exchanges’ complete liabilities from these data. Our interpretation therefore does not prove solvency or the ability to repay all customers from inflow, outflow or a labeled balance. Coin Metrics also cautions that historical results of on-chain indicators do not guarantee future developments; a flow alone does not determine the direction, timing or probability of the next price change. [4] [6]

ExampleEXAMPLE · FLOW

The same transfers, a corrected address label

Our hypothetical model tracks a single exchange over one interval. All its modeled wallets initially hold 100 BTC in total. Three transfers occur in this order: 10 BTC from outside into the exchange, 4 BTC from the exchange to the outside, and 6 BTC between two of the exchange’s own wallets. The destination wallet of the last transfer had a zero opening balance. For clarity, this accounting model omits fees and all other movements; it does not reproduce a specific blockchain transaction. Label version A does not recognize this destination wallet and incorrectly reports the last transfer as external outflow. Version B correctly attributes it to the same exchange and excludes the internal transfer from both external flows. For versions A and B, inflows are [10, 10] BTC, outflows [10, 4] BTC and netflows [0, 6] BTC. For each version, the chart shows inflow, outflow and netflow from left to right in BTC; it is neither a price series nor a time series. With an initial labeled balance of 100 BTC, A reports an ending balance of 100 BTC and B a balance of 106 BTC. The 6 BTC difference comes from adding a label to an already existing wallet, not from a new transfer between versions. The actual modeled transfers are identical in both versions; the total balance of all modeled exchange wallets ends at 106 BTC. The example does not say whether a customer sold, bought or intends to hold, and establishes neither the exchange’s liabilities nor probabilities of future prices.

First define exchanges, asset, interval and the treatment of internal transfers.
Do not confuse netflow with both gross volumes or with a balance.
Address labels and historical values may be revised retrospectively.
Coin transfers alone prove neither a trade, solvency nor the next price movement.

Read in context

For the clearest picture, read this entry together with On-chain Analysis, Custodial Exchange, Self-custody, Proof of reserves, Look-ahead Bias. The reverse links also lead from On-chain Analysis.

?Practical questions

01Is a large inflow into an exchange proof that the bitcoin was sold?

No. A transfer to a labeled address shows coin movement, not execution of an exchange trade or a particular person’s intent. It may involve custody management or another use of services. Address attribution and possible internal transfers must be checked first.

02Why can historical netflow change without a new transaction?

A provider can add or correct address labels. What previously appeared to be a withdrawal may then be recognized as a transfer within the same exchange and recalculated. The interpretation changed, not the chain’s history; a historical test needs the version actually available at the decision time.