One Bitcoin Address Is Not Your Bitcoin Wallet

Paste a Bitcoin address into a tracker and you get a number. Spend from that wallet a week later and the number drops to zero, even though your coins are exactly where you left them and nothing has gone wrong. You watched one address. Bitcoin moved the remainder to a different address that the same wallet also owns, and your tracker has never heard of it.

This is the most common way Bitcoin tracking fails, and it has nothing to do with the app. It comes straight from the way the chain stores value.

Why does my balance drop to zero after I spend?

Bitcoin has no accounts. There is no ledger row with your name on it and a balance beside it. There are unspent transaction outputs, discrete chunks of coin each locked to a particular address, and your balance is whatever your wallet can sum across the chunks it controls.

You cannot spend part of a chunk. You consume the whole output and send the remainder back to yourself, and that remainder is called change. Modern wallets deliberately send change to a brand new address rather than back to the one you just spent from. Pay 0.05 BTC out of a 1 BTC output and 0.95 BTC lands at an address you have never seen.

Where does that address come from? Since BIP32, wallets have been hierarchical and deterministic: one seed phrase generates an unlimited tree of keys, addressed by a derivation path in the shape m/purpose'/coin_type'/account'/change/index. The change level is a single digit, 0 for addresses you hand out and 1 for change coming back. The index counts upward every time either chain is used. Your wallet is not one address. It is two endless sequences of them, and the app that only watches index 0 of the receiving chain sees a rounding error.

Wallets scan a gap limit of 20 unused addresses ahead of the last one with activity. Go quiet for longer than that gap and recovery software will stop looking and report a balance of zero, which is a separate and much more alarming version of the same problem.

What is an xpub, and should I hand one to an app?

An extended public key is the account-level node of that tree, published without its private half. Give a tracker your xpub and it can derive every receiving address and every change address below it, watch all of them, and produce a total that matches your wallet exactly. It cannot derive a private key and it cannot sign anything. That is the appeal, and it is genuine.

The prefix tells you which address type the key was built for. xpub sits under BIP44 and produces legacy addresses beginning with 1. ypub sits under BIP49 and produces wrapped SegWit addresses beginning with 3. zpub sits under BIP84 and produces native SegWit addresses beginning with bc1q. Taproot under BIP86 keeps the plain xpub prefix while producing bc1p addresses, which is exactly the kind of detail that makes a restore look like a lost wallet. Hand a tracker the wrong one and it derives a perfectly valid set of addresses that your coins are not in.

Now the cost, and it is worth stating plainly rather than burying. An address leaks the history of one address. An xpub leaks the history of the whole wallet, in both directions in time. Whoever holds it sees every payment you have ever received, every amount, every counterparty address, your change patterns, your total balance, and every future transaction from that account for as long as you keep using the seed. You cannot rotate it. Revoking an exposed xpub means moving to a new account or a new seed entirely.

The wallet privacy trade-off works through where that line sits for different holders. The practical middle ground most people land on: use a separate account for the balance you are willing to expose, share that account's extended key, and keep the long-term cold storage watched by individual addresses or entered as a manual position with no on-chain identifier at all. Tracking a hardware wallet covers where to find the extended key on each major device.

How do I know an address is real before I use it?

Four formats are in circulation. Addresses starting with 1 are legacy pay-to-public-key-hash. Starting with 3 are pay-to-script-hash, which covers both wrapped SegWit and most older multisig. bc1q is native SegWit under bech32, usually 42 characters. bc1p is Taproot under bech32m, usually 62 characters. Bech32 addresses are written in lowercase, and while an all-uppercase form is valid, a mixed-case bc1 address is not.

Every format carries a checksum, which is why almost nobody loses coins to a mistyped address; the wallet simply refuses it. What the checksum cannot protect you against is a valid address that is not the one you meant. Clipboard malware and address-poisoning attacks work by substituting an address that passes every check and belongs to somebody else. Compare the first and last six characters against your hardware wallet's own screen, not against what your computer is showing you, and treat fake wallet and tracker apps as the more likely attack than any weakness in the chain.

Where do Ordinals, Runes and inscriptions end up in my total?

Nowhere, usually, and that is the answer people find hardest to accept.

Bitcoin has no token standard. Ordinals assign data to individual satoshis; Runes and BRC-20 layer their accounting on top of ordinary outputs. To a base-layer balance query all of it is just satoshis. A tracker reads a number of BTC and has no way to know that one of those outputs carries an inscription somebody values at four figures. The reverse risk is sharper: a wallet without coin control can select an inscribed output to pay a fee, and the inscription is gone.

You also receive whatever anyone chooses to send you. Dust attacks push tiny amounts to your addresses hoping you will spend them alongside your real coins and link the two together. Inscribed junk arrives the same way. Neither can be blocked, so the discipline is not to consolidate carelessly, and to filter at the display layer instead. Filtering spam and dust covers the general approach, and it applies here even though Bitcoin's version of spam does not carry a fake price tag the way an EVM airdrop does.

What should I actually put into a tracker?

1. Decide the exposure first. One extended key covering everything is the most accurate and the least private. Individual addresses are the reverse. Pick before you paste, because you cannot take an xpub back.
2. Match the prefix to the address type. zpub for bc1q, ypub for 3, xpub for 1 or bc1p. If the balance comes back zero and the wallet says otherwise, this is the first thing to check.
3. Use a real explorer for ground truth. mempool.space for individual addresses, fees and confirmation state; Blockchair if you need to look up an extended key's derived addresses directly.
4. Add cold storage you will not expose as a manual position with its real acquisition price, so the amount is counted and cost basis survives.
5. Reconcile once against the wallet's own total, then chase any gap. On Bitcoin the gap is nearly always change addresses or an unscanned account, not a pricing error. Why your portfolio balance is wrong lists the rest.

Set a wallet-transaction alert on the addresses that should never move, and the next unexpected outbound tells you something before the balance does. On Pro and Pro+ that alert fires on the transaction itself rather than on a price, which is the notification that matters when the address in question is your cold storage.