Address Clustering, Mixing Detection, and Source of Funds: What CASPs Actually Need to Know

Every compliance officer at a CASP eventually hits the same question: "We screen against sanctions lists -- is that enough?" The honest answer is: it depends on what your business does, how much risk you're absorbing, and what your regulator expects to see during an inspection.

Blockchain analytics isn't one thing. It's a spectrum -- from simple list lookups to deep behavioral analysis that can identify mixing patterns and trace funds across dozens of hops. Most CASPs don't need the most expensive end of that spectrum. But most CASPs also need more than a simple address lookup.

This article explains each level, how the underlying techniques work, and provides a decision framework for choosing the right depth for your operation. If you've already read our breakdown of screening vs. risk scoring, this picks up where that left off.

What are the four levels of blockchain analytics depth?

Think of blockchain analytics as four distinct levels. Each builds on the previous one, adds capability, and adds cost.

Level 1: List-based screening

The simplest form. You take a blockchain address and check it against the sanctions and restrictive-measures lists that apply to your business -- for example EU and applicable national lists for EU CASPs, plus OFAC, UN, UK OFSI, or other lists where your legal footprint, banking partners, or policy require them. The answer is binary: the address is on the list set you screened, or it isn't.

This is what the Chainalysis free oracle does (covering US, EU, and UN sanctions lists). It's what most free-tier tools provide -- a binary yes/no against designated addresses. It catches the obvious cases -- sanctioned wallets that have been publicly designated. It misses everything else.

What it catches: Addresses directly designated by sanctions authorities in the list set you screen.
What it misses: Addresses one transaction away from a sanctioned wallet. Addresses used by the same entity but not yet designated. Funds that flowed through mixers or tumblers.

Level 2: One-hop tracing

Level 2 looks one step beyond the address itself. Did this address send funds to or receive funds from a sanctioned address? Has it interacted directly with a known darknet market deposit address? Is it a first-degree counterparty of a flagged entity?

This is where most risk scoring APIs start. You submit an address and get back a risk score that reflects its immediate transaction partners -- not just whether the address itself is on a list.

What it catches: Direct counterparties of sanctioned/flagged addresses. First-hop recipients of stolen funds. Addresses that deposited directly to known illicit services.
What it misses: Funds laundered through two or more intermediary wallets. Entity-level connections (multiple addresses likely controlled by the same wallet, service, or customer). Mixing and tumbling activity.

Level 3: Multi-hop clustering (entity identification)

Level 3 is where blockchain analytics gets genuinely sophisticated. Instead of looking at individual addresses, the system groups addresses into entities -- clusters of addresses that are likely controlled by the same wallet or organization. Then it traces the flow of funds across multiple transaction hops, through these entities.

This is the technology behind statements like "this address received 12% of its funds from wallets associated with a sanctioned entity, routed through 4 intermediary hops." It requires large-scale graph analysis and proprietary labeling databases.

What it catches: Funds laundered through intermediary wallets. Entity-level risk (the whole cluster, not just one address). Multi-step exposure to illicit sources.
What it misses: Sophisticated mixing protocols. Privacy coin transactions. Novel obfuscation techniques not yet in the vendor's detection models.

Level 4: Full behavioral analytics

The deepest level. On top of clustering and multi-hop tracing, Level 4 adds pattern detection: identifying CoinJoin transactions, detecting Tornado Cash deposits/withdrawals, flagging peel chains (a laundering technique where funds are sent in a sequence of decreasing-value transactions), and analyzing timing patterns that suggest automated laundering.

This is the enterprise tier used by large exchanges and institutional custodians. It requires real-time transaction monitoring, machine learning models, and massive labeled datasets.

What it catches: CoinJoin and mixing protocol usage. Peel chains and structuring patterns. Tornado-style protocol interactions. Unusual behavioral patterns suggesting automated laundering.
What it misses: Privacy coins (Monero, Zcash shielded pools). Zero-knowledge protocols where deposit-withdrawal linkage is deliberately hidden. Cross-chain bridges without a reliable public mapping.

How does address clustering work?

Address clustering is the foundation of Level 3+ analytics. It answers the question: "Which addresses are likely controlled by the same wallet, service, or entity?" The technique varies by blockchain architecture.

Bitcoin: The common-input-ownership heuristic

Bitcoin's UTXO model means that a single transaction can spend outputs from multiple addresses. The key insight, formalized by Meiklejohn et al. in 2013 and already noted as a privacy issue in the Bitcoin whitepaper, is this: if two addresses appear as inputs in the same standard transaction, they are usually controlled by the same spender, because every input has to be authorized. That is a strong heuristic, not proof of legal or beneficial ownership.

"all inputs to a transaction are controlled by the same user"

-- Meiklejohn et al., "A Fistful of Bitcoins: Characterizing Payments Among Men with No Names," 2013

This heuristic is powerful, but it has known limitations and false-positive modes:

• CoinJoin breaks it. CoinJoin transactions deliberately combine inputs from multiple unrelated users into a single transaction, making the common-input heuristic produce false clusters unless the CoinJoin is detected and excluded.
• PayJoin (P2EP) weakens it. The sender and recipient both contribute inputs, making the common-input heuristic unreliable for that payment.
• Custodial services complicate interpretation. An exchange's hot wallet may combine UTXOs attributable to many customers. The cluster may identify the custody platform, not the underlying beneficial owners.

Analytics vendors supplement the basic heuristic with additional signals: change address detection, timing analysis, address reuse patterns, public attribution, customer-reported addresses, deposit-address behavior, and proprietary research.

Ethereum: Account model differences

Ethereum doesn't have UTXOs. Each address is an account with state and a balance; externally owned accounts initiate transactions, and smart contracts can then update many token balances or emit many internal transfers. This means the common-input-ownership heuristic doesn't apply.

Instead, Ethereum clustering relies on:

• Deposit address patterns. Exchanges generate unique deposit addresses that funnel to a hot wallet. The deposit-to-hot-wallet flow identifies the exchange entity.
• Contract interaction patterns. Addresses that interact with the same smart contracts in similar patterns may be linked, but this is behavioral evidence rather than ownership proof.
• Gas payment analysis. If address A pays gas fees for address B's transactions (via a relayer or direct ETH transfer), they may be linked.
• ENS and on-chain identity. Ethereum Name Service registrations sometimes link multiple addresses to a single identity.

Ethereum clustering does not have the same native multi-input signal as Bitcoin clustering. The account model gives less structural ownership evidence to work with, so Ethereum-focused analytics depends more heavily on labels, contract-specific parsers, and behavioral patterns.

TRON and Solana

TRON uses an account model similar to Ethereum but with very different usage patterns. The network carries a large share of USDT transfer activity, and its resource model uses Bandwidth and Energy rather than Ethereum-style gas. TRON clustering focuses heavily on stablecoin flow patterns and resource-delegation relationships, but delegation is a linkage signal rather than proof of common ownership.

Solana has a unique architecture where a single transaction can include instructions interacting with many accounts. This creates richer graph data for analytics, but also more noise. Account co-appearance in one transaction is not ownership proof; useful attribution depends on program-specific parsers and labeled entities.

What's detectable in mixing detection — and what isn't?

Mixing services are designed to break the link between the source and destination of funds. For compliance teams, detecting mixing is important because FATF identifies anonymity-enhanced cryptocurrencies, mixers, and tumblers as reduced-transparency ML/TF risks, and EBA GL/2024/15 requires CASPs performing transfers to maintain adequate systems and controls for Union and national restrictive measures.

CoinJoin detection

CoinJoin transactions have a distinct on-chain signature: many inputs from different addresses, many outputs of equal (or near-equal) value. Tools like Wasabi Wallet and JoinMarket automate this process.

Detection is well-established for some standard implementations. Published studies have detected Wasabi and Samourai-era CoinJoin transactions with very high accuracy in defined block ranges. That does not make detection universal: implementations, wallet behavior, and vendor heuristics vary.

However, next-generation CoinJoin implementations (like WabiSabi in Wasabi Wallet 2.0) use variable-amount outputs, making detection harder. The arms race between mixing and detection is ongoing.

Tornado Cash and tornado-style protocols

Tornado Cash uses zero-knowledge proofs to break the on-chain link between depositor and withdrawer. Classic ETH pools used fixed denominations such as 0.1, 1, 10, or 100 ETH. Later, the user presents a zero-knowledge proof that they made a deposit -- without revealing which deposit was theirs -- and withdraws to a fresh address.

What's detectable: Deposits into and withdrawals from Tornado Cash contracts are visible on-chain, so analytics tools can flag interaction with those contracts. OFAC designated Tornado Cash in August 2022, but removed the economic sanctions against Tornado Cash on March 21, 2025. As of July 10, 2026, the old 2022 designation should not be treated as a current SDN match; list-screening logic still has to check current OFAC, EU, UN, UK, and applicable national lists.

What's not detectable: The link between a specific deposit and a specific withdrawal. That's the entire point of the protocol. If someone deposits 10 ETH, and later a different address withdraws 10 ETH, you know both addresses used Tornado Cash -- but you can't prove they belong to the same person.

Privacy coins: The screening wall

Monero uses ring signatures, stealth addresses, and RingCT to hide the apparent spender, recipient link, and transaction amount. Public on-chain analysis cannot produce deterministic source-of-funds tracing comparable to Bitcoin or Ethereum. Academic deanonymization attacks, including Möser et al., focused on weaknesses in earlier Monero protocol periods and do not amount to reliable current transaction tracing.

What regulators expect vs. what's technically possible

There's a gap between regulatory expectations and technical reality. Regulators may ask how you assess source of funds for higher-risk crypto activity. But for certain transaction patterns -- funds routed through zero-knowledge mixers, cross-chain bridges without public mapping, or privacy coins -- the specific source-to-destination link may not be observable on-chain.

The pragmatic approach: detect what you can, flag what you can't, and document your methodology. A risk assessment that says "we detect CoinJoin and Tornado-style interactions at the first-hop level, and flag them for enhanced due diligence" is defensible. A risk assessment that says "we trace all funds to their origin" is not.

How does source of funds tracing and exposure scoring work?

Source of funds (SoF) analysis answers the question: "What percentage of this address's funds came from risky sources?" The answer is expressed as an exposure breakdown -- a percentage-based risk profile.

{
  "address": "bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh",
  "risk_score": 72,
  "exposure": {
    "sanctioned_entity":     0.3,   // 0.3% from OFAC-listed addresses
    "darknet_market":        4.2,   // 4.2% from known DNM wallets
    "mixing_service":        12.8,  // 12.8% passed through a mixer
    "gambling":              8.1,   // 8.1% from gambling platforms
    "exchange_verified":     61.4,  // 61.4% from KYC'd exchanges
    "mining":                5.7,   // 5.7% from mining pools
    "unknown":               7.5    // 7.5% unattributable
  },
  "max_hops_analyzed": 10,
  "analysis_timestamp": "2026-03-13T14:22:00Z"
}

This is the kind of output you get from Level 3-4 analytics tools. The risk score (72 in this example) is a composite -- but the breakdown shows why. It's the difference between "this address is risky" and "this address is risky because 12.8% of its funds passed through a mixer and 4.2% trace to darknet markets."

Hop-counting vs. value-flow analysis

Two approaches to tracing, with very different results:

Hop-counting measures the number of transactions between your address and a known risky source. "This address is 3 hops from a sanctioned wallet." Simple to compute, easy to explain. But it generates false positives at scale: at higher hop depths, graph paths quickly reach high-degree services, exchanges, bridges, and old risk labels. Hop-counting alone can make indirect exposure look more meaningful than it is.

Value-flow analysis tracks the actual amount of funds that moved along each path. Instead of "3 hops from a sanctioned wallet," it says "0.003 BTC (0.3% of this address's balance) traces through 3 hops to a sanctioned wallet." This is more computationally expensive but produces far fewer false positives because it weights by actual value, not just graph distance.

What level do YOU need? Decision matrix by service type

The right analytics depth depends on your business model. A payment processor that only sends outbound transfers to verified recipients has very different risk exposure than an exchange that accepts anonymous crypto deposits.

A key factor: can your customers deposit arbitrary crypto from unknown sources? If yes, you need at least Level 2 with exposure scoring. If your service only handles outbound payments to KYC'd recipients, Level 1-2 may be sufficient -- combined with the restrictive-measures screening controls that apply to your legal footprint and risk profile.

Which tools match each analytics level?

Here's how the market maps to the four levels. Note that vendor capabilities overlap -- a Level 3 tool may have some Level 4 features, and vice versa. This is a general positioning based on primary use case and pricing tier.

Public pricing is limited and contract-specific. Treat these ranges as rough procurement bands, not quotes. Actual pricing depends on transaction volume, number of chains, and contract terms. See our full tool comparison for detailed pricing on each vendor.

How do you put together a practical compliance architecture?

For most small-to-mid-size CASPs, the practical approach is layered:

1. Layer 1 -- Restrictive-measures screening (baseline control): For EU CASPs performing crypto-asset transfers, screen against EU and applicable national restrictive measures. Add OFAC, UK, UN, and other lists where your legal footprint, bank partners, or written policy require them. Build or buy -- but do it with an audit trail.
2. Layer 2 -- Risk scoring on deposits (recommended for custodians and above): Check inbound deposits for one-hop exposure to flagged addresses. Flag deposits from addresses that recently interacted with known illicit services. Trigger enhanced due diligence (EDD) above a risk threshold.
3. Layer 3 -- Entity-level analysis (recommended for OTC and exchanges): Cluster analysis on large or suspicious deposits. Exposure scoring with multi-hop tracing. Periodic re-screening of existing customer wallets when new designations are published.

Each layer catches what the previous layer misses. And each layer creates records that demonstrate to regulators that your analytics are proportionate to your risk profile -- which is the core of the risk-based approach under FATF and EBA guidance.