Where a wallet label comes from, and what it misses

You paste an address into an explorer and it comes back with a name: "Binance 14", "Tornado Cash: Router", "Fake_Phishing188234". The address stops being forty hex characters and becomes a party with a reputation, and most people treat that as settled fact.

A wallet label is an off-chain annotation attached to an address by whoever runs the tool you are looking at. Nothing about it is on the chain. It is a claim, made by an identifiable party, using a method they usually do not publish — and knowing where it came from tells you how much weight it can carry.

Where the labels come from

A wallet label can come from four sources, in descending order of reliability.

Self-declaration. An exchange or protocol publishes its own addresses, often signing a message from the address to prove control. This is the strongest form: the party that owns the key says it owns the key.

Transaction-graph inference. An address that receives from a known exchange hot wallet and behaves like a deposit address is labelled as one. This is statistical, correct most of the time, and confidently wrong in a minority of cases.

Community and user submission. Explorers accept reports of scam addresses, phishing contracts and known entities. Volume is high, verification is uneven, and there is rarely a visible appeal process.

Commercial intelligence. Analytics vendors maintain proprietary attribution built from all of the above plus off-chain data. It is the most thorough and the least inspectable, because the methodology is the product.

A label is not a property of the address. It is an opinion about the address, held by whoever is showing it to you.

What labels systematically miss

Every wallet label system shares four gaps, and they are structural rather than incidental.

• Anything new. A contract deployed an hour ago has no label anywhere, because labelling is reactive. The absence of a warning on a fresh address means nothing at all, and this is the single most misread signal in the whole system.
• Ownership changes. A label attaches to an address, and addresses change hands. A wallet labelled as belonging to a project two years ago may have been sold, drained, or handed to a different team, and the label does not know.
• Contracts that behave differently than they look. A proxy contract's label describes the proxy. The implementation behind it can be replaced by whoever holds the admin key, and the name in the explorer does not change when it is.
• Shared addresses. An exchange deposit address, a router, a bridge — these are used by everyone. "Interacted with a known exchange" says nothing about the counterparty, because the exchange is not the counterparty.

The third gap is the one that turns into losses. A wallet label reading like a familiar protocol tells you what the contract was when someone looked at it, not what it will execute when you sign.

What a label cannot tell you about a person

There is a second, quieter misuse: reading a wallet label as a statement about who you are dealing with.

An address labelled with an exchange's name is the exchange's address. Funds arriving there are going to a customer of that exchange, and the label identifies the custodian rather than the counterparty. Two payments to the same deposit address may belong to two unrelated people, and a payment from one tells you which exchange someone used, not who they are.

The same applies in reverse to warnings. An address flagged for receiving from a mixer describes a transaction, not an intent, and there are ordinary reasons — privacy, an exchange withdrawal routed oddly, an airdrop nobody asked for — for funds to arrive from a marked source. Treating receipt as guilt punishes people who had no say in what was sent to them, since nothing prevents anyone from sending to any address.

Three practical consequences follow:

• You cannot refuse an incoming transfer. Anyone can send to your address, including from a flagged one, and your address may inherit a marking you did nothing to earn.
• Compliance decisions made purely on proximity are crude, and they occasionally freeze funds belonging to people who simply received a payment.
• A label on a counterparty is not due diligence. It is one input, and it describes past observed behaviour rather than the transaction in front of you.

The useful posture is to read labels as evidence about history and never as evidence about identity or intent — which is roughly how the people who build them describe them, when asked.

Reading a false positive and a false negative

A wallet label can be wrong in two ways, and they fail in opposite directions.

A false positive — an address labelled malicious that is not — is usually harmless to you and damaging to its owner. Fresh addresses that receive from a flagged source sometimes inherit suspicion through proximity alone, and a personal wallet that once took a payment from a marked address can carry that mark for a long time. If a counterparty tells you their address is wrongly flagged, that is genuinely possible.

A false negative — no label on something dangerous — is the one that costs money, and it is far more common than the first. Labels lag deployment. A drainer contract published this morning is unlabelled everywhere until someone loses funds and reports it, which means the warning system is, by construction, behind the attack.

This is why "I checked and it was clean" is a weaker statement than it feels. What you verified is that nobody has reported it yet.

What to check instead of, or alongside, the label

Five signals that are on-chain, and therefore not subject to the editorial process behind any wallet label.

1. Age and first transaction. A contract that appeared today, interacting with a token launched today, is a different risk from one running for two years. This is directly visible and cannot be faked.
2. Whether the source is verified. Unverified source on a contract asking for approvals is a decision you are making blind.
3. Whether it is a proxy, and who can upgrade it. If an admin key can swap the implementation, the code you read is provisional.
4. The concentration of holders. A token where a handful of addresses hold most of the supply behaves according to those holders, whatever any label says.
5. What you are actually signing. The decoded transaction — the function, the spender, the amount — is the ground truth. It is the same regardless of what any explorer named the address.

Point five outranks the other four combined. A scanner such as Riskira is useful for surfacing these signals in one pass, but the value is in the underlying facts it shows you, not in a verdict it prints. Treat any tool's summary as a prompt to look, not as a conclusion.

How to use labels well

A wallet label is genuinely useful, provided it is used for what it is good at.

Use a wallet label to confirm what you already believe. If you expect an address to be a particular exchange and the label agrees, that is a useful consistency check.

Use a negative label as a hard stop. If something is flagged as phishing, stop. A false positive costs you an inconvenience; ignoring a true positive costs you the wallet.

Do not use the absence of a wallet label as permission. This is the mistake that matters. Unlabelled means unexamined.

Check more than one source when it matters. Different explorers use different pipelines and disagree more often than people expect. A large transfer justifies two minutes and two tabs.

Remember the timestamp. Attribution reflects the moment it was gathered. On a chain where an implementation can change in a single transaction, that gap is the entire risk.

More on evaluating what you are signing in transaction safety, the permission model in web3 security, and the wider assessment approach in risk analysis. Etherscan documents the scope of its own label system if you want a sense of how one provider frames it.

The short version

A wallet label is an off-chain claim by whoever built the tool, sourced from self-declaration, inference, user reports or a commercial pipeline — and it is a lagging indicator by design.

Treat a warning label as a stop and an absent label as no information at all. Verify age, source verification, upgradeability and the decoded transaction yourself, because those are on-chain facts and the name beside the address is somebody's opinion of what it was.