> For the complete documentation index, see [llms.txt](https://gitbook-docs.coinmetrics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gitbook-docs.coinmetrics.io/network-data/network-data-overview/exchange/pairwise-flows.md).

# Pairwise Flows

## Overview

Pairwise flow metrics measure the directional value moving from one tagged entity to another, for example from Coinbase to Binance. Each metric covers a specific ordered pair of entities and includes value that moves indirectly through untagged intermediary wallets for up to two hops, not only direct transfers between the two entities. These metrics can be used to track capital movement between exchanges.

## At a Glance

<table data-full-width="true"><thead><tr><th>Data type</th><th>Entities</th><th width="159">Frequency / cadence</th><th>Unit</th><th>Primary endpoint</th></tr></thead><tbody><tr><td>Metric</td><td>Assets</td><td>1 day, 1 hour</td><td>Native units, USD, transfer count</td><td><code>/timeseries/asset-metrics</code></td></tr></tbody></table>

## Metrics

Each supported ordered entity pair emits three metrics, named with the pair's entity codes in place of `{EntityA}` and `{EntityB}`:

<table data-full-width="true"><thead><tr><th width="360">Metric</th><th>Description</th><th>Frequency</th><th>Coverage</th></tr></thead><tbody><tr><td><code>FlowFrom{EntityA}To{EntityB}Ntv</code></td><td>Native-unit value attributed as flowing from EntityA to EntityB, including value routed through untagged intermediary wallets for up to two hops.</td><td>1d, 1h</td><td><a href="https://coverage.coinmetrics.io/asset-metrics-v2/FlowFromCBSToBNBNtv">🔗</a></td></tr><tr><td><code>FlowFrom{EntityA}To{EntityB}USD</code></td><td>USD value of the same flow, derived from the Ntv metric and the asset's reference rate.</td><td>1d, 1h</td><td><a href="https://coverage.coinmetrics.io/asset-metrics-v2/FlowFromCBSToBNBUSD">🔗</a></td></tr><tr><td><code>FlowTfrFrom{EntityA}To{EntityB}Cnt</code></td><td>Expected number of transfers attributed to this flow, emitted as a whole transfer count. Direct entity-to-entity transfers contribute exact counts and value routed through untagged wallets contributes a fractional expected count; the two are summed and rounded to the nearest whole transfer, with any positive value below one rounded up to one.</td><td>1d, 1h</td><td><a href="https://coverage.coinmetrics.io/asset-metrics-v2/FlowTfrFromCBSToBNBCnt">🔗</a></td></tr></tbody></table>

As of the current release, supported pairs cover six major centralized exchanges — **30 ordered pairs** among them — on USDC on Ethereum. Each pair emits the three metrics above, for **90** standard metrics in total. The data spans from genesis up to the present. See [Supported pairs](#supported-pairs) for the entity codes and pair matrix.

### Point-in-time pairwise flows <a href="#point-in-time-pairwise-flows" id="point-in-time-pairwise-flows"></a>

Each standard pairwise metric has a point-in-time counterpart on **`usdc_eth`**, at **1d** and **1h**, using the same naming rule as [entity-level point-in-time flows](/network-data/network-data-overview/exchange/point-in-time-flows.md): insert `Pit` immediately before the unit suffix (`Ntv`, `USD`, or `Cnt`).

| Standard metric                      | Point-in-time metric                    |
| ------------------------------------ | --------------------------------------- |
| `FlowFrom{EntityA}To{EntityB}Ntv`    | `FlowFrom{EntityA}To{EntityB}PitNtv`    |
| `FlowFrom{EntityA}To{EntityB}USD`    | `FlowFrom{EntityA}To{EntityB}PitUSD`    |
| `FlowTfrFrom{EntityA}To{EntityB}Cnt` | `FlowTfrFrom{EntityA}To{EntityB}PitCnt` |

For example, Coinbase to Binance in native units is `FlowFromCBSToBNBPitNtv`. Attribution uses the same pairwise methodology as the standard metrics, but entity membership for each address is resolved using only tags known at the time of the interval (no look-ahead from later address discoveries). That mirrors [standard vs. point-in-time exchange flows](/network-data/network-data-overview/exchange/point-in-time-flows.md#standard-vs-point-in-time).

Pairwise point-in-time metrics are **not** available at block-by-block (1b) frequency. For coverage per pair, see the coverage links in the table above and substitute the `Pit` metric name (for example, [FlowFromCBSToBNBPitNtv](https://coverage.coinmetrics.io/asset-metrics-v2/FlowFromCBSToBNBPitNtv)).

## Methodology

Each pairwise flow combines two attribution paths over the metric's interval.

### Direct transfers

A transfer sent directly from an address belonging to the source entity to an address belonging to the destination entity is counted in full, with an exact integer transfer count. Transfers with a negative native-unit amount are included when summing flow values, but they do not contribute to the transfer count.

### Through-user attribution

Value that passes through one or more untagged wallets before reaching the destination entity is attributed back to a source entity using a haircut method (Moser, Böhme & Breuker, 2014). When an untagged wallet forwards value onward, each source's share of that outgoing value is proportional to the source's share of the wallet's total available funds at that point:

$$
\text{share}\_{\text{source}} = \frac{\text{value received from source}}{\text{closing balance} + \text{total outflow}}
$$

This keeps attribution conservative in two ways. A source's attributed flow can never exceed what it actually sent, since attribution is capped per entity pair. And because closing balances are never negative, a wallet's denominator is always at least its total outflow, so attribution can only be diluted across multiple destinations, never inflated.

Each supported pair has an independently configured maximum hop depth: direct pairs only match tagged-to-tagged transfers, while other pairs also follow chains of untagged wallet-to-wallet hops (source, then one or more intermediary wallets, then destination) up to that pair's configured depth.

Every tagged address, whether an exchange, a lending protocol, an ETF, a layer-2 bridge, or another tagged category, acts as a boundary that attribution cannot pass through. This keeps flow from being misattributed through a different known entity that happens to sit along the path.

### Transfer counts

Direct transfers contribute an exact integer count, while through-user attribution contributes a fractional expected count in which each wallet-to-destination deposit adds the source's attributed share at that hop. The direct and through-user counts are summed, and the emitted metric is rounded to the nearest whole transfer (ties rounded up), except that any positive value below one is rounded up to one so a small but real attributed flow is never reported as zero.

### Lookback window

Multi-hop chains can span more than one interval, since an intermediary wallet may hold funds for a period before forwarding them. Both the 1-hour and 1-day metrics account for this using a trailing lookback window so these chains are still attributed correctly, while only deposits landing inside the target interval are counted toward that interval's value. Each deposit is counted in exactly one interval, though its source attribution can reach back across the lookback window.

For more information, see [Pairwise Flow Lookback Window](/network-data/methodologies/pairwise-flow-lookback-window.md).

## Accessing the Data

{% tabs %}
{% tab title="Python Client" %}

```python
from coinmetrics.api_client import CoinMetricsClient

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

print(
    client.get_asset_metrics(
        assets="usdc_eth",
        metrics=["FlowFromCBSToBNBNtv", "FlowFromCBSToBNBUSD", "FlowTfrFromCBSToBNBCnt"],
        frequency="1d",
    ).to_dataframe()
)
```

{% endtab %}

{% tab title="Shell" %}

```shell
curl --compressed "https://api.coinmetrics.io/v4/timeseries/asset-metrics?assets=usdc_eth&metrics=FlowFromCBSToBNBNtv,FlowFromCBSToBNBUSD,FlowTfrFromCBSToBNBCnt&frequency=1d&api_key=<your_key>"
```

{% endtab %}

{% tab title="Python" %}

```python
import requests

response = requests.get(
    "https://api.coinmetrics.io/v4/timeseries/asset-metrics",
    params={
        "assets": "usdc_eth",
        "metrics": "FlowFromCBSToBNBNtv,FlowFromCBSToBNBUSD,FlowTfrFromCBSToBNBCnt",
        "frequency": "1d",
        "api_key": "YOUR_API_KEY",
    },
).json()
```

{% endtab %}
{% endtabs %}

Full parameter reference: see the API Reference for [`/timeseries/asset-metrics`](https://docs.coinmetrics.io/api/v4/#operation/getTimeseriesAssetMetrics).

## Supported pairs

Pairwise flow metrics are available for every ordered pair among the following six exchanges. Self-pairs (an exchange to itself) are not included.

| Exchange | Code |
| -------- | ---- |
| Binance  | BNB  |
| Bybit    | BIT  |
| Coinbase | CBS  |
| Kraken   | KRK  |
| KuCoin   | KCN  |
| OKX      | OKX  |

Metric names use these codes in place of `{EntityA}` and `{EntityB}`. For example, Coinbase to Binance native units is `FlowFromCBSToBNBNtv`.

The grid below shows every supported direction. Rows are the source exchange; columns are the destination. A filled cell is an available ordered pair.

<table data-full-width="true"><thead><tr><th></th><th>BNB</th><th>BIT</th><th>CBS</th><th>KRK</th><th>KCN</th><th>OKX</th></tr></thead><tbody><tr><td><strong>BNB</strong></td><td></td><td>●</td><td>●</td><td>●</td><td>●</td><td>●</td></tr><tr><td><strong>BIT</strong></td><td>●</td><td></td><td>●</td><td>●</td><td>●</td><td>●</td></tr><tr><td><strong>CBS</strong></td><td>●</td><td>●</td><td></td><td>●</td><td>●</td><td>●</td></tr><tr><td><strong>KRK</strong></td><td>●</td><td>●</td><td>●</td><td></td><td>●</td><td>●</td></tr><tr><td><strong>KCN</strong></td><td>●</td><td>●</td><td>●</td><td>●</td><td></td><td>●</td></tr><tr><td><strong>OKX</strong></td><td>●</td><td>●</td><td>●</td><td>●</td><td>●</td><td></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://gitbook-docs.coinmetrics.io/network-data/network-data-overview/exchange/pairwise-flows.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.