mempool.space / Blockchain.com: Intelligence Source Guide

Two public Bitcoin block explorers with open, keyless APIs. Between them they give you the raw on-chain record – transactions, outputs, addresses, block timing and mempool state – which is the ground truth that every commercial tracing product is built on top of and occasionally disagrees with.

At a glance

Source	mempool.space / Blockchain.com
Category	Cryptocurrency & Blockchain › Blockchain Explorers
Homepage	https://mempool.space/
Machine interface	`https://mempool.space/api/`
Format	`JSON`
Access	Open — no account required
Disciplines	Cryptocurrency Intelligence
Mission domains	Financial Crime, Anti-Money Laundering, Ransomware, Dark Web Intel

On-chain transaction & address analytics. — as catalogued in the platform’s own source registry.

A block explorer is a web front end and API over an indexed copy of a blockchain. The chain itself is a sequence of blocks containing transactions; it has no concept of an address balance, a transaction history or a search index. An explorer runs a full node, builds those indexes, and exposes them. mempool.space is an open-source Bitcoin explorer and mempool visualiser operated by Mempool Space K.K. It serves Bitcoin mainnet, the test networks, the Liquid sidechain and a separate Lightning Network view, and it is unusual among explorers in treating the unconfirmed mempool as a first-class object rather than an afterthought: projected block composition, fee-rate bands, replace-by-fee chains, difficulty adjustment progress and mining pool attribution of recent blocks are all presented as data rather than as decoration. Its REST API follows the Esplora scheme originally published by Blockstream, so client code written against one works against the other with a base-URL change. Blockchain.com Explorer is the descendant of blockchain.info, one of the oldest Bitcoin explorers in existence, and covers Bitcoin, Ethereum and Bitcoin Cash. Its long-standing data API returns raw address, raw transaction, multi-address and unspent-output views as JSON, along with chart and statistics endpoints and a streaming interface for new blocks and transactions. It is operated by Blockchain.com, a custodial wallet and exchange business, and the explorer sits inside that commercial context.

The analytical job these do that nothing else does is settle questions of fact about the chain, for free, without a vendor between you and the data. When a commercial tracing tool says an address received 3.2 BTC on a date, the explorer is where you confirm that the transaction exists, which outputs it created, how many confirmations it has, and what the block timestamp actually was. That confirmation step is not ceremonial. Tracing products layer attribution, clustering and risk scoring on top of the chain, and all three of those are inference. The chain data underneath is not. For CRYPTINT work the practical division is: use the explorer for what happened, use a clustering vendor or your own analysis for who and why, and never let the second silently overwrite the first in your notes. There is a second job that matters more than analysts expect. mempool.space in particular exposes the pre-confirmation state of the network – what is sitting unconfirmed, at what fee rate, with what replacement history – which is where you observe behaviour rather than outcomes. A ransom payment being fee-bumped repeatedly, a consolidation sweep timed to a low-fee window, a transaction replaced three times before confirming: all of that is visible only while it is in flight and is invisible in the confirmed record. The confirmed chain tells you what settled. The mempool tells you what someone was trying to do.

Who publishes it, and why that matters

The two operators have different shapes and you should treat their output accordingly. mempool.space is a small open-source project turned company, with the code public and self-hostable. Its revenue comes from enterprise instances, sponsorship and a paid transaction acceleration service. That model has two consequences worth naming: the public instance is a free service with no obligation to you, and heavy programmatic use of it is a cost the operator carries on your behalf. If your work depends on the data, you run your own instance – the software is designed for exactly that and the project publishes the means to do it. Blockchain.com is a venture-funded custodial wallet and exchange company, and the explorer is a legacy asset from an era when it was the company's main product. It is stable and widely used, but it is not the business, and the API has accumulated the usual marks of that: endpoints that predate the modern site, documentation that lags the implementation, and periodic changes to limits and access without much warning. Neither operator is a records custodian and neither will certify anything for you. There is also a structural point that applies to all explorers: they are re-serving a public dataset that anyone can regenerate from the chain itself. That is why they are cheap and why they are replaceable, and it is the reason no finding should ever depend on a single explorer's continued existence.

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
`txid`	string	The transaction identifier, a hash of the transaction. For post-SegWit transactions the txid excludes witness data, so it is stable against signature malleability, while the separate wtxid includes it. It is the primary key for everything in a chain investigation.	The full transaction, its inputs and outputs, its containing block, and any child transaction that spends its outputs.
`vin (inputs)`	array	The outputs this transaction spends, each identified by the previous txid and output index. Inputs are where the money came from, and following them backwards is the whole of provenance analysis. An input does not name a person, only a prior output.	The funding transactions one hop back, and from there the entire backward history to coinbase.
`vout (outputs)`	array	The outputs created, each with a value in satoshis, a locking script and, where the script is standard, a derived address. One of these is usually payment and one is usually change, and the explorer does not tell you which.	The spending transaction for each output, which is the forward trace, and the address page for each derived address.
`address`	string	A derived, human-usable encoding of an output script. It is not an account and not an identity. A single wallet routinely uses thousands of addresses; a single address may be reused by an exchange for many customers or by nobody more than once.	All transactions touching that address, its current unspent outputs, and its aggregate received and sent totals as computed by the indexer.
`value`	int	Amount in satoshis, the smallest on-chain unit at one hundred-millionth of a bitcoin. Explorers display bitcoin, APIs return satoshis, and the conversion is the single most common unit error in crypto tooling.	none
`block_height`	int	The position of the containing block in the chain. Height is a reliable ordering key. It is the field to use when you need to say which of two transactions came first, because timestamps are not dependable for that.	The block, its sibling transactions, and the mining pool credited with it.
`block_time`	timestamp	The timestamp in the block header, chosen by the miner. Consensus rules require only that it exceed the median of the preceding eleven blocks and not run more than about two hours ahead of network-adjusted time. It is an approximation, not a clock reading.	The surrounding blocks, whose timestamps constrain the plausible real time window.
`first_seen / received_time`	timestamp	When the explorer's own node first heard the unconfirmed transaction. It is a property of that node's position in the network, not of the transaction. Two explorers will report different values for the same transaction, and neither is the broadcast time.	none
`confirmations`	int	How many blocks have been built on top of the containing block. It is a derived, moment-in-time value and it goes up continuously, so recording it without recording when you recorded it is meaningless.	none
`fee / fee_rate`	int	The difference between input and output value, and that amount divided by transaction weight in virtual bytes. Fee rate is behavioural evidence: an unusually high rate signals urgency and an unusually low one signals a batch or sweep that could wait.	The mempool fee bands at the time, which show whether the payer was overpaying or queueing.
`rbf / replacement flags`	enum	Whether a transaction signalled replaceability and whether it was in fact replaced. mempool.space tracks replacement chains, so you can see the sequence of versions of one intended payment rather than only the version that survived.	The replaced and replacing transactions, which frequently differ in outputs as well as in fee.
`scriptpubkey_type`	enum	The output script type – pay-to-public-key-hash, pay-to-script-hash, witness variants and Taproot. Script type is a soft fingerprint of wallet software and vintage, and a change in script type across a wallet's history usually means a software migration.	Address-format cohorts, which help distinguish self-transfers from payments to third parties.
`mining pool attribution`	string	The pool credited with a block, inferred from coinbase transaction tags and payout patterns rather than declared by the protocol. It is a well-established heuristic and it is still a heuristic, and small or new pools are frequently unattributed or misattributed.	The pool's other blocks and its public infrastructure, which is a rare route from chain data to a named operating entity.
`mempool state (fee histogram, projected blocks)`	array	The set of unconfirmed transactions this node holds, summarised by fee-rate band and projected into the next few blocks. It is inherently a local view, and it is transient – nothing retains it unless you record it.	none

Coverage — and what is not in it

Coverage is defined by the chain, not by the operator, which is an unusual and useful property: for Bitcoin these explorers hold every transaction since the genesis block in January 2009, complete, with no sampling and no editorial selection. There is no coverage window to check and no backfill gap. What varies between explorers is index depth rather than data: whether address histories are indexed to full depth, how far back mempool and fee history is retained, whether replaced transactions are kept after replacement, and whether ancillary layers are served at all. mempool.space covers Bitcoin mainnet and test networks, the Liquid sidechain, and maintains a separate Lightning Network view built from public channel announcements, which is a different dataset with completely different properties – it shows public channels and node metadata, not payments. Blockchain.com Explorer covers Bitcoin, Ethereum and Bitcoin Cash, so it reaches one major account-model chain that mempool.space does not. Update rhythm is the chain's: a new Bitcoin block roughly every ten minutes on average with very wide variance, and mempool contents changing continuously. Neither covers the chains where a large share of contemporary illicit value actually moves – Tron and the Ethereum layer-two networks carry most stablecoin flow, and none of that is visible here. Geographic coverage is a category error: the chain has no geography, and any country attached to an address by any tool is an inference made elsewhere.

Known blind spots

Absence of evidence here is not evidence of absence. These are the conditions under which mempool.space / Blockchain.com will not show you something that is nevertheless real:

No identity, ever. The chain contains scripts and values. Every attribution of an address to a person, exchange, service or country comes from off-chain information, and an explorer that displays a label is displaying somebody else's inference, not chain data.
No clustering. These explorers show you one address at a time. They will not tell you that fifty addresses belong to the same wallet, which is the single most important analytical step in following funds, and doing it yourself requires heuristics that these tools deliberately do not apply.
Change outputs are not marked. The protocol does not distinguish payment from change, and an explorer will not guess. Reading the larger output as the payment is wrong often enough to break a trace within three hops.
Bitcoin-centric. mempool.space is Bitcoin, Liquid and Lightning only. Most illicit stablecoin movement happens on Tron and Ethereum-family chains, and a Bitcoin-only view of a case that touches those will look artificially clean.
The mempool is not global and is not retained. What an explorer shows as unconfirmed is what its node happened to receive, filtered by its relay policy. Transactions that never propagated widely, were relayed only to a mining pool, or paid below the relay minimum may confirm without ever appearing.
Lightning payments are invisible. Channel opens and closes appear on chain; everything that happened between them does not. A route through Lightning breaks a chain trace completely, and the public channel graph does not recover it.
CoinJoin and similar collaborative transactions defeat naive input analysis, and privacy-preserving spend paths such as Taproot key-path spends make multisignature and single-signature arrangements indistinguishable from the outside.
No subpoena value on its own. An explorer is a third party re-serving public data with no chain of custody, no attestation and no obligation to preserve. For evidentiary purposes you want the raw block data verified against your own node, not a screenshot of a website.
Off-chain internal transfers at custodians leave no trace. Value moving between two customers of the same exchange never touches the chain, so a trail that ends at an exchange deposit address ends there in fact, not merely in your visibility.

Write the blind spot into the product. A statement that something “was not observed in mempool.space / Blockchain.com” 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

Both are open in the browser with no account and both expose HTTP APIs that return JSON without a key. mempool.space serves an Esplora-compatible REST interface covering transactions, addresses, blocks, mempool state and fee recommendations, documented on its own site; the same interface is available on any self-hosted instance, on the project's test network deployments and on other operators running the same software, which means you can point identical code at a different provider in a configuration change. Blockchain.com exposes its long-standing data API returning raw address and transaction objects, multi-address queries, unspent outputs and chain statistics, along with a streaming interface for live blocks and transactions; higher-volume use has historically required requesting an API key from the operator, and the terms attached to that have changed over the years, so confirm current arrangements before designing around them. For any serious operation the correct access route is neither: run Bitcoin Core with an indexing layer and, if you want the same interface, the mempool software on top of it. That converts a rate-limited dependency on somebody else's goodwill into a local resource with no query disclosure and no throttling, at the cost of disk, bandwidth and an initial sync measured in days.

Licence

The underlying data has no owner. Blockchain contents are public by construction and no licence attaches to a transaction, so nothing prevents you from copying, republishing, analysing or selling analysis of the chain. What is licensed is the software and the service. The mempool project's source is published openly and self-hosting is an intended use; confirm the current licence text in the repository rather than assuming, because open-source projects in this space have changed terms and the practical questions – whether you may run a modified commercial instance, whether attribution is required – are answered there and not by general expectation. Access to the operators' hosted instances is governed by their terms of service, which is a separate matter from the data licence and is where bulk scraping, resale of API responses and automated high-volume querying are usually addressed. The honest summary is that you almost certainly may use what you retrieve, and you may not be entitled to retrieve it at the volume you want from someone else's server. If you intend to build a commercial product on this data, build it on your own node.

Rate limits and fair use

There is no published quota you can rely on and that is exactly why discipline matters. Treat the public instances as a shared resource: one request at a time per host, a deliberate pause between calls, a user agent that identifies you with a contact address, exponential backoff on any error, and no retries on a timeout until you have waited. Cache aggressively, because the data is immutable. A confirmed transaction never changes, a block at a given height never changes once buried, and a spent output stays spent – so any request you make twice for confirmed data is a request you should have answered from your own store. Poll rhythms should match the chain: new blocks arrive roughly every ten minutes, so a block poller running more often than once a minute is wasting both parties' resources, and a websocket or streaming subscription is better than polling if the provider offers one. Mempool state is the exception that genuinely changes second to second, and if you need it at that resolution you need your own node, because taking it at that resolution from a public instance is abuse. Bulk work – walking an address history of thousands of transactions, or backfilling a range of blocks – should be rate-limited to something you would be comfortable explaining, and is the case where self-hosting stops being advice and becomes a requirement.

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 mempool.space / Blockchain.com 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
Targeted transaction and address lookup	JSON	On demand	The workhorse. Fetch a transaction by identifier or an address history, store the raw response verbatim, and never fetch it again. This is nearly all of what an investigation actually needs and it is a trivial load if you cache.
Forward and backward hop walking	JSON	On demand, breadth-limited	Recursive traversal of inputs and spending transactions to a fixed depth. Enforce a hard hop limit and a fan-out limit before you start, because an unconstrained walk from a busy address will pull tens of thousands of transactions and tell you nothing.
Watched-address monitoring	JSON	Every few minutes for live cases	Poll a small set of case-relevant addresses for new activity. Keep the set small and the interval honest; the reason to watch is that movement is the event, and movement on a dormant address is one of the highest-value alerts in crypto casework.
Block-by-block ingestion	JSON	Once per block	Follow the chain tip and pull each new block with its transactions. This is the only collection pattern that gives you a complete local record, and past a modest scale it should run against your own node rather than a public API.
Mempool state sampling	JSON	Minutes, while a case is live	Snapshot fee bands and unconfirmed transactions of interest. Nothing else preserves the pre-confirmation picture, including replacement attempts that vanish from the record once a version confirms.
Streaming subscription	JSON	Continuous	Where a live socket interface is offered, subscribing to new blocks and to transactions touching watched addresses is both lower latency and lower load than polling. Reconnect logic and gap backfill are mandatory, because a dropped socket silently stops your monitoring.

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.

Normalise units and identifiers at the boundary — ingest.php converts every value to satoshis and every identifier to a canonical lower-case hex form on arrival, so that data from two explorers with different display conventions compares cleanly. Unit mismatch between bitcoin and satoshis is the most frequent silent corruption in crypto pipelines.
Store the raw response alongside the parsed record — import.php retains the original JSON as fetched, with the retrieval timestamp and the instance it came from. Derived records are rebuilt from that store rather than refetched, which makes the pipeline reproducible and removes the temptation to hit the API again.
Register addresses and transactions as distinct entity types — resolve-everything.php creates crypto address and transaction entities and links them through inputs and outputs, so that the graph carries the actual directed relationships rather than a flat list of strings found in a case file.
Keep confirmation state as a snapshot, not a fact — Confirmation counts and mempool membership are recorded with the time they were observed, because both change continuously. A record asserting that a transaction has two confirmations, with no timestamp, is worse than no record.
Attach abuse reports without merging them into chain data — enrich.php joins community reports and blocklist hits from separate sources onto an address entity as annotations. The chain fact and the allegation stay in separate layers, so an analyst can always see which is which and downstream export does not launder one into the other.
Reconcile across explorers before asserting a discrepancy — correlate.php compares the same transaction retrieved from two instances. Agreement on outputs and block height is the expected case; disagreement almost always means a reorg, an indexing lag or a replaced transaction rather than an error worth reporting.
Route by mission rather than by chain — Addresses tied to extortion payment demands surface in ransomware.php, sanctioned-entity addresses in sanctions.php, and laundering typologies in financial-crime.php and blockchain.php. Routing is on the case context attached to the address, never on any model output – no attribution in the platform originates from a language model.
Preserve provenance through to export — export.php carries the source instance, retrieval time and block height with every on-chain fact into STIX 2.1 or CSV, so a recipient can re-derive the same claim from the chain rather than trusting the platform's copy of it.

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.

For the chain data itself, quality is as high as any source in this library and for an unusual reason: the data is verifiable rather than trusted. Anyone with a full node can independently confirm that a transaction exists, what it spends, what it creates and which block contains it, and any explorer that got it wrong would be visibly and immediately wrong. Errors in practice are not falsehoods but lags and gaps: an index that has not caught up with the tip, an address history truncated by pagination, a brief inconsistency during a chain reorganisation. Derived fields are a different matter and should be graded separately. Mining pool attribution is heuristic. First-seen timestamps are observations by one node. Fee-rate projections are estimates about the future and are wrong routinely. Address balance is an indexer's aggregation and is correct arithmetic over a possibly incomplete history if pagination was mishandled. The correct posture is to treat consensus-level facts – transaction contents, block inclusion, height – as reliable to the point where doubting them is a waste of time, and to treat everything the explorer computed on top of them as an analytic product with the same scepticism you would apply to any other vendor's inference.

Characteristic false positives

Block timestamps read as event times. A miner sets the timestamp within a wide permitted window, so blocks can appear out of chronological order and a timestamp can be off by up to roughly two hours. Any timeline built on block time to the minute is fiction; use height for ordering.
First-seen time treated as broadcast time. It is when one node in one network position heard the transaction. Different explorers report different values, none of them identifies the originator, and none of them supports a claim about when or where a payment was initiated.
The larger output assumed to be the payment. Change is frequently the larger output, particularly when a wallet spends a big input for a small purchase, and this single assumption reverses the direction of more traces than any other error.
Address treated as person. Exchange deposit addresses are assigned per customer but are controlled by the exchange; payment processor addresses aggregate many merchants; and one human routinely controls thousands of addresses. Value arriving at an address says nothing about who received it.
Dusting and address poisoning read as relationships. Anyone can send a tiny amount to any address without permission, and attackers deliberately send dust from addresses whose first and last characters mimic a legitimate counterparty. The resulting entry in the address history is an attack, not a transaction between the parties.
Consolidation misread as payment. A wallet sweeping many of its own outputs into one produces a transaction that looks like dozens of parties paying one recipient. It is one party tidying up, and treating the inputs as distinct payers manufactures a network that does not exist.
Replaced transactions cited as real payments. A replace-by-fee chain contains versions that never confirmed and never moved value. Screenshots of a since-replaced transaction circulate as evidence of payments that did not happen.
Balance confused with control. An address holding value may be a burn address, a multisignature arrangement requiring keys held by several parties, a lost wallet, or a contract-like construction. Holding is not spending capability.

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

The confirmed record does not age at all. A transaction from 2013 is exactly as true today as it was then, and this is one of the few sources in the catalogue where a decade-old record needs no revalidation. Three things around it age quickly. Confirmation counts and balances are moment-in-time and are stale the instant you record them; store them with an observation timestamp or do not store them. Mempool state ages in seconds and is gone permanently once transactions confirm or expire, so anything you did not capture while it was live is unrecoverable from any explorer. And attribution ages worst of all: an address labelled as belonging to a particular exchange, service or actor reflects a moment in that entity's operational history, and services rotate infrastructure, get seized, rebrand and hand over custody. A five-year-old label on an address is a hypothesis about the past, not a statement about the present. The practical rule is that a stale on-chain record looks perfectly healthy – it is still correct about the chain – while being completely wrong about the world, which is exactly the failure mode that survives review.

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

How each sector uses mempool.space / Blockchain.com

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

Relevance is mainly in threat finance and force protection rather than in tracing for its own sake. Extortion payments against contractors and partner-nation infrastructure, procurement of dual-use goods through crypto-settled channels, and financing flows around proscribed groups all leave chain traces that these explorers make examinable without a vendor contract or a classification barrier. The unclassified, verifiable nature of the data is the operational advantage: an on-chain fact can be shown to a coalition partner or a host-nation authority in full, with no source protection question, and they can confirm it independently. The discipline to impose is separating chain fact from attribution, because in a coalition setting an unlabelled inference travels further and faster than it should. Note also that Bitcoin-only visibility understates the picture in most contemporary financing cases, where stablecoins on other chains carry the volume.

🕵 National intelligence

For CRYPTINT this is the baseline collection layer and the check on everything above it. Sanctions evasion, procurement networks and state-linked theft operations are examined here at the level of what actually moved and when, in a form that can be re-derived by anyone with a node – which matters when a judgement will be challenged. The pre-confirmation view is the underused capability: fee-bumping behaviour, replacement patterns and timing relative to fee conditions are behavioural indicators about the operator, not just about the funds. Analysts should hold two lines firmly. First, the chain is complete and the attribution is not, so confidence in a flow should never be inherited by the entity claim attached to it. Second, off-chain settlement inside custodians and any hop through Lightning or a cross-chain bridge is a genuine break, and reporting should say so rather than presenting a trace as continuous when it is not.

👮 Law enforcement

Investigators use explorers for three jobs: verifying a subject's transactions before drafting process, identifying the service that received funds so that process can be directed at the right custodian, and monitoring dormant addresses for movement that indicates a suspect acting. The trace supports the request; the custodian's records supply the identity. For evidentiary purposes, treat the explorer as a lead-generation and verification tool and take the actual evidence from a node you or a forensic examiner control, with hashes recorded, because a third-party website printout has weak provenance and the defence will say so. Two errors recur in disclosure: presenting a replaced transaction as a completed payment, and presenting a clustering assumption as an observed fact. Both are avoidable by describing exactly what the chain shows and separately describing what you inferred.

🔍 Private investigation and corporate security

For asset tracing, fraud recovery and due diligence this is a free, high-quality starting point that answers the questions clients actually ask: did the money leave, where did it go in the first few hops, and is it still sitting somewhere. Movement monitoring on known addresses is cheap and often decisive, because dormant funds moving is the trigger for urgent civil steps. Be candid with clients about the limit: the trace typically ends at an exchange deposit address, and going further requires legal process, not better tooling. Selling a client a report that names a beneficial owner on the basis of an unlabelled cluster is the characteristic failure of this work. The other practical caution is that recovery services promising to trace and retrieve funds are themselves a large fraud category, and referring a victim to one is a real harm.

📰 Journalism and OSINT media

Chain data is a rare thing in reporting: a primary source the reader can check themselves. A story can cite a transaction identifier and any reader with a browser can verify the amount, the date and the destination, which is a standard of verifiability almost no other beat offers. That strength is also the trap. The chain will support a claim that funds moved between two outputs; it will not support a claim about who controlled either, and the gap between those two sentences is where most flawed crypto reporting lives. Practical craft: cite transaction identifiers rather than screenshots, state confirmation status and the date of observation, describe clustering as an inference and name whose inference it is, and be careful with victim-linked addresses, because publishing an address can expose a person to targeting and to a second wave of recovery scams.

🌍 NGO, humanitarian and human rights

Humanitarian and human rights organisations meet this data from two directions. Defensively, they receive crypto donations and need to know whether an incoming address is associated with sanctioned entities or with fraud before accepting or forwarding value, and free blocklists plus explorer verification cover most of that need without a vendor relationship. Investigatively, groups documenting extortion, trafficking-linked payments or the finances of armed actors can use the chain as evidence that survives the destruction of other records. In victim-facing work, the referral pathway comes first: a person who has lost funds should be directed to the national reporting mechanism and to their bank or platform, not encouraged to conduct their own trace, and never referred to a paid recovery operation. Publishing addresses associated with victims risks further harm and should be avoided.

🎓 University and research

The chain is one of the largest complete, freely available, verifiable behavioural datasets in existence, and these APIs are a reasonable route into it for small-scale work. For anything at scale, run a node and index locally – it is faster, it removes rate limits from your methodology, and it is the difference between a reproducible study and one that depends on a company's uptime. The methodological points that reviewers should press on are clustering heuristic validity and its known error rates, the fact that mempool observations are node-position-dependent and therefore not directly comparable across studies, the survivorship problem in any dataset built from confirmed transactions only, and the strong selection bias in labelled address sets, which are usually assembled from enforcement actions and therefore over-represent operations that failed.

Playbook: working mempool.space / Blockchain.com 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 what you are actually trying to prove

Chain analysis answers a narrow set of questions well: did value move, how much, in what direction, when relative to other blocks. It answers who badly and why not at all. Write the question down before you open an explorer, because the data is absorbing and it is easy to spend a day building a graph that does not bear on the case.

Phase 2 — Verify the starting point before you build on it

Take the address or transaction you were given and confirm it exists, is on the chain you think it is on, and has the properties you were told. Addresses are copied and mistyped constantly, formats between chains look similar to an untrained eye, and starting a trace from a wrong string produces a coherent and entirely fictional result.

Phase 3 — Read the transaction structure before following anything

Count the inputs and outputs, look at the values and the script types, and form a hypothesis about what kind of transaction it is: a simple payment, a consolidation, an exchange batch payout, a collaborative transaction. The structure tells you which analytical rules apply, and applying payment logic to a batch is how traces go wrong at hop one.

Phase 4 — Identify change before choosing a direction

Work out which output is likely change using script type match with the inputs, the presence of a round-number output, whether an output is immediately spent by a transaction that shares behaviour with the sender, and whether the value is consistent with a plausible payment. If you cannot decide, follow both and say in your notes that you did.

Phase 5 — Constrain the walk before you start it

Set a hop limit and a fan-out limit and enforce them. Beyond a handful of hops from a mixed or consolidated point, the set of reachable addresses becomes the whole economy and the analysis stops carrying information. Depth without a stopping rule is the most common way crypto investigations consume weeks and produce nothing.

Phase 6 — Recognise the boundaries when you hit them

A trace that arrives at a high-volume address with thousands of transactions has probably reached an exchange or a payment processor, and the correct next step is legal process rather than another hop. A trace that reaches a channel-opening transaction has hit Lightning and is over. Naming the boundary is a result; pretending to continue through it is not.

Phase 7 — Capture the pre-confirmation picture while it exists

If the case is live, record mempool state, fee rates and replacement attempts as you observe them. This material is unrecoverable later and it is where intent shows: repeated fee bumps indicate urgency, deliberate low-fee timing indicates patience and planning, and a replacement that changes an output indicates a change of mind about the recipient.

Phase 8 — Corroborate across a second explorer

Pull the same transaction from an independent instance and compare outputs, values and block height. This costs one request and it catches indexing lag, pagination truncation and the rare reorg-related inconsistency. It also gives you a second citation for the same fact, which is worth having when the finding is contested.

Phase 9 — Layer abuse and sanctions signals as annotations

Check addresses against community abuse reporting, published scam databases and official sanctions listings, and attach what you find as clearly labelled allegations. An address appearing in a community report is evidence that someone complained, which is genuinely useful and is not the same as evidence of the conduct alleged.

Phase 10 — Reconstruct the timeline with the right clock

Order events by block height, then attach approximate times with an explicit statement of their uncertainty. Where precision matters, use the constraint that a block's timestamp must exceed the median of the previous eleven, which bounds the real time more tightly than the header value alone.

Phase 11 — Write the finding with the inference layer separated

Produce two distinct sections: what the chain shows, which is verifiable and should be stated flatly with identifiers; and what you concluded, which is inference with a stated confidence and stated basis. Reviewers, courts and editors all need this separation, and analysts who blur it are the reason chain evidence is sometimes treated as unreliable.

Phase 12 — Set monitoring and then leave it alone

Put watches on the addresses that matter and let them run. The highest-value event in most crypto cases is dormant funds moving, and it usually happens months after active work stopped. Monitoring is cheap; the mistake is expensive attention spent refreshing pages in the meantime.

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	An independent open-source explorer implementation serving the same API scheme, which makes it the natural second opinion and a drop-in failover for code already written against mempool.space.
Bitcoin Core	prerequisite	The reference node implementation. Running it is the only way to hold the chain data yourself, verify it independently, and query without disclosing what you are interested in.
Chainabuse	extends	Community abuse reports keyed to addresses across many chains, which supplies the victim-side allegation that chain data cannot contain.
OFAC sanctions listings	prerequisite	Official designations, which since 2018 have included specific virtual currency addresses. This is the one address-attribution source with legal force rather than inferential weight.
MetaMask eth-phishing-detect	extends	Phishing domain intelligence for the web layer that funnels victims toward crypto theft, connecting the infrastructure side of a case to the on-chain side.
Bitcoin Optech	prerequisite	Technical newsletters and topic pages covering fee mechanics, replacement policy, script types and privacy techniques. The background required to read a transaction correctly rather than superficially.
Bitcoin Improvement Proposals	prerequisite	The specifications for address formats, replacement signalling, hierarchical wallets and script types. When an explorer field is ambiguous, the relevant proposal is the authority.
Commercial chain analytics vendors	extends	Chainalysis, TRM Labs and Elliptic add clustering, attribution and risk scoring that explorers deliberately do not. Their inferences are valuable and are inferences, and they should be recorded as such.
IC3 and national fraud reporting mechanisms	prerequisite	The referral pathway for victims. Any victim-facing crypto work should route to the national reporting mechanism before it routes to analysis.

Legal, ethical and operational constraints

The chain is public and reading it is lawful essentially everywhere, but three constraints bind in practice. First, data protection: an address on its own is usually not personal data, and an address linked to an identified person is, so the moment you attach a name to a cluster you have created personal data subject to accuracy, purpose-limitation and retention obligations in most jurisdictions – and an inaccurate attribution that you retain and share is precisely the harm those regimes exist to prevent. Second, defamation and reputational harm: publishing that an address belongs to a named person or a named service, on the basis of clustering heuristics, is an assertion of fact you may be required to defend, and clustering has a known and non-trivial error rate. Third, sanctions and reporting duties: if you are a regulated entity, discovering a link between a customer and a designated address triggers obligations that are jurisdiction-specific and time-bound, and the obligation is generally not discharged by internal note-taking. In criminal contexts, evidence taken from a third-party explorer has weaker provenance than data verified against a node under your control, and prosecutors should expect that to be tested. Finally, do not use tracing capability to identify or approach individuals outside a lawful basis; the technique is investigative, and using it to unmask people for its own sake is both an ethical failure and, in several jurisdictions, an offence.

Operational security

Every query you send to a public explorer tells its operator which address or transaction you are interested in, from which IP, at what time, and in what sequence. Over the course of an investigation those queries describe the investigation. Assume the operator logs them, assume logs can be compelled or breached, and assume that anyone who obtains them can reconstruct your targets and your progress. The sequence is more revealing than any single lookup, because the order in which you walk a trace shows what you believe. There is a further exposure specific to this domain: a subject who controls infrastructure adjacent to an explorer, or who simply watches their own addresses through a service that notifies them, can learn that attention has arrived. The mitigations are ordered by effectiveness. Run your own node and query locally, which eliminates the disclosure entirely. Failing that, use a self-hosted instance of the explorer software. Failing that, route queries over Tor – mempool.space has published an onion service, and you should take its current address from the site rather than from memory – and avoid patterns that fingerprint you, such as querying only your case addresses from a static office IP. Never log in to a service with an account tied to your identity while conducting sensitive lookups, and treat browser-based exploration on a general-purpose workstation as a disclosure you have chosen to make.

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

Cache hit rate on confirmed-data lookups, which should approach total after the first pass of a case; anything else means you are refetching immutable data and paying for it in rate limits and exposure.
Proportion of traces that terminate at an identified service boundary versus dissipating into unresolved fan-out, which measures whether your hop and fan-out limits are set sensibly.
Cross-explorer agreement rate on sampled transactions, tracked as an infrastructure health metric; sustained disagreement means an indexing problem somewhere, not a discovery.
Time from movement on a monitored dormant address to an analyst being notified, which is the metric that determines whether monitoring produces action or archaeology.
Share of published findings that separately state chain fact and analytic inference, tracked as a tradecraft discipline rather than a technical one.
Number of addresses in your case graph carrying an official sanctions or law-enforcement designation as opposed to a community allegation, since the two support very different claims.
Volume of mempool observations captured during live cases, which is the only measure of whether you are collecting the perishable layer or losing it.
Requests per hour against public instances, monitored against your own etiquette ceiling rather than against a published limit, because there is no published limit to violate until you are blocked.

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:

Height orders events, timestamps approximate them. Any sentence that puts two transactions in order should be built on block height, and any sentence with a clock time in it should state the uncertainty rather than implying minute-level precision.
An address is a script, not an account. Wallet software generates a new address per receipt by default, exchanges assign addresses per customer while retaining control, and treating an address as equivalent to a person is the founding error of amateur chain analysis.
Change identification is the skill. Everything downstream of a trace depends on getting the change output right at each hop, and the heuristics for it – script type matching, round-number detection, unnecessary-input reasoning – are learnable and are what distinguishes a real trace from a guess.
Clustering is inference with an error rate, and the error rate is not zero. The common-input-ownership heuristic is defeated deliberately by collaborative transactions, so a cluster is a hypothesis you should be able to state the basis for.
The mempool is perishable and nobody archives it for you. If the pre-confirmation state matters to your case, you must be capturing it while the case is live, and that decision has to be made at the start rather than when you realise you needed it.
Watch for structure that indicates automation. Regular intervals, identical amounts, uniform fee rates and consistent script types across many transactions indicate a service or a script rather than a person, and that recognition changes what the pattern means.
Dust arriving at an address is not a relationship. Anyone can send value to any address, and adversaries do so deliberately to poison histories and to bait address-copying mistakes. Filter tiny unsolicited inputs out of relationship graphs by default.
Bitcoin-only coverage will make a case look cleaner than it is. If the subject touches stablecoins, the interesting movement is on another chain, and a report that only shows the Bitcoin leg is misleading by omission even when every fact in it is correct.
Take custody of anything you will rely on. Screenshots of somebody else's website are the weakest form of chain evidence; raw transaction data verified against a node, with hashes recorded and the retrieval documented, is the strongest, and the cost difference is one afternoon of setup.

Questions analysts actually ask

Can I find out who owns an address from an explorer?

No. The chain contains no identity information and these explorers do not add attribution. Ownership comes from off-chain evidence – an exchange's customer records obtained through legal process, a public posting of the address, a seized device, or an inference from a clustering vendor. Any tool that displays a name next to an address is showing you somebody else's conclusion, and you should find out whose and on what basis.

Which explorer should I trust when two disagree?

Neither, until you understand why. Disagreement about confirmed transaction contents essentially never happens and means one instance is lagging or has an indexing fault. Disagreement about first-seen times, mempool membership or fee estimates is normal and expected, because those are node-local observations rather than facts about the chain. The resolution is your own node, which is also the reason serious operations run one.

Is the block timestamp when the transaction happened?

It is roughly when the block was mined, as declared by the miner, within a permitted window that allows meaningful drift and even out-of-order timestamps between consecutive blocks. The transaction itself was created at some earlier unknown moment and entered the network at some earlier unknown moment. Use height for ordering and treat time as an interval, not a point.

What happens to my trace when funds reach an exchange?

It ends, in fact rather than in visibility. Value moving between customers of the same custodian settles in the custodian's internal ledger and never touches the chain, so no amount of on-chain analysis recovers it. The correct next step is identifying the custodian precisely and directing legal process at it. Reporting a trace as continuing past a custodian without that process is a substantive error.

Do I need my own node, or is the public API enough?

The public API is enough for occasional lookups and for learning. Run your own node the moment any of three things is true: your query volume is more than incidental, the confidentiality of your queries matters, or a finding will be relied on evidentially. Initial sync takes days and the ongoing cost is modest, and it removes rate limits, disclosure and dependency in one step.

Why does an address show incoming transactions the owner says are not theirs?

Because anyone can send to any address without permission. Small unsolicited amounts are usually dusting, intended to link addresses through later spending, or address poisoning, intended to get someone to copy a lookalike address from their own history. Both produce entries that look like relationships and are not, and both should be filtered before graphing.

Can I see Lightning payments here?

No. Opening and closing a channel are on-chain transactions and are visible; everything that moved through the channel while it was open is not, and there is no on-chain residue of individual payments. mempool.space maintains a Lightning view built from public channel announcements, which shows the topology of publicly advertised channels and node metadata, not payment flows.

Is a screenshot of an explorer page acceptable evidence?

It is acceptable as an investigative note and weak as evidence. It is a picture of a third party's website with no attestation, no chain of custody and no guarantee the page said the same thing an hour later. Where the finding will be relied on, retrieve the raw transaction, verify it against a node, record hashes and document the retrieval – and cite the transaction identifier, which is permanent, rather than a URL, which is not.

How do I handle a victim who wants their funds traced?

Direct them to the national reporting mechanism first – IC3 in the United States, the equivalent fraud reporting body elsewhere – and to the exchange or platform involved, because those are the only routes with any realistic prospect of freezing or recovery. Warn them explicitly about paid recovery services, which are a large secondary fraud category preying on the same victims. Tracing without a route to legal process produces a document, not a remedy.

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:

Bitcoin consensus rules, which define what a valid transaction and block are and therefore what an explorer is permitted to show; the median-time-past rule in particular bounds how far a block timestamp may deviate.
BIP-173 and BIP-350 bech32 and bech32m address encodings, alongside legacy base58check, which together determine how addresses are formatted, checksummed and case-handled.
BIP-125 opt-in replace-by-fee signalling, the mechanism behind transaction replacement and the reason a single intended payment can exist as several transactions.
BIP-32, BIP-44, BIP-84 and BIP-86 hierarchical deterministic wallet structures, which explain why one wallet produces an unbounded stream of unrelated-looking addresses.
The Esplora HTTP API scheme, an informal but widely implemented interface standard that makes explorer clients portable between providers and self-hosted instances.
STIX 2.1 and MISP for exporting addresses and transactions as indicators with provenance intact, which is how chain findings travel between organisations without losing their basis.
FATF guidance on virtual assets and virtual asset service providers, including the travel rule, which defines the regulatory frame most institutional consumers of this data operate under.
Satoshi as the atomic accounting unit, with bitcoin as a display convention only; treating the display unit as the data unit is a recurring source of factor-of-one-hundred-million errors.

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.

mempool.space — Mempool Space K.K.. The explorer itself, including mempool visualisation, fee estimation, mining pool attribution and the Lightning view. The best free interface for observing the network in its unconfirmed state.
mempool.space REST API documentation — Mempool Space K.K.. The authoritative description of the HTTP interface, including which endpoints exist for transactions, addresses, blocks, mempool state and fees. Read it before writing a client rather than guessing paths.
mempool open-source repository — The Mempool Open Source Project. Source code, self-hosting instructions and the current licence terms. Running your own instance is the answer to rate limits, query disclosure and dependency risk simultaneously.
Blockchain.com Explorer — Blockchain.com. One of the oldest continuously operating explorers, covering Bitcoin, Ethereum and Bitcoin Cash, with charts and statistics that give useful network-level context alongside per-transaction lookup.
Blockstream Esplora — Blockstream. The open-source explorer whose API scheme mempool.space follows, and the reference for what the shared interface is supposed to do. Useful as an independent second instance.
Bitcoin Core — Bitcoin Core project. The reference node implementation. The starting point for holding the chain yourself, which is the correct infrastructure for any operation that depends on this data.
Bitcoin developer documentation — Bitcoin project. Reference material on transaction structure, scripts, blocks and the RPC interface. The place to resolve questions about what a field means at the protocol level rather than the explorer level.
Bitcoin Improvement Proposals — Bitcoin community. The specifications behind address formats, replacement signalling and wallet derivation. When an explorer displays something ambiguous, the relevant proposal is what actually defines it.
Bitcoin Optech — Bitcoin Optech. Technical newsletters and topic pages on fees, replacement policy, privacy techniques and script types, written for engineers. The fastest route to understanding why a transaction looks the way it does.
Office of Foreign Assets Control — US Department of the Treasury. Sanctions designations, which have included specific virtual currency addresses since 2018. The only widely used address attribution source that carries legal force rather than inference.
Financial Action Task Force — FATF. International standards and guidance on virtual assets, including the travel rule and risk-based supervision of service providers. The regulatory context that governs most institutional use of chain data.
Internet Crime Complaint Center — US Federal Bureau of Investigation. The United States reporting mechanism for crypto fraud and the referral pathway victims should be directed to. Analysis is not a substitute for a report that can lead to freezing action.

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 caches immutable chain data once, keeps confirmation state as timestamped snapshots rather than facts, corroborates transactions across independent explorer instances, and holds community abuse allegations in a separate annotation layer so a report never presents an inference as a chain fact.. Browse the full source catalogue, or follow any tag above into the rest of the library.