Why “Clean” and “Dirty” Crypto Is the Wrong Mental Model

Why the clean/dirty binary is so attractive

The binary is seductive because it is operationally simple. A compliance analyst clearing a withdrawal wants a yes/no. A user who just received an odd deposit wants to know if their wallet is “safe.” A headline wants a villain.

“This wallet is dirty” fits on a sticky note. “This wallet received a small fraction of its lifetime inflow from an address heuristically clustered to a service later associated with a theft, eighteen months ago” does not. But the simplicity is borrowed against accuracy. The moment you ask how a coin became “dirty,” the binary dissolves into a set of separate, weigh-able questions — and those questions are where real investigation lives.

Why the binary fails in practice

Start with the mechanics. The most literal version of taint — follow illicit coins forward and mark whatever they touch — has no single agreed definition. The forensic and academic literature describes at least three incompatible accounting models (see Tironsakkul et al., “Probing the Mystery of Cryptocurrency Theft: An Investigation into Methods for Taint Analysis”, which compares these strategies directly):

• Poison: any output touched by tainted value is treated as fully tainted, regardless of amount.
• Haircut: taint is spread proportionally to value (mix 2 “dirty” units with 3 “clean” and each output carries roughly 40%).
• FIFO: coins are treated as spent in the order received — an accounting convention the protocol does not actually enforce.

The same transaction can come out fully tainted, partially tainted, or barely tainted depending only on which model you pick — different tainting methods can produce materially different results, and the literature does not establish a single accepted method for evaluating their accuracy. A classification that changes drastically with the observer's bookkeeping choice is not an objective fact about the coins; it is an output of a method.

This is the fungibility distinction, stated precisely. Blockchain protocols do not encode “taint” as an intrinsic property of a coin or unit — at the protocol level every unit is interchangeable. Investigators, exchanges and compliance systems may nonetheless attach provenance-based risk to an asset's transaction history, and that is a legitimate analytical activity. The resulting taint or risk classification depends on the attribution data and the analytical/accounting model used. The conclusion is not that history is irrelevant; it is that taint is an analytical classification, not an objective protocol-level property permanently stamped onto the asset.

The framework that replaces it: an evidence hierarchy

The fix is not to abandon provenance. The fix is to stop collapsing six different kinds of statement into one word. In our investigation guides — most explicitly the TRON/USDT tracing methodology — we keep them separate, and it is the single most useful habit for interpreting crypto risk.

Defensible conclusions keep these layers separate: on-chain facts and derived behavior establish what happened; attribution and authoritative external data add counterparty context; scores and hypotheses interpret that evidence. The error behind “clean/dirty” is reporting a Level 5 or Level 6 conclusion as if it were a Level 1 fact. A score is an input to judgment; it is not the evidence, and it is not a verdict.

Direct vs. indirect exposure

The biggest source of false positives is treating proximity like participation.

Even direct interaction is not self-interpreting. Receiving funds is different from sending them. A small touch is different from a large one. A one-time interaction years ago is different from a weekly pattern. And “the counterparty is an exchange” changes the meaning entirely from “the counterparty is a personal wallet.”

Indirect exposure is weaker still. “Three hops from a bad address” feels like a rule, but hop-counting ignores that high-traffic infrastructure connects almost everyone to almost everything within a few hops. There is no universal safe or risky hop threshold, and anyone who gives you one is selling the binary again.

Amount, proportionality, and recency

Weight should scale with materiality. Useful questions include the absolute amount; the share of the wallet's total flow the interaction represents; frequency (incidental vs. repeated); and recency (a single event years ago vs. ongoing activity).

A wallet whose entire history is one unsolicited dust-sized deposit is not the same risk as a wallet routing a large fraction of its volume through a flagged counterparty every week. None of this implies fixed numeric weights — proportionality is a reasoning discipline, not a formula to hard-code without evidence.

Counterparty context

Interacting with shared infrastructure is not itself evidence of wrongdoing. Exchanges, bridges, DEX routers, custody systems, merchant processors and deposit addresses are used by millions of people, including bad actors. Touching the same router a thief used no more implicates you than using the same highway.

The investigative work is identifying the counterparty's role and interpreting the interaction in light of it — not flagging the contact and stopping.

Attribution confidence

“Who is on the other side?” is almost never a settled fact, and the methods differ wildly in reliability:

• Official listing / identifier association (e.g., a digital-currency address listed by a sanctions authority) — authoritative as to the listing, but not by itself proof of who controlled the address at every point in time.
• Strong service/entity attribution (well-evidenced exchange or protocol address) — usually reliable.
• Heuristic clustering (common-input and similar heuristics) — useful but probabilistic.
• Community / OSINT labels — variable quality, often stale.
• Model inference — a hypothesis, not a finding.

Labels propagate. A wrong or outdated label at Level 3–4 silently poisons every downstream score and every “dirty” verdict built on it. Good practice records why an attribution was made and when.

Sanctions: keep five things separate

Nowhere does the binary cause more damage than sanctions, where precise language is a factual necessity. These are distinct states:

1. the address itself is officially listed or designated by an authoritative sanctions authority;
2. a direct transaction with a listed address occurred;
3. indirect proximity to a listed address exists;
4. a service or entity associated with sanctions was used;
5. a model-generated sanctions-risk signal fired.

Only an authoritative sanctions listing or designation supports saying that an address is officially identified in connection with a sanctioned or blocked person. Direct exposure, indirect proximity, service association and model-generated sanctions signals do not themselves make an address sanctioned. A risk signal about sanctions exposure — the kind surfaced by sanctions screening, where supported — is an input to a risk-based decision, consistent with the risk-based approach OFAC's sanctions-compliance guidance for the virtual currency industry describes, not a legal determination. (This article is methodology, not legal advice.)

Source freshness: risk intelligence has a timestamp

Risk data is not immutable truth; it is a snapshot. Labels get added, corrected, and removed; addresses get newly designated; entities get de-listed; service attributions get updated. An interaction's status at one point in time and its status two years later can be genuinely different facts. A historical “dirty” score with no attached source and version is not a verdict you can stand behind later. The Tornado Cash timeline below is the clearest illustration of why.

Behavioral signals are evidence, not proof

Independently of labels, behavior carries information: rapid fan-out, consolidation, peel chains, bridge-hopping, repeated deposit-address interaction, burst activity, routing through contracts. These patterns are worth surfacing — they are often why an investigator looks closer.

But a pattern consistent with laundering is frequently also consistent with ordinary activity: batching, rebalancing, arbitrage, market-making. The FATF, in its Virtual Assets Red Flag Indicators report built on more than a hundred case studies, is explicit that a single indicator does not by itself establish criminal activity — its presence should prompt closer examination, not a conclusion. Treat behavior the same way: a signal that raises or lowers confidence, never automatic proof.

A practical interpretation framework

When you see a “risk” result, run it through the hierarchy instead of accepting the label:

1. Separate fact from inference. What is observed (Level 1–2) vs. attributed or scored (Level 3–5)?
2. Classify the exposure. Direct or indirect? Sending or receiving?
3. Weigh materiality. Amount, share of flow, frequency, recency.
4. Interpret the counterparty's role before interpreting the interaction.
5. Grade attribution confidence and check its date.
6. Separate the sanctions states (officially listed vs. proximate vs. model signal).
7. State a hypothesis with a confidence level — and note what evidence would change it.

Two worked examples

1. When proximity gives the wrong answer

In August 2022, shortly after Tornado Cash was first sanctioned, an unidentified actor sent small, unsolicited amounts of ETH — reported at roughly 0.1 ETH each — through Tornado Cash to a long list of well-known public wallets, including figures such as Vitalik Buterin and various celebrities (as reported at the time).

Under a naive “received funds from a sanctioned mixer = tainted” rule, hundreds of entirely passive recipients would be flagged for an interaction they neither requested nor controlled. The on-chain fact (a transfer occurred) is real; the inference (the recipient did something wrong) is unsupported. The sender's identity and the recipients' intent cannot be read off the ledger — direction, consent, amount and purpose all matter, and the binary ignores all four.

2. When the label itself changes

The same service illustrates source freshness. The authoritative record moved through four distinct states:

• 8 August 2022 — the U.S. Treasury's OFAC first designated Tornado Cash.
• 8 November 2022 — OFAC delisted and simultaneously redesignated Tornado Cash; the November action fully replaced the August designation.
• 26 November 2024 — the U.S. Court of Appeals for the Fifth Circuit decided Van Loon v. Department of the Treasury (No. 23-50669), holding that the immutable smart contracts at issue are not “property” subject to blocking under the relevant statute.
• 21 March 2025 — Treasury removed the economic sanctions against Tornado Cash, after the Fifth Circuit decision and its subsequent review of the legal and policy issues.

An address's exposure to Tornado Cash meant one thing while the service was on the sanctions list and a different thing after its removal. Any “dirty” determination frozen at a point in time — without recording which list, which version, and which date it relied on — is not something an investigator can defend later. (Where no clean, publicly documented on-chain case fits a point, use clearly labelled hypotheticals rather than inventing transactions — a discipline this article itself argues for.)

How to read a risk score, then

A risk score is a compression of many signals into one number for triage. Used well, it tells you where to look first. Used badly — as a verdict — it launders inference into apparent fact. The right posture: a score is an analytical input that should come with explainable reasons, a confidence level, and a timestamp/source. If it cannot tell you why, it cannot be audited, and anything that cannot be audited should not be the basis of a consequential decision. (Our explainer on what a crypto risk score is covers the 0–100 model in detail.)

This is where a tool earns its place. A screening platform can help surface transaction history, counterparty context, labels and attribution where supported, sanctions exposure where supported, and the reasons behind a score — so a human can apply the hierarchy above. OnChainRisk's wallet screening API is built to expose those reasons rather than hide them behind a verdict. But the point stands over any vendor: a risk signal is an input to judgment, not the evidence itself, and never a legal conclusion. No score — ours included — determines guilt, innocence, or regulatory compliance; those remain human and, where relevant, legal determinations.

Conclusion: a checklist to replace the binary

• Replace “is it clean or dirty?” with “what is observed, what is inferred, and how confident am I in each?”
• Distinguish direct from indirect exposure; never treat hop-count as a verdict.
• Weigh amount, share of flow, frequency and recency.
• Interpret the counterparty's role before the interaction.
• Grade attribution confidence and record its date.
• Keep the five sanctions states separate; reserve “sanctioned” for officially listed addresses.
• Treat behavior and scores as signals with confidence, not proof.
• Attach a source and timestamp to every risk claim.

Risk signals and scores are analytical inputs. Evidence comes first; interpretation and hypotheses come afterward — and provenance, read in context, is far more useful than any one-word label.