Wallet labels: source and trust

An address label is a consensus over several sources (several third-party label providers and Vike's own heuristic classifier), and the API returns both the consensus and what each source said. Provenance is read from Ethereum only. The labels on /labels/batch and in the counterparty, compare, trace and token-holder results follow the requested chain (ethereum, bsc, base or hyperevm): each reads that chain's own label table, never Ethereum's for the same 20 bytes (hyperevm has labels for only a few hundred wallets). 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.

Coverage by chain

Each chain has its own label table, built separately, so how far a label can be trusted depends on the chain you ask about.

• Provenance always answers for Ethereum. /labels/{address}/provenance takes no chain; asked about an address you met on another chain, it reports what the sources say about the same 20 bytes on Ethereum, which can be another owner or nobody.
• A miss on hyperevm says little. With so few labelled wallets there, an unlabelled sender on /first-funder or an empty exchanges on /exchange-usage is not evidence that the address is unlabelled anywhere. The HyperCore system addresses (native HYPE bridge-ins, token mints) are typed system once registered: protocol flow, not a trader.
• A label is a consensus, not a certainty, on every chain: /labels/batch returns its confidence, /first-funder returns a label_confidence beside each sender, and /exchange-usage returns label_confidence per exchange as counts of its addresses graded high, medium and unrated.

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. While one of its label sources is being refreshed 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.