BitcoinDatabase.com

Query the chain · Address labels

Bitcoin address labels and entity attribution API

A raw Bitcoin address is just a string of characters, and on its own it tells you nothing about who controls it. Bitcoin address labels close that gap: BitcoinDatabase clusters addresses that provably share ownership and attaches an informational label where the cluster maps to a known entity, such as a major exchange wallet, a mining pool, a payment processor or a well-known service. Query an address and, alongside its balance and history, you get the label we hold for it.

or try it below ↓

REST API · SQL · dashboards · address history from genesis

Query Console
btc
try:

Hit Run to query the Bitcoin blockchain.

Live from the chain for .

BTC

Balance trail

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Reading the chain ...

The same labeled data is queryable three ways: the REST API for apps, SQL for analysts who want to join labels against flows, and dashboards for review. It is built for compliance, research and analytics teams who need to read the chain as entities rather than hashes. Labels are informational context from on-chain clustering and public attribution, not identity claims about individuals and not legal or financial advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

History from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with Address labels

Entities, not just hashes

Where an address clusters to a known exchange, miner, pool or service, we attach a label so your query returns an entity name and category, not only a raw string, and your team reads the chain in plain terms.

Clustering you can join

Labels sit next to balances, transactions and fund flows on the same indexed chain, so in SQL you can group flows by entity, filter transactions touching a labeled exchange, or roll up exposure across a cluster in one query.

Informational, not accusatory

Attribution is framed as on-chain context to support your own review, never an identity claim about a person or a guarantee. It surfaces signals; your compliance or research process makes the decisions.

Side by side

We asked nine public Bitcoin APIs to name an address owner

Measured on 6 September 2026 against the live chain at block 965,794, using five addresses chosen for unusually strong public reporting: the most widely reported cold wallet on the chain, a hot wallet with 2,320,473 transactions, the 2010 pizza address, an address on the OFAC SDN list and a large bech32 cold address. Six providers answered without credentials. Exactly one returned a cluster id. Not one returned an entity name.

Public API Cluster id Entity name What we measured
WalletExplorer Yes, 5 of 5 No, label null on all 5 200, no key, 135 blocks behind the tip
mempool.space No No 200 in 0.11s, no label fields
Blockstream Esplora No No 200 in 0.59s, no label fields
BlockCypher No No 200 in 0.20s, no label fields
blockchain.com No No 200, 8 keys, none about identity
Bitquery unauthenticated No No 200, no label fields returned
Blockchair Not testable Not testable 430, our IP is blacklisted
timechainindex Key required Key required 401, API key required
Arkham Key required Key required 400, sign up required

The split this table exposes is the one that decides your budget. Clustering, which groups addresses that provably co-spend, is arithmetic over the chain and a free API will hand it to you. Attribution, which puts a company name on that cluster, comes from off-chain evidence and nobody gives it away. Two caveats we will state rather than hide: timechainindex and Arkham both refused without keys and may return rich entity data to paying customers, so their rows read key required rather than no, and the Blockchair block is an artifact of our own earlier testing rather than a judgment on their product. One further finding from the same run: two addresses widely reported as cold storage for the same exchange landed in two different WalletExplorer clusters, 011cf39664426f5d and 1c604af8fad4c417. That is not a bug. Common input ownership can only merge addresses that have actually been spent together, and segregated cold storage never co-spends, so any cluster total is a floor rather than a count.

What it handles

The indexed Bitcoin chain, queryable your way

Look up an address, a transaction, a UTXO, the rich list or an on-chain metric, by REST API, SQL or dashboard. The same authoritative data, reconciled block-by-block against the canonical chain, without running a node.

  • Return exchange, miner, pool and service labels
  • Group fund flows by labeled entity in SQL
  • Filter transactions touching known clusters
  • Enrich address lookups with attribution context
  • Label a whole address list in one query, not one call per address
  • Join labels to balances and flows without a second dataset
  • Feed labeled data into AML and research workflows
GET /v1/address/{addr} query result
200 · JSON
{
  "address": "bc1qxy2k…l0wdv8",
  "balance_btc": 68432.10,
  "balance_usd": 4612165420,
  "tx_count": 1284,
  "unspent_outputs": 37,
  "first_seen": "2014-02-09"
}
indexed from genesis · to the satoshi ✓ reconciled block-by-block

Why BitcoinDatabase

One platform, queryable three ways

Not a raw node to sync, not an indexer to build, and not five vendors to stitch together. The fully-indexed Bitcoin blockchain, available as a REST API, as SQL, and as dashboards, on one authoritative dataset.

REST API

Typed JSON for addresses, transactions, balances, UTXOs and metrics. Drop it into apps, wallets, explorers and agents with curl, Python or any HTTP client.

SQL access

Run SQL directly against the indexed Bitcoin dataset for ad-hoc analysis, cohorts and exports, the same data the API and dashboards read from.

Compliance-first

Informational on-chain data and analytics only. Entity labels and flow tracing are framed as tooling to support a regulated team's own review, not accusations.

Good questions

Questions about Address labels

There is a free clustering database, which is not the same thing. On 6 September 2026 WalletExplorer returned a wallet id for all five addresses we tested, with no key, but its label field was null on every one, and null again when we queried the cluster endpoint directly. The one genuinely free, authoritative, named Bitcoin label set is the OFAC SDN list, which ties 532 validated Bitcoin addresses to designated entities and is a sanctions list rather than a market map.
You attach off-chain evidence to an on-chain cluster. The chain records that an address received coins; it never records a name. The workable sources are the entity publishing the address itself, a deposit made to a known service so you can observe where the funds land, sanctions and enforcement filings, and court records. Everything beyond those is inference layered on top, which is why two vendors running identical clustering still disagree about names.
Because they gathered different off-chain evidence, not because they read a different chain. Clustering is reproducible arithmetic and rarely the source of disagreement. Attribution is research, and research coverage differs. When you evaluate a provider, ask what it returns when its evidence is thin: an honest unknown is worth more than a confident guess you cannot audit.
No, and it systematically undercounts. The common input ownership heuristic can only merge addresses that have been spent together in one transaction, so well-run cold storage that never co-spends stays unmerged. We measured this directly on 6 September 2026: two addresses widely reported as the same exchange landed in two separate clusters. Treat any cluster size as a floor, never a total.
It depends on whether you are investigating or deciding. WalletExplorer reported updated_to_block 965,659 against a live tip of 965,794 on 6 September 2026, so it sat 135 blocks behind, roughly 22 hours. That is fine for retrospective research and not fine for a deposit decision made as funds arrive. Ask any vendor for this number separately for clustering and for attribution, because those pipelines usually run on different schedules.
Bitcoin address labels are informational tags that map an address, or a cluster of addresses under shared control, to a known entity such as an exchange, mining pool or payment service. BitcoinDatabase derives them from on-chain clustering and public attribution and returns them alongside balances and history.
No. Labels attribute an address to an entity or service based on on-chain behavior and public information, such as a wallet belonging to a known exchange. They are informational context to support your own review, not identity claims about individuals, and this is data only, not legal or financial advice.
Pass the whole list in one query rather than calling per address. In SQL you filter the labels against an array of addresses and get back one row per match with its tag and entity; over the REST API you post the list and receive the same shape. Labeling ten thousand addresses is one request, not ten thousand.
Yes. BitcoinDatabase exposes labels as a queryable table on the same indexed chain as balances, transactions and flows, so you can select tag, entity and address for a list of addresses and join the result straight to on-chain activity in one statement, with no separate dataset to import and keep in sync.
No. The public crypto_bitcoin dataset holds blocks, transactions, inputs and outputs, which is raw chain data with no exchange, mining pool or service attribution. Analysts usually join a third-party labels table alongside it, inheriting that provider's refresh schedule and labeling decisions. See the BigQuery comparison for how the two approaches differ.

Explore more

More ways to query Bitcoin with BitcoinDatabase

Stop running a node. Just query Bitcoin.

Run your first query now and get on-chain data back by REST API, SQL or dashboard, with address history back to the genesis block over REST. Informational on-chain data only, not financial advice.

See pricing

History from genesis over REST · SQL · dashboards · addresses, transactions, UTXOs, metrics