Xpub (Extended Public Key)

What Is an Xpub?

An xpub (extended public key) is a special public key defined by BIP-32 that contains enough information to derive an entire tree of child public keys. Where a regular public key maps to a single Bitcoin address, an xpub can generate billions of addresses in a deterministic sequence. Anyone holding the xpub can compute every address the wallet will ever produce from that branch, without needing the corresponding private keys.

This capability is foundational to hierarchical deterministic (HD) wallets. When you set up a wallet from a seed phrase, the wallet derives a master key, then branches into account-level extended keys. The xpub for each account is the public half of that branch: it can watch, but it cannot spend.

The term "xpub" technically refers to the Base58Check-encoded string that begins with the characters xpub. This encoding bundles three pieces of data: the public key itself, a chain code used for derivation, and metadata such as depth and parent fingerprint. Together, these allow any software to reconstruct the full hierarchy of child keys from a single string.

How It Works

Extended key derivation starts with BIP-32's child key derivation function. Given a parent extended public key and an index number, the function produces a deterministic child public key. Repeating this process at each level of the derivation path yields the full tree of addresses.

BIP-32 Key Derivation

An extended key consists of two components: a 256-bit key and a 256-bit chain code. The chain code acts as entropy for the derivation function, ensuring that knowing a child key does not reveal its siblings.

BIP-32 defines two types of child derivation:

• Normal (non-hardened) derivation: uses the parent public key and chain code. Since only public data is required, an xpub can derive normal child public keys independently.
• Hardened derivation: requires the parent private key. An xpub cannot perform hardened derivation, which is why hardened steps in the path (indicated by an apostrophe or 'h') create a firewall that limits what the xpub can reach.

In practice, standard wallet derivation paths use hardened steps for purpose, coin type, and account levels, then switch to normal derivation for the change and address index levels. This means an account-level xpub can derive all receiving and change addresses for that account, but cannot reach other accounts.

From Seed to Xpub

A standard BIP-84 native SegWit wallet follows this derivation path:

m / 84' / 0' / 0' / change / address_index
│    │     │     │      │         └─ Normal: 0, 1, 2...
│    │     │     │      └─ Normal: 0 = receiving, 1 = change
│    │     │     └─ Hardened: account number
│    │     └─ Hardened: coin type (0 = Bitcoin)
│    └─ Hardened: purpose (84 = native SegWit)
└─ Master key

The xpub exported from a wallet typically represents the key at depth 3 (the account level): m/84'/0'/0'. From this xpub, software derives child keys at the change and address_index levels without private key access.

Account xpub (m/84'/0'/0')
├── Receiving addresses (m/84'/0'/0'/0/*)
│   ├── Address 0: bc1q...abc
│   ├── Address 1: bc1q...def
│   └── Address 2: bc1q...ghi
└── Change addresses (m/84'/0'/0'/1/*)
    ├── Address 0: bc1q...jkl
    └── Address 1: bc1q...mno

Version Prefixes: xpub, ypub, zpub

The Base58Check encoding of an extended public key includes a 4-byte version prefix that determines the human-readable characters at the start of the string. Different BIPs introduced different prefixes to signal which address type the key tree produces:

On Bitcoin's testnet, the equivalent prefixes are tpub, upub, and vpub. The underlying key data is identical regardless of prefix: the version bytes simply tell wallet software which script template to use when constructing addresses.

Some wallets and tools only recognize xpub format and silently convert ypub/zpub internally. Others require the correct prefix to derive addresses properly. When importing an extended public key into third-party software, verify it interprets the prefix as expected to avoid generating the wrong address set.

Use Cases

Watch-Only Wallets

A watch-only wallet imports an xpub to monitor all addresses and track balances without the ability to sign transactions. This is the most common use of xpubs: operators can monitor funds on internet-connected devices while private keys remain on air-gapped hardware or in cold storage.

For example, a business might store signing keys on a hardware wallet in a vault, then import the xpub into accounting software running on a server. The software generates fresh receiving addresses for each customer invoice, monitors incoming payments, and computes balances: all without ever touching the private keys.

Payment Processors

Payment processors use xpubs to generate unique addresses for each transaction. When a customer checks out, the processor derives the next unused address from the merchant's xpub and presents it as the payment destination. This eliminates address reuse and avoids the need for the merchant's hot wallet to be online during address generation.

The processor tracks the address gap limit to determine how far ahead to scan for payments. If a customer pays to address index 500 but addresses 480 through 499 have never received funds, the processor must scan at least 20 indexes beyond the last known transaction to detect the payment.

Accounting and Auditing

Auditors and accounting teams use xpubs to verify complete transaction histories. By importing the xpub, they can independently reconstruct every address the wallet has used and cross-reference on-chain data against internal records. This provides cryptographic proof of the full UTXO set without requiring access to spending keys.

This pattern is especially valuable for multisig wallet setups where multiple parties need independent visibility into shared funds. Each cosigner can export their xpub so that all participants (and auditors) derive the same set of multisig addresses.

Multi-Account Structures

HD wallets use separate account indexes to segregate funds. An exchange might use account 0 for hot wallet operations, account 1 for cold storage, and account 2 for fee management. Each account has its own xpub, and sharing one account's xpub reveals nothing about the others thanks to hardened derivation at the account level.

Privacy Risks and Considerations

Address Linkability

This is the most critical risk of xpub exposure. Anyone who obtains your xpub can derive every address your wallet has generated or will generate from that account branch. This means they can:

• Calculate your total balance across all derived addresses
• Trace every incoming and outgoing transaction
• Monitor future transactions in real time as new addresses receive funds
• Link addresses that would otherwise appear unrelated on-chain

A single address leak is limited in scope. An xpub leak exposes the entire financial history of that account. For this reason, an xpub should be treated with the same sensitivity as a bank statement: it cannot steal funds, but it destroys financial privacy.

Safe Sharing Practices

There are legitimate reasons to share an xpub: configuring a watch-only wallet, setting up a payment processor, or enabling an auditor. When doing so, follow these guidelines:

• Share over encrypted channels only: never transmit an xpub via email, unencrypted chat, or public forums
• Use account-level xpubs (depth 3), not the master xpub: this limits exposure to a single account rather than the entire wallet
• Prefer output descriptor format when possible: descriptors like wpkh([fingerprint/84'/0'/0']zpub.../0/*) make the derivation scheme explicit and reduce ambiguity
• Rotate to a new account if an xpub is compromised: generate a new account index and migrate funds to addresses derived from the fresh xpub

Xpub Leaks in Practice

Common xpub leak vectors include wallet software that transmits xpubs to backend servers for balance lookups, browser extensions that phone home with key material, and block explorer services that log xpub queries. Privacy-focused wallets mitigate this by running a personal full node or using client-side filtering so the xpub never leaves the device.

When working with PSBTs for transaction construction, ensure that xpub metadata embedded in the PSBT is stripped before broadcasting. PSBT files can contain extended public key fields that are useful for signing coordination but should not be shared publicly.

Master Key Compromise

A subtle but serious risk: if an attacker obtains both an xpub and any single child private key derived from the same non-hardened branch, they can mathematically compute the parent private key and all sibling private keys. This is an inherent property of BIP-32 non-hardened derivation. Hardened derivation at the account level prevents this from escalating to the master key, but within a single account branch, one leaked child private key plus the xpub equals total compromise of that branch.

This is why modern key schemes and wallet architectures emphasize strict separation between public key material shared for coordination and private key material used for signing.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.