Blockstream Esplora: Intelligence Source Guide

Esplora is Blockstream's open-source Bitcoin explorer, and its REST API answers unauthenticated queries about addresses, transactions and blocks in plain JSON. The important part: you can run the same software yourself and remove the third party entirely.

At a glance

Source	Blockstream Esplora
Category	Cryptocurrency & Blockchain › Blockchain Explorers
Homepage	https://blockstream.info/
Machine interface	`https://blockstream.info/api/`
Format	`JSON`
Access	Open — no account required
Disciplines	Cryptocurrency Intelligence
Mission domains	Financial Crime

Bitcoin explorer REST API. — as catalogued in the platform’s own source registry.

Esplora is a Bitcoin block explorer consisting of an indexing backend and a web front end, published as open source and operated publicly by Blockstream at its explorer site. Behind the web pages sits a REST API that requires no key and returns JSON. The endpoints follow the natural shape of Bitcoin: an address endpoint returning aggregate statistics and its transaction list, a transaction endpoint returning the full input and output structure with confirmation status, endpoints for the spending status of individual outputs, block endpoints by hash and by height, an unspent output listing per address, mempool endpoints, fee estimates, and a broadcast endpoint. The address statistics are presented as separate confirmed and mempool objects, each reporting how many outputs funded the address and their total, how many were spent and their total, and a transaction count – which means a balance is something you compute from funded minus spent rather than something the API hands you, an honest reflection of how Bitcoin actually works. The public deployment covers Bitcoin mainnet, with parallel deployments for testnet and for Blockstream's Liquid sidechain under separate paths. Because the software is open, the same API can be run on your own hardware against your own node.

Every other source in this category asks you to trust an operator. Esplora is the one where you do not have to. That matters in three distinct situations, and they are the situations where the stakes are highest. First, evidential integrity: an analyst who can say the transaction data came from a node we operate, indexed by open-source software, verified against consensus rules, is making a claim about provenance that no commercial API can match, and it is the claim that holds up when the analysis is contested. Second, confidentiality: a query to a public explorer discloses which address you care about, and for live operations, protected sources and investigations into well-resourced parties that disclosure is unacceptable – self-hosting removes it completely rather than mitigating it. Third, continuity: a research programme or a production pipeline that depends on somebody else's free service has a dependency it cannot control, and rebuilding at short notice is expensive. The public deployment is a convenient, well-run instance of that software, and the correct way to think about it is as a preview of a system you can adopt, not as a service you are locked into.

Who publishes it, and why that matters

Blockstream is a Bitcoin infrastructure company founded in 2014, whose business spans mining, the Liquid sidechain, hardware wallets, Lightning software and enterprise products. Its core engineering staff includes long-standing Bitcoin protocol contributors, and the company has a sustained record of publishing significant work as open source – Esplora among it. That matters for reliability in a specific way: the public explorer is a public-good service adjacent to a commercial business rather than a product with paying customers, so it is well engineered and has no service commitment to you. It could be rate-limited, restricted or discontinued and you would have no recourse, which is exactly why the open-source path is the answer rather than a footnote. The company is also a participant in the ecosystem it indexes, holding positions in Bitcoin infrastructure and having a stated view of how the network should develop; nothing about that affects the factual accuracy of block data, which is verifiable against consensus, but it is a reason to keep the distinction between raw chain facts and any interpretive layer clear. There is essentially no interpretive layer here, which is a large part of the source's value.

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
`chain_stats.funded_txo_count`	int	How many confirmed outputs have paid to the address over its lifetime. Together with the spent count this is how Bitcoin balance is expressed here – as flows rather than as a stored value – which is a truer representation of the UTXO model than a single balance figure.	The address transaction list, and the individual outputs with their spending status.
`chain_stats.funded_txo_sum`	int	Total value received by the address in satoshis, confirmed. Note the unit: satoshis, not bitcoin. Every pipeline that has ever mishandled this produced numbers wrong by eight orders of magnitude that looked entirely plausible in a chart.	Historical price data at the relevant block heights if a fiat figure is required, recorded with the basis used.
`chain_stats.spent_txo_sum`	int	Total value spent from the address, confirmed. Subtracting this from the funded sum gives the current confirmed balance, and doing that arithmetic yourself is a small but real safeguard against misreading a number somebody else computed for you.	The spending transactions, which are where the trace continues and where co-spend relationships appear.
`mempool_stats`	array	The same funded and spent statistics for unconfirmed transactions, reported separately from confirmed activity. Keeping them apart is the correct design and the correct analytical discipline: unconfirmed transactions can be replaced or dropped and must never be reported as settled facts.	The mempool transaction list for the address, and a later confirmed check to establish what actually settled.
`txid`	string	The transaction identifier. On Bitcoin this names a set of inputs and outputs, not a payment from one party to another, and the whole discipline of change identification exists because of that distinction.	The transaction endpoint for full structure, the outspend endpoints for what happened to each output, and any independent explorer for verification.
`status.confirmed`	enum	Whether a transaction is confirmed, accompanied by its block height, block hash and block time when it is. An unconfirmed transaction is a proposal, not an event, and reporting one as a completed transfer is a mistake that has embarrassed serious organisations.	The containing block, and the confirmation depth relative to the current tip for a defensible statement of finality.
`vin`	array	The inputs consumed by a transaction, each referencing a previous output and, in this API, carrying the previous output's value and script details. This is the field that makes clustering possible, because inputs spent together are the evidence for common control.	The previous transactions, and the set of addresses co-spent in the same transaction – the raw material of the common-input-ownership heuristic.
`vout`	array	The outputs created, each with a value, a script and a decoded address where the script has one. Outputs without addresses exist – non-standard scripts and data carriers – and a parser that assumes every output has an address will silently discard them.	The outspend endpoint to see whether and where each output was spent, which is how a trace advances one hop.
`scriptpubkey_type`	enum	The output script type, distinguishing legacy, script-hash, native segwit and taproot forms. Analytically valuable: type consistency between a transaction's inputs and one of its outputs is one of the better change-identification signals, and type prevalence dates a wallet's software generation.	Other outputs of the same type in the same period, and wallet adoption timelines that explain when each type became common.
`spent`	enum	Whether a specific output has been consumed, returned by the outspend endpoints together with the spending transaction where it exists. This is the primitive that a forward trace is built from, one hop at a time.	The spending transaction, its other inputs, and the outputs it created.
`fee`	int	Transaction fee in satoshis. Useful beyond accounting: fee behaviour is a behavioural fingerprint, and consistently unusual fee choices across transactions can associate them with a common piece of wallet software or a common operator.	Fee rates in the surrounding blocks, which establish whether a fee choice was ordinary or distinctive at that moment.
`block_height`	int	The height of the containing block, the correct ordering key for anything on this chain. Where you need to state when something happened relative to something else, use height; where you need wall-clock time, use block time and accept its imprecision.	The block endpoint, the surrounding blocks, and the corresponding chain state in any independent index.
`blocks/tip/height`	int	The current chain tip as the instance sees it. Reading it at the start of a session is the check that tells you whether the instance is synchronised, and it is the field that makes any statement about current balances meaningful rather than hopeful.	An independent explorer or another node to confirm the instance is not stalled or serving a stale view.

Coverage — and what is not in it

Bitcoin mainnet from genesis, complete, with the full transaction and output structure – which is the whole of Bitcoin and nothing else. Testnet and Blockstream's Liquid sidechain are served under separate paths on the public deployment, useful respectively for development and for questions about Liquid assets. There is no coverage of any other blockchain, no token layer beyond what Liquid provides, and no labelling, clustering or attribution of any kind. That absence is deliberate and it is the point: this is a factual index of the chain, and everything interpretive is left to you. Update cadence follows the chain, with the tip endpoint disclosing exactly where the instance stands so you never have to infer currency. Mempool coverage means the instance's own view of unconfirmed transactions, which differs legitimately between nodes and should never be treated as a global truth. For historical work the coverage is complete and permanent; for current work it is as good as the instance's synchronisation; and for anything beyond Bitcoin it is simply out of scope, which is a cleaner boundary than most sources offer.

Known blind spots

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

It is Bitcoin only. A subject who moves value to another chain, into a token on another network, or through a service that settles off-chain disappears at that point, and the Bitcoin view will present that as the trail ending rather than as the trail leaving.
There is no attribution layer whatsoever. Every address is an anonymous string, no exchange is named, no cluster is offered, and building the picture of who is involved requires a different source entirely.
No clustering is performed. The co-spend evidence is all present in the input lists, but assembling addresses into wallets is work you must do, which is more honest and considerably more effort than a tool that shows you clusters without showing you why.
The mempool view is one node's view. Unconfirmed transactions differ between instances by propagation and policy, so an absence in the mempool is not evidence that a transaction was never broadcast.
Address transaction lists are paginated, and an integration that reads only the first page will silently analyse a fraction of a busy address's history while appearing to have read all of it.
Layer-two activity is invisible except where it touches the base chain. Channel opens and closes appear; everything that happened inside a channel does not, and the on-chain record will understate activity accordingly.
The public instance has no service commitment and undocumented limits, so a production pipeline built against it has an unmanaged dependency that will fail without warning at some point.
Self-hosting is not free. A full index requires a synchronised node plus substantial additional storage and an initial indexing run measured in hours to days, and the cost is real even though the software is not.
It answers factual questions only. Whether a flow is suspicious, whether an amount is unusual, whether a counterparty is a service – none of that is here, and analysts accustomed to enriched tools will find the silence disorienting.

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

Access, licensing and what you may do with it

Access model: Open — no account required

The public API is open over HTTPS with no key and no registration, which makes it the lowest-friction way to get authoritative Bitcoin data into a script. Blockstream has also published a Tor onion service for the explorer, which is the appropriate route where the network origin of your queries is itself sensitive. For anything sustained, the right move is to run your own instance: the software is open source and the deployment consists of a Bitcoin node plus the Esplora indexing backend and, if you want it, the web front end. Budget honestly – you need the full chain plus an address index that is substantially larger than the raw chain, a machine with real disk throughput, and an initial index build that takes a long time on modest hardware. What you get in return is unlimited queries, no disclosure to anyone, no dependency on another organisation's goodwill, and a data lineage you can describe precisely in a report. For teams doing serious Bitcoin work this is not an optional refinement; it is the correct architecture, and the public instance is how you evaluate it first.

Licence

Esplora is published as open source and can be run, modified and deployed on your own infrastructure, which is the practical fact that matters; confirm the specific licence terms in the repository before redistributing modified code or embedding it in a product. The Bitcoin data it serves is public and unowned – transactions, blocks and addresses are facts nobody holds rights in, and you may use them without permission from anyone. Use of Blockstream's public deployment is subject to whatever terms that operator sets, and the honest framing is that a free public instance run as a community service should be used considerately rather than exhaustively. Nothing here restricts what you may publish about the chain, which is a meaningful contrast with commercial tracing products where the derived layer is licensed and constrained. If you need certainty for a commercial deployment, read the repository licence and, for any hosted or enterprise arrangement, get terms in writing.

Rate limits and fair use

The public instance publishes no formal quota, which means the constraint is fairness rather than enforcement, and abuse is met with blocking rather than with a bill. Practical etiquette: single concurrency, a real pause between requests, permanent caching of confirmed historical data because it cannot change, and exponential backoff on any error rather than immediate retry. If your workload involves more than a few thousand requests, you have crossed the line where self-hosting is the correct answer, and continuing to hammer a free service is both discourteous and fragile. Two implementation details save more quota than any tuning: fetching a transaction once and deriving everything from it rather than calling several endpoints for the same object, and paginating address histories properly so you are not repeatedly re-reading the same first page. Set a hard request ceiling in your own collector so that a loop bug cannot become an incident.

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 Blockstream Esplora 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
Address lookup and history pagination	JSON	Per case, or scheduled for watched addresses	Statistics first, then the full transaction history through the pagination cursor. Read every page – a busy address's history extends far beyond the first, and stopping early is a silent analytical error rather than a visible one.
Transaction retrieval with full structure	JSON	Per hop	The complete input and output structure with values, script types and confirmation status. One call gives you everything needed for change reasoning and co-spend analysis at that hop, so fetch once and derive locally.
Output spend resolution	JSON	Per hop	Determining whether and where each output was spent. This is the primitive of forward tracing, and doing it explicitly rather than through a rendered graph is what keeps the reasoning visible and reviewable.
Unspent output enumeration	JSON	On demand	The current unspent set for an address, which is what a balance actually consists of on this chain. The correct basis for any statement about assets that are still there.
Chain tip and mempool monitoring	JSON	Continuous, low frequency	Tracking the tip to confirm the instance is synchronised, and watching the mempool for early sight of movement from monitored addresses – with the standing caveat that unconfirmed means proposed, not settled.
Self-hosted deployment	bulk	Once, then continuous	Running the software against your own node. Unlimited, private, and the only configuration that gives you a provenance statement you fully control. The initial index build is long; everything after it is cheap.

Ingesting it into the platform

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

Register the instance, not just the source — sources.php records which deployment is being collected from – the public one or your own – because provenance differs materially between them and any evidential claim depends on which was used. Two instances of the same software are two sources.
Record the tip height at collection — collect.php stores the chain tip observed at the time of each collection run, so every derived record carries the state of the world it was drawn from. This is what makes an analysis reproducible and what lets you detect a stalled instance.
Store confirmed and unconfirmed separately — ingest.php keeps mempool observations in a distinct state from confirmed transactions and never promotes one to the other automatically. An unconfirmed transaction that is later replaced must not leave a settled-looking record behind.
Model inputs, outputs and spends explicitly — Outputs are stored as objects with their own spend status rather than flattened into transfers. This preserves the co-spend relationships that clustering requires and the change-identification signals that a flattened model destroys.
Normalise satoshis once at the boundary — Values are converted from the smallest unit at ingest with the conversion recorded, and both representations are retained. Unit errors are the most common defect in Bitcoin pipelines and are almost never caught by the person who wrote them.
Derive clustering locally and label it as derived — Where the platform assembles addresses into wallets from co-spend evidence, the resulting cluster is stored as a dated assertion with the heuristic named, so it can be revised, contested or excluded from a report that requires only chain facts.
Screen addresses against designation lists — sanctions.php checks addresses against authoritative sources directly. Since this source provides no attribution at all, designation screening is the one enrichment that must not be skipped, and it must run against the list rather than against any intermediary's flag.
Correlate, case and export — correlate.php surfaces addresses recurring across investigations, add-to-case.php binds them to the case, and export.php emits CSV, JSON or MISP. Summarise (Copilot) can draft prose over these records; every transaction and relationship in the platform comes from collected data, never 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.

This is the highest-integrity source in the batch and the reasoning is structural rather than reputational. The data is a direct rendering of consensus-validated blockchain state produced by open-source software you can read, run and audit; there is no proprietary transformation, no undocumented heuristic and no vendor judgement anywhere in the path. Errors, when they occur, are operational – an instance behind on synchronisation, a pagination bug in your own client – and both are detectable by checking the tip and by reconciling counts. The absence of enrichment is the quality argument, not a gap: a source that only reports what the chain says cannot mislead you about who anybody is, because it never claims to know. The realistic caveats are about your use rather than the source: unconfirmed transactions are a node's local view and are not facts, address histories must be paginated fully or your analysis is on a subset, and the public instance's availability is not guaranteed. Run your own instance and even those caveats reduce to arithmetic you control. For anything that will be challenged, this is the source you want your figures to come from.

Characteristic false positives

Partial address history read as complete. Pagination is the single most common integration failure here, and the result is an analysis of the first page of a long history presented with total confidence.
Unconfirmed transactions reported as settled. Mempool entries can be replaced or dropped, and a report stating that funds moved when only a broadcast occurred is wrong in a way that is difficult to walk back.
Satoshi values treated as bitcoin. The API is consistent about units and pipelines are not, producing figures wrong by eight orders of magnitude that pass casual review because they are still numbers.
Change outputs misidentified, sending the trace down the wrong branch. The API gives you the evidence to reason about change; it does not do the reasoning, and a wrong call at an early hop invalidates everything after it while looking perfectly coherent.
Co-spend evidence over-interpreted. Inputs spent together usually indicate common control, but collaborative transactions and shared-custody arrangements break that assumption, and building clusters without testing for them merges unrelated parties.
Outputs without addresses dropped silently. Non-standard scripts and data-carrying outputs are real and sometimes analytically important, and a parser assuming an address on every output loses them without raising an error.
A stalled instance mistaken for a quiet chain. If the deployment is behind, recent activity is simply absent, and an analyst concludes that an address has been dormant when it has been busy.
Fee and time fields over-read. Block time is a declared value with real imprecision and fee is a wallet policy choice, so both support behavioural inference and neither supports precise claims about when or why.

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

Ageing

Confirmed Bitcoin data never ages: a transaction at a given height is a permanent fact, which is why aggressive caching is correct rather than merely convenient and why historical analysis here is exceptionally durable. Address statistics and unspent output sets age on the block interval, which for Bitcoin means roughly every ten minutes on average and irregularly in practice, so a balance is a statement about a specific height rather than about now. Mempool data ages in seconds and is provisional throughout its life. Fee estimates age fastest of all and are only meaningful at the moment they are read. The instance's own currency is the variable that catches people out: a deployment behind on synchronisation serves data that is perfectly accurate and out of date, and the only defence is checking the tip. The characteristic stale record in a case file is an address enrichment showing a balance and a last-seen date from months ago, still displayed as though current, describing an address whose funds moved shortly afterwards – which in a recovery context can be the difference between a viable application and a wasted one.

What this source feeds

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

Collected by these intelligence disciplines

Cryptocurrency Intelligence

Serves these mission domains

Financial Crime

Yields these data points

How each sector uses Blockstream Esplora

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

The specific value for defence use is sovereignty over the data path. A self-hosted instance means Bitcoin analysis can be performed inside a controlled environment with no external queries, no disclosure of which addresses are of interest, and a provenance statement that satisfies an assurance process – none of which is true of any commercial API. For threat finance work this supports verification of indicators from partners and open sources without revealing that the indicator was received or acted upon, which is frequently the operative constraint. It provides no attribution, so it belongs alongside a labelling source rather than instead of one, and the labelling source is where the external disclosure occurs. The deployment cost is a node, storage and an index build, which is small relative to almost any other collection capability and is the reason this is usually the first piece of blockchain infrastructure a serious programme stands up.

🕵 National intelligence

Within CRYPTINT this is the collection layer that leaks nothing. Where a query to a commercial service discloses your interest to a company in another jurisdiction, a self-hosted instance discloses it to nobody, and for indicators derived from sensitive collection that difference is decisive rather than marginal. It also supports the methodological work that enriched tools discourage: because clustering is not done for you, the co-spend evidence is visible and you can implement, test and document your own heuristics – which means the resulting assertions are defensible in your own terms rather than in a vendor's. Practical posture is a division of labour: run this instance for all base-layer facts and all sensitive lookups, use commercial tools only for attribution on indicators whose exposure you can accept, and keep the two layers separate through to the finished assessment.

👮 Law enforcement

For investigators the argument is evidential. Data drawn from a node your organisation operates, indexed by open-source software, verified against consensus rules, is provenance a court can follow, and it removes the recurring difficulty of relying on a commercial product whose method cannot be explained. The full transaction structure supports the analysis that matters in Bitcoin cases – which output was change, which inputs were spent together, whether a transaction was confirmed at the relevant time – and it supports it with primary data rather than with a rendering. Two practical warnings. Pagination must be handled correctly or your analysis covers part of the history; check totals against the transaction count in the statistics. And never present an unconfirmed transaction as a completed transfer, because the defence will find the replacement and the error will contaminate the rest of your evidence.

🔍 Private investigation and corporate security

The free, neutral verification layer for any Bitcoin asset trace. When a client's question is whether a transaction occurred, at what time and for what amount, this answers it authoritatively without a subscription and without disclosing the matter to a vendor. Balance questions should be answered from the unspent output set at a stated height rather than from a figure copied out of an interface, which is both more accurate and more defensible if the report is challenged. It gives you no attribution, so pair it with a labelling product to identify the services in the picture. For firms doing enough Bitcoin work to justify it, a self-hosted instance is a modest infrastructure cost that eliminates client confidentiality concerns about third-party lookups, which is increasingly a question sophisticated clients ask.

📰 Journalism and OSINT media

Best used for verification rather than for discovery: confirming that a transaction cited by a source or a subject really exists, on the date and for the amount claimed, from a source that has no commercial interest in the story. That is a genuinely valuable capability for a newsroom and it costs nothing. Publish transaction identifiers so readers can check your work against any explorer. Be precise in language: an address is not a person, an unconfirmed transaction has not happened yet, and a balance is a statement about a moment. Where an analysis involves clustering, say that the clustering came from somewhere else and describe the method, because this source does not do it and readers deserve to know which parts of a story rest on facts and which rest on inference.

🌍 NGO, humanitarian and human rights

The relevant properties are cost and confidentiality. It is free, it requires no account, and a self-hosted instance means that checking an address associated with a person at risk discloses nothing to any commercial party – which matters when the subject of the check could be harmed by the disclosure and when your organisation cannot guarantee what a vendor does with submissions. Practical uses are verification of payment claims in fraud and exploitation casework and documentation of flows for advocacy. The limits are real: no attribution, no recovery assistance, no interpretation, and the priority for a victim remains referral to the appropriate national channel and protection from follow-on recovery fraud. Handle any address linked to an identified person with the discipline you would apply to a bank account number, and remember the linkage is permanent.

🎓 University and research

Methodologically this is the right foundation. Open-source indexing software, a public protocol, no proprietary transformation and the option to run the whole stack yourself means an analysis can be described completely and reproduced by a reviewer with the same code and the same chain – which is the standard the field should hold and frequently does not. Run your own instance for any published work, both for reproducibility and because a paper's data collection should not depend on somebody else's uncommitted free service. Implement and publish your clustering rather than importing someone else's, and evaluate it explicitly against the known failure conditions including collaborative transactions and shared custody. Ethics review still applies: chain data is public but address-level datasets are re-identifiable through off-chain records, so publish aggregates and code rather than address lists linked to behavioural claims.

Playbook: working Blockstream Esplora 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 — Confirm the instance is synchronised

Read the chain tip and compare it against an independent view before anything else. A deployment behind on synchronisation returns accurate data about a past state, which is the most dangerous failure mode available because nothing in the response looks wrong. Thirty seconds of checking prevents an entire analysis being built on a stale view.

Phase 2 — Decide whether this is a public-instance job

If the addresses involved are sensitive – a live operation, a protected source, an investigation into a party with reach – do not query a public service at all. Stand up your own instance or use one your organisation controls. This decision has to be made before the first query, because the disclosure cannot be undone afterwards.

Phase 3 — Pull address statistics before history

The funded and spent counts and sums tell you immediately what scale of entity you are dealing with and how much history there is to read. An address with a handful of transactions is a different analytical proposition from one with tens of thousands, and knowing which you have before you start paginating shapes the whole approach.

Phase 4 — Paginate the full history and reconcile the count

Read every page of the transaction list and check the number retrieved against the transaction count in the statistics. Any mismatch means your collection is incomplete, and discovering that now is trivial while discovering it after the analysis is not. This single reconciliation catches the most common integration bug in this API.

Phase 5 — Separate confirmed from unconfirmed rigorously

Treat mempool observations as a separate class of information with a separate status throughout your analysis, and never let one be promoted silently. A transaction that was broadcast and replaced leaves a mempool record that reads exactly like a transfer, and reporting it as one is a hard error to recover from.

Phase 6 — Reconstruct the transaction structure rather than the transfer

For each transaction of interest, work from the full input and output list: which outputs were consumed, what they were worth, what was created, and what the fee was. Bitcoin transactions are not transfers between two parties, and any analysis that treats them as such will misattribute change and miscount value.

Phase 7 — Reason about change explicitly and write it down

For each hop, identify which output continued to your subject using script type consistency, value patterns, subsequent spending behaviour and known address associations – and record the reasoning. An unstated change decision cannot be reviewed, and change decisions are where Bitcoin traces silently go wrong.

Phase 8 — Harvest co-spend evidence for clustering

Collect the input sets of every transaction spending from your subject's addresses. These are the raw evidence for common control and the basis for any clustering you do. Building this yourself is more work than reading a vendor's clusters and it produces an assertion you can defend and revise.

Phase 9 — Test clusters against the known failure conditions

Before treating a cluster as an actor, check whether any merge came through a transaction with many similar-value outputs and many inputs, or through a shared-custody arrangement. Both defeat the ownership assumption. A cluster that has been tested against its own failure modes is worth stating; one that has not is a liability.

Phase 10 — State balances as at a block height

Compute balance from the unspent output set and report it with the height at which it was observed. A bare balance figure is not a fact about anything in particular, and the height-qualified form is both more accurate and the form an expert report has to take anyway.

Phase 11 — Screen every address against designation lists

This source offers no attribution and no risk flags, so sanctions screening is an explicit step you must add rather than something that arrives with the data. Check against authoritative lists directly and record the date, because designation status is a legal fact with consequences that attach on knowledge.

Phase 12 — Document provenance in terms a reviewer can follow

Record which instance served the data, whether it was public or self-hosted, the software version, the tip height, and the collection time. This is the paragraph that makes the analysis credible, and it is the one thing a commercial API cannot give you in the same form. Write it while you have the details, not from memory afterwards.

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
Blockchair	corroborates	Independent multi-chain index with a query API and bulk dumps, providing both a second opinion on Bitcoin facts and the population-level filtering this API does not offer.
mempool.space	extends	Deep live view of the Bitcoin mempool, fee market and block propagation, and also open source and self-hostable – the natural companion for questions about pending activity and network conditions.
WalletExplorer	extends	Adds the clustering and historical service naming layer that this source deliberately omits, which is expensive to reproduce well and valuable for older Bitcoin matters.
MetaSleuth	extends	Modern multi-chain attribution and tracing, covering the two things missing here: entity labelling and continuity past the Bitcoin boundary.
MistTrack	extends	Risk categorisation and labelling with strong coverage of regional services, complementing an index that names nothing at all.
Esplora source repository	prerequisite	The software itself, including the API reference and deployment instructions. Reading it is how you learn what the endpoints actually guarantee rather than what you inferred from responses.
Bitcoin developer documentation	prerequisite	The reference for transaction structure, script types and the UTXO model, without which the fields this API returns can be parsed but not understood.
OFAC Sanctions List Search	prerequisite	Authoritative designations including listed digital currency addresses, which is an explicit step you must add because this source provides no screening of any kind.

Legal, ethical and operational constraints

Reading public blockchain data requires no authority and is lawful in every jurisdiction that matters, and running your own node is likewise unrestricted in most places – though a small number of jurisdictions regulate cryptocurrency infrastructure in ways worth checking before deploying. The constraints that do apply are downstream. Addresses linked to identified people constitute personal data under most modern regimes, bringing lawful basis, purpose limitation and retention obligations to your case files regardless of the ledger's public nature. Clustering assertions are claims about who controls what and should be presented with their method and limitations, particularly in legal filings where an unqualified assertion invites a challenge that a qualified one survives. Sanctions screening is entirely your responsibility here since the source performs none, and obligations in most regimes attach on knowledge. One legal advantage is worth stating plainly: because the software is open and the data is consensus-verified, a self-hosted deployment gives you an evidential provenance story – this machine, this software, this chain state – that no commercial API can match.

Operational security

Queries to the public instance disclose to its operator, and to anyone observing the network path, which Bitcoin addresses you are researching and when. That is a modest risk for routine work and an unacceptable one for sensitive work, and unlike most sources in this category the mitigation is complete rather than partial: run the software yourself and the disclosure ceases to exist. Where the public instance is used, the Tor onion service removes the network-origin element while still disclosing the queries themselves to the operator, which addresses one problem and not the other. Query pattern is its own signal – a sequence of address lookups reconstructs a trace and therefore a hypothesis – so avoid walking a sensitive path through any third-party service. If you self-host, remember the instance is now your infrastructure with your logs: decide who can read them, how long they persist, and whether the machine's own network behaviour reveals what it is indexing, because a node making distinctive outbound connections is itself observable.

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

Instance tip lag against an independent chain view, sampled continuously, which is the primary health measure and the one that silently invalidates analysis when unmonitored.
Reconciliation rate between the transaction count in address statistics and the number of transactions actually retrieved, which detects pagination defects that otherwise never surface.
Proportion of sensitive lookups performed against self-hosted rather than public infrastructure, which is a direct measure of whether your confidentiality policy is being followed or merely stated.
Number of analyses in which balances were reported at a stated block height rather than as bare figures, a simple proxy for whether the work is written to survive challenge.
Cluster assertions accompanied by a documented heuristic and a failure-mode check, as a share of all cluster assertions made.
Requests issued to the public instance per case, tracked to confirm that heavy workloads are being moved to self-hosted infrastructure rather than absorbed by someone else's free service.
Time from a monitored address moving funds to the alert reaching an analyst, which for recovery work is the interval that determines whether anything can be done.

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:

Check the tip before you check anything else. A stalled instance produces perfectly formatted answers about a world that has moved on, and nothing in the response will tell you.
Read every page. An address history that stops at the first page is a subset presented as a whole, and the transaction count in the statistics is the check that catches it.
Unconfirmed is not a transfer. Mempool entries are proposals that can be replaced, and calling one a payment is an error that contaminates whatever else you wrote.
Satoshis, not bitcoin. Convert once at the boundary, keep both representations, and treat any figure that arrived without a recorded unit as suspect.
Write down the change reasoning at every hop. It is the step that decides where the trace goes and the step nobody records, which is why so many traces cannot be reviewed.
Bitcoin transactions are not transfers between two parties. Reason from inputs and outputs, or you will misattribute change, miscount value and invent counterparties.
Self-host for anything sensitive. It is the only configuration in this entire category where your queries disclose nothing to anyone, and the cost is a machine and some disk.
The absence of labels is a feature. A source that never claims to know who anybody is cannot mislead you about it, and the discipline of adding attribution deliberately is worth the friction.
Provenance is the product. Being able to say which instance, which software, which height, and which collection time is what makes the analysis defensible when it is attacked.

Questions analysts actually ask

Do I need an API key?

No. The public API answers unauthenticated requests, which makes it the fastest route to authoritative Bitcoin data in a script. There is no formal published quota either, which means the constraint is courtesy – keep concurrency low, cache historical data permanently, and move to your own instance when the volume becomes real.

How do I get an address balance?

You compute it. The API reports how much has funded the address and how much has been spent, separately for confirmed and unconfirmed activity, and the balance is the difference. This is a more honest representation of the UTXO model than a single balance figure, and doing the arithmetic yourself makes you aware of what you are actually stating.

Why does the address transaction list seem incomplete?

Because it is paginated and you probably read only the first page. Use the pagination cursor to walk the full history and reconcile what you retrieved against the transaction count in the address statistics. This is by a wide margin the most common integration mistake against this API and it fails silently.

Should I run my own instance?

If you do sustained Bitcoin work, yes. It removes rate limits, removes any disclosure of which addresses you are researching, removes your dependency on someone else's free service, and gives you a provenance story that stands up to challenge. The cost is a synchronised node, substantial additional storage for the index, and a long initial build.

Does it cover other blockchains?

No. Bitcoin, with separate deployments for testnet and for the Liquid sidechain on the public instance. Anything on another chain requires a different source, and a trace that leaves Bitcoin leaves this source entirely – which the data will present as the trail ending rather than as the trail moving.

Can I see who owns an address?

No, and it does not pretend to. There is no labelling, no clustering and no attribution here at all. Identity requires a labelling source to identify the service and legal process to identify the customer, and this source is the factual foundation those sit on top of rather than a substitute for them.

Is the mempool view authoritative?

It is one node's view, which is the only kind of mempool view that exists. Nodes differ by propagation and relay policy, so a transaction absent from this instance's mempool may be present elsewhere. Treat mempool data as provisional intelligence about intent rather than as a record of events.

How does this compare to a commercial tracing tool?

It is better at facts and provides nothing else. Commercial tools give you labels, clusters, cross-chain continuity and a graph interface, all of which are useful and none of which are verifiable by you. The mature arrangement uses both: this for the evidential layer, a commercial tool for attribution leads, and a clear separation between them in the finished product.

Can I broadcast transactions through it?

The API supports transaction broadcast, which is a legitimate feature of an explorer and irrelevant to investigative use. Analysts should note only that broadcast capability exists on the endpoint they are querying, and that any operational use of a wallet is a separate matter that has no place in an investigative workflow.

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 Bitcoin consensus rules and the UTXO transaction model, which define what the data means and why balances are derived rather than stored.
Bitcoin Improvement Proposals covering address formats, segregated witness and taproot, which determine the script types this API reports and their analytical significance.
REST over HTTPS returning JSON with no authentication, a deliberately minimal interface that makes integration and independent verification straightforward.
Open-source distribution of both the indexing backend and the front end, which is what makes self-hosting and full method disclosure possible.
Tor onion services as an access route where network-origin confidentiality matters, and as part of a considered approach to query exposure.
MISP cryptocurrency attribute types for sharing Bitcoin address indicators with partners in a structured, widely supported form.
The common-input-ownership heuristic and its documented failure conditions, which is the clustering method the raw input data here supports and which you must implement and defend yourself.

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.

Blockstream Explorer — Blockstream. The public Esplora deployment, serving both the web explorer and the REST API. The place to confirm current behaviour and to evaluate the software before deploying your own.
Esplora source repository — Blockstream. The open-source implementation with its API reference and deployment guidance. Read this rather than inferring endpoint behaviour from responses; it documents guarantees the responses do not.
Blockstream — Blockstream. The operator, its products and its engineering output. Relevant for judging the longevity of the public instance and for understanding the company's role in the ecosystem it indexes.
Bitcoin developer documentation — Bitcoin Project. Authoritative reference for transaction structure, script types and the UTXO model – the grounding without which this API's fields can be read but not interpreted.
Bitcoin Improvement Proposals — Bitcoin BIPs repository. The specifications behind address formats, deterministic wallets and transaction features that shape what patterns are visible in the data.
Bitcoin white paper — Satoshi Nakamoto. Worth reading for its privacy section, which describes address reuse as the weakness that all subsequent clustering analysis exploits.
Bitcoin Core — Bitcoin Core project. The node software an Esplora deployment sits on top of. Necessary reading before self-hosting, particularly on storage requirements and indexing options.
mempool.space — mempool.space. Open-source live explorer with deep mempool and fee analysis, also self-hostable, and the natural complement for questions about pending activity.
Blockchair — Blockchair. Independent index for cross-checking Bitcoin facts and for population-level queries that a per-object REST API cannot express.
OFAC Sanctions List Search — US Department of the Treasury, Office of Foreign Assets Control. Authoritative digital currency address designations. Screening is entirely your responsibility with this source, because it performs none.
Financial Action Task Force — FATF. The virtual asset standards defining which entities at the end of a Bitcoin trace are regulated and therefore reachable through legal process.
Europol — European Union Agency for Law Enforcement Cooperation. Threat assessments on criminal use of digital assets and the coordination route once a trace crosses into 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 records which instance served every record along with the tip height at collection, keeps mempool observations in a separate state from confirmed transactions, stores outputs and spends rather than flattened transfers so clustering evidence survives, and supports pointing the same collector at a self-hosted deployment through sources.php when the queries themselves must not leave your infrastructure.. Browse the full source catalogue, or follow any tag above into the rest of the library.