An extended public key can let compatible software derive public information across part of a wallet. That can reveal substantially more activity than one receiving address. It is different from a spending key, but it is still sensitive for privacy. Identify the scope and purpose before exporting it.
An export can reveal future activity within its derivable scope as well as existing history.
BTKWIN.COM · EDUCATIONAL EXAMPLEWhat an extended public key means
Hierarchical deterministic wallets derive related keys through a tree structure. Extended public data includes a public key and information used for derivation. Compatible receiving software can use an appropriate export to construct public account information without being given the corresponding spending secret.
A practical use is a watch-only arrangement for monitoring or generating receiving addresses within the supported scope. The resulting visibility depends on what was exported, its position in the tree and the settings understood by the receiving application. The label xpub alone does not describe every account in a user’s wallet.
Different exports may involve different address types, networks or accompanying configuration. Do not assume any public-looking text is universally compatible. Begin with the source wallet’s documentation and the recipient’s actual purpose rather than uploading an entire wallet folder to an arbitrary import tool.
1. It is neither one address nor a recovery phrase
A receiving address identifies a particular destination. Extended public data may permit observation of multiple derived addresses and their activity. A recipient asked to confirm one payment could consequently learn much more than the original task requires.
Conversely, a public export is not a substitute for private recovery material. A program showing addresses and balances does not thereby demonstrate spending capability. Keep a proper recovery plan for the relevant account and distinguish it from accounting and monitoring files.
A watch-only wallet can be useful precisely because the monitoring environment does not hold spending secrets. Preserve that distinction during troubleshooting. If an import fails, adding a private key to a support package is not a routine correction to a public-data compatibility problem.
2. Scope depends on the tree and configuration
An account-level extended public export does not automatically reveal every account, network or hardened branch belonging to a person. The available derivation scope depends on the export and its location in the hierarchy. Avoid both understating and overstating what a specific file reveals.
A narrower export may accomplish the job while exposing less unrelated activity. Ask which account or range the recipient needs and which format the application understands. A shortened display of the export string says nothing useful about the breadth of the information it represents.
Document the scope using non-secret labels meaningful to you. A record saying which account was exported, to whom and for what purpose can support later privacy review. It need not contain private material or publish the financial relationships attached to those labels.
3. Privacy is different from spending authority
Public data alone normally serves observation rather than spending, but observation can connect balances, counterparties and timing across addresses. Attached customer names or invoice labels can make a file even more sensitive. The lack of a private key does not make unrestricted sharing appropriate.
There is a specific technical caveat: BIP32 warns about combining a parent extended public key with a non-hardened descendant private key, which can expose broader private-key authority in that branch. This does not apply identically to every path or account construction.
The practical rule is to keep private keys out of public-data exports and support packages. Do not infer that a mixed file is safe because one of its components is public. Identify what the actual export contains before sending it anywhere.
4. Deleting a share does not retract another copy
After a recipient receives data, deleting your local export or a message does not prove their copy disappeared. Information already learned cannot generally be recalled by changing the account’s display name. Derivable future activity within the exported scope may also remain visible.
Review necessity before sharing. Minimizing the original disclosure is easier than trying to reverse the recipient’s knowledge afterward. If you need new privacy separation, understand the wallet design and implications of changing account use; do not assume there is a universal revoke-xpub button.
Distinguish the types of incident if data was already sent. Disclosure of account labels and transaction links is a privacy problem. Disclosure of private recovery or spending material changes the risk and response. Do not treat those as identical cases simply because they were in similarly named files.
Match the data to the task
| Task | Potentially sufficient data | Question before expanding |
|---|---|---|
| Verify one payment | Transaction ID and relevant destination | Why expose unrelated account history? |
| Monitor one address | Address on the correct network | Does it omit other wallet addresses? |
| Ongoing account reporting | Public export with the needed scope | Will future derived activity be visible? |
| Move a watch-only setup | Supported public configuration export | What labels and metadata accompany it? |
| Restore spending access | Appropriate private recovery route | A public export alone cannot replace it |
Example: an accounting request wider than the invoice
An accountant needs to reconcile three payments for one invoice. The wallet owner instead sends a public account export used for several other activities, together with internal labels. The file may be technically useful, yet much broader than the invoice task.
Before exporting, define the payments, period and assets that need reconciliation. A focused report or set of transaction references may be sufficient. If full ongoing account monitoring is actually required, understand that scope and agree how the recipient will handle the data.
Read the actual export description. Its file name does not guarantee the absence of labels, settings or private fields. A request for one defined public data type is not a reason to transmit the complete wallet directory.
A practical export review
Confirm the purpose, source account, required scope and compatible format. Inspect accompanying metadata and exclude secrets. Then verify the imported result against a known address and expected activity, rather than assuming a plausible-looking balance establishes completeness.
Be especially careful with similar-looking long strings. In the BIP32 format, xpub and xprv describe different public and private serialized data. Verify the product’s export function instead of testing a string by pasting it into an external website.
If you already shared something, identify exactly what was sent and stop expanding the package while diagnosing it. Seek explanations through official channels using a non-secret description. Our watch-only guide explains how monitoring scope can differ from the complete wallet.
Continue reading
English content and examples reviewed: 27 October 2026. Read the Arabic edition.
