Follow the same trader across every venue.
L4 tells you who placed an order on one venue. L4+ links that participant to activity elsewhere: on-chain wallets, deposits and withdrawals, and trades on other exchanges. Every link carries a calibrated confidence score, and every entity is an anonymous id.
Three steps from a wallet to cross-venue flow.
E-4417.The trace on the right follows one entity through five hops in a little over three minutes: a perp position on Hyperliquid, a spot hedge on a second venue, a bridge withdrawal and a sale on a third.
How attribution works.
Each step uses public data only and records which method produced a link, so you can filter on the methods you trust.
Entity clustering
Addresses are grouped when on-chain evidence shows a common owner. The method behind each address is stored in cluster_method.
common_input: on Bitcoin, inputs spent together in one transaction share an owner.deposit_reuse: addresses that send to the same exchange deposit address belong to that deposit's owner.gas_funding: on EVM chains, a fresh address whose first gas comes from another address, followed by matching activity.venue_native: on Hyperliquid, the trading account is the on-chain address, so bridge deposits and trades link directly.
Venue attribution
Exchange-owned addresses are identified from public data, then flows to and from them are labeled with the venue.
- Hot and cold wallets from addresses exchanges publish themselves, such as proof-of-reserves lists.
- Deposit addresses found by their sweep pattern: many senders in, a periodic forward to a known hot wallet.
- Withdrawals as transfers out of a known hot wallet to an address outside the exchange.
Cross-venue trade tracking
Where our coverage of a venue includes participant ids (L4), an entity's trades there are linked exactly, with link_type = "address_native". Elsewhere, trades are linked to a matched deposit or to the entity's activity on another venue by timing and size, with link_type = "timing_size". Each candidate match is scored against every competing explanation on the public tape in the same window.
Confidence scoring
Every link gets a confidence between 0 and 1. Inputs include the time gap, the size ratio, how unusual the amount is, how many other candidates fit, and the method used. Links scoring below 0.50 are not published.
A score of 0.9 should be right nine times in ten.
Scores are calibrated, so they can be read as probabilities. The raw model output is mapped to a probability with isotonic regression, fitted on a labeled set of links whose truth is known, and checked on a held-out part of that set.
Calibration is refit monthly and the current reliability table is published in the chain intelligence docs. Each row records model_version, so results stay reproducible after a refit.
Entities, never identities.
Chain intelligence describes trading behaviour. It is built from public data, keyed by anonymous ids, and the data license forbids using it to identify individuals.
Public data only
Public blockchain data, and market data we hold under the terms agreed with each exchange. No KYC records, no leaked or purchased databases.
Identify individuals
No names, emails, IP addresses or social accounts are collected or joined. We do not attempt to link an entity to a natural person, and we do not offer lookups of people.
Anonymous by design
Entities get random ids such as E-4417 that encode nothing about their addresses. Only institutional wallets (exchanges, protocols, bridges) carry a name in label.
Re-identify
The data license prohibits using chain intelligence to identify or target individuals. Questions go to chris@financedatacloud.com; see also our privacy policy.
chain_entities and chain_flows.
Chain tables use chain where market tables use venue, and add the block timestamp ts_block next to ts_capture. Amounts are decimal128(38,18).
CHAIN_ENTITIES
| Column | Type | Meaning |
|---|---|---|
entity_id | string | Anonymous id, e.g. E-4417. |
chain | string | bitcoin, ethereum, arbitrum, solana, hyperliquid; tron from Phase 2. |
address | string | One address per row. |
entity_type | string | exchange, protocol, bridge or unlabeled. |
label | string | Institutional label, e.g. bridge:arbitrum. Always null for unlabeled. |
cluster_method | string | Evidence that put the address in the entity. |
confidence | decimal | Calibrated 0–1 score for the address belonging to the entity. |
first_seen last_seen | int64 | First and last on-chain activity, ns. |
valid_from valid_to | int64 | Version window; clusters are versioned hourly. |
merged_into | string | Surviving entity_id if two entities were merged. |
model_version | string | Clustering and calibration version. |
CHAIN_FLOWS
| Column | Type | Meaning |
|---|---|---|
flow_id | string | Stable id for the flow. |
entity_id | string | Entity the flow belongs to. |
chain tx_hash | string | Chain and transaction. |
ts_block | int64 | Block timestamp, ns. |
direction | string | deposit, withdrawal, transfer or bridge. |
from_address to_address | string | Counterparty addresses. |
asset amount amount_usd | string, decimal | Asset moved, in units and USD at the block time. |
venue | string | Attributed exchange, as a venue id, or null. |
link_venue link_symbol link_trade_id | string | Linked trade, where one was matched. |
link_type | string | address_native or timing_size. |
confidence | decimal | Calibrated 0–1 score for the link. |
model_version | string | Attribution and calibration version. |
Chains and venues.
Phase 1 covers five chains: Hyperliquid, Arbitrum, Ethereum, Bitcoin and Solana. Tron is planned for Phase 2. Chain history is computed back to January 2019, or to the chain's launch if later. Venue attribution and trade links start with Hyperliquid in Phase 1. Other venues are planned, subject to a data agreement with each exchange, and are added on the terms of that agreement.
Roadmap and phases| Venue | Phase | Status |
|---|---|---|
| Hyperliquid | P1 | address_native links |
| Binance | P2 | Planned, subject to agreement |
| Bybit | P2 | Planned, subject to agreement |
| OKX | P2 | Planned, subject to agreement |
| Coinbase | P3 | Planned, subject to agreement |
| Deribit | P3 | Planned, subject to agreement |
| Kraken | P3 | Planned, subject to agreement |
| Bitget | P3 | Planned, subject to agreement |
| KuCoin | P4 | Planned, subject to agreement |
| Bitfinex | P4 | Planned, subject to agreement |
| Bitstamp | P4 | Planned, subject to agreement |
| dYdX | P4 | Planned, subject to agreement |
From an order to an entity's flows.
With the add-on, book_l4 rows carry entity_id. Use it to pull everything else that entity did.
import polars as pl
from fdc import Client
fdc = Client(api_key="fdc_live_...")
window = dict(start="2027-02-03T13:00:00Z", end="2027-02-03T14:00:00Z")
# largest attributed taker on Hyperliquid BTC-PERP in the hour
l4 = fdc.book(venue="hyperliquid", symbol="BTC-PERP", depth="L4", **window).to_polars()
top = (l4.filter(pl.col("event") == "fill")
.group_by("entity_id").agg(pl.col("fill_size").sum())
.sort("fill_size", descending=True)[0, "entity_id"])
# everything else that entity did, high-confidence links only
flows = pl.read_parquet(fdc.download(dataset="chain_flows", **window))
trail = flows.filter((pl.col("entity_id") == top) & (pl.col("confidence") >= 0.8))curl -G https://api.financedatacloud.com/v1/chain_flows \
-H "Authorization: Bearer fdc_live_..." \
-d entity_id=E-4417 -d min_confidence=0.8 \
-d start=2027-02-03T13:00:00Z -d end=2027-02-03T14:00:00ZSee flow that crosses venues.
Chain intelligence is part of Enterprise and available to Desk as an add-on. Pre-register to discuss access and pre-sale terms.
EARLY ACCESS · PRE-SALE PRICINGPre-register for early access → DANIEL GARCIA · CEO & FOUNDERdaniel@financedatacloud.com →