What privacy does an xpub provide in a watch-only wallet?
An xpub can monitor a public branch, but it can also reveal its addresses and activity. Learn its limits, import metadata and how SeedAddress fits in.
View article
An xpub can create a watch-only view of a branch in a hierarchical deterministic wallet: software can derive descendant public keys and monitor the addresses belonging to that branch, but it cannot sign transactions from that public material alone. The convenience has a cost. Whoever receives the xpub may observe the scope of the exported branch and link its addresses and activity. An xpub does not automatically reveal every wallet account, but it is not just an isolated receiving address that can be shared without context.
The practical answer is to export only the branch you need, document the network, script type and path, and treat the xpub as sensitive financial information. When importing it into a watch-only wallet, check which format and metadata the software requires.
What an xpub is
The BIP32 specification represents an extended public key as a public key together with a chain code, describing a node in a key tree. The term xpub commonly refers to a serialization of that information for a wallet family, although exact prefixes and formats depend on the network and application. State which standard and wallet created the export instead of assuming that every similarly prefixed string means the same thing.
From a public node, BIP32 can derive child public keys when the following steps are non-hardened. Software can turn those keys into the outputs it watches according to its script and address rules. An xpub does not contain the private key needed to sign; a watch-only wallet can calculate addresses and query balances, but another device or wallet must keep the private keys and approve a transaction.
The scope includes only descendants reachable without crossing hardened steps. An account outside that scope is not exposed automatically. Changing a network label does not cryptographically separate reused keys: the limits depend on the wallet scheme and the export.
What the xpub recipient can see
The main risk is privacy. An xpub can make it possible to generate many addresses in the branch and follow their incoming and outgoing activity when the lookup infrastructure identifies it. It can also help link new addresses to the same branch, especially if you share the xpub with a service that keeps history, labels or IP addresses. The Bitcoin.org privacy guide explains that address reuse and disclosed payment information make activity easier to relate; an xpub expands that exposure to a derivable set of addresses.
Do not confuse visibility with spending control. An observer may know balances and activity without being able to authorize a transaction. A balance or incoming payment does not prove who controls the keys: see why a public address cannot recover a wallet. Before receiving funds, compare the address with the one shown by your trusted signing device; malicious watch-only software could substitute a different address.
An xpub is also not harmless key data. BIP32 warns that knowing a parent xpub together with a non-hardened descendant private key allows recovery of the parent extended private key and its descendants. Hardened derivation boundaries exist precisely so that a leak of a child branch private key does not compromise a root or higher accounts. Do not combine a shared xpub with private keys from its descendants without understanding that relationship.
Privacy by branch and hardened derivation
Export the smallest branch
Before sharing an xpub, identify the purpose of the export. For a watch-only wallet for one account, export that account branch or the descriptor recommended by the software. A higher xpub only expands visibility to other branches reachable without hardened steps; a master xpub cannot derive accounts placed behind those boundaries.
Hardened derivation changes the boundary of what public material can derive. BIP32 does not allow a hardened child to be calculated from the parent xpub. Many wallets place hardened boundaries at account levels, but do not assume a path: check the wallet documentation and the actual export. The guide on why one seed phrase can show different wallet addresses explains how a different path, account, network or format changes the recovered view.
What a watch-only wallet needs to import correctly
An xpub alone may be insufficient to reconstruct the outputs the wallet should watch. The BIP380 specification for output script descriptors explains that an export needs to describe how to interpret keys, which scripts to produce and which derivation path to follow. Missing that information creates incompatibilities between wallets even when both accept extended keys.
A descriptor may include the script type, the fingerprint of the key where derivation starts and the path to the exported key, plus subsequent derivation steps. That fingerprint usually identifies the master key, not a physical device. The exact format depends on the application. Some wallets import a checksummed descriptor; others show separate fields for account, external chain and change. BIP380 also addresses exporting the public key from the last hardened step so that an export without private keys remains useful.
Before funding the wallet, verify in a test copy or device:
- the network and asset it should monitor;
- the complete account and derivation path;
- the script type and address format;
- the receiving and change chains;
- the address discovery limit and how to extend it;
- the historical address you expect to find.
Do not enter a seed phrase or private key into a watch-only importer. A watch-only wallet should work with public material and derivation metadata; if it requests a signing secret for a simple view, stop and verify the software. The guide on protecting a seed phrase from phishing gives broader rules for keeping secrets away from pages or supposed support services.
How to share an xpub with less exposure
Share the narrowest branch your wallet supports and document its network, script, account, path and date. Avoid publishing the xpub in chats, screenshots or logs you do not control; a provider may retain history and associate it with other data. Run discovery with an unfunded address and confirm that the signing device still controls the corresponding wallet: the test validates the view, but does not turn an xpub into a signing backup.
If it was shared too broadly, assume that branch privacy is compromised. Deleting a service account does not revoke a copied xpub: its holder can keep deriving and monitoring future reachable addresses. To separate future activity, use an account behind a hardened boundary that the disclosed xpub cannot derive, or an independent wallet, with a verified backup. A new non-hardened branch below the exposed xpub remains observable. A public transfer can link the new destination; migration neither erases history nor guarantees anonymity.
What this means for SeedAddress
SeedAddress generates a BIP39 mnemonic locally in the browser from the selected coordinates, input password, language and word count. Its v1 method uses a precision-nine geohash and HMAC-based derivation. It does not generate receiving addresses or wallet private keys, and the public place does not add fresh random entropy. A 24-word output therefore does not guarantee the security of a wallet created with 256 bits of random entropy; the legacy five-character minimum is not a recommendation for a new password.
Afterward, a compatible wallet can derive its own accounts and addresses from the mnemonic, with its own paths, networks and formats. SeedAddress does not decide which xpub that wallet will export or guarantee that two applications use the same branch. Keep the exact deterministic inputs and an independent offline backup; see how to recover a SeedAddress phrase to reproduce the deterministic result and how to migrate to a new wallet if you plan to protect funds with randomly generated keys.