OPSEC52 / Week 10 — On-chain heuristics
On a transparent chain, you are not anonymous — you are pseudonymous, which is a very different and much weaker thing. Every payment is a permanent public edge in a graph, and chain-analysis firms do nothing but collapse that graph back onto real identities. A single KYC withdrawal, one reused address, one careless consolidation, and years of “private” history unzip at once. Linkability is decided at spend time, and the ledger never forgets.
Threat model: a chain-analysis firm clustering your addresses via common-input-ownership, change-output detection, and round-amount timing; an exchange mapping your KYC identity onto whatever cluster your withdrawal touched; a counterparty who knows one address and walks the graph outward; and the retroactive nature of it all — a spend that looks safe today gets deanonymized by a new heuristic or an old data breach years later.
Pseudonymous is not anonymous
Bitcoin and every transparent chain publish, forever, who paid whom and how much. Your address isn’t your name — until it is. The entire chain-analysis industry exists to bridge that last gap: attach one real identity to one address, then let the graph do the rest. And the graph is generous. It doesn’t leak one payment; it leaks the whole cluster the moment any single node is tagged.
The mistake is thinking privacy is something you add later — mix it, VPN it, move it to a fresh wallet. But the links were minted at spend time and are immutable. You cannot un-publish a transaction. So on-chain OPSEC is not cleanup; it’s discipline applied before every spend.
The three heuristics that do most of the damage
Common-input-ownership. When a transaction spends several inputs at once, analysts assume one entity owned all of them. This is the single most powerful clustering heuristic. Every time your wallet consolidates coins to cover a payment, you are publicly asserting “these all belong to me” — welding previously separate addresses into one identity.
Change-output detection. Pay someone 0.7 from a 1.0 input and 0.3 comes back to you as change. Analysts spot the change output by its properties (freshly generated address, non-round amount, script type matching your wallet) and follow your money forward, not the recipient’s. Your change is a homing beacon.
Amount + timing correlation. Round numbers, repeated identical amounts, and payments that always land minutes after your paycheck all create fingerprints. A “$500.00” withdrawal followed by a “$500.00” deposit an hour later links two accounts without any shared address at all.
The KYC anchor is the whole game
None of the above matters to an adversary until one node in your cluster is tagged with a name. That anchor almost always comes from KYC: you withdraw from a regulated exchange to your own wallet, and now the exchange — and anyone it shares data with, by subpoena or breach — knows the entry point into your entire cluster. From there the heuristics fan out across every address you ever linked.
This is why the order of operations matters more than the tooling. Coins that were never KYC’d have no name to anchor to. Coins that touched KYC carry that identity forward through every hop unless you break linkability decisively — which transparent chains make genuinely hard.
What actually defends you
- Stop consolidating. Avoid sweeping many inputs into one transaction unless you accept they’ll be clustered. Keep funds compartmentalized by purpose, and spend from the right compartment.
- Never reuse an address. A fresh receive address per payment is the floor, not an achievement. Reuse hands analysts free edges.
- Break the KYC anchor before it matters. Assume any coin that passed KYC is tagged. Don’t mix “clean” and KYC’d coins in the same transaction — that just tags the clean ones too.
- Kill round amounts and predictable timing. Vary amounts; don’t move money on a schedule an observer can predict.
- Treat change as identity. Understand which output is your change and where it goes next.
Where Monero changes the math
Every defense above is you fighting the ledger’s default, which is total transparency. Monero inverts the default: ring signatures hide which input is really being spent (common-input-ownership stops working), stealth addresses mean the recipient’s address never appears on-chain (no reuse to exploit, no change-detection foothold), and RingCT hides the amounts (timing/round-number correlation loses its fingerprints). You are not manually defeating three heuristics on every spend — the protocol defeats them for you, for everyone, all the time.
That’s the structural point this series keeps returning to: on a transparent chain, privacy is a fragile discipline you can lose in one careless spend; on Monero, it’s the default you’d have to work to break. If your threat model is chain analysis, the highest-leverage move isn’t a better mixing strategy — it’s not producing the transparent graph in the first place.
This week’s drills
- Pull your own most-used transparent address into any block explorer and look at it the way an analyst would: what clusters to it, where does your change go, which amounts repeat?
- Identify every coin you hold that touched KYC. Mentally tag its whole forward history as named.
- Stop address reuse today — configure your wallet to generate a fresh receive address per payment.
- For your next private payment, ask before you sign: what does this spend assert to a graph-walker — and would Monero have asserted nothing?
See also
- OPSEC52 Week 9 — Hardware wallet OPSEC (protects your keys; this pillar protects your linkage)
- OPSEC52 Week 1 — VPN exit discipline (the network-layer half of not building the bridge yourself)
OPSEC52 is xmr.club’s weekly OPSEC series. Series index: /opsec.
Curated by Cyber Satoshi