Wallet labels

An address label is a consensus over several sources (Arkham, OLI, Blockscout, Dune, the MEW darklist, Etherscan and Vike's own heuristic classifier), and the API returns both the consensus and what each source said. Labels are always read from Ethereum. The fields are listed on the Wallet labels dataset; the routes are /labels/batch and /labels/{address}/provenance.

Sources and consensus

Two structural notes on the provenance response:

• sources[] entries are not the same shape as consensus. A source carries {source, label, entity, category} in the provider's own vocabulary — note "entity": "Binance" capitalised and "category": "Hot Wallet" — while consensus carries the normalised {entity, wallet_type, cex_product, user_subtype, risk_flag, confidence} with "entity": "binance" lower-cased and "wallet_type": "cex". Join on the consensus fields; the source fields are free text.
• The source field reads provider_a, not a vendor name. The sources are anonymised on the wire, so you cannot use this route to tell which of the named providers made a claim — only how many distinct sources did, and what each said.

source_count counts raw claims, while consensus comes from our own classification, so found: true with one source, or none, is still a successful lookup. Sources can disagree with the consensus and with each other: on 2026-10-19 vitalik.eth drew "Vitalik Buterin" from one source and "sushiswap" from another. An address genuinely unknown to the cascade (found: false) is the case to test your handling against separately.

Reading the fields

Two field notes. risk_flag is the empty string rather than null on a clean row, so a truthiness check is the right test and an is None check is not. And wallet_type is a classification of behaviour, not of ownership: vitalik.eth is typed dex by /labels/batch, which describes where its transfers land rather than what the address is — do not read wallet_type as "this address is a DEX".

A thin answer is ambiguous

This route does not fail when a label source is unavailable. When an upstream label dump is mid-rebuild the route returns fewer rows instead of a failure. A thin provenance list is therefore ambiguous between few sources know this address and a source is rebuilding — re-query before concluding an address is unlabelled.