Look up all known LABELS for a blockchain ADDRESS — entity, category,
CEX deposit/hot wallet, mixer, gambling, scam, token-clone, contract
type, NFT collection, ENS, … Works for both wallets and token/contract
addresses. Use for "what / who is this address", "is this token a scam or
a clone", "is this wallet a CEX or mixer". To label MANY addresses at once
use `labels_for_addresses`; to list every address carrying a
label use `addresses_by_label`; to resolve a human name to a stored value
use `find_label_values`.
Backed by the Bitquery address-label directory (directory.labels).
Coverage: token/contract labels are dense on EVM (Ethereum, BSC, Polygon);
exchange deposit / hot-wallet labels are broad on the EVM chains and Tron;
wallet (EOA) labels are densest on Tron and Bitcoin; mixer labels exist
essentially only for Bitcoin, and sanctioned / darknet tags sit mostly on
Bitcoin, Tron and Ethereum. Pass chain='' (the default) to search every chain —
recommended on EVM, where one address is the same owner on every chain and its
label may be stored under a different one.
Tracing note: MOST tracing rows carry NO label field, so this call is what puts a name
on a counterparty. On Ethereum, BSC, Polygon, Arbitrum, Base, Optimism, Tron, the XRP
Ledger, Stellar and Cardano NONE of the transfer / flow tools return a label — always
look the address up here (or pass the whole counterparty list to `labels_for_addresses`).
Only the Solana tools (address_flow_summary, flow_edges, trace_next_hop, transfers_in/out)
and the Bitcoin-style tools of Bitcoin, Zcash, Litecoin, Dogecoin, Dash and Bitcoin Cash
(address_profile, address_flow_summary, flow_edges, related_addresses, tx_flow) carry an
inline label field at all, and even there it is SPARSE on Solana and EMPTY on every other
chain (the inline list holds none of their addresses — batch those addresses into
labels_for_addresses) — never treat a blank inline label as "unlabeled", always confirm
it here. On the XRP Ledger (chain='ripple'), Cardano
(chain='cardano'), Stellar (chain='stellar'), Litecoin (chain='litecoin') and Bitcoin Cash
(chain='bitcoin-cash') the directory is sparse, mostly exchange reserve wallets; Dogecoin
(chain='dogecoin') holds about 40,000 addresses, almost all exchange reserve wallets. Most
Bitcoin Cash entries are stored in the old 1… / 3… address form, so a CashAddr (q… / p…)
lookup finds only a few of them.
Robinhood, Zcash, Dash and Arc have no label coverage at all, so an empty result there is a
coverage gap, not a finding. An empty result while find_label_values shows rich coverage (e.g.
'binance') is a meaningful NEGATIVE signal, not missing data.
One row per chain + label_type + label_value; recorded_at is the newest record of it.
Several sources can record labels for one address. Rows that agree are merged: Sources
lists every source behind a label and Source_Count how many there are. Labels that disagree
stay separate — typically the same entity in different roles, e.g. cex-deposit-address AND
cex-hot-wallet for one exchange, or a token-contract next to a token-clone. Such a conflict
comes from different sources; weigh it by Source_Count and by the kind of source: sanctions
lists (ofac, uk-ofsi, eu-sanctions …), official proof-of-reserves disclosures and verified
sources are curated, while a source whose name contains "heuristic" was inferred from
transfer patterns (broad, less certain) — trust the entity they agree on, and prefer the
curated role when they differ.
Source names: workflow:<name> is a Bitquery labelling pipeline - curated imports such as
sanctions and issuer block lists, proof-of-reserves disclosures, research sets and
label-provider enrichment - except that a name containing "heuristic" marks labels
inferred from transfer patterns (most exchange-deposit labels); labels-query-service:<provider>
was fetched on demand from an outside label provider when the address was looked up (one
provider's view, not reviewed); a plain name is the dataset itself (ofac, uk-ofsi,
eu-sanctions, japan-mof, france-gels and israel-nbctf are sanctions lists; walletexplorer and
bitcoinabuse are public Bitcoin datasets), and a name containing "verified" is a reviewed
import.
