> For the complete documentation index, see [llms.txt](https://docs.intelligenceonchain.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.intelligenceonchain.com/technical-module-guidance/exchange-x-ray-user-guide.md).
# Exchange X-ray User Guide
*Following funds into an instant exchange and out the other side.*
**Module:** Exchange X-ray · **Cost:** 5 credits · **Tier:** Basic
***
## What this module does
Instant exchanges — ChangeNow, FixedFloat, eXch, SideShift, SimpleSwap and others — break the on-chain trail by design. Your subject sends funds into the service's hot wallet, and completely unrelated funds come out to their new address, often on a different chain. There is no on-chain link between the two legs.
Exchange X-ray reconstructs the *likely* pairing by matching the two legs on two things the service cannot hide:
* **Timestamp proximity** — the payout follows the deposit within a predictable window.
* **USD value** — the payout is worth roughly what went in, minus the service's fee and spread.
You supply the deposit leg. The module searches the service's known hot wallets across the supported (EVM only) chains, prices every candidate outflow in USD at the time it happened, and returns the outputs that fit your tolerances, ranked by match quality.
**This produces correlation, not proof.** How much weight it carries depends entirely on how busy the service was and how distinctive your amount is — which is exactly what the tolerance controls let you measure.
***
## When to use it
Reach for this when a trace stops at an address you've identified as an instant-exchange deposit address, and you need to pick the trail back up on the other side.
It is the wrong tool for a centralised exchange with accounts (Binance, Coinbase and so on). Those pool customer funds at a scale that makes value-and-time correlation meaningless, and the answer there isn't analysis — it's a request to the exchange.
***
## Before you start
You need three things:
1. **The deposit leg** — both the transaction hash of the payment from the 'Deposit Address' to the 'Hot Wallet', and the 'Deposit Address' itself.
2. **The date** it happened.
3. **Which service it was.** If you don't know yet, run Wallet Mentions on the deposit address first, or check it in Arkham. Guessing the entity wastes a run.
Have the deposited **amount and asset** to hand too. You'll need it to sanity-check the results, and knowing whether it was a round number (1.00 ETH) or an odd one (0.8347 ETH) tells you in advance how much this run is likely to be worth.
***
## The fields
| Field | What to put in it |
| --------------------- | -------------------------------------------------------------------------------------------------------- |
| **Transaction hash** | The hash from the deposit address into the services' hot wallet. |
| **Deposit address** | The services deposit address funds were sent to. |
| **Date** | When the deposit occurred. Anchors the search window. |
| **Entity** | Which instant exchange. Determines which hot wallets get searched. |
| **Time tolerance** | How long after the deposit to look for the payout. **Your main control.** |
| **Value tolerance %** | How far the payout's USD value may differ from the deposit's, to absorb fees, spread and price movement. |
| **Max tolerance** | The upper bound on how far the search will widen. Keeps a loose run from returning the world. |
> **Check the field labels in the panel before relying on this table.** These are documented from the module's registry definition; if the UI wording differs, the UI is authoritative. The exact behaviour of *Max tolerance* — whether it caps the widening or bounds a progressive search — is worth confirming on a test run against a case you already know the answer to.
***
## How to run it
### 1. Start tight
Set the time tolerance to the **narrowest plausible window** — a few minutes for most instant exchanges, since these services settle quickly. Set the value tolerance low, around a few percent, enough to cover the service fee.
Run it. If you get a small number of candidates, you're in a good position.
### 2. Widen only if you need to
Nothing back? Increase the time tolerance in steps and re-run. Widen **time before value** — time discriminates far more than value does on a busy service.
The reason to start tight and widen, rather than opening wide and filtering, is that it tells you *how hard you had to work* to find a match. A candidate found in a 90-second window is worth far more than the same candidate found in a six-hour one, and you only know which you have if you widened deliberately.
### 3. Stop when the result stops meaning anything
If a tight window still returns dozens of candidates, the service was too busy at that amount for correlation to be useful. **That is itself a finding.** Record it — "correlation not viable at this volume and amount" — and pursue another line rather than widening until something appears.
***
## Reading the results
You get the deposit transaction confirmed back to you, then candidate outputs ranked by match quality, each with an Arkham link for immediate follow-up.
Two things are marked for you:
* **Higher-value outputs are flagged.** An outflow noticeably larger than the deposit is a common laundering signature — funds consolidated with others before moving on — so these are worth a look even when they rank below a cleaner match.
* **Improbable candidates are styled distinctly**, so a weak match can't be mistaken for a strong one at a glance.
### Judging a match
Ask three questions:
**How busy was the service in that window?** One candidate in a tight window on a quiet service is close to a certainty. One candidate among forty is a coin flip with extra steps.
**How distinctive was the amount?** Odd amounts with several significant figures are strong. Round numbers are weak — many people send exactly 1 ETH, and the value leg contributes almost nothing.
**Does the destination make sense?** A payout to a fresh address that then behaves like your subject's other wallets corroborates the match. A payout to a known service hot wallet doesn't tell you much.
A match that survives all three is a solid lead. A match that survives only one is a hypothesis to keep on the list.
***
## Worked examples
**Strong case.** 3.7418 ETH into FixedFloat at 02:14 UTC. A 5-minute window returns two candidates; one is within 2% on value, the other is 40% off. The close match is a near-certainty — odd amount, quiet hour, tight window, single plausible fit.
**Weak case.** 1.00 ETH into ChangeNow at 18:00 UTC on a weekday. A 5-minute window returns eleven candidates within value tolerance. Round amount, peak hours, busy service. No amount of tuning fixes this — record the constraint and move on.
**Useful negative.** A deposit address returns no candidates at any tolerance. Check the entity is right and the date is right; if both hold, consider that funds may not have left on a supported chain, or the service may hold and batch payouts. Not every dead end is a failure of the tool.
### Example
**Blockchain:** Ethereum **Instant Exchange:** ChangeNOW **Transaction Hash:**
```
0x9c8de3462048cf8f6f8f2f3b2d28ec2c14d84a600033d08464ee3a46c0a720ac
```
**Deposit Address:**
```
0xB369a14348D3282e981EdF34699eA4454a6A6424
```
**Date:** 15th February 2024 at 12:05 UTC
**Output Address:**
```
0x5a3c0cD06Ea20FC7b42bcA4B2e7ff53488531DA4
```
***
## Chaining onward
The output is a new address, so the trace continues:
* **Wallet Mentions** on the payout address — has it been posted anywhere publicly?
* **Temporal Analysis** — does the operating pattern match your subject's other wallets? Independent corroboration of a value-and-time match is worth a lot.
* **Exchange X-ray again** if the funds hit a second swap service. Chains of two or three hops are common, and each hop compounds the uncertainty of the last — say so explicitly in your notes.
* **Multi-Wallet Researcher** if you now have several candidate addresses to triage at once.
***
## Troubleshooting
**Too many candidates.** Tolerance is too wide for the service's volume. Tighten time first. If a few minutes still returns dozens, correlation isn't viable here.
**No candidates at all.** Check the entity and the date first — a wrong entity searches the wrong hot wallets and returns nothing rather than an error. Then widen time in steps. If still nothing, the payout may have gone out on an unsupported chain.
**A candidate that looks right but ranks low.** Ranking combines time and value fit. A payout delayed by service processing can rank below a closer-in-time coincidence. Read the whole list, not just the top row.
**Results don't reproduce.** Values are priced in USD at the time of the transaction, so a re-run should be stable. If it isn't, note the timestamps of both runs and raise it.
***
## What to record
Whatever the outcome, write down: the deposit leg, the entity, the exact tolerances that produced your result, how many candidates came back at that setting, and why you accepted or rejected each one.
The tolerance settings are the whole argument. A match without the settings that found it is unreviewable, and a documented dead end saves the next person repeating your run.
***
## Limitations
* **Correlation, not proof.** The module reconstructs a plausible pairing. It does not establish that the two legs are the same funds.
* **Quality depends entirely on volume and distinctiveness.** The same tool is near-conclusive in one case and worthless in another, and the difference is the service and the amount, not the analysis.
* **Coverage is limited to supported services and chains.** A payout on an unsupported chain won't appear, and its absence isn't evidence it didn't happen.
* **Hot-wallet lists go stale.** Services rotate addresses. A recent deposit to a newly-rotated wallet may not be recognised.
* **It cannot name anyone.** It gives you an address. Attribution is a separate job — OSINT, or a request to whoever holds the account at the end of the trail.