Dormant Bitcoin Wallets: How to Tell If an Address Is Asleep

Dormancy sounds like the easiest thing on the blockchain to measure. The chain is public, every transaction is timestamped, so finding wallets that have gone quiet should be a filter. In practice almost everyone who tries it gets a number that is wrong in one of two ways, and both mistakes come from the same place: the tooling makes the easy question convenient and the correct question expensive.

Start with the address that breaks every dormancy screen

On 22 May 2010, at 18:16 UTC, an address received 10,000 BTC in block 57,043. Ten minutes later, in block 57,044, it spent all 10,000 BTC. That was Laszlo Hanyecz paying for two pizzas, and it is the only time that address has ever spent anything.

What happened next is the interesting part. People kept sending it money. We pulled its full transaction list on 13 August 2026 and it holds seventeen transactions: one receive, one spend, and fifteen more receives spread across sixteen years. The tribute payments total 379,983 satoshis and none of them have ever been moved. Look at when they landed:

Three separate Pizza Day anniversaries show up in that list. Somebody sends the pizza address a few thousand satoshis every 22 May, which is a nice thing about this industry and also a serious problem for anyone building a dormancy screen.

Because now ask the question two ways. When was this address last active? March and May 2026, so it looks live. When did this address last spend? May 2010, sixteen years and change ago. The coins on it have never moved. If your screen sorts by last activity, this address and every address like it drops off your dormant list, and those are exactly the addresses you were looking for. Anyone can send coins to an address they do not control, which means last activity is a signal partly under a stranger's control. Last spend is the only side of it that requires the owner's key.

Why the public APIs will not just tell you

Here is the part that surprises people. We called the three most widely used public address endpoints from a US server on 13 August 2026, single polite requests, and asked each for that address. None of them returned a date.

Both Esplora-style responses will cheerfully tell you this address has spent exactly one output in its entire life, and refuse to say when. That is the whole dormancy question, one field away, and it is not there. Blockchair does document a last-seen-spending field, which would solve this neatly, but our unauthenticated request on the same day came back HTTP 430 with a message saying the IP was temporarily blacklisted for exceeding usage, so plan on getting a key before you rely on it.

The workaround is to fetch the transaction list, take the newest transaction that spends from the address, and read its block time. That works. It is also why dormancy screening gets expensive fast. The transaction list endpoint returns full transaction objects, inputs, outputs, scripts and all, twenty five to a page, and you are keeping one integer from all of it. For one address that is nothing. For a list of 10,000 addresses it is 10,000 extra round trips minimum, more for any address with real history, against providers that rate limit you. BlockCypher's free tier allows 100 requests an hour, so that screen alone would take over four days.

How to check whether a Bitcoin address is dormant

The method, in the order that actually works:

1. Fix your definition first, in writing. Dormant since when? Five years is the common threshold, ten years for the satoshi-era question. Write it down, because every number you produce afterwards is meaningless without it.
2. Use last spend, not last activity. Pull the address transaction list and find the newest transaction where the address appears in the inputs. Receives do not count, for the reason the pizza address demonstrates.
3. Decide whether you are measuring addresses or wallets. One person can hold a thousand addresses. If you want dormant wallets rather than dormant addresses you need address clustering first, and clustering has known failure modes that are worth understanding before you quote a figure.
4. Score it with coin days destroyed. For every spent input, multiply the amount by the days those coins sat unspent. A coin from the pizza era moving today destroys 5,927 coin days per BTC. A coin that moved yesterday destroys almost none. This is the standard way analysts separate genuinely old supply moving from ordinary daily churn.
5. Watch it forward, do not just snapshot it. The valuable event is a wake-up: a long-dormant address spending for the first time in a decade. That needs a standing filter and a webhook, not a monthly report.

Dormant is not the same as lost

This is the mistake that turns a good analysis into a bad headline. Dormancy is observable: the coins have not moved, and the chain proves it. Whether anyone still holds the keys is not observable at all, from any dataset, ever.

Long-term holders, cold storage that is working exactly as intended, estates in probate, institutional custody and genuinely lost keys all produce an identical on-chain signature, which is silence. This is why published estimates of lost Bitcoin vary so widely. They are not measuring different chains, they are applying different definitions to the same one. Any figure quoted without stating its dormancy threshold, its clustering method and its treatment of provably unspendable outputs cannot be compared to any other figure. When you publish a number, publish those three choices next to it.

There is a related point worth being blunt about, because the search results around this topic are full of it. No amount of chain analysis produces a private key. Addresses and balances are public, keys are not, and the arithmetic between them only runs one way. Services offering lists of dormant wallets with recoverable keys are selling a scam, and anything that asks for a seed phrase is trying to take your coins.

What a wake-up actually means

When a decade-old address moves, it gets reported within minutes and the interpretation is usually wrong. The chain shows a transfer. It does not show intent. A 2013 address spending into two fresh addresses is far more likely to be a custody migration, an estate settlement or a firm consolidating storage than anybody selling. Coins moving to a labeled exchange deposit address is a different and much stronger signal, which is why exchange flow data and entity labels matter more than the movement alone.

If those coins are yours and you are the one moving them, the awkward part is not the analytics. It is that a disposal of coins acquired in 2011 needs a cost basis, and the records from that era are usually a screenshot and a memory. Working out what you owe on a fifteen-year-old acquisition is genuinely painful, and it is worth getting the tax side prepared before you touch the coins rather than the following April. On the chain side you can at least reconstruct exactly what the address held on the acquisition date and every date since, which is the evidence half of the problem.

The shortcut

Everything above is a description of work you do not have to do if the chain is already indexed by the fields the question needs. On dormant Bitcoin wallet data here, last spend, last receive, first activity and coin age are columns on the address record. Finding every address holding more than 50 BTC that has not spent since 2013 is a filter, not a crawl, and coin days destroyed over a block range is a query rather than a pipeline. You can also run it across a supplied address list in one pass, or read the same data in SQL if you would rather join it against labels and flows.

Every figure in this article was measured on 13 August 2026 and the block heights are printed so you can check them against any explorer. The pizza address is a good test case precisely because it is public and stubborn: seventeen transactions, one spend, sixteen years ago. If your dormancy screen calls it active, the screen is measuring the wrong thing. This is informational on-chain data only, not financial, investment, tax or legal advice.