Cross-chain bridges and swaps · Lesson 3 of 5
Swaps, DEXs and instant exchanges
8 min read
Almost every laundering trail changes asset somewhere, and the way it changes decides how strong the next link can be. A swap on a decentralized exchange is recorded in one transaction; a cross-chain swap protocol can write the destination into the source chain and the source into the destination chain; an instant-exchange service or an OTC desk leaves only a deposit on one side and a payout on the other. This lesson covers how to read each kind of swap as evidence, what records exist outside the chain, and what you may state about each link.
DEX swaps and aggregators in a trace
The mechanics of pools, routers and swap events are covered in the IDFE-BA lesson DEX swaps and liquidity flows. For a forensic trace, four points matter.
- The link is deterministic, the asset changes. Input and output appear as transfer events in the same transaction. Record both amounts, the effective rate and, if you need a fiat value, the price source and time. Whatever tracing method you apply (see the lesson Tracing methods and their consequences), the output of that swap is the proceeds of its input.
- The pool is not a counterparty. A liquidity pool is a contract holding many providers' funds. Funds do not "go to" the pool owner; follow the output, not the pool.
- The recipient may differ from the sender. Routers and aggregators accept a recipient parameter, so the output can be paid to a fresh address in the same transaction. Read the decoded call or the transfer events; never assume the caller received the output.
- Aggregators split routes. One aggregator call can touch several pools and intermediate tokens. Net the transfers per address across the whole transaction: what left the subject and what arrived at the recipient are the facts; the route between them is detail.
Adding stolen funds to a pool as liquidity and removing them later is a different pattern: the depositor receives an LP token or position, and the removal event returns the share. Follow the position, not the pool's balance.
DEX contracts have no operator who keeps records, but the interface a subject used may. Web front ends and aggregator APIs can log IP addresses, user agents and quote requests, and wallet applications may route swaps through their own APIs. Whether such logs exist, and for how long, depends on the operator.
Cross-chain swap protocols: memos as public evidence
Cross-chain swap protocols exchange native assets between chains through vaults that the protocol's nodes control. THORChain is the reference example, and its records are unusually useful because both sides carry text that names the other.
On the inbound side, the user sends the asset to the protocol's vault (on EVM chains through a router contract that records the memo in its deposit event; on Bitcoin, in an OP_RETURN output, which the protocol's documentation limits to 80 bytes). The swap memo format is SWAP:ASSET:DESTADDR/REFUNDADDR:LIMIT/INTERVAL/QUANTITY:AFFILIATE:FEE (the refund address is optional), usually shortened with = for a market swap, as the IDFE-BA lesson Cross-chain tracing shows. On the outbound side, the protocol's vault pays the destination asset in a transaction whose memo is OUT: followed by the inbound transaction hash. A failed swap is refunded with a REFUND: memo carrying the same hash. A fictional pair:
Ethereum (inbound, fictional)
tx 0x9a3f…c21e from 0x3f9c…a1d7 to swap router 130.0 ETH
deposit event memo "=:BTC.BTC:bc1q…r7w2::xx:20"
Bitcoin (outbound, fictional)
txid 6d0b…e45a from vault bc1q…v9tn
vout 0 5.16800000 BTC bc1q…r7w2
vout 1 OP_RETURN "OUT:9A3F…C21E"
The inbound memo names the Bitcoin recipient; the outbound memo names the Ethereum transaction. The pairing can therefore be verified on both chains from your own nodes, without trusting any API, and the protocol's public records (its node API and indexers) give a third, independent confirmation. Few cross-chain links are as strong.
Three details change how you read such swaps:
- Timing. Streaming swaps are executed as sub-swaps over several blocks, and limit swaps can wait in a queue for up to 43,200 protocol blocks (about three days) by default. Set time windows from the memo parameters, not from a fixed guess.
- Affiliates. The affiliate field names the interface or wallet that built the transaction, by a registered short name. That operator is a possible source of logs, even though the protocol itself has none.
- Memoless and reference memos. To work around tight memo space, the protocol lets a memo be registered in advance and then referenced, for example by an amount-encoded reference; registrations expire after a set number of blocks (the protocol's
MemolessTxnTTLparameter, by default 3,600 blocks, about six hours). Decoding such a swap needs the protocol state at the time, so preserve the registration record with the transactions.
Other cross-chain swap and intent-based protocols use different fields, but the method is the same: find what the source transaction says about the destination, and what the destination says about the source.
Instant-exchange services
Instant-exchange services convert one asset into another without an account: the user enters a payout address, receives a fresh deposit address for the order, sends funds, and is paid out, often on another chain. Many describe themselves as non-custodial because they keep no balances. They do control the funds between deposit and payout, which is why the on-chain trail breaks there, and exchanging one virtual asset for another for or on behalf of a customer is VASP activity under the FATF definition used in Recommendation 15, whatever the label.
On chain, an instant exchange looks like any custodial service: per-order deposit addresses, sweeps to a hot wallet, payouts from a hot wallet. Without records, the link between a deposit and a payout is an amount-and-time inference, built and tested as described in the lesson Chain-hopping as an obfuscation and laundering pattern. With records, it becomes a documented fact. Depending on its practices, a service may hold:
| Record | Evidential use |
|---|---|
| Order ID, creation time, assets and quoted rate | Ties a deposit address to one order |
| Deposit address and deposit txid | Confirms which deposit belongs to the order |
| Payout address and payout txid | Converts the inferred link into a recorded one |
| Refund address | Often a wallet the subject controls; links other orders |
| IP address, user agent, language settings | Leads for attribution (see module 5) |
| Email or contact given for support | Identifier for further legal process |
| Partner or affiliate ID | Identifies the wallet or website that sent the order |
| Risk flags, holds and screening results | Shows whether the service froze or questioned the order |
Ask for all orders sharing the same payout address, refund address or IP address in the period, not just the one you found: the order history often reveals the subject's other wallets. Read the response critically. IP addresses may belong to VPNs or hosting providers, and contact data is unverified. Many such services operate where cooperation is slow, so preservation requests go out as soon as the deposit is identified (see the lesson Working with service providers).
OTC desks
An OTC desk negotiates trades off chain, often over messaging applications, and settles on chain to and from its own addresses. The two legs of an OTC trade may sit on different chains, or one leg may be a bank transfer, so there is often no on-chain link at all between what the subject sent and what the subject received. The desk's records (customer due diligence, trade confirmations, settlement instructions, chat logs, bank details) are the only bridge. Brokers who trade through an account at a larger exchange add a layer: the exchange sees one customer, the broker, while the broker's clients are invisible to it. Nested services of this kind are covered in the lesson Other obfuscation techniques.
What you may state about each swap link
| Evidence available | Basis of the link | Wording in a report |
|---|---|---|
| Same-transaction DEX swap | Deterministic (grade A) | "In transaction T, X was exchanged for Y and paid to address B" |
| Cross-chain memo on both chains | Deterministic on both chains (grade A), also protocol-recorded | "The protocol paid Z to address B in respect of inbound transaction A" |
| Instant exchange, amount and time only | Inference (grade D) | "Consistent with", with candidate count and chance-match rate |
| Instant exchange with order record | Record-confirmed (grade B) | "According to the service's records, order N paid Z to address B" |
| OTC desk, no records | None | "The destination of these funds is not known" |
The grades are those of the illustrative scale in the lesson Tracing to an evidential standard. A record-confirmed link is only as reliable as the record: name the producer, the date received and the hash of the file as received.
Exam focus: DEX swaps as deterministic links that change the asset; pools as non-counterparties, recipient parameters and netting aggregator routes; interface and API operators as record holders; cross-chain swap memos, theOUT:andREFUND:outbound memos that carry the inbound hash, and verifying the pair on both chains; streaming and limit swap timing, affiliate fields and reference memos; instant-exchange services as VASPs under the FATF definition and the records they may hold; asking for linked orders; OTC desks as hops with no on-chain link; matching wording to the basis of each link.
Practice questions
Check your understanding. These questions do not count towards the exam.
Sign in to save your progress and continue where you left off. It is free. Sign in