follow-the-crypto

Follow the Crypto

Public chains are pseudonymous, not anonymous. Every transfer is permanently visible to anyone; what's missing is the mapping from address to human. So the whole game is attribution, and attribution almost always happens at an off-ramp — the point where value converts to fiat through a service that collected identity documents. Everything between the crime and the off-ramp is just plumbing you have to follow.

The beginner error is treating a clustering heuristic's output as fact. "These addresses belong to the same entity" is a probabilistic inference with known failure modes, and commercial attribution labels are proprietary guesses you cannot audit. Trace confidently; attribute carefully.

Triage: what are you holding?

The method

1. Establish the chain and address type. The string tells you. Bitcoin legacy pay-to-public-key-hash addresses begin with 1; pay-to-script-hash, historically multisig and wrapped SegWit, with 3; native SegWit bech32 with bc1q; Taproot with bc1p. Ethereum and every EVM chain use 0x plus 40 hex characters, with mixed-case acting as an EIP-55 checksum. Full table in the reference file above.

2. Open the address in a block explorer and read it properly. Balance is the least interesting field. What matters: first-seen and last-seen timestamps (activity lifespan), total received versus current balance (a swept address is a conduit, a holding address is a destination), transaction count, and the counterparty set. On EVM chains also read the internal transactions, the token transfer tab, and whether the address has code — an address with bytecode is a contract, not a person's wallet, and its behaviour is defined by that code.

3. Choose the right mental model for the chain. UTXO chains like Bitcoin have no accounts: a transaction consumes discrete unspent outputs and creates new ones, so "the balance of an address" is a derived aggregate and value visibly splits and merges. You trace coins through a graph of outputs. Account-model chains like Ethereum have balances mutated by transfers, so you trace account-to-account edges, and a single transaction can trigger a cascade of internal transfers and token movements that don't appear in the top-level view. Confusing the two is the most common source of nonsense conclusions.

4. Cluster, and know what each heuristic is worth.

• Common-input ownership is the strong one: if a UTXO transaction spends several inputs, whoever built it had to hold the keys for all of them, so those addresses share a controller. This is the backbone of every Bitcoin clustering engine.
• Change-address identification is the weak one. The heuristics — output with an unrounded amount, output whose script type matches the inputs while the other doesn't, output to a never-before-seen address, and the unnecessary-input rule — are individually fallible and compound their errors across hops. A single wrong change call sends the whole downstream trace to a stranger.
• Address reuse collapses activity into one identity for free and is common among people who don't consider themselves targets.

5. Find the off-ramp. Exchanges assign each customer a unique deposit address, then periodically sweep those deposits into consolidated hot wallets. That sweep is the giveaway: many independent addresses funnelling into one large wallet, on a schedule, is an exchange deposit structure. Reaching a deposit address is the single most valuable outcome of a trace, because the exchange holds KYC records for whoever it belongs to — obtainable by law enforcement through legal process, not by you. Document the deposit address, the amount, the timestamp, and the exchange identification basis, and hand it over.

6. Recognise service and contract interaction by pattern. Equal-denomination outputs with many participants in one transaction is CoinJoin. Fixed-denomination deposits and later withdrawals from the same contract are a Tornado-style shielded pool. A transfer into a contract followed by an event on a different chain is a bridge. Repeated round-number transfers between two addresses on a schedule looks like payroll or a subscription, not a market operation. Peel chains — a large amount that repeatedly spends a small piece out and forwards the remainder — are a classic laundering and cash-out pattern.

Where the trail breaks, and what you can still say

CoinJoin breaks common-input ownership by design: the inputs belong to different people. Naïve clustering that ignores this merges unrelated users into one giant false cluster — a well-known and serious failure mode.

Shielded mixing pools break the deposit-withdrawal link cryptographically. What survives are the metadata leaks: an anonymity set that's small at low volume, deposit and withdrawal timing, a withdrawal whose gas is paid from an address that also funded the deposit, and users who withdraw to an address already linked to them.

Cross-chain bridges and swap services don't break linkage cryptographically but do break it practically, because they move the trail to another chain with different tooling. Amount-and-timing correlation across the two chains often re-establishes it. Instant no-account swap services are the same problem with an added custodial hop that keeps its own logs.

Privacy coins are a hard stop, not a slowdown. Ring signatures, stealth addresses and confidential amounts mean there is no public sender, no public recipient and no public amount to follow. Say so plainly rather than implying you could have gone further. On chains with optional shielding, most activity is transparent, and the leaks are at the shielded/transparent boundary.

Taint analysis after any of these is a modelling choice, not a measurement. Poison, haircut, FIFO and last-in-first-out give materially different answers on the same data, and courts in some jurisdictions impose their own rule for mixed funds. Always state which model you used. "40% tainted" without a named model is meaningless.

Where this lies to you

• Address poisoning. Attackers send zero-value or dust transfers from addresses crafted to match the first and last characters of a legitimate counterparty. These appear in the victim's history and will pull a careless analyst onto a completely unrelated address. Compare full strings, always.
• Dusting. Unsolicited tiny amounts sent to many addresses, intended to be spent and thereby merge clusters. A received transfer proves nothing about the receiver's intent or relationships.
• Explorer labels are third-party claims. Public name tags, self-submitted contract verifications and community-sourced entity labels vary in quality and are sometimes simply wrong or stale. A label is a lead. Cite the labeller.
• Commercial attribution is unauditable. Chain-analytics vendors' entity labels derive from proprietary undisclosed methods and have been challenged in court. Never present a vendor label as ground truth; present it as that vendor's assessment.
• Contracts move value for people who never touched it. A DEX router, a multisig, a custodial wallet or an NFT marketplace shows up as a counterparty. It is infrastructure, not a suspect.
• Timestamps are block times. They approximate when the transaction was mined, not when the human acted, and they say nothing reliable about timezone.
• Same address, different chain, different person is possible — but the reverse is the practical risk: assuming the chains are unrelated when the key is the same.
• Chain reorganisations and unconfirmed transactions. Something you saw in the mempool may never confirm. Cite confirmed transactions with block heights.

Grading a finding

• Confirmed — on-chain facts: this transaction moved this amount from this address to that address in this block. These are cryptographically verifiable and you should say so without hedging. Also confirmed: an address published by the entity itself in a signed message or on a domain you've verified via recon-a-domain-passively.
• Probable — a cluster built on common-input ownership with no CoinJoin pattern present; a service identified by structural behaviour that matches multiple independent labels; an ENS name with matching forward and reverse records tied to a social profile.
• Unconfirmed — anything resting on change-address heuristics, a single commercial label, an unsigned claim of ownership, timing correlation alone, or a cluster spanning a mixing event.

Attribution to a named human is never confirmed on-chain evidence alone. It becomes confirmed when an off-chain record — a subpoena return, a court filing, a signed message, an entity's own disclosure — closes the gap.

Worked example

A victim reports paying an extortion demand to bc1q… and provides the transaction ID.

The explorer shows one input from the victim and two outputs: 0.4137 BTC to a fresh bc1q address and a smaller amount to another. Change heuristic says the unrounded larger output is the payment and the smaller is the victim's change — but the victim confirms the demanded amount was the smaller figure, so the heuristic was backwards here. Dead end avoided only because a human corroborated it; note that in the file.

Following the extortion output: within a day it merges with eleven other inputs into a single transaction. Common-input ownership means all twelve are one controller, and the equal-value structure that would indicate CoinJoin is absent. The consolidated output forwards to an address that receives from thousands of unrelated addresses and sweeps outward on a fixed schedule — an exchange hot-wallet structure. The address immediately before it, which received only from our cluster, is the deposit address.

Graded: transaction facts confirmed; the twelve-address cluster probable; the exchange identification probable, on structure plus two independent labels; the account holder's identity unknown and only obtainable by legal process. Reported that way, with the deposit address and timestamps flagged for the victim's counsel.

Pivots

Tools and explorers by chain, with what each is actually good for, are in the explorer and tooling catalogue.

Legal and compliance

Reading a public ledger is not regulated. Acting on it can be. Sanctions authorities publish specific digital-currency addresses on their designated persons lists — the US OFAC SDN list carries them as explicit address entries — and transacting with a designated address is a strict-liability matter in many jurisdictions. Check listings before you interact with anything, and never send a "test transaction" to a subject address: it is interaction, it marks you, and it may be a violation.

Naming a person as the owner of an address is a serious public accusation with defamation exposure, and the underlying inference is probabilistic. Bulk purchase or handling of leaked exchange customer data brings data-protection obligations regardless of how it reached you; see what-leaked-about-you. Where the objective is asset recovery or a criminal referral, preserve the chain of custody: record block heights, transaction IDs and capture timestamps, not screenshots of an explorer.