How to check if a bitcoin address has been used

Looking up a bitcoin address takes a few seconds, and any block explorer will do it for free. The harder part is knowing what the answer means, because “used” covers two different events. An address can have received coins, and it can have spent them. Your wallet treats both as used. For privacy, both matter. For quantum exposure, only one of them changes anything. This article shows how to read the numbers, what they do and do not prove, and what a lookup tells the service you ask.

Two meanings of “used”

When someone pays a normal address, the transaction records a locking condition built from the address. For the hashed formats, that condition contains a hash of your public key, not the key. You can receive a thousand payments and your key stays where it was.

When you spend, the network has to check your signature, and it needs the public key to do so. BIP-141 shows it plainly for a native SegWit spend: the witness holds the signature and the public key. Legacy spends carry the same two items in the input script. From then on the key is permanent public data.

So the question “has this address been used?” splits in two, and they answer different concerns:

• Has it received? This is about privacy. Receiving twice on one address links those payments to each other, which is why wallets hand you a new address each time.
• Has it spent? This is about the key. It is the question that matters for address reuse and quantum exposure, because Shor's algorithm works from a public key and has nothing to work with on a hash alone.

How to check on a block explorer

Open any block explorer, paste the address into the search box and read the address page. Layouts differ, but nearly all of them show total received, total sent, the current balance and a transaction list. Then read it like this:

The last row is the one that matters most. It usually comes from coins arriving after an earlier spend, a spend that used only some of the address's outputs, or change sent back to the same address.

Two habits make the reading more reliable. First, check for pending transactions. A spend waiting in the mempool has already been broadcast, so its public key is already visible to anyone watching the network, even though it is not in a block yet. Second, do not judge from the balance: a brand-new address and one that has moved thousands of coins can both show zero.

The same check with raw numbers

If you would rather see the data without a page around it, public explorer APIs return it directly. Our scanner uses the API from mempool.space (no affiliation), and the request is one line: https://mempool.space/api/address/<address>.

The response has two blocks with the same fields, chain_stats for confirmed activity and mempool_stats for unconfirmed. Three fields answer the question:

• tx_count above zero, in either block, means the address has appeared in a transaction.
• funded_txo_count is how many outputs have paid this address. Above zero means it has received.
• spent_txo_count is how many of those outputs have been spent. Above zero, in either block, means the address has spent.

That third field, added across both blocks, is the test our scanner applies.

Where the simple reading stops working

“Never spent means the key is hidden” holds for a hashed single-signature address considered alone. Here is where it does not hold, or does not say enough.

Taproot. A bc1p address has no hash in front of its key. The key is in the output itself, so coins there are exposed whether or not the address has ever spent. For Taproot the used-or-not question does not settle exposure at all, as we explain in our Taproot article.

Multisig and other scripts. A 3 or a 62-character bc1q address commits to a hash of a script. From the outside you cannot tell what the script contains until it spends. A spend reveals the script that was used, including the keys inside it.

The same key in another format. One public key can produce a legacy address, a nested SegWit address and a native SegWit address. If you spent from one of them, the key is public, and the others are exposed even though each one looks unspent on an explorer. Explorers treat addresses as separate things, and so does our scanner.

Keys revealed off the chain. An explorer only shows what is on the chain. A public key can leave your hands in other ways. An extended public key given to a service lets that service derive your public keys. A signed message can reveal one: the classic Bitcoin message signature lets the verifier recover the key. A public Lightning channel announces its funding keys to the whole network, which we cover in our Lightning article. None of this appears on an address page.

The address nobody can read correctly by this test. The address usually associated with the genesis block is 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa. When we looked it up on mempool.space on 2 November 2026, its confirmed stats showed 67,234 transactions and a spent_txo_count of zero. By the rule above that reads as hashed and hidden. But the genesis reward was a pay-to-public-key output, so the key behind that address has been readable since the first block. The hashed address is a label for a key that is already public. Our P2PK article explains the format. If you are checking a very early address, a clean result is no answer at all.

Payments you did not ask for

Anyone can send coins to any address, so a retired address can show a new small incoming transaction. This is usually dust, sent by someone trying to link addresses together.

Receiving does not reveal your key, so the transaction itself changes nothing about exposure. What matters is the next step. If your wallet later spends that small output together with your other coins, the spend reveals the key and links those coins publicly. If your wallet lets you freeze a single output, that is the sensible response.

What a lookup tells the service you ask

This applies to us too. When you look up an address on a public explorer, the operator can see the request: that address, your IP address and the time. Look up several addresses from the same connection and the operator can reasonably guess they belong together.

The ShorWatch scanner sends nothing to a ShorWatch server, because the page calls the mempool.space API directly from your browser. That means mempool.space receives those requests, under its own policies. The same applies to any hosted explorer. To reduce it:

• Use a VPN or Tor, and look addresses up at different times rather than all at once.
• Run your own instance. The mempool project is open source, and a self-hosted address index answers the same query without telling anyone.
• Check what your own wallet already knows. Its address list may answer the question with no new lookup.

A plain Bitcoin Core node is less help here than people expect. Its scantxoutset command searches the current unspent set, so it can show what an address holds now, but it cannot show that the address once spent. Its own help text also notes that the addr() descriptor does not include P2PK. For per-address history you need an address index on top, or a wallet that has imported the address and rescanned.

Checking a whole wallet

A single seed can hold dozens of addresses, and each one has its own answer. Change addresses are the ones people forget, since you never typed them or shared them.

You can export the list from your wallet and check each one, or give a tool the extended public key and let it derive them. Our scanner does the second. It follows the receive and change chains and uses the 20-address gap limit from BIP-44, stopping once a full batch of 20 shows no activity, with a safety cap of 100 addresses per chain. A wallet with a long unused gap, or more than 100 addresses on a chain, can have balances the scan does not reach.

An extended public key cannot spend, but it reveals your public keys and full address history to whoever holds it. Do not hand it to anyone who asks for it. If you use a tool with one, choose a tool you have reason to trust.

What to do with the answer

If a hashed address has never spent, there is nothing to do except keep its key out of the other routes listed above. When you do spend from it, send the remainder to a new address and stop receiving on the old one.

If an address has spent and still holds coins, or the coins are on Taproot, they are exposed at rest. That is a fact about the coins, not an emergency. The way out is an ordinary transaction to a new, never-used hashed address. The spend reveals the key for the short time it takes to confirm, which is true of every bitcoin transaction. Fees and privacy trade-offs still apply.

No computer today can run Shor's algorithm against a 256-bit curve key, and we do not put a date on when one could. BIP-361, a draft proposal, states that over 34% of all bitcoin had a revealed public key as of 1 March 2026.