> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allium.so/llms.txt
> Use this file to discover all available pages before exploring further.
# Exchange Flows Classification
> Counterparty-level classification of every stablecoin transfer touching a centralized exchange
## What is Exchange Flows Classification?
The payments pipeline deliberately excludes exchange-touching transfers from the payment mix — intra-exchange activity is not observable on-chain, so its purpose cannot be inferred. **`stablecoins.intelligence.central_exchange_flows_classification`** makes those flows visible instead of invisible, by describing the **counterparty**: a business sending to an exchange typically signals liquidity management; a consumer, an on/off-ramp.
Every stablecoin transfer leg with a labeled exchange on either side is classified — coverage reconciles exactly with the exchange-touching population upstream. These flows are **never** counted as payments, B2B, or real-world payment volume.
## The classification matrix
Sender type always comes first. Wallet counterparties are typed behaviorally (Consumer / Business / Institutional / Unclassified); labeled counterparties get their own segments.
| Category | Direction | Counterparty |
| ----------------------------- | ---------------------- | --------------------------------------------------------- |
| `C2X` / `B2X` / `I2X` / `U2X` | deposit | Consumer / Business / Institutional / Unclassified wallet |
| `X2C` / `X2B` / `X2I` / `X2U` | withdrawal | wallet, typed as above |
| `DF2X` / `X2DF` | either | DeFi-labeled counterparty |
| `PS2X` / `X2PS` | either | payment services (incl. stablecoin issuers) |
| `IN2X` / `X2IN` | either | infrastructure (incl. chain, custody, oracle) |
| `BR2X` / `X2BR` | either | bridge |
| `GM2X` / `X2GM` | either | gambling |
| `TR2X` / `X2TR` | either | treasury |
| `X2X` | exchange\_to\_exchange | both sides labeled exchanges |
Two refinements add color to every exchange leg:
* **`exchange_flow_subtype`** splits `X2X`: `intra_exchange` (same entity — hot→cold consolidation, treasury sweeps), `inter_exchange` (genuine inter-venue settlement), `unknown` (entity attribution missing).
* **`exchange_rank_tier`** sizes the venue by global stablecoin holdings: `top_1_5`, `top_6_15`, `top_16_30`, `rest` (ranked below 30), `unranked` (attributed but absent from the exchange ranking — may not be a real/active exchange), `unknown` (no entity attribution).
**Grain matters.** Rows are per transfer **leg** — exchange batch payouts pay many users in one transaction, and every leg is kept. Filter `is_max_transfer = true` for Visa-style per-transaction dedup; leave it unfiltered to analyze batch withdrawals.
## Schema
Table: `stablecoins.intelligence.central_exchange_flows_classification`
| Column Name | Data Type | Description |
| ------------------------------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `chain` | VARCHAR | Blockchain network (33 chains) |
| `unique_id` | VARCHAR | Chain-scoped surrogate key for the transfer leg |
| `transaction_hash` | VARCHAR | On-chain transaction identifier |
| `block_timestamp` / `activity_date` | TIMESTAMP / DATE | Transfer time (UTC) |
| `block_number` | NUMBER | Chain-native block index |
| `token_address` / `token_symbol` | VARCHAR | Stablecoin identity |
| `product_id` / `stablecoin_type` / `currency` | VARCHAR | Registry product metadata |
| `amount` / `usd_amount` | NUMBER | Quantity / USD notional |
| `from_address` / `to_address` | VARCHAR | Transfer legs |
| `direction` | VARCHAR | deposit / withdrawal / exchange\_to\_exchange |
| `exchange_flow_category` | VARCHAR | The matrix above |
| `exchange_flow_subtype` | VARCHAR | intra\_exchange / inter\_exchange / unknown (X2X only) |
| `exchange_address` | VARCHAR | The exchange-labeled side |
| `exchange_rank_tier` | VARCHAR | Venue size tier by stablecoin holdings |
| `counterparty_address` | VARCHAR | The non-exchange side |
| `counterparty_segment` | VARCHAR | Unified taxonomy: consumer, business, institutional, unclassified, defi, payment\_services, infrastructure, bridge, gambling, treasury, exchange |
| `counterparty_wallet_type` | VARCHAR | Behavioral type for wallet counterparties; null for labeled segments and X2X |
| `counterparty_balance_tier` / `counterparty_30d_volume` | VARCHAR / NUMBER | Counterparty wallet context |
| `is_max_transfer` | BOOLEAN | Largest leg of its (day, transaction) — per-transaction dedup gate |
| `is_mev_transfer` / `is_inorganic_sender` / `is_inorganic_receiver` | BOOLEAN | Kept and flagged — a bot depositing to an exchange is a real exchange flow |
## Example queries
#### Deposit vs withdrawal mix by counterparty segment (30d)
```sql theme={null}
SELECT
chain,
exchange_flow_category,
COUNT(*) AS legs,
SUM(usd_amount) AS usd
FROM stablecoins.intelligence.central_exchange_flows_classification
WHERE activity_date >= DATEADD('day', -30, CURRENT_DATE)
AND is_max_transfer
GROUP BY 1, 2
ORDER BY usd DESC;
```
#### Hot→cold consolidation vs inter-venue settlement, by venue tier
```sql theme={null}
SELECT
exchange_rank_tier,
exchange_flow_subtype,
SUM(usd_amount) AS usd
FROM stablecoins.intelligence.central_exchange_flows_classification
WHERE exchange_flow_category = 'X2X'
AND is_max_transfer
GROUP BY 1, 2
ORDER BY usd DESC;
```
#### Exchange-rail payouts (batch withdrawals to many recipients)
```sql theme={null}
SELECT chain, activity_date, transaction_hash,
COUNT(*) AS legs, SUM(usd_amount) AS usd
FROM stablecoins.intelligence.central_exchange_flows_classification
WHERE direction = 'withdrawal'
GROUP BY 1, 2, 3
HAVING COUNT(DISTINCT counterparty_address) >= 10
ORDER BY usd DESC;
```
**Relationship to the behavioral flows pipeline.** Payout runs executed *from exchange accounts* appear here as high-fan-out withdrawals — they are deliberately out of scope for [`merchant_payout_runs`](/historical-data/payments/behavioral-flows), which covers platform-wallet payouts. The two are adjacent and non-overlapping; union them knowingly for total on-chain disbursement.