Query the chain · dormant Bitcoin wallet data
Dormant Bitcoin wallets and addresses API, by last spend
A dormant Bitcoin wallet is one whose coins have not moved in years. Finding those addresses is harder than it looks, because dormancy is a fact about spending, and the public address endpoints do not tell you when an address last spent.
REST API · SQL · dashboards · indexed from genesis
Hit Run to query the fully-indexed Bitcoin blockchain.
BTC
30-day trend
informational on-chain data · not financial advice
The Bitcoin Pizza address is the clearest illustration we know of, and you can check every figure in it yourself. On 22 May 2010 at 18:16 UTC it received 10,000 BTC in block 57,043. Ten minutes later, in block 57,044, it spent all 10,000 BTC. That is the only time it has ever spent anything. Since then it has received fifteen more payments, tiny tribute amounts totaling 379,983 satoshis, the most recent on 22 May 2026. Three of those arrived on Pizza Day itself: 22 May 2023, 22 May 2024, and twice on 22 May 2026. So how dormant is this address? Sorted by last activity it looks like it moved three months ago. Sorted by last spend it has been asleep for sixteen years. Any screen built on the first definition gets this address, and every address like it, completely wrong.
The practical problem is that the endpoints most people reach for cannot answer the second question at all. We called them from a US server on 13 August 2026. Blockstream Esplora returns an address object with exactly three keys, and the useful one holds funded and spent output counts and sums plus a transaction count. There is no timestamp anywhere in it. mempool.space returns the identical shape, down to the same three keys. BlockCypher's balance endpoint returns nine fields, all of them counts and amounts, and again not one date. Every one of these will happily tell you an address has spent exactly one output in its life, while refusing to say when. To learn the date you make a second call for the transaction list, which hands back full transaction objects twenty five to a page, and you throw nearly all of it away to keep one number.
Here the answer is a field. Every address in the indexed chain carries its last spend, its last receive, its first activity and the age of the coins currently sitting on it, so a dormancy screen is a filter rather than a crawl. Ask for every address holding more than 50 BTC that has not spent since 2013, get the list. Ask for coin days destroyed over a block range and get the standard dormancy measure, the amount of each spent input multiplied by the days those coins sat still, which is how analysts separate old money moving from ordinary daily churn. For scale, a single coin from the pizza era moving today would destroy 5,927 coin days per BTC. Watch the same filter forward and you get an alert the moment something long-dormant wakes up. This is informational on-chain data, not financial, investment or legal advice.
Indexed from genesis queryable in seconds
On-chain data not financial advice
Why it works
What you get with dormant Bitcoin wallet data
Dormant by last spend, not last touch
Every address carries its last spend and its last receive as separate fields, so an address that only receives tribute dust still reads as dormant. That distinction is the difference between a screen that works and one that quietly drops the oldest coins on the chain.
Coin days destroyed, already computed
Each spent input is valued by amount multiplied by the days it sat unspent, aggregated per block, per day or per entity. That is the standard dormancy measure, and it separates genuinely old supply moving from the ordinary churn that dominates transaction counts.
Screen a list, or watch it forward
Run the filter once across an address set to find everything that has not spent since a date you choose, or leave it running so a webhook fires the moment a long-dormant address moves. The same query serves the audit and the alert.
Side by side
Can these APIs tell you when an address last spent?
Every public endpoint below was called from a US server on 13 August 2026, once each rather than in a burst. The question asked is the one a dormancy screen depends on: when did this address last move coins out?
| Source | Returns a last-spend time on the address record | What you have to do instead | Calls to screen 10,000 addresses |
|---|---|---|---|
| Blockstream Esplora | No. Three keys, holding funded and spent counts and sums only | Call the transaction list endpoint and read the newest spending transaction | 20,000 or more |
| mempool.space | No. Identical response shape, same three keys | The same second call, returning 25 transactions per page | 20,000 or more |
| BlockCypher | No. The balance endpoint has nine fields and no date among them | Request transaction references and scan them yourself | 20,000 or more, against 100 requests per hour on the free tier |
| Blockchair | Documents a last-seen-spending field, but our unauthenticated request returned HTTP 430 on 13 August 2026 | Contact them for a key, then batch the dashboard calls | Not knowable without a key |
| Own node plus indexer | Only if you build that index yourself. Bitcoin Core stores the current UTXO set, not spend dates by address | Sync the chain, then write and maintain the dormancy index | None, once you have built and kept it running |
| BitcoinDatabase | Yes. Last spend, last receive, first activity and coin age on every address record | Nothing. Filter the address list by last spend date in one query | 1 |
The 10,000 address figure assumes the minimum a dormancy screen needs: one address lookup plus one transaction page per address. Addresses with long histories need several pages each, so the real number is higher.
What it handles
The indexed Bitcoin chain, queryable your way
Look up an address, a transaction, a UTXO, the rich list or an on-chain metric, by REST API, SQL or dashboard. The same authoritative data, reconciled block-by-block against the canonical chain, without running a node.
- Find addresses that have not spent since a given date
- Separate last spend from last receive on every address
- Rank dormant addresses by balance and by coin age
- Compute coin days destroyed over any block range
- Alert when a long-dormant address moves coins
- Screen a supplied address list for dormancy in one pass
- Measure how much supply has sat still for five or ten years
{
"address": "bc1qxy2k…l0wdv8",
"balance_btc": 68432.10,
"balance_usd": 4612165420,
"tx_count": 1284,
"unspent_outputs": 37,
"first_seen": "2014-02-09"
}Why BitcoinDatabase
One platform, queryable three ways
Not a raw node to sync, not an indexer to build, and not five vendors to stitch together. The fully-indexed Bitcoin blockchain, available as a REST API, as SQL, and as dashboards, on one authoritative dataset.
REST API
Typed JSON for addresses, transactions, balances, UTXOs and metrics. Drop it into apps, wallets, explorers and agents with curl, Python or any HTTP client.
SQL access
Run SQL directly against the indexed Bitcoin dataset for ad-hoc analysis, cohorts and exports, the same data the API and dashboards read from.
Compliance-first
Informational on-chain data and analytics only. Entity labels and flow tracing are framed as tooling to support a regulated team's own review, not accusations.
Good questions
Questions about dormant Bitcoin wallet data
Explore more
More ways to query Bitcoin with BitcoinDatabase
Bitcoin Supply Metrics API
Query supply in profit and loss, HODL waves and exchange supply from the indexed chain.
Learn moreBitcoin address lookup
Look up any Bitcoin address: balance, full history and UTXOs in one query.
Learn moreBitcoin active addresses
Daily active address counts, historical series and entity-adjusted numbers from the indexed chain.
Learn moreBitcoin historical data API
Full-depth history: every block, transaction and metric back to 2009.
Learn moreBitcoin webhook API
Real-time notifications on address activity, incoming payments and confirmations.
Learn morexpub balance API
Derive an HD wallet's addresses from its xpub and total the balance to the satoshi.
Learn moreStop running a node. Just query Bitcoin.
Run your first query now and get on-chain data back by REST API, SQL or dashboard, indexed from the genesis block. Informational on-chain data only, not financial advice.
Indexed from genesis · REST · SQL · dashboards · addresses, transactions, UTXOs, metrics