Watch-Only Wallets: What an xpub Exposes

The neutered key

BIP32 defines two extended keys. An extended private key is a private key plus a chain code, written (k, c). An extended public key is the corresponding public key plus the same chain code, written (K, c). The specification calls the conversion from one to the other the “neutered” version, and describes what it removes: the ability to sign transactions.

That is the whole idea behind a watch-only wallet. It imports (K, c), derives addresses from it, watches them, and cannot spend from them. The signing device keeps (k, c) and never shares it.

What the xpub can derive

The derivation function is where the exposure becomes concrete. BIP32 defines CKDpub, which computes a child extended public key from a parent extended public key and an index. The function is only defined for non-hardened child keys: if the index is at or above 2^31 — a hardened index — the function returns failure.

For non-hardened indexes, the specification is explicit about the consequence:

knowing an extended public key allows reconstruction of all descendant non-hardened public keys

Read that with the account structure in mind. A typical account-level export is the node at m/84'/0'/0', the native segwit account BIP84 defines. Because the purpose, coin type and account levels are hardened, the export cannot walk upward to the master key or sideways into another account. But below that point the external chain and the internal chain are non-hardened, so the xpub can derive:

• the first receiving address, then the second, and onward;
• the first change address, then the second, and onward;
• the same set again for any other non-hardened index below that node.

That is exactly what a watch-only wallet needs in order to show the correct balance. It is also what makes the xpub a privacy problem rather than a custody problem.

Privacy is the exposure

BIP32’s security section draws the line directly: leaking a private key means access to coins, while leaking a public key can mean loss of privacy.

Privacy, in this context, is not abstract. The addresses an xpub produces are the addresses the signing wallet uses for receiving and for change. If someone can derive them, they can look them up on a public block explorer, see when each one was funded and spent, and build a transaction history for that account. They still cannot move a coin. What they can do is see the whole account’s activity, and correlate it with anything else they know about the holder.

Two practical consequences follow from the derivation rule:

1. Publish the xpub only where a watcher needs it. A watch-only wallet, a portfolio tracker or an accounting tool all need it. A public profile does not.
2. Treat change addresses as exposed. They are on the internal chain, which the same xpub derives. A user who thinks only receiving addresses are visible is underestimating what the key covers.

The combination risk

The security section contains a second warning, and it is the one that surprises people:

knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key

The logic is a consequence of how CKDpub and CKDpriv relate. Because both derive the child from the same chain code and index, a leaked child private key paired with the parent’s chain code allows the parent private key to be reconstructed. BIP32 names this as the reason hardened keys exist, and the reason they are used at the account level: a leak of an account-specific private key never risks compromising the master key or other accounts.

For a watch-only setup the rule becomes a hygiene rule. The xpub for an account should not be paired with private keys from that same account in a way that lets both leak together. The hardened account boundary is what keeps a leak inside one account. Removing that boundary — exporting a higher-level key, or moving to a scheme where the account level is not hardened — widens what a single leak can reach.

What a watch-only wallet is good for

The common thread is that every one of these uses needs derived addresses, not the ability to spend. That is precisely the capability an xpub provides.

Setting one up

Sparrow’s FAQ covers the detail that trips people up on import. When setting up a watch-only wallet, often only the xpub is known. In that case, the FAQ says a default master fingerprint such as 00000000 is safe to use, and the derivation path can be set to the default for the script type if it is not known.

The fingerprint is an identifier of the root, not a secret and not a checksum of the xpub. Leaving it at a default does not change which addresses are derived; the derivation path does. Getting the path wrong is the more consequential error, because a wallet pointed at the wrong branch will show a zero balance on a funded account.

A short policy

• Keep the seed phrase and the xpub separate. The seed is custody; the xpub is visibility.
• Export at the account level, where the levels above are hardened.
• Treat every address the xpub derives — including change — as public to whoever holds the key.
• Do not pair an account xpub with private keys from the same account on a machine that can leak both.
• Remember what the key cannot do: without a private key, CKDpub produces addresses and nothing that can sign.

The watch-only wallet is a good tool precisely because it is limited. The limit is not that it sees too little; it is that it sees a whole branch at once, and that branch is what the holder of the xpub can look up.

Risk note. The definitions, derivation rules and security statements in this article were read from BIP32 and BIP84 on 2026-10-26, and the import detail from Sparrow Wallet’s FAQ on the same date. Nothing here is investment advice.