Tracing through exchanges and custodial services

Sooner or later, almost every trace reaches an exchange, broker, custodial wallet, payment processor or gambling site. That boundary is often where an investigation becomes winnable, because the service knows its customers, holds records and can freeze funds. It is also where on-chain tracing stops and where weak reports overreach. This lesson covers how services look on chain, how to evidence that funds entered one, what can be said about the inside, when to stop and request records, and how to resume from the withdrawal side.

How a custodial service looks on chain

Most centralized exchanges follow a similar architecture:

• Deposit addresses: each customer receives one or more addresses that belong to the exchange but are assigned to that customer's account; funds sent there are credited in the exchange's internal ledger.
• Sweeps: the exchange periodically moves funds from many deposit addresses into a central hot wallet: a large fan-in transaction in UTXO chains, or on Ethereum a series of transfers to the same destination, often after the exchange sends a little ETH for gas.
• Cold storage: most reserves move from the hot wallet into offline or multisig wallets, and back when needed.
• Withdrawals: paid from the hot wallet, frequently batched into one transaction with many outputs.

Some services use omnibus deposit addresses instead: one address receives funds for all customers, and the customer is identified by a tag or memo carried in the transaction, such as the destination tag on the XRP Ledger or the memo field on Stellar. The address then identifies only the service; the tag identifies the customer, and a deposit sent without it usually needs manual recovery by the service.

A fictional Ethereum sequence shows the deposit-and-sweep pattern:

block      from          to            amount (ETH)  note
21004112   0xF00d…11  →  0x7c3E…a2     2.5000        deposit from wallet under investigation
21004140   0x9aB4…07  →  0x7c3E…a2     0.7500        second sender, same deposit address
21004233   0x7c3E…a2  →  0xE1f9…44     3.2489        sweep to hot wallet (3.25 minus gas)
21004990   0xE1f9…44  →  0x51e0…3b     3.1000        withdrawal by some customer

The first three rows are strong evidence: 0x7c3E…a2 forwards everything to 0xE1f9…44, which is labeled as the exchange's hot wallet, so 0x7c3E…a2 is very likely a deposit address of that exchange, assigned to one account. Two different wallets paying into one deposit address also suggests both are connected to the same customer (Lesson 4.3). The fourth row cannot be linked to the deposit at all.

Not every service ends the trail, so sort them before you start:

The non-custodial rows are mechanisms rather than counterparties; tracing through them is covered in Module 5.

Evidencing the service boundary

The forensic question is narrow: on what basis do you say that an address is a deposit address of a particular service, and how strong is that basis? Using the grades from Lesson 3.2:

Record the attribution basis as its own entry, with its source and retrieval date, so the hop record can cite it (Lesson 4.6). Typically the flow into the address is grade A, while the claim that the address belongs to a service stays grade C until the service confirms it.

Inside the black box

Once funds are swept into pooled wallets, the customer's money becomes an entry in a private ledger. Inside it the customer can trade into other assets, transfer to another customer without any on-chain transaction, withdraw to a bank account, or withdraw crypto that came from somebody else's deposit. A later withdrawal is paid from whatever coins the hot wallet holds. Applying FIFO or haircut through a hot wallet produces numbers, but they describe the rule, not the service's books, so most examiners treat a labeled service as a stopping point and report "deposited to", not "passed through".

The left column is what a forensic report states. The right column needs records.

The boundary is not a dead end but a handover point. From the chain you can still establish which service received the funds and on what basis; the deposit address, which in most designs maps to one customer account (or the omnibus address plus tag); the exact deposits with txid, block height, UTC time, asset, amount, path, hop count and allocation method; and other deposits to the same address, which may reveal more of the subject's activity or other victims.

When to stop and request records

Stopping on-chain work at a service is a decision, and the case notes should record when and why it was taken. Stop and request records when:

1. the funds have entered a custodial service on a stated basis, ideally grade B or C;
2. further on-chain work could only produce inferences about the inside;
3. the funds may still be in the account, so delay costs recovery;
4. the request package is ready: deposit addresses or tags, txids with output or log references, amounts in base units, UTC times, the path, the method and the grades.

Who may obtain records, and how, depends on the jurisdiction. Generically, the request comes from a competent authority (police, prosecutor, financial intelligence unit or court) or from a victim through civil proceedings, and runs through these steps:

Preservation and freeze go first, because a balance in a hot wallet can leave within minutes; analysis continues in parallel. After the 2025 Bybit theft, for example, the FBI published dozens of addresses linked to the laundering and asked exchanges, bridges and other services to block transactions derived from them. Drafting the request is covered in Lesson 1.4. For tracing, ask for what you need to resume: the account's complete internal ledger for the period (deposits, trades and conversions, internal transfers, fiat and crypto withdrawals), and for every crypto withdrawal the asset, chain, amount, fee, destination address, txid and time with its time zone. Ask also for other deposit addresses assigned to the account, saved withdrawal addresses, and accounts linked by device, IP address or payment instrument, in machine-readable form. Keep the package short and precise: the recipient's compliance team will search by address and txid, not by narrative.

Withdrawal-side analysis

When records arrive, the trace resumes from the withdrawals. Continuing the case from Lesson 3.2: Exchange K reports that the 1.2 BTC deposit was credited, that the account also held other funds, and that it made these withdrawals:

Each reported withdrawal is checked against the chain before anything is built on it:

-- Check reported Bitcoin withdrawals against on-chain outputs
SELECT r.record_id, r.txid, r.dest_address,
       r.amount_sat                AS reported_sat,
       o.value                     AS onchain_sat,
       r.amount_sat - o.value      AS difference_sat,
       o.block_number, o.block_timestamp
FROM provider_withdrawals r
LEFT JOIN outputs o ON o.transaction_hash = r.txid
                   AND o.address = r.dest_address
WHERE r.chain = 'bitcoin'
ORDER BY r.requested_at;

provider_withdrawals is the service's export loaded as a case table; outputs follows the generic schema of Lessons 2.7 and 2.9. The left join keeps every record even when no matching output exists. Suppose W-1 returns an on-chain value of 49,990,000 satoshis: the difference of 10,000 satoshis matches the exchange's published withdrawal fee, so the record reports the amount before the fee. Suppose W-3 returns no output: the txid exists but pays a different address. That is a discrepancy to put back to the service, not to fix silently. W-2 is checked the same way against Tron token transfers. Authenticating provider records more fully is covered in Lesson 7.5.

Three points follow. First, a withdrawal confirmed by both record and chain is a grade B link between the account and the destination. Second, the conversion into USDT on Tron is visible only in the records: the trace changed asset and chain inside the black box. Third, the internal ledger is itself a mixed account. The 1.2 BTC was credited to an account holding other funds, so how much of each withdrawal is victim value is again an allocation question, computed over the ledger entries with a declared method (Lesson 3.3).

Timing and amount correlation

Without records, or while waiting for them, examiners often look for a withdrawal that resembles the deposit. This is an inference, grade D, and its value depends on how many alternatives exist. In this case the hot wallet made 212 withdrawals in the hour after the deposit, nine of them between 1.15 and 1.20 BTC. A candidate set of nine is a lead to prioritize, not a link.

Correlation also fails exactly when it matters. The records show withdrawals of 0.5 and 0.3 BTC and a conversion into a stablecoin withdrawn on another chain; an amount-and-time search for about 1.2 BTC would have pointed confidently at an unrelated customer. Use correlation to frame questions to the service ("please confirm the account behind deposit bc1q…dx7e and its withdrawals between 14:00 and 16:00 UTC"), and report it, if at all, with the size of the candidate set and the window used.

Nested services and payment processors

Not every custodial service is an exchange, and some need more than one request.

• Nested services: a broker, swap desk or smaller exchange that holds an account at a large exchange. Funds from the nested service's deposit address belong to its customers, so the large exchange's records return the intermediary, and a second request is needed, often in another jurisdiction.
• Payment processors: many generate a fresh address per invoice and sweep to their own wallets. Their records identify the merchant and the order; the merchant may hold the buyer's details, which means a second request.
• Custodial wallets, gambling sites and OTC desks: pooled like exchanges, with records that range from detailed to thin. A service without identity checks can still hold IP addresses, device data, email addresses and withdrawal destinations.

The 2016 hack of the Bitfinex exchange shows the handover at scale. According to the US Department of Justice, the attacker sent 119,754 BTC to a single wallet in more than 2,000 unauthorized transactions, and over about five years roughly 25,000 BTC left it through accounts opened under false identities at exchanges and darknet markets (accounts at the AlphaBay market served as a pass-through, deposit in and equivalent amounts out), conversions including into privacy coins, and mixing services. Each custodial service broke the on-chain trail and was also a source of records: funds followed into a service selling gift cards for cryptocurrency led, through records of where a card was redeemed, to the defendants, and a search warrant then produced the contents of a cloud storage account holding an encrypted file with the wallet's private keys (Lesson 7.5). Investigators decrypted the file on January 31, 2022, and between January 31 and February 1, 2022 used the keys to seize the wallet's remaining balance of approximately 94,636 BTC. On-chain tracing found the service endpoints; off-chain records closed the gaps.

For each service, document the boundary the same way: the basis for the service attribution, the exact deposits, the time-critical requests sent, and what the records later added. The trail is broken on chain, but not in the case file.

Exam focus: the on-chain architecture of a custodial exchange (deposit addresses, sweeps, hot and cold wallets, batched withdrawals) and omnibus addresses with tags or memos; which service types end on-chain tracing; grading the claim that an address is a service's deposit address; which statements about funds inside a service are and are not supported by on-chain data; criteria for stopping and requesting records, with preservation and freezing first; the ledger and withdrawal fields needed to resume a trace; checking reported withdrawals against the chain, including fee differences and discrepancies; the internal ledger as a mixed account; amount-and-time correlation as a grade D lead with a stated candidate set; nested services and payment processors needing a second request.