MetaSleuth (Blocksec): Intelligence Source Guide

MetaSleuth is BlockSec's fund-flow tracing workbench: paste an address or transaction hash and it builds an expandable graph of where value went, across chains and through bridges, with entity labels attached. It is usable free and treats cross-chain movement as a first-class problem.

At a glance

Source	MetaSleuth (Blocksec)
Category	Cryptocurrency & Blockchain › Blockchain Analytics & Attribution
Homepage	https://metasleuth.io/
Machine interface	`https://metasleuth.io/`
Format	`HTML`
Access	Open — no account required
Disciplines	Cryptocurrency Intelligence
Mission domains	Financial Crime, Anti-Money Laundering

Fund-flow tracing & labelling. — as catalogued in the platform’s own source registry.

MetaSleuth is a web application for tracing cryptocurrency fund flows. You give it a starting point – an address, a transaction hash, sometimes a token contract – and it renders a directed graph in which nodes are addresses or labelled entities and edges are aggregated transfers carrying a token, an amount and a time range. From there the work is interactive: you expand a node to pull in its counterparties, collapse a cluster you have decided is one actor, filter edges below a value threshold or outside a date window, annotate a node with what you have concluded, and keep going until the graph either terminates at something you recognise or dissolves into noise. It attaches labels to addresses it knows – centralised exchange deposit addresses, bridges, mixing services, known incident addresses, protocol contracts – and those labels are what turn a wall of hexadecimal into a narrative. It covers Bitcoin, the major EVM chains, and several non-EVM chains; the exact supported list changes and is stated inside the product, so check it rather than assuming. It is built by BlockSec, a blockchain security firm whose other products include an attack-detection and transaction-blocking system and a browser extension that overlays additional data onto public explorers.

The analytical job MetaSleuth does that a block explorer does not is aggregation and continuity. An explorer answers per-transaction questions: what happened in this transaction, what is in this address, what does this contract do. A tracing tool answers path questions: where did the proceeds of this incident end up, how many hops until they touched a service with a compliance function, did two apparently separate incidents converge on the same off-ramp. Doing that by hand in an explorer is possible and is how a lot of good work still gets done, but it degrades at the third or fourth hop and it breaks completely at a chain boundary. MetaSleuth's specific contribution is that it attempts to carry the trace across bridges – matching a deposit on the origin chain to the corresponding withdrawal on the destination chain – which is the single manoeuvre that most often defeats an amateur trace and the one that laundering patterns exploit deliberately. The second contribution is shareability: a saved graph is a reviewable artefact that a colleague, a lawyer or a counterpart agency can open and disagree with, which matters far more than it sounds when the alternative is a screenshot.

Who publishes it, and why that matters

BlockSec is a commercial blockchain security company with strong academic roots; its founders and early technical staff came out of university systems-security research, and the firm built its public reputation on fast, technically detailed post-mortems of DeFi exploits published in the open. That history matters for two reasons. First, the labelling and incident data behind MetaSleuth is partly a by-product of incident response work the company does anyway, which is a healthier provenance than labels bought wholesale from a data broker. Second, the company's commercial centre of gravity is attack detection and protection sold to protocols and exchanges, not investigations sold to governments – MetaSleuth is adjacent to the core business rather than the whole of it. The practical implications: the free tier exists to acquire users and can be narrowed at any time, the labelling is best where BlockSec has done incident work and thin where it has not, and there is no regulatory obligation on the company to maintain any particular standard of evidentiary rigour. Treat it as a capable commercial tool with a published track record, not as a source of record.

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`	string	The account identifier at the centre of a node. MetaSleuth is a web application rather than a documented open feed at the entry tier, so these are the attributes the interface exposes per node and edge rather than literal API keys. Address format is chain-specific and case handling differs: EVM addresses carry a mixed-case checksum, Bitcoin bech32 addresses do not tolerate case changes at all.	Public explorers for the same chain, sanctions list screening, other tracing tools for label disagreement, and any off-chain mention of the string in leaks, forums or court filings.
`chain`	enum	Which ledger the node lives on. This is not cosmetic. The same hexadecimal address string is a valid account on every EVM chain and is frequently controlled by the same key across all of them, so a node identity is only meaningful as the pair of chain plus address.	The same address string on sibling chains, which is a standard and productive sweep that often finds activity the incident report missed.
`entity_label`	string	The human-readable name attached to a known address – an exchange, a bridge contract, a mixing service, a protocol, a named incident actor. This is the highest-value and least verifiable field in the tool. It is an assertion by BlockSec, not an observation from the chain.	The named entity's own disclosures, other vendors' labels for the same address, and regulatory filings or enforcement actions naming the service.
`token`	string	The asset moved on an edge, identified by symbol and, on token-capable chains, by contract address. Symbols are not unique and are trivially spoofable; the contract address is the identity. Two edges labelled with a major stablecoin symbol may be the real asset and a worthless impersonation.	The token contract, its deployer, its holder distribution, and whether it appears on any legitimate market.
`amount`	string	The quantity transferred on an edge, in token units. Fiat-equivalent figures shown alongside are conversions at some price point, and which price point – time of transfer, time of query, a daily close – materially changes the number in any volatile asset. Never carry a fiat figure into a report without recording the basis.	Historical price series for the asset at the transaction timestamp, and threshold rules in the relevant reporting regime.
`timestamp`	timestamp	The block time of the underlying transfer. On most chains this is a miner or validator supplied value with limited precision and some tolerance for drift; it is close enough for sequencing at hour resolution and unsafe for sub-minute claims about ordering across chains.	Block height, the surrounding blocks, and off-chain events – announcements, exchange halts, media reports – in the same window.
`tx_hash`	string	The identifier of the specific transaction underlying an edge. Where an edge aggregates many transfers, the hash list behind it is what makes the edge auditable. Always drill to hashes before asserting anything in writing.	Any block explorer for full transaction detail, including inputs, internal calls, logs and failure status that the graph view abstracts away.
`direction`	enum	Whether the edge represents value moving into or out of the node in focus. Trivial in principle and a common source of error in practice, because analysts reading a dense graph reverse arrows in their notes and then in their report.	The counterparty node, and the same relationship viewed from the other end as a check.
`balance`	string	Current holdings at the address, per asset. This is a snapshot at query time, not at incident time. An address that is empty now may have held the entire proceeds for a week, and an address holding a fortune now may have received it long after the events you care about.	Historical balance reconstruction from the transaction list, which is the only defensible way to state what an address held on a given date.
`first_activity`	timestamp	When the address was first seen transacting. A funding event immediately before an incident is one of the strongest single signals in on-chain work, because it says the address was created for the purpose.	The funding transaction and its origin, which is very often the first and best lead toward attribution.
`bridge_link`	string	The asserted correspondence between a deposit into a bridge on one chain and a matching withdrawal on another. This is an inference produced by matching amounts, timing and, where available, bridge message identifiers – not a fact stated by either ledger.	The bridge protocol's own message or transfer identifiers, which are the only way to raise a bridge link from plausible to demonstrated.
`risk_indicator`	enum	Flags attached to addresses associated with sanctioned entities, known incidents, mixing services or high-risk categories. Useful for triage, unreliable as an assertion. The category boundaries are the vendor's and the underlying evidence is usually not shown.	Primary sanctions lists, incident post-mortems and enforcement filings, which is where the flag has to be grounded before it enters a report.
`graph_annotation`	string	Analyst-authored notes and node renaming within a saved graph. Not chain data at all, but the layer that carries reasoning between analysts and the reason a saved graph is worth more than a screenshot.	Your case management system – the annotation should never be the only place a conclusion is recorded.

Coverage — and what is not in it

Coverage is best understood in three layers, each with a different shape. The ledger layer is complete by construction: for any chain the tool indexes, every confirmed transaction exists and no amount of vendor failure can remove it, so the transfer graph is as good as the indexing. The label layer is where coverage becomes uneven. Labels are dense on high-volume centralised exchanges, major bridges, well-known mixing services and addresses involved in publicly analysed incidents – which is to say, dense exactly where BlockSec and the wider security community have already looked. They are sparse on regional exchanges outside the English-language and Chinese-language security ecosystems, on over-the-counter brokers, on payment processors, and on anything that has not been the subject of a public write-up. The incident layer follows BlockSec's own casework and the DeFi exploit corpus generally, meaning it is strongest on smart-contract exploits and bridge compromises and weaker on the slower, less spectacular flows that carry most illicit value: fraud proceeds, sanctions evasion through nested services, and payment for goods and services. Update rhythm on the ledger layer is effectively continuous; labels appear when someone does the work, which can be hours after a major incident or never for a quiet regional exchange.

Known blind spots

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

It cannot see anything that did not happen on a chain it indexes. Value that moves inside an exchange between two customer accounts, through an internal ledger, or via an off-chain agreement leaves no trace, and the graph will show funds arriving at the exchange and simply stopping.
Cross-chain links through bridges are inferences and can be wrong. Where a bridge is high-volume and amounts are round, matching a deposit to the correct withdrawal is genuinely ambiguous, and the graph presents the chosen match with the same visual weight as an on-chain edge that is a matter of fact.
Privacy chains and privacy techniques defeat it by design. Value that enters a shielded pool or a chain with confidential amounts and recipients exits the traceable world, and the honest output is a terminal node rather than a guess about what happened next.
Absence of a label is not absence of an entity. A cluster with no label may be a large regional exchange the vendor has never characterised, and treating unlabelled as suspicious inverts the actual base rate, in which most unlabelled addresses belong to ordinary users.
Attribution stops at the service boundary in every case. When funds reach a centralised exchange, the identity of the person controlling the depositing account exists only in that exchange's records and is obtainable only through legal process, so the graph goes blank at precisely its most important endpoint.
Contract-internal movement is easy to misread. Value routed through a router, an aggregator, a proxy or a batching contract can appear as a hop through an unrelated address, and an analyst who counts contracts as counterparties will overstate the number of parties involved.
The tool has no view of intent or legality. A path through a mixing service is a path through a mixing service; it may be laundering, it may be a privacy-conscious user, and nothing on-chain distinguishes them.
Entry-tier limits on expansion depth and history change without notice, so a trace that was fully explorable last quarter may hit a wall this quarter – and the wall looks exactly like an endpoint if you are not paying attention.
It shows value movement, not control. Two addresses in a path may be the same person, a victim, a service and a customer, or an attacker and an unwitting recipient, and the edge looks identical in all four cases.

Write the blind spot into the product. A statement that something “was not observed in MetaSleuth (Blocksec)” 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

Access at the entry level is a browser and an account. There is no meaningful barrier to a journalist or a caseworker starting a trace, and for one-off work that is often all you need. Paid tiers extend expansion depth, monitoring, team features and programmatic access; the specific tier boundaries and pricing change and should be confirmed with the vendor rather than inferred from any guide including this one. For sustained investigative programmes the important question is not price but whether you can get data out. A tool that will only render a graph inside its own interface is a viewing device; a tool that will export the underlying transfers and labels is an intelligence source. Establish which one you have bought before you build a workflow on it. If you need bulk or programmatic access, ask the vendor directly and get the terms in writing, including whether derived data may be retained after a subscription lapses – that clause decides whether your case files survive a procurement gap.

Licence

This is proprietary commercial software with terms of service that govern use, and the terms are the vendor's to change. What is safe to say: the underlying blockchain data is public and no vendor can restrict your use of facts you could have derived from a public ledger yourself, while the labels, clustering, entity resolution and cross-chain inferences are the vendor's product and are typically restricted to internal use under the subscription agreement. Redistribution of labels, wholesale export into a product you resell, and scraping the interface are the usual prohibitions. Screenshots in an internal report are ordinarily fine; a published article reproducing a substantial body of the vendor's labelling probably is not, and the polite and safe route is to ask. Confirm current terms before relying on this commercially – the licensing posture of tracing vendors has shifted repeatedly as the market has consolidated.

Rate limits and fair use

The interface is interactive and paced by human attention, so classical rate limiting is not the operative constraint at the entry tier; expansion depth, retained graphs and monitored addresses are. The etiquette question that does matter is automation: driving a web interface with a headless browser to extract labels in volume violates the terms of service at most vendors, is detectable, and will get an organisation blocked in a way that is awkward to explain to a client mid-case. If you need volume, buy the API. For manual work the practical throughput limit is analytical rather than technical – a careful analyst manages perhaps a few dozen well-verified hops in a working day, and any workflow claiming more is skipping the verification step.

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 MetaSleuth (Blocksec) 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
Manual trace from a seed indicator	HTML	Per case, as leads arrive	The primary mode. Start from an address or hash you have from an incident report, a victim or a ransom note, expand outward, and record hashes for every hop you intend to assert. This is not automatable and should not be.
Graph export into the case file	CSV	At each analytical checkpoint	Export the underlying transfer list rather than only the picture. The picture ages badly and cannot be re-verified; a transfer list with hashes can be checked against any explorer years later, including by an opposing expert.
Address monitoring and alerting	JSON	Continuous while a case is live	Watch dormant addresses of interest for movement. The analytically valuable event is usually not a large transfer but the first small test transaction, which typically precedes a cash-out attempt by hours.
Label lookup for triage	HTML	Ad hoc, seconds per address	Single-address queries to establish whether an indicator touches a known service before deciding whether the lead is worth a full trace. Cheap, fast, and the right first step on a queue of tips.
Programmatic access at paid tiers	JSON	Batch or event-driven	Where the commercial arrangement supports it, pull labels and flows into your own store. Verify the contractual retention position first, because building a pipeline you must later purge is expensive.

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.

Register the source and record its nature — sources.php holds the entry with an explicit flag that this is a vendor-derived analytic product rather than a primary ledger feed, so every record it produces inherits that provenance downstream and no analyst mistakes a label for an observation.
Normalise addresses to chain-plus-address identity — ingest.php stores the chain identifier alongside the address string and applies chain-appropriate case normalisation. Without this, the same EVM string on four chains collapses into one entity and the resulting picture is fiction.
Load transfers as first-class relationships — The transfer list becomes edges carrying hash, token contract, amount, block height and timestamp. Every edge keeps its hash so any assertion can be re-derived from a public explorer independently of the vendor.
Load labels as dated claims, not attributes — enrich.php attaches each label with its asserting source and the date it was observed, so a label that changes or is withdrawn shows up as a change rather than silently overwriting history.
Flag cross-chain links as inferred — Bridge correspondences are stored with a distinct relationship type marking them as inference. A downstream query for the provable transfer graph can then exclude them, which is exactly what you want before a disclosure deadline.
Screen against sanctions and watchlists — sanctions.php and watchlist.php check every ingested address against authoritative designation lists directly, rather than trusting a vendor risk flag. The vendor flag is a triage hint; the list is the legal fact.
Correlate across cases — correlate.php and link-analysis.php surface addresses appearing in more than one case file, which is where genuinely new intelligence comes from – two unrelated frauds converging on one deposit address is a finding neither case produced alone.
Attach to the case and set monitoring — add-to-case.php binds the trace to the investigation, alerts.php watches terminal addresses for movement, and reports.php renders the narrative. Summarise (Copilot) can draft prose over records that already exist; no indicator, relationship or attribution in the platform originates from a model.

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.

Judge this in two halves and do not average them. The transfer graph is high quality because it is a rendering of ledger data, and errors there are indexing bugs that show up as missing edges rather than invented ones – verifiable in seconds against any independent explorer, which is the check you should perform on every hop that matters. The label and inference layer is a different proposition: a commercial analytic product with no published methodology, no auditable confidence scoring, no stated error rate, and no obligation to tell you when a label changes. BlockSec's public incident work is technically strong and specific, which is genuine evidence that the people doing the labelling know what they are looking at, and it is the best available basis for trusting the product. But evidence of competence is not a measurable accuracy figure, and no responsible analyst treats a vendor label as a finding. The working standard is simple: the graph is a lead-generation instrument, the hashes are the evidence, and labels are corroborated against a second source before they appear in anything with your name on it.

Characteristic false positives

Address reuse across chains creates phantom identity. The same hexadecimal string on Ethereum, BNB Chain, Polygon and Arbitrum is read as one node by a careless analyst, merging four independent behavioural histories into an actor that does not exist.
Dusting and unsolicited token transfers create false association. Anyone can send anything to any address, so an incoming edge from a sanctioned address proves nothing about the recipient – and this is done deliberately to poison analysis and trigger automated compliance flags.
Contract intermediaries are counted as parties. Routers, aggregators, proxies and multicall contracts appear as hops in the path, and an analyst who counts them as counterparties will describe a two-party transfer as a five-hop laundering chain.
Bridge matching picks the wrong withdrawal. On a busy bridge with common round amounts, several candidate withdrawals fit a deposit, and choosing one produces a confident-looking cross-chain path that leads to an innocent party.
Stale labels persist after the underlying reality changed. A deposit address reassigned by an exchange, a service that shut down, a contract upgraded behind a proxy – the label was true once and is presented in the present tense.
Token symbol spoofing misleads on value. Worthless tokens are minted carrying the symbols of major stablecoins precisely so that a graph shows large apparent transfers, inflating the apparent scale of a flow by orders of magnitude.
Clustering over-merges on shared infrastructure. Addresses that share a deposit service, a custodian or a batching contract can be drawn together as one entity when they belong to unrelated customers of the same provider.
Fiat conversion at the wrong reference time inflates or deflates the story. A transfer valued at query time rather than transfer time can differ by a factor of several in a volatile asset, and the error survives into headlines and charging documents.

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

Confirmed transactions do not age – a transfer that happened in 2019 is as true today as it was then, and this is the property that makes on-chain evidence unusually durable. Everything layered on top ages fast. Balances are stale the moment you record them, and a balance figure in a report without an as-of block height is not a fact. Labels age on the timescale of exchange operations: deposit addresses get reassigned, services rebrand, merge or collapse, and contracts get upgraded behind proxies, so a label more than a few months old should be re-checked before it carries weight. Risk flags age fastest of all because they sit downstream of designations and incident disclosures that change weekly. Cross-chain inferences do not so much age as become unreviewable, because reconstructing why a particular match was made months later is often impossible. A stale record here looks entirely healthy: a clean graph, a named exchange, a plausible path – with the exchange having ceased operating and the deposit address having belonged to a different customer since long before the events described.

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

Yields these data points

Cryptocurrency Address

How each sector uses MetaSleuth (Blocksec)

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

Relevant to threat finance and to force protection in theatres where irregular actors are funded through digital assets. The practical use is tracing declared indicators – addresses published in sanctions designations, recovered from captured media under proper authority, or disclosed in partner reporting – to establish which services and jurisdictions sit at the ends of the flow, because that determines whether a financial disruption option exists at all and which partner nation would have to execute it. The output that matters to a planner is not the graph but the terminal node inventory: which regulated entities hold the choke points, and how many hops separate the actor from them. Handle with care in coalition settings. The vendor is commercial, the labels are unattributable assertions, and coalition partners will and should ask what the basis is. Anything crossing into a targeting or sanctions nomination process needs the underlying hashes and independent verification, not a vendor screenshot. Timeliness is also worse than it looks: labels appear after analysis, so the most operationally interesting addresses are usually the least labelled.

🕵 National intelligence

This sits squarely in the CRYPTINT collection lane and its value is in network discovery rather than in confirming what you already believe. The strongest analytical moves are convergence findings: two separately reported operations sharing a funding source, an infrastructure procurement address appearing in two campaign datasets, a dormant address of interest waking. Financial infrastructure is stickier than network infrastructure – actors rotate domains weekly and rotate payment arrangements rarely, because payment arrangements involve counterparties who took effort to establish – which makes on-chain identity a durable selector when hosting indicators have gone cold. Two disciplines apply. First, the vendor sees your queries, so treat query patterns as collection about you and route sensitive work accordingly. Second, keep vendor inference and ledger fact in separate layers all the way through to the finished product, because an assessment that cannot distinguish them will not survive review, and the distinction is exactly what a peer reviewer is trained to attack.

👮 Law enforcement

For investigators this is a lead-generation and case-shaping tool whose main job is telling you where to send legal process. The trace establishes which exchange or service received the funds; the exchange's records establish who controlled the account; only the second is evidence of a person. Practical sequence: preserve the hashes immediately, trace to the first regulated recipient, send the preservation request before the retention window closes, and continue the trace while you wait. Two warnings recur in real cases. Vendor labels are hearsay and will not survive a competent challenge – build the evidential chain from public ledger data your own analyst can independently verify and, where the case is serious, obtain records directly from the service. And any fiat figure needs a stated conversion basis and time, because a defence expert who can move your loss figure across a statutory threshold by changing the pricing convention will do exactly that. Budget for the fact that most traces terminate at a service in a jurisdiction where mutual legal assistance is slow or unavailable.

🔍 Private investigation and corporate security

For asset tracing, fraud recovery and pre-litigation work the entry tier is genuinely useful and often sufficient to answer the question the client is actually paying for, which is usually whether recovery is plausible rather than who did it. A trace terminating at a major regulated exchange in a cooperative jurisdiction supports a civil disclosure application; one terminating at a mixing service or an exchange in a jurisdiction with no mutual legal assistance relationship tells the client to stop spending money, and delivering that quickly is worth more than an elaborate report. Three cautions. Do not overstate what a label means to a client who will read a named exchange as a named person. Do not present a vendor risk flag as evidence of wrongdoing to anyone, ever – the defamation exposure is real and the flag comes with no supporting evidence you could produce. And be explicit in the engagement letter about what the tool can and cannot establish, because clients arrive with the firm expectation that the blockchain identifies people.

📰 Journalism and OSINT media

Strong for stories where the ledger carries the narrative: tracing a hack's proceeds, showing that two apparently separate scams share an off-ramp, demonstrating that a promised burn or treasury never existed. The graph is also a good visual and an honest one if the caption is honest with it. The standards that keep this out of trouble are unglamorous. Publish the transaction hashes so readers can verify – it costs a footnote and it is the difference between reporting and assertion. Never name an individual from a label; the label names a service, and inferring a person from a service is the single most common way crypto reporting goes wrong. Give the fiat conversion basis and time. Put the trace to an independent analyst before publication, because tracing errors are subtle and confident-looking, and the correction is far more damaging than the delay. Where the story concerns fraud victims, remember that a payment address can identify a victim as easily as a perpetrator.

🌍 NGO, humanitarian and human rights

Useful in fraud and exploitation casework where a victim has a payment address, and in research into how proceeds from trafficking, extortion or romance fraud move. Two things are worth knowing. A trace can sometimes tell a victim, quickly and definitively, that funds went to a service that will never respond and that recovery firms promising retrieval are selling a second fraud – a genuinely protective use of the tool that costs nothing. And the address itself is sensitive personal data in many jurisdictions once linked to an identified person: an address in a case note is a durable identifier that will still resolve in a decade, so apply the handling rules you would apply to a bank account number. For advocacy work, aggregate patterns are safer and more persuasive than individual traces, and they do not risk exposing a victim who can be identified from a payment they made. Refer criminal matters to the national reporting channel rather than attempting recovery yourself.

🎓 University and research

For research the appeal is speed of exploration and the label layer, and the hazard is exactly the same label layer, because a vendor-derived, undocumented, non-reproducible classification cannot carry the weight of a published finding. Use it to develop hypotheses and to sanity-check clusters, then reproduce the underlying flows from public node data or an open dataset another researcher can obtain, and state clearly in the methods section which classifications came from a commercial tool and that they could not be independently validated. Ethics review deserves attention even though the data is public: pseudonymous addresses are re-identifiable through exchange records and off-chain leaks, so a dataset of addresses linked to a stigmatised category is a re-identification risk, and publishing address lists tied to behavioural claims about individuals is the specific practice to avoid. Longitudinal work should also record the label as observed on a date, because the vendor will change it and your results will silently stop replicating.

Playbook: working MetaSleuth (Blocksec) 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 — Establish provenance of the seed indicator

Write down where the starting address came from and what makes it reliable before you trace anything. An address from a signed sanctions designation, one from a victim's own wallet history, and one from a forum post have completely different evidential value, and the whole trace inherits the weakest link at its root. Traces that collapse under scrutiny almost always collapse at the seed, not at hop nine.

Phase 2 — Fix the question and the stopping rule

Decide in advance what would end the trace: reaching a regulated service, establishing that funds are unrecoverable, identifying convergence with another case, or exhausting the budget. Fund-flow work expands without limit and will consume as much time as you give it. An analyst without a stopping rule produces a large graph and no conclusion.

Phase 3 — Characterise the seed address before expanding

Look at its age, its funding transaction, its total throughput and whether it carries a label. An address created hours before the event and funded from a single source is operational infrastructure; an address with years of diverse history is probably a service or a person's main wallet. This one judgement determines whether you trace backwards toward attribution or forwards toward recovery.

Phase 4 — Trace backwards first when attribution is the goal

The origin of an operational address is usually more informative than its destination, because someone had to fund it and the funding often comes from an exchange withdrawal, a previous operation, or a personal wallet. Forward tracing follows money into professional laundering infrastructure designed to defeat you; backward tracing follows it into a moment when the actor was less careful. Do the backward hop before the graph gets large.

Phase 5 — Expand breadth-first with a value threshold

Take every hop at depth one before any hop at depth two, and set a minimum transfer value that excludes dust. Depth-first tracing follows whichever branch looks interesting and reliably misses the branch that mattered, and dust transfers are frequently deliberate noise. Record the threshold you used, because it is a methodological choice a reviewer will ask about.

Phase 6 — Identify and mark service boundaries

Every node that is a centralised exchange, custodian, payment processor or bridge is a boundary where on-chain visibility ends and legal process begins. Mark them explicitly rather than tracing through them, because tracing through a service's operational wallet produces nonsense – the outputs belong to unrelated customers. Recognising a boundary and stopping is a skill; the graph will happily let you keep going.

Phase 7 — Verify each load-bearing hop against an independent explorer

For every edge you intend to state as fact, open the transaction hash in a public explorer sharing no code or data with this tool and confirm the parties, amount, token contract and time. This takes a minute per hop and catches token spoofing, aggregated-edge misreading and indexing errors. Hops you are not prepared to verify are context, and should be described as such.

Phase 8 — Handle chain boundaries as a separate evidential question

When the path crosses a bridge, stop and ask what the correspondence rests on. If the bridge protocol emits a message or transfer identifier appearing on both sides, the link is demonstrable and you should capture both hashes. If the match rests only on amount and timing, it is an inference, and you must say so in the report and test how many other withdrawals in that window would also have fitted.

Phase 9 — Screen every significant node against authoritative lists

Run the addresses through primary sanctions and designation sources directly rather than relying on the tool's risk flags. A designated address in the path changes the legal character of the case in most jurisdictions and may create immediate reporting obligations for you or your client. Do this before you write, not after, because it can change who you are permitted to talk to.

Phase 10 — Test the alternative explanation deliberately

Take the strongest innocent reading of your path – the intermediary is a legitimate service, the dusting was unsolicited, the bridge match is a coincidence – and try to defeat it with evidence rather than with the shape of the graph. Write down which alternatives you excluded and how. This section is what distinguishes an analytical product from a picture, and it is the first thing a competent opponent will attack.

Phase 11 — Convert the graph into a portable evidence package

Export the transfer list with hashes, timestamps, token contracts and amounts, record the block height at which you took every balance figure, and store it in the case file alongside the graph image. The image is a communication aid with a short shelf life; the hash list is the durable artefact and the only part that can be re-verified after the vendor relationship ends.

Phase 12 — Set monitoring and define the trigger for reopening

Dormant addresses at the end of a trace are the highest-value monitoring targets in the case, because movement after a long silence usually means a cash-out attempt and is often preceded by a small test transfer. Decide now what movement would justify reopening, and who gets alerted, so the alert does not land in a dead inbox eight months from now.

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
MistTrack	corroborates	A second commercial tracing and labelling product from a different security firm with different casework behind it. Where two independent vendors agree on a label the confidence is materially higher; where they disagree you have learned something important about how soft the label layer is.
Etherscan	prerequisite	The authoritative per-transaction view for Ethereum and, through its sibling explorers, most EVM chains. This is where you verify hops, read contract source, inspect internal calls and confirm what a graph edge actually abstracted.
Blockchair	extends	Multi-chain explorer with a documented query API and bulk dumps, which is what you use when the question requires filtering across many transactions rather than following a single path.
Blockstream Esplora	extends	Open-source Bitcoin explorer and REST API you can self-host, giving you a verification path for the Bitcoin side of a trace that depends on no vendor and leaks no queries.
OFAC Sanctions List Search	prerequisite	The authoritative source for United States designations, including the digital currency addresses listed against designated persons. Screen here rather than trusting any vendor risk flag.
Chainabuse	corroborates	Community-reported scam and abuse reports keyed to addresses. Low evidential weight individually, useful in volume, and sometimes the only source connecting an address to a victim narrative.
SlowMist Hacked archive	extends	A curated archive of blockchain security incidents with dates, amounts and references. Good for establishing whether an address you are looking at belongs to a publicly documented event.
DefiLlama hacks tracker	corroborates	An aggregated record of protocol exploits with dates and loss figures, useful for placing an incident address in a chronology and for sanity-checking loss amounts quoted elsewhere.

Legal, ethical and operational constraints

The underlying data is public and querying it is lawful essentially everywhere, but three constraints bite in practice. First, an address linked to an identifiable person is personal data under most modern data protection regimes, which means a lawful basis, purpose limitation, retention limits and in some jurisdictions subject rights apply to your case file – the public nature of the ledger does not exempt you from processing rules. Second, the vendor's terms govern what you may do with labels and inferences: internal investigative use is normally fine, redistribution and resale normally are not, and reproducing a substantial body of labelling in a published product is the case where you ask first. Third, discovering that funds touched a designated address can create immediate obligations – a reporting duty, a freezing obligation, a prohibition on continuing to act for a client – and those obligations generally arise on knowledge, so it is safer to screen early and take advice than to find out at the end. For law enforcement specifically, treat vendor labels as investigative leads rather than evidence, and be prepared to explain any methodology you relied on to a court that will not accept a proprietary black box as the basis for a factual assertion.

Operational security

Every query tells the vendor which address you are interested in, when, from which account and network, and how deep you went. That log is a highly informative picture of your case: the sequence of addresses you expanded reconstructs your reasoning and your priorities, and it lives on a commercial company's infrastructure subject to its jurisdiction, its security posture and any legal process brought against it. Assume it is retained. For sensitive work the mitigations are procedural rather than technical: verify on infrastructure you control – a self-hosted explorer or your own node – for anything where the fact of your interest is itself sensitive, avoid distinctive query patterns that reveal a hypothesis before you have tested it, and do not use one account for both open research and protected casework. Monitoring alerts deserve specific thought, because registering an address is a durable declaration of interest that persists long after the analyst who set it has moved on. There is also a counterparty risk: sophisticated actors watch for their own addresses being probed on public tools, and a burst of expansions around a dormant address is exactly the signal they are looking for.

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 MetaSleuth (Blocksec) is contributing anything, and they are worth baselining now so the answer is available later.

Proportion of traces that reach a named service boundary rather than terminating in unlabelled space, which is the honest measure of whether the label layer works for your case mix.
Rate at which independently verified hops disagree with the graph – token contract mismatches, misread aggregations, indexing gaps – measured by actually spot-checking rather than assuming.
Time from receiving a seed indicator to identifying the first regulated recipient, because that number determines whether preservation requests land inside retention windows.
Agreement rate on labels between this tool and at least one independent source, tracked over time; a falling rate is early warning that one of them has stopped maintaining its data.
Number of cases where a monitoring alert produced an actionable event rather than noise, which decides whether the monitoring quota is worth its cost.
Count of cross-case convergences discovered – shared addresses across separate investigations – since this is the yield no single-case tool provides and the main argument for centralising traces.
Share of report assertions backed by a stored transaction hash rather than a screenshot, which is a direct measure of whether your work will survive challenge.

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:

A label names a service, never a person. The distance between them is a subpoena, and every serious error in crypto investigation lives in that gap.
Trace backwards for attribution and forwards for recovery. They are different jobs with different stopping points, and analysts who conflate them do both badly.
Record the block height with every balance. A balance without a height is not a fact, and reconstructing what an address held on a given date months later is painful and sometimes impossible.
Distinguish an edge that aggregates many transfers from one representing a single transaction. Aggregated edges hide structure, including the small test transfer that tells you a cash-out was imminent.
Verify the token contract, not the symbol. Symbol spoofing is cheap, common, and specifically designed to make a trace look like it involves real money.
Never trace through an exchange's operational wallet. Its outputs belong to unrelated customers, and a path that continues through one is not a path at all.
Treat cross-chain hops as a claim requiring their own evidence. Ask what identifier ties the two sides together, and if the answer is amount and timing, say so in the report.
Unlabelled is the default state of the chain, not a suspicion. Most addresses belong to ordinary users, and an analyst whose graph implies otherwise has confused vendor coverage with the world.
Write the alternative explanation down before you are asked for it. If you cannot articulate the innocent reading of your own graph, you have not finished the analysis.

Questions analysts actually ask

Can this tell me who owns an address?

No. It can tell you that an address is, in the vendor's assessment, a deposit address at a named exchange or a contract belonging to a named protocol. Who controls the account behind that deposit address exists only in the exchange's customer records and is obtainable only through legal process. Everything else is inference, and presenting it as identification is the most common serious error in this field.

How do I know the labels are right?

You do not, from within the tool. There is no published methodology, no auditable confidence score, and no error rate. Corroborate with a second independent tool, with the named service's own published addresses where they exist, or with primary documents such as enforcement filings. Where two independent vendors agree, confidence rises materially; where they disagree, the label does not enter your report as a fact.

Is the free tier good enough for real work?

For a single trace with a clear question, frequently yes – and that is a genuinely useful thing to be able to say about a professional tool. For sustained casework the binding constraints are expansion depth, monitoring capacity and whether you can export underlying transfers. Do not build a workflow on a free tier whose limits the vendor can change without notice.

What happens when funds enter a mixing service?

Your trace ends there, and the honest report says so. Some analysts attempt statistical association across such services; results are probabilistic, contested, and in most legal settings not worth the exposure. Record the deposit, note the amount and time, and pivot to other lines of enquiry rather than presenting a guess as a continued path.

Why do two tracing tools show different amounts for the same flow?

Usually one of three reasons: they aggregate transfers differently over the same window, they convert to fiat at different reference times, or one counts internal contract calls that the other treats as a single logical transfer. Drill to transaction hashes and the discrepancy resolves. If it does not, one of them has an indexing problem and you have learned which to trust.

Does querying an address alert its owner?

Not through the tool. But sophisticated actors monitor their own addresses using public services and infrastructure of their own, and a sudden pattern of activity around a dormant address is observable to anyone watching the same chain. For genuinely sensitive work, verify against your own node or a self-hosted explorer.

Can I use output from this in court?

The graph is not evidence; the underlying transactions are, and they are independently verifiable by anyone with a node, which is a considerable advantage over most digital evidence. Build the evidential chain from ledger data with your own analyst able to explain the method, and treat vendor labels as investigative leads. A proprietary tool that cannot explain how it reached a conclusion will not survive a competent challenge.

How far back does the data go?

To the genesis of each indexed chain for the transfer layer, because that is simply what the ledger contains. The label layer has no comparable depth: labels reflect what has been characterised, mostly in recent years and mostly around incidents that received attention. Old flows are fully traceable and largely unlabelled, which is the opposite of what most analysts expect.

Should I trace or send legal process first?

Both, in that order, immediately. Trace far enough to identify the first regulated recipient – often a matter of minutes – then send the preservation request, then continue tracing while it is processed. Retention windows at exchanges are finite, and delay caused by completing a thorough trace before making any request is the most common reason recoverable funds become unrecoverable.

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:

FATF Recommendation 15 and the virtual asset service provider framework, which defines the regulated entities appearing as the terminal nodes of most traces and determines whether legal process is available at all.
The FATF travel rule, which creates the originator and beneficiary information held off-chain at those terminal nodes and is what a disclosure request is actually asking for.
MISP attribute types for cryptocurrency addresses, which are native and are the practical route for sharing on-chain indicators with partners running MISP.
STIX 2.1, which has no native cryptocurrency observable in the core specification, so sharing on-chain indicators requires a custom object or extension – a real friction point worth knowing before you promise an integration.
EIP-55 mixed-case checksum encoding for EVM addresses, which is why case matters when normalising and why a naive lowercase comparison can silently merge or miss records.
Chain-agnostic identifier conventions for expressing chain-plus-address as a single portable identity, which is the correct unit of record and the thing most homegrown schemas get wrong.
ERC-20, ERC-721 and ERC-1155 token standards, which determine how transfers are represented in event logs and therefore what a tracing tool is actually reading when it draws a token edge.

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.

MetaSleuth — BlockSec. The product itself. Start here for the current supported chain list, tier boundaries and feature set rather than trusting any secondhand description including this one.
BlockSec — BlockSec. The operator. Worth reading for the incident analyses and research output, which is the best available evidence of whether the team behind the labelling knows what it is doing.
Etherscan — Etherscan. The independent verification path for Ethereum hops. Every load-bearing edge in an EVM trace should be confirmed here or on an equivalent explorer sharing no data with the tracing vendor.
Blockchair — Blockchair. Multi-chain explorer with a query API, useful both as a second opinion and for the filtering questions a path-tracing tool cannot answer.
OFAC Sanctions List Search — US Department of the Treasury, Office of Foreign Assets Control. The authoritative screening interface for US designations, including digital currency addresses associated with designated persons. This is the legal fact; a vendor risk flag is not.
Financial Action Task Force — FATF. The standard-setting body whose virtual asset guidance defines the regulatory architecture every trace eventually runs into. Read the VASP guidance before assuming what an exchange can lawfully disclose.
SlowMist Hacked — SlowMist. Curated archive of blockchain security incidents. The quickest way to check whether an address you are tracing belongs to a publicly documented event and to find the associated write-ups.
Chainabuse — Chainabuse. Community scam and abuse reports keyed to addresses. Individually weak, collectively informative, and sometimes the only link between an address and a victim account of what happened.
Internet Crime Complaint Center — US Federal Bureau of Investigation. The reporting channel for victims in the United States and publisher of annual figures on digital asset fraud. Relevant because referral, not tracing, is usually the right first action for a victim.
Europol — European Union Agency for Law Enforcement Cooperation. Publishes threat assessments covering criminal use of digital assets and coordinates cross-border action, which is the mechanism that turns a trace terminating in another jurisdiction into something actionable.
Ethereum developer documentation — Ethereum Foundation. The technical grounding for what an EVM transaction, an internal call and a token transfer actually are – necessary to read a graph edge correctly rather than trusting its rendering.
Bitcoin developer documentation — Bitcoin Project. Equivalent grounding for the UTXO model, which behaves nothing like an account model and is the reason Bitcoin tracing and EVM tracing are different disciplines.

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 stores traced transfers as verifiable relationships keyed to transaction hashes on blockchain.php and financial-crime.php, keeps vendor labels as dated claims separate from ledger facts, screens every node against sanctions.php and watchlist.php directly, and surfaces cross-case convergence through correlate.php rather than leaving it in one analyst's saved graph.. Browse the full source catalogue, or follow any tag above into the rest of the library.