Chainalysis, Elliptic, TRM Labs, and a handful of other blockchain analytics companies collectively process billions in contract revenue by turning the pseudonymous transaction graph of public blockchains into actionable identity data. Law enforcement, exchanges, and financial institutions pay for this capability. Understanding how it works is not just academically interesting — it directly explains why privacy at the protocol level matters.
The Common Input Ownership Heuristic
The most powerful analytical tool in blockchain tracing is also the simplest: if two addresses both appear as inputs to the same transaction, they are almost certainly controlled by the same person.
This follows from basic Bitcoin and Ethereum mechanics. To spend from two addresses simultaneously, you must sign with both keys. Only the person who controls both keys can create that transaction. When you pay for something that costs more than any single UTXO you hold, your wallet software combines multiple UTXOs from different addresses you control into a single transaction. This is a deliberate co-spending event that reveals ownership clustering to any observer.
Chainalysis applies this heuristic at scale — every transaction in the history of the chain, updated in near-real-time. The result is a massive graph where individual addresses are nodes and known co-spending relationships are edges. Clusters of addresses that have ever co-spent are merged into inferred "entities."
Change Output Detection
In Bitcoin-style UTXO chains, transactions almost always include a change output — when you send 0.5 BTC from a 1 BTC UTXO, the remaining 0.5 BTC (minus fee) returns to an address you control. Analytics software detects change outputs using several heuristics: the output with the "round number" amount is likely the payment, the other is likely change; the output that follows the same address type as the input is more likely change; an output to a fresh address not seen before is more likely change.
Each correctly identified change output adds another edge to the entity graph, linking the change address to the same entity as the input addresses. Over many transactions, this builds comprehensive entity maps even without the common input heuristic.
Dust Attacks
A dust attack is a deliberate technique used by analytics firms (and sometimes malicious actors) to map wallet clusters. The attacker sends tiny amounts — "dust" — of a token to thousands of addresses simultaneously. When wallet owners later spend funds from those addresses and accidentally co-spend the dust with other UTXOs, the common input heuristic links those addresses to the dust sender's target cluster.
The dust itself is worthless. Its purpose is entirely as a tracking mechanism: by seeding addresses with small amounts and waiting for them to be spent, the attacker maps ownership relationships that were not previously visible. Users who are aware of this attack can avoid it by never spending dust outputs — some wallets allow marking specific UTXOs as "frozen" so they are not included in future transactions.
Exchange Deposit Clustering
Centralized exchanges generate a specific and extremely useful clustering signal. When users deposit to Coinbase, each deposit goes to a unique deposit address — but all of those deposit addresses belong to Coinbase's known wallet infrastructure. Analytics firms maintain databases of known exchange deposit address ranges by monitoring exchange public addresses, on-chain patterns, and in some cases, direct data-sharing relationships with exchanges.
When an analytics firm sees funds flowing to a known exchange deposit address cluster, they flag that transaction as a deposit to that exchange. This labels the source address as having interacted with a KYC'd exchange. If the exchange cooperates with a legal request, the account holder's identity is retrieved. Combined with the entity clustering from earlier, this one exchange deposit can de-anonymize years of prior transaction history in a single step.
Chain Peeling Analysis
A common technique for moving large amounts while avoiding detection is "chain peeling" — sending funds in a long sequence of transactions through intermediate addresses, peeling off small amounts at each step. The naive assumption is that this breaks the trail. In practice, chain peeling produces a highly distinctive graph pattern: a linear chain of transactions with one large output and one small output at each step.
Analytics software recognizes this pattern automatically. The large output at each step is trivially identifiable as the "change" — the fund being moved — and the small outputs are the actual payments or deliberate obfuscation attempts. The entire chain is attributed to a single entity and flagged as a peeling behavior, which in many analytics frameworks increases the risk score assigned to the addresses involved.
Off-Chain Data Sources
The on-chain heuristics alone are powerful, but the real edge for analytics firms comes from correlating on-chain data with off-chain sources:
- KYC records from exchanges. Legal processes and voluntary data-sharing agreements give analytics firms direct access to real-world identity data for millions of addresses.
- IP addresses from node logs. When you broadcast a transaction from a full node, your IP address is visible to every node that receives it. Some analytics firms run large numbers of nodes specifically to collect this IP data. The IP can be correlated with ISP records to narrow down geographic and sometimes user-level identity.
- Social media disclosures. People openly share addresses for donations, payments, or proof of holdings. These voluntary disclosures anchor the graph at specific identities.
- Forum posts and public communications. Addresses mentioned in cryptocurrency forums, GitHub repositories, or support tickets are indexed and connected to usernames, which can often be further connected to real identities.
What ZK Privacy Actually Prevents
Zero-knowledge shielded transactions break all of the above heuristics simultaneously. The common input ownership heuristic requires seeing the inputs to a transaction — in a ZK shielded transfer, there are no visible input addresses. Change output detection requires seeing outputs — shielded outputs are cryptographic commitments with no amount or recipient address visible. Dust attacks require the dust to be spent in a later transaction that's visible — shielded spends don't expose which commitment they're spending.
The exchange deposit clustering problem remains at the entry and exit points of a shielded pool — when you deposit into or withdraw from a shielded pool, that transaction is visible. But the activity within the shielded layer is completely opaque. The longer funds stay in the shielded pool, and the more transactions they participate in while shielded, the more thoroughly the trail is broken — not by obfuscating a visible path, but by eliminating the visible path entirely.
This is the structural difference between mixing and native privacy: mixing tries to obscure a visible graph, while ZK shielding eliminates the graph in the first place.