Labelling What You Find: A Vocabulary With Limits

Label an address by what it demonstrably does, date the evidence, state which tier the label sits in, and refuse any label that names a person or implies wrongdoing. A functional label such as "receives deposits from many addresses and sends onward to one" is checkable by anyone. An attributive label such as "the team's wallet" is a claim about the world, and the ledger has no view on the world.

Labelling is where careful analysis most often becomes careless publishing, because the label is the part that travels. Nobody forwards a scoring sheet. They forward the name, stripped of its confidence band, its date and its evidence, and after enough forwarding the name is treated as a property of the address.

Why labels fail more often than data

Transaction data is unusually reliable: signatures either exist or they do not, and balance deltas are exact. Labels are the opposite, because they are summaries produced by a person under time pressure, and a summary discards the caveats first. The failure is not in the observation; it is in the compression.

Three properties make labels fragile. They are sticky, in that a label written once tends to be copied rather than re-derived. They are context-free, in that the label travels without the evidence. And they are confident, because a short noun phrase reads as settled in a way that a paragraph with a confidence band does not. Those three combine to produce claims that are far stronger than the work behind them.

Three tiers of label

Sorting labels into tiers before writing them forces the question of what kind of claim you are making. The tiers are not stylistic; they map onto different evidence requirements and different risks.

Structural labels are safe because they are computed. An associated token account is derived deterministically from an owner and a mint, so the claim "this is the associated token account for that owner and that mint" can be verified by rederiving it. Nothing about a person is involved.

Functional labels are the working currency of good analysis. They describe a role, they can be checked against transactions, and they age gracefully if dated. Most of what an analyst actually needs is functional: which addresses hold reserves, which distribute, which consolidate, which trade.

Attributive labels are where the trouble lives, and they almost always rest on off-chain information: an official announcement, a documentation page, a disclosure. When that source exists, cite it and the label is defensible. When it does not, the attribution is an inference and must be marked as one, or dropped.

The evidence each tier demands

Set the bar before you write the label rather than after somebody challenges it. For a structural label, the evidence is the derivation itself: state the inputs and let a reader recompute. For a functional label, the evidence is a count and a window: how many transactions, over what period, showing what pattern, with the signature range recorded.

For an attributive label, the standard is a named public source that the entity itself published, or a disclosure from a party in a position to know. On-chain behaviour is never sufficient by itself, no matter how distinctive, because behaviour is imitable and addresses change hands. If the only support for an attribution is that the address behaves the way you would expect that entity to behave, you have a hypothesis rather than a label.

Labels rot, so date them

Every functional label describes a period, and periods end. Operators retire wallets, rotate keys, sell accounts, change tooling and repurpose addresses that used to do something else. A label with no date implicitly claims to describe the present using evidence from whenever the analyst happened to look.

The fix is mechanical. Record the first and last signature time in UTC that supports the label, and treat the label as describing that window only. When reusing it later, either re-check the behaviour in the current window or carry the original dates forward visibly so a reader can see how old the claim is.

Set a review interval that matches how fast the behaviour could plausibly change. Structural labels effectively never expire, because a derivation does not change. Functional labels describing high-frequency automated behaviour should be treated as stale quickly, since the underlying configuration can change in a day. Attributive labels should be re-checked whenever the source you cited is updated, and dropped if it disappears.

Inherited labels from tools and lists

Most analysts do not write labels from scratch; they inherit them from explorers, indexers and shared lists. Inherited labels are useful and they carry a hidden cost, because the method behind them is invisible and the dates are usually missing. Worse, lists get copied between projects, so a single early error can appear in a dozen sources and look like independent corroboration.

Handle inheritance with two habits. First, record the source of every inherited label next to the label itself, so a later reader can see that four mentions trace back to one origin. Second, verify any inherited label that materially affects a conclusion, by checking the address behaviour against the transaction record rather than against another list.

Contradictions between sources are informative rather than annoying. When two explorers label the same address differently, at least one is wrong and the disagreement marks exactly the address worth checking yourself. Silent agreement between sources that copy each other is much less reassuring than it appears.

Labelling activity from a named tool

One category of attribution is genuinely well supported: activity produced by a service whose behaviour is publicly documented by the service itself. When a tool describes how many wallets it operates, how it funds them, what venues it routes across and what a completed run leaves on chain, the analyst has a published description to compare an observed pattern against.

That is a different evidential situation from inferring an operator from transaction shape. Documentation from a product such as Solana Volume Bot Pro describes what the software does rather than who used it on any given day, which is exactly the right scope for a functional label: "consistent with the documented pattern of a published volume tool" is checkable, whereas "operated by whoever runs that tool" is not.

Keep the distinction sharp when you write it down. A pattern matching a documented tool tells you which software was probably running. It does not tell you who ran it, whether they were the token's team, an unrelated trader or somebody testing, and it does not tell you whether anybody was informed. Software identification and operator identification are different claims and only the first one is available to you.

Name services are not identity

Human-readable names registered against addresses look like a solved labelling problem and are not. A registered name is a record that somebody paid to associate a string with an address at a point in time. It is not verified, it is transferable, it can be chosen to resemble somebody else's, and it can be pointed at a different address later without any announcement.

Use such a name as a convenience label at the structural tier, phrased as what it is: this address currently resolves from that name, as of a stated date. Do not promote it to an attributive label, because the registration proves that a registration exists rather than that the registrant is who the string suggests. Impersonation through lookalike registrations is common enough that treating names as identity is actively unsafe.

The stronger reason to be careful is that names frequently match handles and profiles elsewhere, which makes them an obvious bridge from an address to a person. Following that bridge is de-anonymisation regardless of how public each half is, and it is outside what this desk does. A name that resolves to an address stays a string in a record here, and nothing more.

Labels this desk refuses to write

Some labels are excluded regardless of how strong the evidence feels, because the harm of being wrong is asymmetric and falls on somebody who cannot correct the record.

• Any label containing a person's name, handle, alias or employer.
• Scammer, rug puller, launderer, thief, or any term asserting a crime.
• Insider, dev wallet, team wallet, or any claim of a privileged relationship to a project.
• Sanctioned or blacklisted, unless quoting a specific published designation with its identifier.
• Victim, which exposes somebody who has already been harmed once.
• Any label whose main function is to tell readers who to be angry with.

The reasoning is practical as well as ethical. These labels are unfalsifiable from the data, they invite readers to act on them, and addresses are frequently reused, shared or compromised, so the person harmed by a wrong label is often not the person the labeller had in mind. Describing the behaviour precisely gives a reader everything defensible without any of that.

A label syntax that survives quoting

Write labels so that the caveats travel with the name. A four-part form works: the label itself, the tier, the evidence in a clause, and the date window. For example: "distribution source (functional; sent to 300 distinct addresses in a two-day window; observed 1-3 of a stated month, UTC)".

It is longer than "distributor" and that is the point. When somebody quotes it, they carry the tier and the window with them, and the claim degrades gracefully instead of hardening. If a format constraint forces a short label, keep the long form in the notes and make sure the short form is functional rather than attributive, since the short form is what will escape.

Avoid labels that smuggle a quantity. "Whale" implies a threshold nobody agreed on; "large holder as of a stated date, holding a stated percentage by that snapshot" says something checkable. The same applies to "bot", which conflates several very different mechanisms; naming the observable, such as "regular sub-minute intervals with identical instruction sequences", is more informative and less loaded.

Reviewing a label you already wrote

Old labels deserve the same scepticism as inherited ones, and they get less of it because they are yours. A short review pass catches most decay: pull the current activity for the address, check whether the behaviour that justified the label is still present, confirm the evidence window is still stated, and confirm the tier still matches what you would claim today.

When a label no longer holds, correct it visibly rather than quietly. A note saying the behaviour changed on a stated date is more useful than a silent edit, because anyone who acted on the old label needs to know it moved. This is ordinary correction practice and it is rare in this field, which is one reason stale labels circulate for years.

How labelling fails

The dominant failure is the stale label quoted as current: accurate when written, wrong by the time it matters, and impossible to challenge because the evidence was never attached. Dating fixes it almost entirely, which is why dating is the single highest-value habit in this whole method.

The second failure is tier drift. A functional label repeated often enough starts being read as attributive: "deposit address" becomes "their deposit address" becomes "their wallet". The drift happens in the reader rather than in the writer, so the defence has to be built into the wording, which is what the four-part syntax is for.

The third is inheritance without verification, where one early guess is copied across sources until its ubiquity is mistaken for corroboration. The counter is to record provenance for every inherited label and to verify the ones that carry weight. Where a label is the load-bearing element of a conclusion, the conclusion is only as good as that label, and most of the time it was never checked at all. Where the trail behind a label stops entirely, the honest response is set out in where a trail goes cold.

Questions this page gets asked