Custodial mixers

A custodial mixer takes a customer's coins and later pays out other coins, so the on-chain link between deposit and payout simply does not exist. For an investigator this means two things: on the chain alone, the best you can produce is a candidate set built on stated assumptions; and when a mixer is taken down, its servers can turn those candidates into records. Knowing which of the two you are working with, and saying so, is the forensic skill this lesson builds.

How a custodial mixer works

The customer requests an order, receives a fresh deposit address, and names one or more payout addresses, a delay and sometimes a fee level. After the delay, the operator pays the deposit amount minus its fee from its reserve, which is made of earlier customers' coins. Wu and colleagues (Towards understanding and demystifying Bitcoin mixing services, 2021), who studied several services with their own test deposits, described two mechanisms:

Two features matter for evidence. Many services issue a letter of guarantee, a message signed by the service that names the deposit address and order terms; customers keep it to prove an order. Many also give repeat customers a code so they never receive their own coins back. Both are artifacts that can sit on a suspect's device or in a seized database, and both tie a person to an order in a way the chain never can (see the lesson Wallets on seized devices). Some services went further: the operator of Helix, which processed about 354,468 BTC from 2014 to 2017, built an interface that let darknet markets send customer withdrawals straight into the mixer.

The on-chain picture on each side

On the deposit side, the trail is deterministic up to the deposit address and usually one more hop, when the operator consolidates deposits into its own cluster. How that cluster was identified matters: a label from a test deposit you made yourself, a label from seized data, or a commercial label each carries a different reliability (see the lesson Attribution sources and their reliability). Record which.

On the withdrawal side, payouts leave the reserve along peel chains or in batches. The withdrawal shape can itself become evidence of origin. Zavřel and colleagues (Tumbling down the stairs: exploiting a tumbler's attempt to hide with ordinary-looking transactions using wallet fingerprinting, presented at DFRWS EU 2025 and published in Forensic Science International: Digital Investigation) built a wallet fingerprint for one tumbler from about 40 of its own transactions, using rare combinations of transaction version, replace-by-fee signaling and locktime that its software set seemingly at random. Following matching transactions forward and backward, they separated 344 service addresses from 461 customer addresses. They also warned that a fingerprint match is probabilistic and reported no validated error rate. A fingerprint can therefore attribute a payout to the mixer at grade C; it cannot tell you which customer the payout was for.

Once funds enter the mixer, treat the deposit as you would a deposit at an exchange: the chain ends at the service boundary (see the lesson Tracing through custodial services).

Timing and amount analysis

Without records, the examiner can only ask which payouts are consistent with a known deposit. The parameters are the deposit amount, the fee range the service advertised, the network fee and the maximum delay. The query below searches one window.

-- Candidate payouts for a 0.50000000 BTC deposit confirmed at block 850,100
WITH payouts AS (                      -- transactions that spend mixer-cluster coins
  SELECT DISTINCT i.spending_transaction_hash AS tx
  FROM inputs i
  JOIN mixer_cluster m ON m.address = i.address
)
SELECT o.transaction_hash, o.output_index, o.value_btc, t.block_number
FROM outputs o
JOIN payouts p      ON p.tx = o.transaction_hash
JOIN transactions t ON t.hash = o.transaction_hash
WHERE t.block_number BETWEEN 850100 AND 850244           -- delay up to 144 blocks
  AND o.value_btc BETWEEN 0.4748 AND 0.4950              -- fee 1-5%, network fee up to 0.0002
  AND o.address NOT IN (SELECT address FROM mixer_cluster)  -- exclude internal change
ORDER BY t.block_number;

The CTE finds transactions that spend coins from the mixer's cluster. The outer query keeps their outputs in the delay window whose value equals the deposit less a fee of 1–5% and less up to 0.0002 BTC of network fee (0.5 × 0.95 − 0.0002 = 0.4748; 0.5 × 0.99 = 0.4950), and drops outputs going back into the cluster. Every number in the WHERE clause is an assumption, and the result is only as good as the cluster.

The size of the candidate set is very sensitive to those assumptions. In test transactions published by Tippe and Deckers (Unmixing the mix: patterns and challenges in Bitcoin mixer investigations, DFRWS EU 2025, in the same journal), searching a 24-hour window for the exact deposit value less the mixer's fee left two candidate payouts, one of them the real payout. Searching across the advertised fee range produced 4,453 candidates, and an open range from zero up to that value 461,140. When the customer split the payout across two addresses, no single output matched the combined value. That is why the finding is the candidate set together with its parameters, never "the" payout.

A defensible record of such an analysis contains:

1. the deposit txid, amount and block;
2. how the mixer cluster was identified, and its snapshot date;
3. each parameter and where it came from (the service's advertised fees and delays, archived);
4. the number of candidates for each parameter set, run at least twice with different widths;
5. the grade: a timing-and-amount match is grade D, rising only with independent corroboration such as records (see the lesson Tracing to an evidential standard).

Seized servers as evidence

Takedowns change the picture because the operator's records hold the link the chain hides.

Tippe and Deckers, reviewing the ChipMixer, Helix and Bitcoin Fog cases, noted that in all three the operators were identified through off-chain information, not through blockchain tracing alone.

A seized database is powerful and dangerous. Before relying on it, the examiner checks:

• Provenance: the seizing authority's chain of custody and image hash values, and the channel through which the data arrived (see the lessons Legal authority and international cooperation and Hashing, logging and chain of custody).
• Schema and time: what each table and column means, the time zone of timestamps, test or cancelled orders.
• Completeness: retention or deletion windows; a service that promised to delete logs after a few days may hold only recent orders.
• Reconciliation: every recorded deposit should match an on-chain transaction to its deposit address, and every recorded payout an on-chain output. Report the match rate for the whole table, not a sample alone.
• Integrity: whether the operator could have altered records, and whether internal totals agree with reserve balances on chain.

A reconciled order, recorded so that a second examiner can repeat the check:

{
  "source": "seized_image_03/orders.db, image SHA-256 9c1e…44ab",
  "order_id": "A7F3…",
  "deposit": {"address": "bc1q…7k3f", "txid": "9b1e…47d0", "onchain_match": true},
  "payouts": [
    {"address": "bc1q…m2pz", "txid": "9b0d…e7a2", "onchain_match": true},
    {"address": "bc1q…r81d", "txid": "c4e1…0f9b", "onchain_match": true}
  ],
  "db_time": "2022-11-04T13:22:07", "db_timezone": "UTC+1 (from server config)",
  "block_time_utc": "2022-11-04T12:31:55Z",
  "grade": "B (record corroborated by chain)",
  "examiner": "EX-14", "verified_utc": "2026-10-20T09:12:00Z"
}

The record cites the database file and the hash of the image it came from, so the source is fixed. It states for each address whether the chain confirms the record, and it keeps the database time and its time zone apart from the block time. The raw gap of almost an hour disappears once the server's time zone is applied: the order was recorded about ten minutes before the deposit confirmed, as expected. Only after this check does the link from deposit to payouts rise from "no link" to grade B.

Limits of inference

Keep three limits in view. First, using a mixer is not in itself evidence of the source of funds; many users seek privacy for lawful reasons. Second, in chain terms a payout's "source" is other customers' deposits, so tainting every payout of a mixer, or every customer, attributes crime to people with no link to the case. Third, a seized record proves what the operator's system recorded, and a reconciled record proves value moved as recorded; neither proves who typed the order. That still needs account, device or network evidence.

Exam focus: swapping and obfuscating mixer mechanisms and their on-chain shapes; letters of guarantee and customer codes as artifacts that tie a person to an order; wallet fingerprinting of a mixer's withdrawals and its probabilistic nature; building a timing-and-amount candidate set from stated parameters and reporting its sensitivity (two candidates versus 461,140); Bestmixer, ChipMixer, Helix and Bitcoin Fog as context and the fact that operators were identified through off-chain information; validating a seized database (provenance, schema and time zone, completeness, full reconciliation, integrity); why tainting every mixer payout or user is unsupported.