An xpub supports watch-only derivation of non-hardened public descendants. Sharing it has privacy consequences that differ from sharing a receiving address.
What the primary record establishes
BIP-32 combines a public key with a chain code to form an extended public key. The specification allows derivation of non-hardened descendant public keys without possession of the corresponding private key. Hardened public-child derivation is deliberately unavailable. Bitcoin BIPs — BIP-32 Hierarchical Deterministic Wallets ↗
The specification warns that extended keys cover a subtree. It also identifies a separate security boundary: a parent extended public key combined with a non-hardened descendant private key can expose the parent extended private key. An xpub alone is not a spending key. Bitcoin BIPs — BIP-32 Hierarchical Deterministic Wallets ↗
What the distinction changes
A watch-only accounting service may need to discover addresses and incoming payments. Giving it an xpub can support that workflow, but can also let the service associate multiple addresses within the exposed branch. A single-address privacy assumption is therefore inappropriate.
This does not mean every wallet address becomes visible under every derivation path. The scope depends on the exported node and hardened boundaries. Treat the path and account structure as part of the disclosure, not as irrelevant implementation details.
What to check before drawing a conclusion
Before exporting, identify which account and branch the receiving service requests and why. Keep private keys and recovery material out of an analytics integration. The combined-key warning should not be misread as a reason to disclose private child keys for troubleshooting.
Review the wallet’s documented derivation scheme and the service’s data retention. Revoking a web connection does not make already shared address relationships unknown again. WFN’s analysis concerns information exposure; it does not certify a particular wallet implementation.