What on-chain analytics can and cannot prove

A thread appears: an address is traced through six hops, connected to a known exchange deposit, and named as belonging to a particular person. The evidence is on-chain, public and verifiable. It looks like proof, and people treat it as such — including sometimes about the wrong person.

Chain analytics is the practice of drawing conclusions about entities and behaviour from public transaction data. It is genuinely powerful, and it establishes some things with near-certainty while establishing others not at all. The line between those two categories is not where most readers assume it is.

What it can establish

Four categories, and these are as close to fact as this field gets.

• That a transaction happened. Amount, addresses, block, timestamp. This is the ledger itself, replicated across thousands of nodes, and it is not subject to opinion.
• That two addresses transacted. The link between them is a recorded event, not an inference.
• The state of a contract. What code is deployed, what permissions stand, what balances exist. All directly readable.
• The sequence of events. Ordering within and across blocks is definite, which matters when arguing about what preceded what.

The chain records what addresses did. It does not record who controls them, and no amount of analysis converts one into the other.

That distinction carries almost the entire subject. Everything above concerns addresses; everything people usually want to know concerns people.

What it cannot establish

Five things, each of which has been asserted confidently and wrongly.

Who controls an address. There is no identity layer. Attribution comes from off-chain information — an exchange's records, a public statement, a leak, a pattern of behaviour — and every one of those is a claim from outside the chain with its own reliability.

Intent. A transfer to a mixer might be privacy-seeking, or an exchange's routing, or a scripted process. The chain shows the movement, not the reason.

Whether the same person controls two addresses. Clustering heuristics — common inputs, change detection, timing correlation — are probabilistic. They are frequently right and occasionally spectacularly wrong, and the confidence with which they are reported rarely reflects that.

That funds are "stolen". An address can be labelled following a report, and reports can be mistaken or malicious. The label is a claim.

What happened off-chain. A payment might settle a real invoice. The chain sees a transfer and knows nothing about the agreement behind it.

How clustering actually works, and where it fails

The heuristics are worth understanding because their failure modes are specific rather than random.

Common-input ownership. If several addresses fund one transaction, they are usually controlled by one party — the assumption behind most clustering. It breaks on collaborative transactions, where multiple people deliberately contribute inputs precisely to defeat it.

Change detection. Identifying which output returns to the sender. It relies on wallet behaviour patterns that differ between implementations and change with software updates.

Timing and amount correlation. Linking a deposit to a withdrawal by proximity and size. It is inference from coincidence, and it produces false links whenever volume is high.

Address reuse. Genuinely strong when it happens — but it is a behaviour, and the moment someone stops reusing addresses the signal disappears.

The pattern across all four: they infer from behaviour, and behaviour changes. Anyone deliberately avoiding these heuristics can, and the analysis then describes the people who were not trying.

Privacy tools and what they change

A recurring confusion is treating the use of a privacy tool as evidence in itself, so it is worth separating the mechanics from the judgement.

Mixers, coinjoins and privacy-preserving chains work by breaking the link between an input and an output, and they do so deliberately. After funds pass through one, chain analytics genuinely cannot follow them in the way it follows an ordinary transfer — what remains is statistical argument about timing and amounts, which is far weaker than a recorded link.

Three things follow:

• "Traced through a mixer" usually means "assumed through a mixer". The strength of that assumption varies enormously with the pool's size and activity, and it is rarely stated.
• Use is not intent. Privacy has ordinary motivations — a salary paid on-chain, a donation, not wanting counterparties to see a whole balance — and the technique cannot distinguish those from any other reason.
• The regulatory position is separate from the analytical one. Whether a service is sanctioned in your jurisdiction is a legal question with real consequences, and it is not the same question as whether the analysis is sound.

The honest framing is that these tools shift what is knowable rather than hiding wrongdoing specifically. An analysis that treats their use as its own conclusion has substituted a judgement for a finding, and that substitution is worth noticing whichever direction it points.

Reading someone else's analysis

Most people encounter chain analytics as a conclusion presented by somebody else. Five questions separate a sound one from a confident one.

1. Which parts are ledger facts and which are inference? A good analysis marks the difference. One that presents both in the same voice is doing something else.
2. Where did the attribution come from? "Known to belong to X" needs a source. Absent one, it is an assertion.
3. How many hops? Confidence decays with distance. Two hops from a known entity is meaningful; six is a statement about the network, not about a person.
4. What would the innocent explanation be? If the author has not considered one, they were not testing the hypothesis.
5. Who benefits from this conclusion? On-chain analysis is used in disputes, and selective presentation is easy when all the data is public.

Point three deserves emphasis because it is where most public threads overreach. Funds passing through a service that pools deposits break the chain of custody entirely — after that point, "these are the same funds" is usually not a claim the data can support at all.

Using it for your own decisions

For an ordinary person, the useful applications are narrower and more reliable than the investigative ones.

Checking a contract before interacting. Age, verification status, what has called it. These are facts, and they answer real questions — which is what a tool like Riskira is for: surfacing the underlying signals against an address rather than issuing a verdict about who owns it.

Verifying an address you were given. Compare against the source, check whether it has plausible history.

Monitoring your own addresses. Alerts on outgoing movement, using data you can interpret because you know the ground truth.

Confirming a payment. The transaction is either in a block or it is not.

Notice that all four concern behaviour and state rather than identity. That is the boundary within which this data is reliable, and staying inside it is what makes chain analytics useful rather than merely impressive.

More on how labels are constructed in risk analysis, what a preview can show you in transaction safety, and the permission model in web3 security. Chainalysis publishes its methodology overview if you want a vendor's own account of how attribution is built.

The short version

Chain analytics proves that transactions happened, that addresses transacted, and what state a contract is in. It does not prove who controls an address, what they intended, or whether two addresses share an owner — those are inferences from heuristics that people can and do defeat deliberately.

When you read someone's analysis, separate the ledger facts from the inference, ask where the attribution came from, and count the hops. And for your own decisions, stay on the reliable side of the line: check contracts, verify addresses, monitor your own wallets — none of which requires knowing who anybody is.