Breadcrumbs: Intelligence Source Guide

Breadcrumbs is a free browser tool for building and sharing cryptoasset transaction graphs. Most analytics products hand you the vendor's picture of an entity; this hands you a canvas and lets you construct, annotate and export your own trace.

At a glance

Source	Breadcrumbs
Category	Cryptocurrency & Blockchain › Blockchain Analytics & Attribution
Homepage	https://www.breadcrumbs.app/
Machine interface	https://www.breadcrumbs.app/
Format	HTML
Access	Open — no account required
Disciplines	Cryptocurrency Intelligence
Mission domains	Financial Crime, Anti-Money Laundering

Free visual crypto tracing. — as catalogued in the platform’s own source registry.

Breadcrumbs is a web application for visual investigation of public blockchain transactions. The working unit is an investigation: a saved graph in which addresses are nodes and value transfers are edges, which the analyst builds up by starting from one or more known addresses and expanding outward through inbound and outbound flows. Expansion is filtered – by direction, by value, by date range, by asset – so that a large address with thousands of counterparties can be reduced to the movements that matter. Nodes can be annotated with notes and tags, grouped, hidden and laid out, and the resulting graph can be saved, revisited and shared. The application draws on public chain data for the networks it supports, principally the major account-based and UTXO ecosystems, and overlays an attribution layer of labels identifying known services – exchanges, custodians, mixers, protocols, payment processors and other recognisable entities – so that a counterparty is not merely a hexadecimal string. It has been widely adopted in open-source investigation training as the accessible entry point to on-chain tracing, because it requires no licence, no installation and no scripting, and because the artefact it produces is a document an investigator can reason about rather than a query result. Supported chains, tier limits and feature availability have changed as the product has developed, so check the current state in the application rather than relying on a description written at any particular time.

The distinction that matters is between an entity browser and an investigation tool, and Breadcrumbs is the second. An entity browser answers the question what does the vendor think this address is; an investigation tool answers the question what did the money do, and it records your reasoning about it in a form somebody else can follow. That difference has practical consequences. Because the graph is constructed by the analyst, every node in it is there for a reason the analyst can state, which is the opposite of the automatic multi-hop expansion that produces impressive and unusable pictures. Because the graph persists and is annotatable, it functions as a working case file rather than a screenshot, and the reasoning survives the session. Because it can be shared, it supports the actual workflow of most cryptoasset casework, which is collaborative and involves handing a trace to a lawyer, a regulator, a partner organisation or a victim's counsel who was not present when it was built. And because it is free, it puts basic tracing capability in the hands of the people who most often encounter these cases first – fraud caseworkers, small law enforcement units, journalists, victims' advocates – who otherwise have no route into the evidence at all. For CRYPTINT and AML work the honest positioning is that it is the best free instrument for constructing and communicating a trace, and that its attribution coverage is thinner than the commercial products it is often compared with.

Who publishes it, and why that matters

Breadcrumbs is an independently operated commercial product with a free tier, and the specifics of its ownership, funding and corporate structure are not documented anywhere that permits confident description here – so treat those specifics as unknown rather than assuming an answer. What can be reasoned about is the structural position, which is common to every freemium investigation tool and has predictable consequences. The free tier exists to acquire users and to demonstrate the paid product, which means the constraints you encounter are commercial decisions rather than technical limits, and they can change on any release. Attribution coverage is a cost centre: maintaining a label set requires continuous work, and a small independent operator will have a materially smaller and less current label corpus than a vendor selling to banks at institutional prices. Longevity is a real question for any product in this category, and the mitigation is straightforward: keep your own copy of everything. Export the graph, record the addresses and transaction hashes in your own case system, and treat the platform as a workspace rather than a repository. An investigation that exists only inside a third-party web application is an investigation you can lose without notice. None of this is a criticism of the product; it is the standard planning assumption for depending on a small vendor for anything that matters.

Provenance is the first question to ask of any dataset and the one most often skipped. Who collects it, what their incentive is, whether they publish a methodology, and whether they correct the record when they get something wrong all bear directly on how much weight a finding drawn from it can carry.

What a record actually contains

The fields you will be working with, what each one means, and whether it is something you can pivot on. Read the meanings carefully — more analysis is wrecked by misreading a field than by failing to find one, and a field that looks like an observation is often an inference.

Field	Type	What it means	Pivot value
address_node	string	An on-chain address rendered as a node in the graph, with its chain, balance and activity summary. The address string is the only fully verifiable element in the workspace and it is what every other object in the investigation ultimately hangs from.	Any block explorer, any other analytics tool, and the raw chain data, all of which should be used to confirm what the graph shows.
transaction_edge	string	A value transfer between two addresses, carrying amount, asset and timestamp, and resolvable to one or more transaction hashes. Edges are aggregated in the display where multiple transfers exist between the same pair, so a single thick line can represent hundreds of movements.	The individual transaction hashes, which are the citable evidence and must be extracted rather than left implicit in the picture.
attribution_label	string	The service or entity the tool associates with an address – exchange, mixer, protocol, payment processor. Coverage is strongest for well-known services and sparse elsewhere, and the label is an assertion whose basis is not exposed in the interface.	Open tag corpora, sanctions designations and the service's own published address disclosures, which is where verification happens.
entity_or_cluster	string	A grouping of addresses treated as one actor. Where present it collapses a service's many addresses into a single node, which is what makes a graph readable, and it imports whatever clustering assumptions the tool applies without stating them.	The constituent addresses, which should be inspected individually before a cluster carries any weight in a conclusion.
investigation	string	The saved graph itself, with its nodes, edges, layout, filters and annotations. This is the artefact of the work and the thing that distinguishes the tool from an explorer, and it should be exported rather than trusted to persist.	Your own case system, where the export and the underlying addresses should live independently of the vendor.
note_or_annotation	string	Analyst-written text attached to a node or an investigation. The most underused feature in the product and the one that determines whether the graph is comprehensible to anyone else in six months, including you.	The case file, into which annotations should be transcribed rather than left only in the tool.
expansion_filter	string	The constraints applied when expanding a node – direction, minimum value, date window, asset. These decisions determine everything the graph shows and nothing records them once the expansion is done, which makes the graph irreproducible unless you write them down.	None. Document the filter settings alongside the graph or the analysis cannot be repeated.
amount_and_asset	int	The value transferred and the token or coin it was denominated in. Fiat equivalents shown anywhere are computed at some exchange rate at some time, and the rate and time are usually not stated, so any monetary figure needs to be re-derived before it appears in a report.	Historical price data for the asset at the transaction timestamp, sourced and cited separately.
timestamp	timestamp	Block time for the transaction, which is chain-derived and reliable, subject to the ordinary variance between block time and the moment a transaction was actually broadcast. Time zone rendering in the interface is a display choice; record UTC.	Contemporaneous off-chain events, which is where a timestamp becomes analytically useful rather than merely accurate.
shared_link	string	A shareable reference to an investigation. Operationally valuable for collaboration and a disclosure surface in its own right, because a link that leaves your control is an investigation that has left your control.	None. Treat sharing as a deliberate decision with a named recipient, not as a convenience.
export	string	The extracted representation of the graph and its underlying data. This is the object that should end up in your case system, because it is the only version that remains yours regardless of what happens to the vendor or the account.	Your own storage, and any link-analysis system that can ingest addresses and relationships.

Coverage — and what is not in it

Chain coverage is centred on the major public networks and has expanded over the product's life, so the current list in the application is the authoritative answer and any figure quoted elsewhere is likely to be stale. Within a supported chain, transaction coverage is complete in the sense that it derives from the public ledger, and history reaches back as far as the chain does. Attribution coverage is the axis on which this source differs most from the expensive alternatives. Labels are good for the large, well-known services that everybody labels – major exchanges, prominent mixing services, widely used protocols and bridges – and thin for regional exchanges, newer services, small payment processors and anything outside the attention of the English-language crypto ecosystem. That skew matters for cases involving flows into markets in Asia, Africa, the Middle East and Latin America, where a counterparty that is a significant regulated venue locally may appear entirely unlabelled. Individual attribution is essentially absent, which is a virtue rather than a defect: the tool does not purport to name private persons and therefore does not tempt you into publishing an unverifiable identification. Update cadence for chain data is effectively continuous. Update cadence for the label corpus is unstated, which means a label may reflect an address's function from some time ago and there is no field telling you when it was last reviewed.

Known blind spots

Absence of evidence here is not evidence of absence. These are the conditions under which Breadcrumbs will not show you something that is nevertheless real:

• Attribution coverage is materially thinner than the institutional commercial products, and the gaps are concentrated in exactly the regional venues that matter most in cross-border fraud cases, so an unlabelled counterparty is often a real exchange rather than a private wallet.
• Clustering logic is not published, so where addresses are grouped you cannot see why, and a grouping that is wrong will distort every path through the graph without producing any visible error.
• Mixing services, coinjoin implementations and privacy protocols terminate a trace as a matter of design. What appears after them in a graph is inference, and the tool cannot tell you which output corresponds to which input.
• Cross-chain movement through bridges and swap services is not a continuous flow and cannot be treated as one. Where a graph appears to follow value onto another chain, that continuity is a reconstruction that requires independent confirmation.
• Internal transfers within an exchange are invisible. Value that reaches a custodial venue and moves between customers there leaves no on-chain record at all, so the graph ends at the venue whether or not the money did.
• Fiat values displayed in the interface are conversions at an unstated rate and time and should never be carried into a report without re-derivation from a cited price source at the transaction timestamp.
• Free tier constraints on expansion depth, node counts and features are commercial decisions that change without notice, so an analysis method that works today may be unavailable tomorrow, and any workflow built around a specific limit is fragile.
• The graph does not record how it was built. Filters, thresholds and expansion choices vanish once applied, which makes an unannotated investigation irreproducible even by the person who created it.
• There is no evidentiary framework – no methodology statement, no chain of custody, no versioning of labels – so nothing produced here stands on its own in a legal proceeding without being rebuilt on verifiable transaction records.

Write the blind spot into the product. A statement that something “was not observed in Breadcrumbs” is defensible; a statement that it “did not happen” is not, and the difference is what survives cross-examination.

Access, licensing and what you may do with it

Access model: Open — no account required

The tool runs in a browser and the free tier is genuinely usable rather than a demonstration, which is the reason it appears in so many investigation curricula. An account is required to save and share investigations, which is the whole point of the product, so anonymous use is possible but self-defeating. Paid tiers exist and their boundaries have moved; check current limits rather than planning around remembered ones. Programmatic access has been offered for attribution and address data under account terms, and where you need labels systematically that is the route to ask about rather than scraping the interface. The practical guidance for professional use is about exit rather than entry: export every investigation you care about, record addresses and transaction hashes in your own case system as you go rather than at the end, and never let the vendor's copy be the only copy. Use an account and an email address appropriate to the sensitivity of the work, and be deliberate about sharing links, because a shared investigation is a disclosure of your entire line of enquiry to whoever holds the link.

Licence

The transaction data underneath is public chain data that anyone may derive independently and that carries no licence restriction of its own. The application, the attribution labels and any exported representation of them are the vendor's product and are governed by its terms of service, which should be read before anything is redistributed, republished at scale or built into another product. Terms for freemium tools in this category commonly distinguish between individual investigative use, publication of specific findings, and systematic reuse, and the third is usually where permission is required. Attribution to the tool is the minimum courtesy when a graph appears in a published piece, and it is also good practice analytically, because it tells the reader what produced the picture. Separately, an investigation graph that names natural persons in its annotations – which is entirely possible, since you write the annotations – contains personal data that you control, and your own data protection obligations attach to it including when it is stored on a third-party service and when it is shared by link. Confirm the current terms directly; they are not stable across the life of a product like this.

Rate limits and fair use

Interactive use is bounded by tier limits rather than by request rates, and the meaningful constraints are on how far and how wide you may expand a graph. Those limits are less of a problem than they appear, because unbounded expansion is bad practice regardless of what the tool permits: a graph large enough to hit a free-tier ceiling is usually already too large to interpret. Treat the limit as a discipline. Automated collection against the web interface should be assumed to be outside the terms and will break in any case; where systematic access to attribution data is genuinely required, ask about the programmatic route. The throughput that actually matters in this work is not requests per second but verifications per hour, and that is human-paced: every attribution you intend to rely on needs an independent check, every transaction you intend to cite needs confirmation against the chain, and no amount of interface speed changes that. Plan casework around the verification budget rather than around the tool's limits and the limits will rarely be the binding constraint.

Licensing changes, and it changes without warning. A dataset that was free for research this year may not be free for commercial or evidential use next year. Confirm the current terms before you build a dependency on it, and record the terms you relied on alongside the data — the licence in force at the time of collection is part of the provenance.

Collecting it

How Breadcrumbs is actually pulled, in the order you would set it up. Prefer the bulk or export interface over per-item lookups wherever one exists: it is kinder to the publisher, faster for you, and gives a reproducible snapshot rather than a series of point-in-time answers you cannot reconstruct later.

Method	Format	Cadence	Notes
Seeded investigation build	HTML	Per case	Start from verified addresses supplied by a victim, a court document, a designation or a report, and expand outward under explicit filters. The seed must be independently verified before anything is built on it.
Filtered expansion with recorded parameters	HTML	Per expansion step	Expand by direction, value threshold and date window, and write the parameters into the investigation notes as you go. Unrecorded filters are the reason most graphs cannot be reproduced.
Transaction hash extraction	CSV	Per finding	Pull the specific hashes behind every edge you intend to rely on and store them in the case system. The graph is a working aid; the hashes are the evidence.
Investigation export	CSV	At every meaningful milestone	Export the graph and its underlying address and transaction lists to your own storage. Anything held only in a third-party workspace is at risk from account changes, tier changes and vendor changes.
Attribution cross-check	JSON	Before any conclusion	Take the labelled addresses to an open tag corpus, a sanctions list and a second analytics tool. Disagreement between tools is common, informative, and invisible from inside any one of them.
Deliberate sharing	HTML	As required	Share the investigation with named recipients when handing work to counsel, a regulator or a partner. Record who received what and when, and revoke when the engagement ends.

Ingesting it into the platform

Every step below is idempotent and cursor-based: interrupt one and it resumes from where it stopped rather than duplicating rows or losing progress. Collection is recorded per source, so a feed that quietly stops publishing shows up as a stale timestamp instead of silently thinning your coverage.

1. Register it as a workspace, not a feed — sources.php records the tool as an analyst workspace whose outputs enter the platform as exports rather than as collected records. This keeps the distinction between what was traced and what was observed visible in the audit trail.
2. Ingest addresses and hashes, not pictures — import.php takes the exported address and transaction lists and creates records keyed on the address and the hash. A graph image attached to a case is documentation; the structured export is the data, and only the latter can be queried or corroborated.
3. Verify every hash against chain data on ingest — enrich.php confirms each transaction exists on the stated chain with the stated amount and timestamp before it is accepted. This catches transcription errors, chain confusion and any rendering artefact, and it costs nothing.
4. Store labels as dated third-party assertions — Attribution labels are attached to addresses as claims with the source and observation date, never as entity properties. Because the tool does not date its own labels, the ingest date is the only temporal anchor available and it must be recorded.
5. Screen addresses against designations before anything else — resolve-tags.php checks every ingested address against published sanctions designations. A designation is a legal fact carrying immediate obligations and it takes precedence over any commercial label in triage.
6. Rebuild the relationship graph inside the platform — link-analysis.php reconstructs the address relationships from the verified transaction records, so the platform's graph rests on confirmed hashes rather than on an imported picture. The two should agree; where they do not, the discrepancy is the finding.
7. Carry the analyst's annotations across — Notes written in the investigation are transferred into cases.php with their authorship and date. The reasoning is the most valuable thing the tool produces and it is also the thing most often left behind in the vendor's workspace.
8. Surface the trace where the case lives — Verified addresses and relationships appear on blockchain.php and against the case in cases.php, so that the on-chain work sits alongside the victim statements, the correspondence and the legal steps rather than in a separate tool.

Registered sources and their last-collected state are listed in sources.php, and the scheduled chain that keeps them current is in automation.php.

How it is wrong, and how to tell

Every dataset is wrong in characteristic ways. Knowing which ways is the difference between using a source and being used by one, and it is the part of source evaluation most often skipped because it is the part that takes work.

The chain-derived layer is as good as the ledger it comes from, which is to say correct and independently checkable, and in practice discrepancies between what this tool shows and what a block explorer shows are rare and are display artefacts rather than data errors. The attribution layer is thinner than the commercial alternatives and should be judged on that basis: where a label exists for a major service it is usually right and usually confirmable from the service's own disclosures, and where no label exists the correct inference is that the tool has no information, not that the address is a private wallet. That distinction is the most consequential quality judgement a user makes with this source. The aggregation layer – how edges are combined, how nodes are clustered, what a thick line represents – is where interpretation errors originate, because the display simplifies in ways that are invisible and unstated. And the reproducibility layer is weak by construction: two analysts starting from the same seed with different filter choices will produce different graphs, both correct, and neither will record the choices that produced it. The overall assessment is a reliable data layer, a modest but honest attribution layer that does not overclaim, and a presentation layer that requires discipline from the user to keep interpretable.

Characteristic false positives

• Reading an unlabelled address as a personal wallet. Absence of a label means absence of information, and in cases involving non-Western venues the unlabelled node is frequently a substantial regulated exchange.
• Treating an aggregated edge as a single transaction. A thick line between two nodes may represent one movement or a thousand, over years, and reasoning about it as a payment produces conclusions that the underlying hashes contradict.
• Following the trace through a mixer. The graph will continue to render nodes after a mixing service; the linkage between specific inputs and outputs is not observable, and continuing the narrative across that boundary is the most common serious error in visual tracing.
• Assuming bridge continuity. Value entering a bridge and value leaving on another chain are separate events that may or may not correspond, and the graph's line between them is a hypothesis rendered as a fact.
• Carrying fiat figures out of the interface. Displayed conversions use an unstated rate at an unstated time, and a monetary total assembled from them will be wrong by an amount that varies with market volatility over the period of the trace.
• Confusing chains. Address formats overlap across compatible networks, and a trace that mixes activity from two chains produces a subject with a history that never existed on either.
• Believing the layout. Node position, cluster proximity and visual centrality are rendering outputs with no analytical meaning, and readers of a graph consistently interpret them as significance. Central does not mean important.
• Losing the reasoning. An investigation without annotations is a set of nodes whose presence nobody can justify, including the analyst who added them, and it will be indefensible the first time anyone asks why a particular address is in the picture.

None of these make the source unusable. They make it a source that requires corroboration before an assertion built on it goes into a product, which is true of every source and admitted by few.

Ageing

Everything chain-derived is permanent and does not age: a transaction that occurred is a fact forever, and an exported hash list will be as valid in a decade as it is today. Two other things age quickly. Labels age because addresses change function – services rotate hot wallets, protocols redeploy, custodians migrate – and because the tool does not expose when a label was last reviewed, so there is no way to tell a current label from a legacy one. The practical consequence is that an attribution applied to a transaction from several years ago may reflect the address's role today rather than its role then, which is an easy and serious error in historical tracing. And the investigation itself ages, in the sense that a graph built at a point in time shows the flows that had occurred by then; addresses continue to transact, and a stale graph presented in the present tense asserts a state of affairs that has moved on. The characteristic stale artefact is a shared investigation link circulated months after it was built, read by a recipient who assumes it is current. The defence is dating: every export, every screenshot and every shared link should carry the date the graph was constructed, stated on the artefact rather than in the covering email.

What this source feeds

A source is only worth what it lets you conclude. These are the disciplines that collect through it, the mission domains it serves and the data points it yields — every one is a tag, so you can follow any thread from here into the rest of the library.

Collected by these intelligence disciplines

• Cryptocurrency Intelligence

Serves these mission domains

• Financial Crime
• Anti-Money Laundering

Yields these data points

• Cryptocurrency Address

How each sector uses Breadcrumbs

The same dataset is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The records are shared — the constraints, thresholds and outputs are not.

🎖 Military and defence

Applicability is narrow but real, in threat finance and in support to sanctions implementation. Where a unit or a staff has a set of addresses from reporting or from a partner and needs to understand quickly whether the value moved to regulated venues, to bridges, or to services designed to break the trail, a free browser tool with an exportable graph is proportionate and sufficient. It is also usable in coalition and partner settings where a commercial licence cannot be extended and where classification would otherwise impede sharing, since everything involved is public ledger data. The constraints are the obvious ones: nothing produced here is an attribution, the label set is thinner than institutional products, and any finding that would inform a nomination or an enforcement action must be rebuilt on verified transaction records with a defensible methodology behind it.

🕵 National intelligence

The value for CRYPTINT is the working artefact rather than the data. Analysts need to hand a trace to a colleague, to a partner service, or into a written product, and a graph with annotations explaining why each node is present is a far better vehicle than a list of addresses or a screenshot of somebody else's entity page. Because the tool does not attempt individual attribution, it also keeps the analysis honestly bounded at the level the chain actually supports – flows between addresses and services – which is where careful on-chain work should stay in the absence of collection from elsewhere. Use it to structure and communicate, cross-check its labels against provenance-bearing sources, and remember that the investigation is stored on a third-party service in a jurisdiction, which is a counterintelligence consideration before it is an analytical one.

👮 Law enforcement

For units without a commercial licence – which is most units outside specialised cybercrime teams – this is a realistic route into cryptoasset tracing, and its primary output is the identification of the regulated venue that received the funds. That identification is what converts a case from analysis into action, because it is the target of a preservation request or a production order, and speed matters enormously since exchange records and balances do not wait. Build the graph, extract the hashes, verify them against the chain, and act. What must not happen is that the graph itself becomes the evidence: there is no methodology statement, no chain of custody and no versioning behind it. Rebuild the evidential account on transaction records obtained and verified properly, and use the graph as the investigative aid and the briefing document it is designed to be.

🔍 Private investigation and corporate security

For fraud recovery work this is the practical tool, because it is free, it produces a client-comprehensible artefact, and it supports the actual deliverable, which is a document explaining where the money went that a lawyer can act on. Manage the client expectation from the first meeting: the realistic result is the identification of an exchange and a referral into a legal process, not a name, and the graph should be presented in a way that makes that boundary visible rather than implying that identification is one more hop away. Two operational disciplines: annotate as you build, because a graph you cannot explain is worse than no graph in front of a client; and export everything, because you may need the trace long after the engagement, the account or the vendor has changed.

📰 Journalism and OSINT media

Reporting on crypto flows needs a picture, and this produces one you built and can defend rather than one a vendor produced and you cannot. That is a meaningful editorial difference: you can state in the piece which addresses are in the graph and why, cite the transaction hashes so readers can verify, and describe your expansion criteria. The usual cautions apply with force. Do not carry the tool's fiat conversions into copy; re-derive from a cited price source. Do not follow the narrative through a mixer or across a bridge as though the linkage were observed. Do not treat an unlabelled address as a private individual's wallet. And where a graph appears in a published piece, date it and say what filters produced it, because a graph without its construction method is an illustration rather than evidence.

🌍 NGO, humanitarian and human rights

Victim-facing organisations dealing with investment fraud, romance-investment schemes and extortion payments use this to answer the first question a victim asks, which is where did my money go. The honest answer is usually that it reached an exchange and that recovery depends on how quickly a legal or regulatory process can reach that exchange, and being able to show the victim a clear picture of that with the destination named is both more useful and more respectful than a technical summary. The referral pathway is the point of the exercise: the national reporting route, the police cybercrime unit, the financial regulator, the exchange's own compliance channel. Keep the victim's personal information out of the tool entirely – you are tracing addresses, not people – and remember that a shared investigation link discloses the case to anyone who obtains it.

🎓 University and research

For teaching, this is close to ideal: free, browser-based, immediately comprehensible, and structured so that students learn the actual reasoning of a trace rather than a query language. It makes the pedagogically important errors visible – unbounded expansion, mixers, aggregation, unlabelled nodes – in a way that a scripted approach hides. For research it is a poor instrument and should not be the basis of quantitative claims: attribution provenance is undisclosed, labels are undated, clustering is unpublished, the corpus is not enumerable and the terms constrain systematic collection. Studies of flows should derive the network from chain data directly and attribute using open corpora that publish their sources, with this tool cited only where a specific well-attested service is involved. Its own design is also a legitimate research subject in work on how visual analytics shape investigative conclusions.

Playbook: working Breadcrumbs end to end

A repeatable sequence from first pull to finished product. Each phase states what you are trying to establish, not merely what to click — the objective is a defensible chain of reasoning, not a completed checklist.

Phase 1 — Verify the seed before you build anything

Confirm the starting addresses independently – from the victim's own transaction records, an exchange statement, a court document or a published designation – and check each one exists on the chain you think it does. A graph built from a seed supplied second-hand and never verified is an elaborate way of being wrong, and this happens more often than anyone admits.

Phase 2 — State the question the graph is meant to answer

Write it down before expanding: where did the proceeds of this transaction go, which venues received value from this address, what happened in the seventy-two hours after the theft. A graph built without a question grows until it is unreadable. A graph built to answer one stops when the question is answered.

Phase 3 — Set expansion parameters and record them

Decide the value threshold, the date window, the direction and the hop limit before the first expansion, and write them into the investigation notes. These choices determine everything the graph contains and the tool does not remember them, so an unrecorded parameter set makes the analysis irreproducible by anyone including you.

Phase 4 — Expand in one direction at a time

Trace outbound flows to answer where the money went, or inbound flows to answer where it came from, but not both simultaneously. Bidirectional expansion doubles the node count each hop and produces a graph in which the two questions are visually indistinguishable, which is how traces become uninterpretable by the third hop.

Phase 5 — Classify each counterparty before expanding it

For every node you reach, establish whether it is an exchange, a bridge, a mixing service, a protocol contract or unknown. That classification determines whether expansion is meaningful: expanding into an exchange's hot wallet produces thousands of unrelated counterparties and tells you nothing, and it is the single most common way a useful graph becomes garbage.

Phase 6 — Stop at the service boundary and say so

When value reaches a custodial venue, the on-chain trace has ended, whatever the graph continues to render. Mark that node clearly as the boundary. Everything past it is either internal to the venue and invisible, or is the venue's own operational movement and has nothing to do with your subject.

Phase 7 — Annotate every node as you add it

Write one sentence per node explaining why it is in the graph and what you concluded about it. This feels like overhead and it is the difference between an artefact that persuades a lawyer and a picture that impresses nobody. Do it during construction; nobody has ever successfully annotated a finished graph.

Phase 8 — Extract and verify the transaction hashes

Pull the hashes underlying every edge that carries weight in your conclusion and confirm each against a block explorer or a node – amount, timestamp, direction, chain. This is the step that turns a visual trace into evidence, and it is the step most often skipped because the picture already looks convincing.

Phase 9 — Cross-check the attributions

Take every label you rely on to an open tag corpus, to sanctions designations, and to a second analytics tool if you have one. Agreement strengthens the finding, conflict is a stop condition, and absence is the normal state. Record which you found, because a reader will ask what the label rests on.

Phase 10 — Re-derive any monetary figures

Do not use interface fiat conversions in a report. Take the asset amount and the transaction timestamp to a cited historical price source and compute the value yourself, stating the source and the convention. Totals assembled from unstated conversions are the easiest thing in a crypto report for an opponent to discredit.

Phase 11 — Export everything and store it in your own system

Export the graph, the address list and the hash list to your own case storage with the date. The vendor's copy is a workspace, not a repository. Accounts lapse, tiers change and products end, and an investigation that exists only inside a web application is one email away from being unrecoverable.

Phase 12 — Convert the finding into an action with a deadline

Identify the venue, decide who must be contacted – the exchange's compliance channel, the police unit, the regulator, counsel – and do it immediately, because balances move and record retention is finite. Then decide what would change your assessment and monitor only that. Analysis that does not convert into a request is a cost with no recovery attached.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

What to pair it with

No single source carries a finding. These are the datasets that corroborate, extend or contradict this one — and a source that contradicts is worth more than one that agrees, because it is the only thing that will tell you when you are wrong.

Source	Relationship	What it adds
Arkham Intelligence	corroborates	Entity-centric attribution across many chains, useful as a second opinion on labels and as a fast orientation layer. Its attributions are less transparent, so disagreement between the two is informative rather than decisive.
GraphSense TagPacks	corroborates	Open, provenance-bearing attribution tags in a documented schema. The right cross-check for any label you intend to rely on, because every tag carries an explicit source.
OFAC sanctions lists	prerequisite	Published designations including cryptoasset addresses. The only attribution in this ecosystem that carries legal weight and the first check on any address in a trace.
Block explorers	prerequisite	Independent confirmation of every transaction, balance and timestamp in the graph. Verification here is what converts a visual trace into something citable.
mempool.space	prerequisite	Bitcoin-specific verification including fee and confirmation behaviour, which occasionally matters for establishing the urgency or sophistication behind a movement.
Commercial analytics platforms	supersedes	Where a case must survive legal challenge, a vendor with documented methodology, versioned attributions and expert testimony is a requirement rather than an upgrade.
Internet Crime Complaint Center	extends	The reporting pathway for cryptoasset fraud victims in the United States, and the kind of referral route that a completed trace should feed into rather than substitute for.
Europol	extends	Published typologies of organised crime use of cryptoassets, which supply the behavioural context that turns a flow pattern into an assessment.

Legal, ethical and operational constraints

Using the tool is governed by its terms of service, which should be checked before any systematic reuse, redistribution or incorporation of its outputs into a product. The more significant legal considerations concern what you do with a trace. A graph that connects addresses to named individuals – through your own annotations, if not through the tool's labels – is personal data under your control, and data protection obligations follow it including when it is stored on a third-party service and when it is shared by link, which is a form of disclosure. Where the work supports a legal process, be clear that the graph is investigative material rather than evidence: it has no methodology statement, no chain of custody and no versioned attribution, and any evidential account should be rebuilt on verified transaction records with the verification documented. Where the work concerns a victim, keep their personal information out of the platform entirely; you are tracing addresses and there is never a need to enter a person's identity. And where a trace supports a public allegation, the ordinary defamation analysis applies with a domain-specific aggravation, which is that a wrong identification in this field can expose the person named to targeted theft or violence.

Operational security

Every address you enter tells the operator what you are investigating, and a saved investigation is a durable record of your entire line of enquiry held by a third party. That is a materially larger exposure than a series of block explorer lookups, and it is the price of the workspace. For sensitive matters, use an account and email address that do not identify your organisation, and consider whether the case belongs in a hosted tool at all. Shared links are the highest-risk feature: a link that circulates beyond its intended recipient discloses your seeds, your hypotheses and your annotations to whoever holds it, and the recipients of investigative material are not always careful. Share deliberately, to named people, and revoke when the engagement ends. The subject-facing exposure is different and is common to all on-chain work: read-only analysis is invisible to the person you are investigating, but any interaction with the chain – a test transfer, a dust payment, a contract call – is a permanent public record that a subject monitoring their own addresses will see, and sophisticated subjects do monitor. Keep the work read-only unless there is a specific, authorised reason not to.

Two rules that hold regardless of jurisdiction. Collection that is lawful is not automatically proportionate, and a dataset assembled for one purpose does not carry consent for another. Where the records concern identifiable people, the question is not only whether you may hold the data but whether holding it serves the purpose you are accountable for.

Is it earning its place?

Sources accumulate. Feeds get added during an incident and are never reviewed again, and a decade later the pipeline is carrying dead weight that nobody dares remove. These are the measures that show whether Breadcrumbs is contributing anything, and they are worth baselining now so the answer is available later.

• Proportion of investigations in which the receiving regulated venue was identified, which is the outcome that determines whether any recovery or enforcement route exists.
• Median elapsed time from case intake to the first preservation request or referral, because in cryptoasset cases the value of a trace decays with the balance it is chasing.
• Share of graph nodes carrying an analyst annotation, as a direct measure of whether the artefact will be comprehensible to anyone else.
• Proportion of relied-upon edges whose transaction hashes were independently verified against chain data, which should be complete and rarely is.
• Rate of label disagreement found when attributions are cross-checked against open tag corpora and a second tool, tracked as a running calibration of how much the labels are worth.
• Number of investigations exported to internal storage versus investigations existing only in the vendor's workspace, which is a plain measure of institutional risk.
• Count of monetary figures in finished products traceable to a cited historical price source, since unattributed fiat conversions are the easiest error for an opponent to exploit.

Beware of volume. Indicator counts rise easily and say almost nothing. Unique contribution — findings this source produced that no other source in your stack would have — is the measure that matters, and it is usually far lower than anyone expects.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

• Build to answer a question and stop when it is answered. The temptation with an expandable graph is to keep expanding, and every hop past the question adds nodes that nobody can justify and that dilute the ones that matter.
• Classify before you expand. Knowing whether the next node is an exchange, a bridge, a mixer or unknown determines whether expanding it is informative or catastrophic, and expanding an exchange hot wallet is how a good trace turns into an unusable one.
• The service boundary is the finding. When value reaches a custodial venue the on-chain story ends there, and recognising that quickly and acting on it is worth more than any additional analysis. Mark the boundary explicitly on the graph so the reader sees it too.
• Annotate during, never after. The reasoning behind adding a node is available for about ninety seconds and then it is gone. An annotated graph is a case document; an unannotated one is a picture of some addresses.
• Write down the filters. Threshold, direction, date window and hop limit are the parameters that produced everything in the picture, and the tool forgets them the moment they are applied. Without them the analysis cannot be repeated or defended.
• Unlabelled is not unattributed. It means the tool has no label, which is the default state of nearly every address on every chain and which is especially common for legitimate regional exchanges. Never let an unlabelled node be described as a personal wallet.
• Re-derive every fiat number. Interface conversions are convenient and uncitable. A total assembled from them will be challenged and will not survive, and re-deriving from a cited price source at each timestamp is an hour's work that protects the whole report.
• Export as you go. Treat the hosted workspace as borrowed. Address lists, hash lists and exported graphs belong in your own case system from the first session, not from the last one.
• Layout is not evidence. Readers infer importance from node position and cluster proximity, which are artefacts of a force-directed rendering. If a node is important, say so in the annotation rather than letting the picture imply it.

Questions analysts actually ask

Is it good enough to replace a commercial analytics licence?

For constructing and communicating a trace, it is often sufficient, and for organisations with no licence it is the difference between doing the work and not doing it. For attribution depth, regional label coverage and evidentiary defensibility it is not a substitute, and cases that will be litigated need a vendor that will state its methodology and stand behind it.

Why does an address have no label here but a label in another tool?

Because label corpora are independently maintained and differ substantially, particularly outside the major Western services. Absence here is not evidence that another tool's label is wrong, and presence elsewhere is not confirmation either. Where the label matters, verify against an open tag corpus and against the service's own published disclosures.

Can I use the graph as evidence?

Treat it as investigative material. It has no methodology statement, no chain of custody and no versioned attribution, and it should not be tendered as though it were a forensic product. Extract the transaction hashes, verify them independently, and build the evidential account on those verified records with the verification documented.

How far should I expand a trace?

Until the question is answered or until value reaches a custodial venue, a mixing service or a bridge, whichever comes first. Those three are boundaries rather than waypoints. Expanding past them produces nodes that look like continuation and are not, and that is where most visual traces go wrong.

Is my investigation private?

It is stored on a third-party service and is visible to the operator, and any share link discloses it to whoever holds the link. For sensitive matters use an account that does not identify your organisation, share deliberately with named recipients, revoke when finished, and consider whether the case belongs in a hosted tool at all.

Can the person I am tracing tell that I am looking?

Not from your use of the tool – read-only analysis is invisible to the subject. What is visible to them is any on-chain action you take, including test transactions and dust, which are permanent public records. Keep investigative work strictly read-only unless there is an authorised reason otherwise.

What should I do the moment I identify an exchange?

Act, immediately. Contact the exchange's compliance or law enforcement channel, or have counsel or the investigating unit do so, and pursue a preservation request through the appropriate route. Balances move and records have retention limits, so the hours after identification are worth more than any further analysis.

The trail disappears into a mixing service. Is the case over?

The on-chain trail is, in the sense that specific input-to-output linkage is not observable and should not be asserted. The case is not necessarily over: the entry point into the mixer, the timing, the amounts and the behaviour around it remain evidence, and the investigative route usually shifts to off-chain material and to the venues on either side.

Should I keep the investigation in the tool or in my own system?

Both, with your own system as the authoritative copy. Export the graph, the address list and the hash list at every milestone. Small vendors change tiers, features and sometimes existence, and an investigation that survives only in someone else's web application is not under your control.

Standards, formats and interoperability

What this source speaks natively, and what it has to be translated into before a partner can consume it. Work that arrives in a recognised format is easier to defend, easier to hand over and easier to automate against:

• Public blockchain address formats and transaction structures for each supported network, which are the verifiable substrate of everything the tool renders.
• Common-input-ownership and change-address clustering heuristics as described in the published literature, which are the general basis for address grouping in every tool of this class.
• FATF definitions of virtual asset service providers, which are the categories that a service label is attempting to express and which determine the regulatory obligations of an identified counterparty.
• Sanctions authority publication of designated cryptoasset addresses, which should be screened before any commercial or community label is considered.
• STIX 2.1 and MISP object models for representing addresses, relationships and confidence when a trace has to move between organisations in a machine-readable form.
• Suspicious activity and suspicious transaction reporting frameworks, which are the operational destination of most findings for regulated and law enforcement users.
• Digital evidence handling practice, which is what a graph does not satisfy and which governs how the verified transaction records behind it must be captured if the case is litigated.

References

Primary documentation and authoritative references for this source. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

1. Breadcrumbs — Breadcrumbs. The application itself, including the current statement of supported chains, tier limits and features, all of which have changed over the product's life.
2. OFAC Sanctions Programs and Information — US Department of the Treasury, Office of Foreign Assets Control. Designated addresses and the legal basis for each designation. The first screen on any address in a trace and the only attribution with legal force.
3. FATF — Financial Action Task Force. The international standards defining virtual asset service providers and the obligations that attach to them, which is what makes identifying a venue analytically decisive.
4. GraphSense TagPacks — GraphSense / Iknaio. Open attribution tags with explicit sources and a confidence vocabulary. The right instrument for checking a label you intend to rely on.
5. Blockchair — Blockchair. Multi-chain block explorer for independent verification of transactions and balances across several networks from one interface.
6. mempool.space — mempool.space. Bitcoin explorer with mempool and fee detail, useful for verifying Bitcoin transactions and for reading the urgency behind a movement.
7. Elliptic — Elliptic. Commercial analytics vendor whose published typology research is a good calibration reference for what an observed flow pattern is likely to represent.
8. Chainalysis — Chainalysis. Commercial analytics vendor and the benchmark for evidentiary posture in this domain, which is the standard a free tool is not attempting to meet.
9. Internet Crime Complaint Center — US Federal Bureau of Investigation. Victim reporting route for cryptoasset fraud and a source of aggregate typology data. The referral is usually the most valuable thing a caseworker can do.
10. Europol — European Union Agency for Law Enforcement Cooperation. Assessments of organised crime use of cryptoassets, providing the operational context a transaction graph cannot supply on its own.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this source: it ingests the exported address and hash lists rather than the picture, verifies every transaction against chain data on arrival, stores labels as dated third-party claims, rebuilds the relationship graph on confirmed hashes, and keeps the trace alongside the correspondence and legal steps in the case rather than in a vendor's workspace.. Browse the full source catalogue, or follow any tag above into the rest of the library.