Open-Source Chain Forensics

Wallet-Tracer

Trace where stolen crypto went, one wallet at a time — free, private, runs entirely on your own device.

Network map

Checking…
Or, on any device: export from BREAKPOINT, then import it here.
Getting started 30 seconds
  1. Pick a chain, paste the wallet address, choose a scan depth, click Investigate.
  2. Click any node in the network map to inspect it, classify it, or trace it further.
  3. Optional: connect a BREAKPOINT registry file — BREAKPOINT is a companion tool that stores hand-verified addresses for known exchanges, bridges, and mixers. Connect its export here and this map recognizes those addresses automatically instead of showing them unclassified.
  4. Click Save network when you're done — everything stays on your own device.
How to read what this tool tells you read me first

This tool surfaces patterns in public blockchain data. Patterns are leads, not verdicts. The points below were learned the hard way tracing a real theft — each one is a mistake that wastes days or, worse, puts a wrong name in a report. Read them before you trust a result.

1. An exchange wallet is a wall, not a hub — never read its depositors as victims.

When money reaches a centralized exchange (Bybit, Gate.io, Coinbase…), the on-chain trail ends. Thousands of unrelated people deposit into the same exchange wallet, so they all look like "sent money in, got nothing back" — the same shape as a victim. If you scan an exchange wallet expecting victims, you'll get hundreds of false ones. The tool now warns you when you start on a known exchange, but tagging isn't perfect: if a wallet has thousands of counterparties and heavy two-way flow, treat it as an exchange or service, not a scammer. To learn who's behind an exchange deposit, law enforcement must send the exchange a legal request — the blockchain can't tell you.

2. A busy hub is not a victim — check before you accuse.

A wallet that received a lot and also sent a lot onward, or that has hundreds or thousands of counterparties, is infrastructure — a mule, a mixer, a relay, or a service — not a person who lost money. A real victim usually deposits once or a few times and stops. A coincidental match on amount (someone who lost "about what you lost") means nothing until you confirm it's the same token and the wallet actually behaves like a victim. The victim census now filters these out automatically, but when you're clicking around manually, this is the easiest and most damaging mistake to make.

3. Start from the thief's wallet if you know it — not just your own.

Your own drained wallet mostly shows one thing: the path your money took out. The scammer's collection wallet shows the whole operation — every victim feeding in, the relays, and the exits toward exchanges. Scan the hub first, then follow the interesting wallets it reveals. Use your own wallet as a cross-check that the theft transaction connects where you expect.

4. The numbers are relative scale, not dollars.

Value figures shown here are unit-less and mix different tokens. A "bigger" number moved more of something, but it is not a dollar amount and not necessarily the token you care about. Always open the transaction on the block explorer (every address links out) to confirm which token, how much, and the real value before putting a figure in any report.

5. Verify every address independently before you act on it.

A category label here is the tool's guess from a pattern. Before you report, accuse, or file anything, open each key address at its public block explorer and confirm it with your own eyes. This is investigative assistance — it does not confirm guilt, freeze funds, or take any action for you, and it is not legal or financial advice.

6. Chain-of-custody tracing follows money. It will not find who's in charge of a contract — that takes a separate, deliberate step.

The instinct on a known phishing act is to trace the stolen funds and run Contract Intel on the deployer of the vault/drainer contract — and that's correct, but it's not the whole picture. Every contract sitting on an edge of that custody chain — every wallet the funds merely passed through, not just the original trap — can itself have an owner or admin, and ownership almost never shows up as a transaction. It's often set once at deployment, stored silently in the contract's internal state, with no transfer to see. Money-tracing will never surface it, no matter how thoroughly you scan — it's a fundamentally different question ("who controls this?") from the one transaction graphs answer ("where did the money go?"). Run Contract Intel on every contract-type node touching your custody chain, not only the one that looks like the obvious center of the case — a "boring" secondary contract can turn out to be the one with the real owner behind it.

7. A custody chain moves forward in time. A hop dated before the theft doesn't belong in it, no matter how real the transaction is.

A wallet can be a genuine, active part of a criminal operation's infrastructure and STILL be the wrong hop for one specific case — if the dated evidence you have for it predates the theft, it's necessarily some other batch of funds moving through the same pipeline, not this one. This tool's own amount-anchored tracing (the theft anchor's token/amount/date, set from the auto-trace panel) already filters this out automatically when following stolen value hop by hop. That protection does NOT extend to manual work — hand-picking an edge's sample transactions, building a report by inspecting raw data directly, or citing a "representative hash" for a busy pipeline. Every single date used as evidence for a specific theft must be individually checked against that theft's date before it goes in front of anyone else, especially in anything meant for a filing or referral.

Bulk Scan — transaction-history file (CSV/JSON) rarely needed

Flags wallets connected to anything already marked Suspected Scam in this network — mark a wallet Suspected Scam first, then bulk-scan its transaction history to find everything it touches.

Phishing Contract Registry — load a deployer's contracts rarely needed

Not every contract this wallet ever deployed is necessarily malicious — a shared deployer can serve both legitimate and scam contracts. Treat a match as "worth checking further," not automatic proof.

Contract Intel — read clues out of a contract's bytecode no source needed

Reads the raw bytecode — no verified source required. Surfaces hardcoded addresses (drain destinations, admin/fee wallets), the contract's functions, whether it's a CREATE2 factory (real operator sits one level up), and a code fingerprint so identical contracts cluster as one template. A hardcoded address is a lead — confirm the actual on-chain flow before relying on it.

Paste contract addresses (one per line), or leave blank to use the contracts already in your network / loaded deployer registry. Groups them by identical bytecode (same template = one toolkit) and reads each owner() — so a fleet controlled by one operator wallet stands out.

IC3 Complaint — what they'll ask, before you start read me first

ic3.gov (the FBI's Internet Crime Complaint Center) does not save your progress and has no file upload — the session can time out after a few minutes idle, and once you close the confirmation page you cannot reopen it. The single biggest tip from the DOJ's own filing guide: draft everything below in a separate document first, then paste it all into the form in one sitting. This tool's exports (census CSV, feeder CSV, exhibits) already have most of the numbers you'll need — pull from those rather than re-deriving anything by hand.

Before you open the form, have these ready:

Loading network…
Applies to both Exchange Deposit Feeders exports below. Blank = no filter.