OXT / WalletExplorer: Intelligence Source Guide

WalletExplorer groups Bitcoin addresses into wallets and puts service names on many of them – the most useful single transformation you can apply to raw Bitcoin data. It is free, it is old, and you should check what block it last indexed before trusting anything it says.

At a glance

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

Bitcoin wallet clustering & attribution. — as catalogued in the platform’s own source registry.

WalletExplorer is a Bitcoin block explorer that presents wallets rather than addresses. Instead of showing you one address and its transactions, it applies address clustering to group addresses believed to be controlled by the same party, then shows that cluster as a single entity with a combined transaction history, balance and counterparty list. Many clusters carry a service name – an exchange, a gambling site, a mining pool, a payment processor, a mixing service – and clusters without a name are given an opaque identifier. The naming was established by transacting with services directly and observing which cluster the funds entered or left, which is a sound and checkable method. The tool was built by an independent developer and later became associated with Chainalysis when its author joined that company; the public site has remained accessible but has not been actively developed at anything like the pace of commercial products, and its indexing currency has varied over time. OXT was a separate Bitcoin analytics platform associated with the Samourai Wallet development team, offering entity clustering, deep statistics and transaction entropy analysis; following United States enforcement action against that team in 2024 its availability has been unreliable, and it should be treated as a historical reference rather than a live service unless you have verified otherwise.

Clustering is the step that turns Bitcoin from a stream of transactions into a map of parties, and this source is where most analysts first meet it. Raw Bitcoin gives you outputs and inputs; it does not give you actors. The common-input-ownership heuristic – that inputs spent together in one transaction are normally controlled by one party, because one party had to hold the keys for all of them – is what constructs an actor from that stream, and everything downstream depends on it. WalletExplorer does this transformation for you and shows the result in a form you can inspect. That has two distinct values. Operationally, it collapses hundreds of addresses into one entity so you can see scale, counterparties and rhythm at a glance. Pedagogically, it makes the heuristic visible: you can see a cluster, look at the transactions that merged it, and form a view on whether the merge was sound. Analysts who learn clustering on a tool that only shows conclusions never develop that judgement, and it is the judgement, not the tool, that survives cross-examination. The service naming is the second contribution and the reason many investigators still open it: a named exchange cluster tells you where to send legal process, which is the practical end of most Bitcoin traces.

Who publishes it, and why that matters

WalletExplorer was built and run by a single developer as an independent project and made freely available. Its author subsequently joined Chainalysis, and the free site continued to run afterwards without becoming a maintained commercial product. That history explains everything about its behaviour: no service level, no support, no published change log, no guarantee of currency, and a labelling corpus whose density reflects the exchange landscape of the mid-2010s rather than today's. It is a public good that nobody is paid to maintain, and it should be used with that understanding rather than with irritation when it lags. OXT's operator history is different and more consequential: it was associated with a wallet development team that became the subject of United States criminal charges in 2024, after which the availability of the associated services changed. For any organisation with procurement or reputational sensitivity, the provenance of an analytical tool matters independently of whether the tool works, and that is a decision for your legal function rather than your analysts. In both cases the practical lesson is the same – do not build a pipeline whose continuity depends on a free service run by people with no obligation to you.

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
`wallet_id`	string	The identifier of a cluster, which is either a service name where one has been established or an opaque hexadecimal string where it has not. This is the core unit of the tool and it is a derived construct, not a fact from the chain – the cluster exists because a heuristic put it together.	The full address list of the cluster, its counterparty clusters, and the same addresses in an independent explorer to see what the clustering has hidden.
`address`	string	An individual Bitcoin address belonging to a cluster. Bitcoin addresses are not accounts; they are one-time payment destinations in the intended usage model, and a wallet may generate a new one for every receipt, which is exactly why clustering exists.	The cluster it belongs to, the transactions that spend from it, and off-chain occurrences of the string in leaks, forums, ransom notes or court documents.
`service_name`	string	The human-readable name attached to a cluster believed to be a known service. Established historically by transacting with the service and observing where the funds landed, which is a directly checkable method – though the check was performed at a point in time that may be many years ago.	The service's own published addresses, enforcement filings, and other explorers' attribution of the same cluster.
`tx_hash`	string	The transaction identifier. In Bitcoin this identifies a set of inputs and outputs, not a payment from one party to another, and the distinction is fundamental: one transaction can pay several unrelated recipients and return change to the sender in the same operation.	Any Bitcoin explorer or your own node, where the full input and output structure and script types can be inspected.
`block_height`	int	The block containing a transaction. Height is the reliable ordering key in Bitcoin, unlike wall-clock time, and it is the correct thing to record when stating when something happened relative to something else on the same chain.	Surrounding blocks, the difficulty and fee environment at that height, and the block timestamp for approximate wall-clock correlation.
`timestamp`	timestamp	The block time as declared by the miner. Bitcoin block timestamps are constrained but not exact and can legitimately run ahead of or behind real time by a meaningful margin, so they support hour-level reasoning and not minute-level claims.	Block height for ordering, and off-chain events in the same window for correlation.
`amount`	string	Value in bitcoin, denominated on-chain in the smallest unit. The displayed figure is the transfer amount, not the economic value to any party, because a single transaction combines payment, change and fee in ways that are not separable without interpretation.	Historical exchange rates at the block time if a fiat figure is required, recorded with the source and the convention used.
`counterparty_wallet`	string	The cluster on the other side of a transaction. This is where the tool earns its keep: a counterparty rendered as a named exchange rather than as an address is the difference between a lead and a wall.	The counterparty cluster's own history and counterparties, and the legal process route if it is a regulated service.
`received_total`	string	Cumulative inflow to a cluster over its lifetime. A far better indication of significance than current balance, and the number that distinguishes a transient intermediate hop from a long-running collection point.	The inbound transaction list and the distribution of source clusters, which reveals whether inflow came from many victims or one source.
`balance`	string	Current holdings of the cluster at the time the index last updated – which is a critical qualifier here, because the index may be well behind the chain tip. A balance from a stale index is not a current balance, it is a historical one presented as current.	A live explorer or your own node to establish the true present balance, and the transaction history to reconstruct balance at any specific height.
`first_seen`	timestamp	When the cluster first appears in the data. For a service this approximates when it began operating; for an operational wallet it is often close to when it was created for a purpose, which is a strong signal when it sits days before an incident.	The funding transaction and its source cluster, which is the standard route back toward an identifiable account.
`address_count`	int	How many addresses the cluster contains. A useful sanity check: a cluster of millions of addresses is infrastructure, not a person, and a cluster of two may be a heuristic accident rather than a real entity.	The address list itself, and the specific transactions that caused the largest merges – which is where over-clustering can be diagnosed.

Coverage — and what is not in it

Coverage is Bitcoin only, from the genesis block forward, which is both a limitation and the reason the source retains value: the early chain is exactly where commercial tools have the least commercial incentive to invest and where a great deal of historically important activity sits. The clustering covers the whole indexed history. The service naming is heavily weighted toward the exchange, gambling and mixing landscape of the period when the labelling work was done, which means it is unusually good on services that no longer exist – a real asset for historical investigation, cold cases and academic work – and correspondingly poor on anything that launched recently. Indexing currency is the field to check first and the one most users skip: establish which block the tool has reached before treating anything it says as present-tense, because a stale index produces confident output about a world that has moved on. There is no coverage of any other chain, no token or smart contract layer, and no visibility into anything off-chain. For Bitcoin activity of the last few years the sensible posture is to use it for its clustering view and to take currency, balances and recent counterparties from a live explorer or your own node.

Known blind spots

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

The index may be significantly behind the chain tip, and nothing in the interface makes that as loud as it should be. Recent transactions, current balances and new counterparties can simply be absent, which reads as an address having stopped rather than as the tool having stopped.
Clustering merges only what the heuristics can see. A party who never spends two of their addresses together in one transaction remains multiple clusters, so an actor can be substantially larger than the cluster you are looking at without any indication that this is so.
Service naming decays as the ecosystem changes. Exchanges close, rebrand, get acquired, migrate their infrastructure and reassign addresses, so a name established years ago may describe an entity that no longer exists in that form.
CoinJoin and other collaborative transactions break the ownership assumption on which clustering rests. Inputs from unrelated parties appear together deliberately, and a naive cluster built across such a transaction merges strangers into one apparent entity.
Payment batching by exchanges makes one transaction with many outputs look like one party paying many recipients, when it is a service settling unrelated customer withdrawals – producing false association between customers who have never interacted.
It sees no other chain and no other asset. A subject who moved value to a different network, into a token, or through a service that settles off-chain vanishes at that point, and the Bitcoin-only view will read that as the trail ending.
Multisignature and collaborative custody arrangements co-spend inputs held under shared control, which the common-input heuristic reads as single ownership when it is nothing of the sort.
No off-chain identity information exists here at all. A named cluster identifies a service, and everything about who used that service is held by the service, obtainable only through legal process.
There is no service commitment behind the site. It may be slow, out of date or unavailable, and a workflow built on continuous access to a free unmaintained service will fail at an inconvenient moment.

Write the blind spot into the product. A statement that something “was not observed in OXT / WalletExplorer” 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 is a browser, with no registration and no key. A lightweight programmatic interface has historically been available and documented on the site itself, with a convention that callers identify themselves in the request – the etiquette of a free service asking to know who is using it. If you intend any automated use, read the current documentation on the site rather than following any example you find elsewhere, identify yourself honestly, and keep the request rate low enough that you are not the reason the service degrades for everyone else. For anything requiring guaranteed availability, current data or volume, the correct architecture is your own Bitcoin node with an indexing layer, using this source for its clustering view and its historical service names rather than as a data pipeline. OXT should not be assumed available; verify current status before referencing it in any methodology, and cite it as a historical analytical resource rather than a live one unless you have confirmed otherwise yourself.

Licence

There is no clearly stated commercial licence in the way a vendor product has one, and the safe assumption for a free public service is that personal and investigative use is intended, bulk extraction is not, and redistribution of the clustering and naming as your own dataset is not. The underlying Bitcoin data is public and unowned – transactions, addresses, amounts and blocks are facts you may use freely, and you can derive them yourself from a node with no permission from anyone. The derived layer, meaning the clusters and the service names, represents someone's analytical work. Cite it when you rely on it. If you intend to publish a dataset built substantially on its output or to embed it in a commercial product, seek clarification rather than assuming; the absence of a licence page is not permission. Where the analysis matters, reproduce the clustering yourself from public data so your result does not depend on someone else's unlicensed and unmaintained work.

Rate limits and fair use

No published quota, which means the constraint is courtesy rather than enforcement, and courtesy is the operative word for a free service run without funding. Keep concurrency at one, put a real pause between requests, cache aggressively because the underlying data for historical transactions never changes, and never run a bulk crawl of clusters or address lists. If your question needs thousands of lookups, it needs a local index rather than this service. The practical throughput for legitimate investigative use is a few hundred lookups a day at most, and even that is more than the site was designed for. Anyone who hammers it degrades a resource that the whole community relies on and that nobody is being paid to keep running.

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 OXT / WalletExplorer 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
Cluster lookup from a known address	HTML	Per case	The core operation: take an address, see which wallet it belongs to, and inspect the cluster's size, age, throughput and counterparties. The first three seconds of this tell you whether you are looking at a person, an operational wallet or a service.
Counterparty review for service identification	HTML	Per case	Reading the named clusters on either side of a subject cluster to find the regulated entities in the picture. This is what converts a trace into an actionable disclosure request.
Historical service research	HTML	As required	Looking up defunct exchanges, gambling sites and mixing services from earlier eras, where this source's naming is stronger than modern commercial tools. Particularly relevant to cold cases and to research on the early ecosystem.
Light programmatic lookup	JSON	Low rate, cached	Where a documented interface is available, small automated lookups with an honest caller identifier and generous pauses. Cache permanently; historical Bitcoin data does not change and re-fetching it is simply rude.
Local reproduction from a node	bulk	Continuous once built	The durable answer for any sustained programme: run a node, index it, and implement clustering yourself. Slower to build, unlimited to use, leaks nothing, and produces a method you can explain in court.

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 with an explicit currency check — sources.php records the source together with the last indexed block observed at collection time, so every derived record carries the knowledge of how far behind the index was when it was read. Without this the platform silently mixes stale and current Bitcoin data.
Store the cluster as a hypothesis, not an entity — ingest.php writes the cluster as an assertion that a set of addresses shares control, attributed to this source and dated. Clusters from different tools disagree, and modelling one as ground truth destroys the ability to reconcile them later.
Keep addresses as the primary key — Every address is stored individually with its cluster membership as a relationship. This keeps the platform correct when a cluster is later split or merged, which happens whenever a better heuristic or a new transaction changes the picture.
Record service names as dated claims with a method note — enrich.php attaches the service name with its source and the date observed. Where the naming method is known – transacting with the service and observing the destination – that goes in the record, because a name with a method behind it is worth far more than a bare label.
Preserve transactions independently of the cluster view — Transaction hashes, heights, inputs and outputs are stored as facts derived from the chain, so the evidential layer stands even if every clustering assertion is later withdrawn.
Screen clusters against designation lists — sanctions.php checks the constituent addresses against authoritative lists. A designation applies to specific listed addresses, and inferring that an entire cluster is designated because one address in it is listed is a legal conclusion the platform should surface rather than assume.
Reconcile against a live source — resolve-everything.php re-checks balances and recent activity against a current explorer or local node, and flags any record where this source's view and the live view diverge – which is the automated version of the currency check every analyst forgets.
Correlate and case — correlate.php surfaces clusters appearing across multiple investigations, add-to-case.php binds them to the case file, and export.php emits MISP or CSV for partners. Summarise (Copilot) writes prose over existing records; no clustering assertion 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.

The transaction data is as reliable as the chain it indexes, subject entirely to how current the index is – which is the one thing you must check and the one thing the interface understates. The clustering is methodologically sound in the sense that the common-input-ownership heuristic is the standard on which the whole field is built, and it is transparent in the sense that you can look at the transactions that produced a merge and judge them. That transparency is genuinely rare and is the strongest argument for using this source at all. The service naming is the most trustworthy element in provenance terms, because the method – sending value to a service and observing where it went – produces a directly evidenced association rather than an unexplained assertion. Its weakness is age, not method. Against modern commercial tools the honest comparison is unflattering on currency and coverage and surprisingly favourable on inspectability: a vendor will tell you an address belongs to an exchange and not why, while this will show you the cluster and let you argue with it. For historical Bitcoin work it remains a serious tool. For present-tense work it is a second opinion, not a primary source.

Characteristic false positives

Over-clustering through collaborative transactions. CoinJoin-style transactions deliberately combine inputs from unrelated parties, and a heuristic that assumes shared ownership will merge strangers into one apparent wallet with a completely fictitious combined history.
Batched withdrawals create false counterparty links. A service paying many customers in one transaction makes those customers appear related, and analysts routinely read a batch output as evidence of a relationship between recipients who have never met.
Change output misidentification sends the trace down the wrong branch. Deciding which output is change and which is payment is a judgement, and a wrong call at hop two makes every subsequent hop irrelevant while the graph looks entirely coherent.
Stale service names attribute a cluster to a company that no longer runs it. Infrastructure is sold, migrated and reassigned, and a name from an earlier era can point at an entity with no connection to the current controller.
Under-clustering understates an actor. A subject who is careful never to co-spend appears as many small unrelated wallets, and an analyst who equates cluster with actor will report a fraction of the real holdings and activity.
A stale index makes an active address look dormant. If the tool has not indexed recent blocks, an address that moved funds last week appears untouched, which can lead directly to a wrong conclusion about whether assets are still recoverable.
Multisignature co-spends read as single ownership. Shared-control arrangements produce exactly the input pattern the heuristic interprets as one party, and collaborative custody is now common enough that this is not an edge case.
Cluster size is mistaken for significance. A vast cluster is almost always a service and a tiny one may be a heuristic artefact, and neither tells you anything about the importance of the party to your case.

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

Two clocks run here at very different speeds. Chain data does not age at all: a transaction from 2013 is exactly as valid a fact now as it was then, and this is why the source remains useful for historical work long after its currency became doubtful. Everything derived ages. Clusters grow as new co-spends occur, so a cluster you recorded is a snapshot of a heuristic applied to a chain state, and the same query later can return a larger cluster with different counterparties – which is not an error, it is the nature of the construct, and it is why cluster assertions must be dated. Service names age on the timescale of business change, which is years for the naming to become misleading and decades for it to become useless, since a defunct exchange is still correctly named even though it no longer operates. Balances and recent activity age immediately and are additionally distorted by index lag. The characteristic stale record is a wallet page showing a plausible balance and a last transaction some time ago, where the truth is that the funds moved long since and the index simply never caught up – a record that looks healthy and is materially wrong.

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 OXT / WalletExplorer

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

Bitcoin remains the settlement asset for a meaningful share of illicit procurement, ransom payment and sanctions-evasion activity, and clustering is the step that turns raw ledger data into a picture of parties. For threat finance work this source is useful mainly for historical reconstruction: establishing what a cluster looked like at the time of an event years ago, or identifying services from an earlier period that no longer appear in commercial datasets. It is not a current-intelligence tool and should not be treated as one – index currency is unreliable and there is no service commitment. Its practical advantage in a coalition setting is that the method is explicable: you can show a partner the transactions that produced a cluster and let them assess it, which is far more useful in a shared assessment than a proprietary verdict nobody can interrogate. Anything feeding a nomination or targeting process must rest on transactions verified against your own node.

🕵 National intelligence

The analytical value in the CRYPTINT lane is the cluster as a durable selector. Addresses are cheap and disposable; the wallet that spends them is not, because an actor with operational funds must eventually consolidate and consolidation is what the heuristic sees. A cluster identity therefore persists across address rotation and is often the only link between two operations separated by years. This source is worth running specifically because it makes the merge visible – you can see which transaction joined two address sets and decide whether the actor was careless or whether you are looking at a collaborative transaction that has misled you. Treat it as a historical and methodological resource rather than a live feed: verify currency at every use, take present-tense facts from your own infrastructure, and remember that a free unmaintained public service is not a dependency you can build a standing requirement on.

👮 Law enforcement

For investigators the payoff is service identification. A named exchange cluster in the counterparty list tells you which company to serve process on, and that is usually the step that converts an on-chain trace into evidence about a person. Two disciplines are essential. Check the index currency before drawing any conclusion about present holdings, because reporting that funds remain in a wallet when they moved months ago is the kind of error that ends badly in a restraint application. And be prepared to explain clustering to a court in your own words: the common-input-ownership heuristic is defensible, widely accepted and demonstrably wrong in identifiable circumstances, and an officer who can articulate both halves is credible while one who says the software said so is not. For historical and cold-case work the older service naming is a genuine advantage over modern commercial tools, which have little reason to maintain data on exchanges that closed a decade ago.

🔍 Private investigation and corporate security

Cheap, immediate and useful for the first hour of a Bitcoin asset trace, particularly for establishing whether a subject address belongs to a large service cluster – which usually means the assets are in custody somewhere and the question becomes a legal one rather than a technical one. Do not quote balances from it to a client without verifying against a live explorer, because index lag will make you look careless at exactly the wrong moment. Explain clustering to clients explicitly: they will assume a wallet is a person, and the gap between a cluster and a legal person is where professional negligence lives. For older matters the historical naming can identify a defunct exchange that other tools no longer recognise, which occasionally revives a trace that had appeared to dead-end. Use it as a first pass and corroborate anything consequential.

📰 Journalism and OSINT media

Good for showing readers how Bitcoin tracing actually works, because the cluster is inspectable and the reasoning can be explained in a paragraph without hand-waving. Also useful for historical stories about early exchanges, defunct marketplaces and long-running scams where the naming predates commercial products. Publishing discipline: state that a wallet is a cluster produced by a heuristic, not a person; publish transaction hashes; verify balances and recent activity against a live source before printing them, since a stale index will hand you a wrong number with total confidence; and never name an individual on the basis of a cluster. Where the source is a free, unmaintained service, say so in the methodology note – readers and subjects both deserve to know that the underlying tool has no service commitment behind it.

🌍 NGO, humanitarian and human rights

Relevant mainly to research and documentation rather than casework: reconstructing how a fraud or extortion operation moved value, or evidencing the scale of a scheme for an advocacy or policy audience. The clustering view lets you show aggregate flows without publishing individual addresses, which is a meaningful protection when victims can be identified from their own payments. For direct victim support the practical use is limited and the referral route matters more – the appropriate national reporting channel, and a clear warning about recovery-fraud operators who target victims a second time. Treat any address linked to an identified person as sensitive personal data with the retention and handling discipline that implies, and remember that the linkage is permanent because the chain is permanent.

🎓 University and research

This is a good teaching instrument and a reasonable comparator, and a poor primary dataset. It is excellent for teaching clustering because students can see the transactions that produce a merge and can be shown, concretely, where the heuristic fails – which is the lesson that matters. It is a reasonable comparator for evaluating clustering implementations, since its output is public and stable enough to reference. It is a poor primary dataset because there is no versioning, no documented methodology, no currency guarantee and no licence clarity, so results built on it are not reproducible in the sense a reviewer should require. The defensible pattern is to reproduce clustering from public chain data with published code, use this source to sanity-check, and cite the foundational academic literature on address clustering and its failure modes rather than leaning on a tool for methodological authority.

Playbook: working OXT / WalletExplorer 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 index currency before anything else

Find the most recent block the tool has processed and compare it to the current chain tip from an independent source. If the gap is material, every present-tense statement the tool makes is unreliable and you have just learned the most important thing about your data. This check takes thirty seconds and analysts skip it constantly.

Phase 2 — Classify the cluster before interpreting it

Look at address count, total received, transaction frequency and counterparty diversity. Enormous, continuously active clusters with thousands of counterparties are services. Small, sporadic clusters are individuals or single-purpose wallets. Everything you conclude afterwards depends on getting this classification right, and it is a five-minute judgement that prevents most catastrophic errors.

Phase 3 — Inspect the merges that built the cluster

Identify the transactions that joined the largest address groups and look at them directly. If a merge came through a transaction with many equal-value outputs and inputs from many parties, you may be looking at a collaborative transaction and the cluster may be an artefact. This is the check that distinguishes an analyst from an operator of software.

Phase 4 — Separate the payment from the change on every hop

For each transaction you intend to follow, decide which output continued to your subject and which went to a counterparty, and write down why – address type, round-number amount, subsequent spending behaviour, or the fact that one output returns to a known cluster. A trace that never states its change reasoning cannot be reviewed and is usually wrong somewhere.

Phase 5 — Map the named service boundaries

List every named cluster touching your subject and mark which are exchanges, payment processors, gambling services or mixing services. These are the points where the on-chain trail ends and the legal route begins. Identifying them early tells you whether the case is viable at all and where the process request has to go.

Phase 6 — Verify service names against a second source

Take each name that matters and check it against a modern explorer, a second tracing tool or the service's own published addresses. Names here can be a decade old. A name that survives independent corroboration is usable; one that does not becomes a line of enquiry rather than a fact.

Phase 7 — Take live facts from a live source

Balances, recent counterparties and current status come from an independent explorer or your own node, never from a possibly stale index. Use this tool for structure – clusters, historical naming, relationships – and take anything present-tense from somewhere with a currency guarantee. Mixing the two silently is the most common way this source produces a wrong report.

Phase 8 — Reconstruct historical state at the relevant height

For questions about what was held or what had happened at a specific past moment, work from the transaction list up to that block height rather than from any displayed total. Stating balances as at a block height is both more accurate and more defensible than any figure the interface offers, and it is the form an expert report should take anyway.

Phase 9 — Cross-check the cluster against an independent clustering

Run the same seed address through another tool and compare cluster boundaries. Agreement on a boundary is real corroboration because the implementations differ. Disagreement identifies precisely which merge is contested, and that merge is exactly where an opposing expert will attack, so you want to find it first.

Phase 10 — Screen the constituent addresses against designation lists

Check individual addresses against authoritative sanctions sources, and be precise about the difference between a listed address and a cluster containing one. Designation attaches to what is listed; extending it to an entire heuristic cluster is a legal argument, not a technical fact, and stating it as the latter is a serious error.

Phase 11 — Document the method in transferable terms

Write down the heuristic used, the change-identification reasoning, the clustering source with the date and index height, and the known failure modes. This section is what makes the work reviewable and, in litigation, admissible. It also forces you to notice the steps you took on assumption rather than on evidence.

Phase 12 — Decide what you would need to be wrong about

Identify the single merge or change decision on which your conclusion most depends, and ask what would happen if it were reversed. If the answer is that the conclusion collapses, either strengthen that step with independent evidence or weaken the conclusion. This is the difference between a finding and a story that happens to be consistent with the data.

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
Blockstream Esplora	corroborates	Open-source Bitcoin explorer and REST API you can self-host, giving current chain state, full transaction structure and script detail with no index-lag problem and no third-party visibility into your queries.
Blockchair	extends	Multi-chain explorer with a query API and bulk dumps, which supports the filtering and aggregate questions a cluster-oriented interface cannot express.
mempool.space	corroborates	Live Bitcoin explorer with strong mempool, fee and block detail, and the fastest way to confirm current chain tip and recent activity when checking another tool's currency.
MetaSleuth	extends	Commercial multi-chain tracing with modern labelling and cross-chain inference, covering the ground where this source is weakest – recent activity and anything beyond Bitcoin.
MistTrack	corroborates	Second commercial labelling source with different regional coverage, useful for checking whether a historical service name still corresponds to anything in the present ecosystem.
OFAC Sanctions List Search	prerequisite	Authoritative United States designations including listed digital currency addresses, which is where a sanctions question is answered rather than inferred from a cluster.
Bitcoin Improvement Proposals	prerequisite	The specifications behind address formats, hierarchical deterministic wallets and transaction features, which is what you need to understand why clustering works and where it breaks.
OXT	extends	A Bitcoin analytics platform associated with the Samourai Wallet team offering entity views and transaction entropy analysis. Availability has been unreliable since 2024 enforcement action against that team; verify status before relying on it and treat it as a historical reference.

Legal, ethical and operational constraints

Reading public blockchain data is lawful and requires no authority anywhere that matters. The complications are downstream. Clustering produces an assertion about who controls what, and that assertion, applied to an identified person, is personal data processing subject to the usual obligations of lawful basis, purpose limitation and retention – and it is also a claim you may have to defend. Presenting a heuristic cluster as established fact in a legal filing is where investigators get into difficulty; the honest formulation states the heuristic, its acceptance in the field, and its known failure conditions, and it survives challenge far better than an unqualified assertion. Sanctions designations attach to specific listed addresses; treating every address in a cluster as designated is a legal position that may be correct in a given regime but is not a technical conclusion and should never be presented as one. The licence position of the derived cluster and naming layer is unclear because there is no licence page, so investigative use with citation is safe and republishing the dataset is not. Where the analysis is load-bearing, reproduce the clustering yourself so the method rather than the tool is what you are defending.

Operational security

Queries to a public web service reveal to whoever operates and observes it which addresses you are researching and when. For a free service with an uncertain maintenance and ownership picture, that is a consideration worth taking seriously rather than dismissing: you cannot audit its logging, you do not know who has access, and the browsing pattern of an investigator is a legible document. For sensitive work the answer is straightforward and permanent – run your own Bitcoin node with an index, do the clustering yourself, and disclose nothing to anyone. It costs a machine and some disk and it removes the entire problem, which is why serious programmes do it. Where you do use the public service, avoid distinctive sequences that reconstruct your reasoning, do not query addresses whose sensitivity lies in the fact of your interest, and remember that browser-level identifiers persist across sessions. The same reasoning applies with more force to OXT given its enforcement history: understand whose infrastructure you are touching before you touch it.

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 OXT / WalletExplorer is contributing anything, and they are worth baselining now so the answer is available later.

Index lag at time of use, recorded per query, which is the single most important quality measure for this source and the one nobody tracks until it causes a problem.
Proportion of counterparty clusters that carry a service name, which measures how often the tool actually delivers the thing you came for on your case mix.
Rate at which service names survive independent corroboration against a modern source, which tells you how much of the naming layer is still describing the present.
Frequency of cluster-boundary disagreement with an independent clustering implementation, which is a direct measure of how contestable your attributions are.
Share of Bitcoin traces where this source identified a defunct or historical service that no other tool recognised, which is the specific niche justifying its continued use.
Number of occasions where a present-tense figure taken from this source had to be corrected against a live explorer, which should be zero and will not be until the currency check becomes routine.
Time from seed address to identification of the first named service boundary, since that interval drives how quickly preservation requests can be issued.

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 wallet is a hypothesis. It is what a heuristic produced from co-spending behaviour, and it can be too large, too small or simply wrong – state it as an assertion with a method behind it, never as an entity that exists.
Check the last indexed block before you read anything else on the page. Every present-tense conclusion depends on it and the interface will not stop you drawing one anyway.
Write down your change-output reasoning at every hop. An unstated change decision is an unreviewable trace, and change decisions are where traces silently go wrong.
Equal-value outputs with many inputs are a warning, not a windfall. Collaborative transactions are designed to defeat the ownership assumption, and clustering across one merges unrelated parties.
A batch payout does not relate its recipients to each other. Exchange withdrawals are batched constantly, and reading co-recipients as associates is a fabrication that looks like analysis.
Cluster size classifies before it informs. Millions of addresses means infrastructure; a handful may be an artefact; neither tells you the party matters to your case.
Old service names are an asset, not a defect. This source knows about exchanges that closed years ago, and modern commercial tools frequently do not – which makes it the right first stop on a cold case.
Take structure from here and facts from a node. Clusters and historical names are what this source is for; balances, recent activity and current status are not.
If the conclusion matters, reproduce the clustering yourself. Defending your own documented method is possible; defending an unmaintained free tool's undocumented output is not.

Questions analysts actually ask

Is the data current?

Do not assume so. Indexing currency on this service has varied considerably over its life and there is no service commitment behind it. Establish the most recent indexed block yourself and compare with the live chain tip before treating any balance, recent transaction or counterparty list as present-tense. Use it for structure and history; take current facts from a live explorer or your own node.

What exactly is a wallet here?

A cluster of addresses that a heuristic concluded are controlled by one party, principally because they were spent together as inputs to the same transaction. It is a derived construct rather than something recorded on the chain. It can be too large when collaborative transactions are misread, and too small when a careful party never co-spends.

How were the service names established?

Historically by transacting with services and observing which cluster the funds reached, which is a directly evidenced method and better than an unexplained vendor label. The weakness is age rather than method: a name established years ago may describe an entity that has since closed, rebranded or migrated its infrastructure, so corroborate names that carry weight.

Can I use this instead of a commercial tracing product?

For historical Bitcoin work, often yes, and it has the advantage of being inspectable. For current investigations it is a second opinion rather than a primary source, because currency is unreliable, coverage stops at Bitcoin, and there is no support. The reasonable posture is to use it alongside a modern tool rather than instead of one.

What is OXT and can I still use it?

OXT was a Bitcoin analytics platform associated with the Samourai Wallet development team, notable for entity views and transaction entropy analysis that measured how ambiguous a transaction's interpretation is. Following United States enforcement action against that team in 2024 its availability has been unreliable. Verify current status yourself before citing it, and treat it as a historical analytical reference.

Why do two tools show different clusters for the same address?

Because they implement different heuristics and apply them to different chain snapshots. One may include change-output heuristics the other omits, or exclude transactions it identifies as collaborative. The disagreement is useful: it isolates the specific merge that is contested, which is where any competent challenge to your analysis will start.

Does clustering identify a person?

No. It identifies a set of addresses probably under common control. The controller may be an individual, a company, a service holding customer funds, or several people sharing keys. Turning a cluster into a person requires off-chain evidence, usually records held by a regulated service and obtainable only through legal process.

Is it safe to automate queries against it?

Only lightly, honestly identified, and cached. This is an unfunded free service and heavy automated use degrades it for everyone. If your question requires volume, the right answer is a local node with an index, which is unlimited, private and gives you a method you can document.

Should I cite it in a report?

Yes, with the date, the observed index height and an explicit statement that clusters are heuristic. Citing a source and disclosing its limitations is what makes a report credible. What you should not do is present its clusters or names as established facts without qualification, because a competent reviewer will know exactly how they were produced.

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:

The common-input-ownership heuristic, the foundational clustering assumption in Bitcoin analysis, together with the academic literature documenting both its effectiveness and the conditions under which it fails.
Bitcoin Improvement Proposals covering address formats and hierarchical deterministic wallets, which explain why one party generates many addresses and therefore why clustering is necessary at all.
The UTXO transaction model, in which a transaction consumes and creates outputs rather than moving a balance between accounts – the reason change identification is a separate analytical problem with no equivalent on account-based chains.
Script and address types, which distinguish legacy, script-hash, native segwit and taproot outputs and provide one of the more reliable change-identification signals.
MISP cryptocurrency attribute types, the practical route for sharing Bitcoin address indicators with partners in a structured form.
FATF virtual asset service provider definitions, which determine whether the named service at the end of a trace has any obligation to respond to legal process.
Transaction entropy and deterministic link analysis as developed in the Bitcoin privacy research literature, which formalise how ambiguous a transaction's interpretation is and are the correct antidote to overconfident tracing.

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.

WalletExplorer — WalletExplorer. The service itself, including its own description of how wallets are grouped and how services were identified. Read that description before using the output; it is more candid about method than most commercial products.
Blockstream Esplora — Blockstream. Live Bitcoin explorer with an open REST API and self-hostable source, the natural currency check and the private alternative for anything sensitive.
mempool.space — mempool.space. Live explorer with detailed mempool, fee and block views. The quickest way to establish the current chain tip when assessing another tool's index lag.
Blockchair — Blockchair. Multi-chain explorer with a documented query API and bulk data, for aggregate questions and for cross-checking Bitcoin facts against an independent index.
Bitcoin developer documentation — Bitcoin Project. Authoritative grounding in the UTXO model, transaction structure and script types, without which clustering and change analysis are cargo cult rather than method.
Bitcoin Improvement Proposals — Bitcoin BIPs repository. The specifications for address formats, deterministic wallets and transaction features that determine what patterns clustering can and cannot see.
Bitcoin white paper — Satoshi Nakamoto. Worth reading for the privacy section alone, which anticipated address reuse as the weakness that clustering exploits and stated the intended mitigation.
OFAC Sanctions List Search — US Department of the Treasury, Office of Foreign Assets Control. Authoritative designations including listed digital currency addresses. Designation attaches to what is listed, not to a heuristic cluster containing it.
Financial Action Task Force — FATF. The virtual asset standards defining which services at the end of a Bitcoin trace are regulated and therefore reachable by legal process.
MetaSleuth — BlockSec. Modern multi-chain tracing tool, useful as the current-data counterpart to this source's historical strength and as an independent check on cluster boundaries.
Chainalysis — Chainalysis. The commercial firm whose orbit this project entered when its author joined. Relevant background on provenance, and its published research is a reasonable public window on how industrial clustering is done.
Europol — European Union Agency for Law Enforcement Cooperation. Threat assessments and coordination mechanisms for cross-border cryptocurrency investigation, which is where a trace goes once the named service sits in another jurisdiction.

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 keeps clusters as dated, source-attributed hypotheses rather than entities, records the observed index height alongside every collected record, reconciles balances against a live source through resolve-everything.php, and preserves the underlying Bitcoin transactions on blockchain.php so the evidence outlives the tool.. Browse the full source catalogue, or follow any tag above into the rest of the library.