Extended Key (xprv/xpub)

What Is an Extended Key?

An extended key is the fundamental building block of hierarchical deterministic (HD) wallets. It combines a standard cryptographic key (either private or public) with a 32-byte chain code that serves as additional entropy for deriving child keys. Without the chain code, a key alone cannot produce deterministic descendants: the chain code is what makes the derivation tree possible.

Extended keys were introduced in BIP-32, proposed by Pieter Wuille in 2012. They solved a critical problem in Bitcoin wallet design: before HD wallets, every new address required an independent key backup. With extended keys, a single seed phrase can generate an entire tree of keys and addresses, all recoverable from that one seed.

There are two types. An extended private key (xprv) contains a private key plus chain code and can derive the full range of child keys. An extended public key (xpub) contains a compressed public key plus chain code and can only derive child public keys. This separation is what allows a merchant to generate fresh receiving addresses on a server without ever exposing private keys.

How It Works

Master Key Generation

The master extended key is the root of the entire HD wallet tree. It is derived from a seed (typically produced from a BIP-39 mnemonic phrase) using HMAC-SHA512:

I = HMAC-SHA512(Key = "Bitcoin seed", Data = seed)

# The 64-byte result splits into two halves:
master_private_key = I[0..31]   # Left 32 bytes
master_chain_code  = I[32..63]  # Right 32 bytes

Together, the master private key and master chain code form the master extended private key. The master extended public key is derived by computing the corresponding secp256k1 public key and pairing it with the same chain code.

Child Key Derivation

BIP-32 defines two derivation modes, each with distinct security properties:

Normal (non-hardened) derivation uses indexes 0 through 2³¹-1. The HMAC input includes the parent public key, so both extended private and extended public keys can derive child public keys. This is what enables xpub-based watch-only wallets.

# Non-hardened child derivation
I = HMAC-SHA512(
  Key  = parent_chain_code,
  Data = compressed_parent_public_key || child_index
)
child_key        = (parse256(I_left) + parent_key) mod n
child_chain_code = I_right

Hardened derivation uses indexes 2³¹ through 2³²-1 (written with a prime symbol, e.g., 0'). The HMAC input uses the parent private key instead of the public key, meaning only the extended private key can perform hardened derivation. An xpub cannot derive hardened children.

# Hardened child derivation (index i')
I = HMAC-SHA512(
  Key  = parent_chain_code,
  Data = 0x00 || parent_private_key || child_index
)
child_key        = (parse256(I_left) + parent_key) mod n
child_chain_code = I_right

Standard derivation paths like BIP-44's m/44'/0'/0'/0/0 use hardened derivation for the purpose, coin type, and account levels, then switch to non-hardened for the change and address index levels. This creates security firewalls between accounts while still allowing xpub-based address generation within each account.

Serialization Format

Extended keys are serialized into a 78-byte structure before being encoded with Base58Check:

The 78-byte payload is then double-SHA-256 hashed to produce a 4-byte checksum, which is appended before Base58 encoding. The result is a 111-character string. The version bytes are chosen so that the Base58 output starts with a recognizable prefix: "xpub" or "xprv" for mainnet, "tpub" or "tprv" for testnet.

Version Byte Variants

Different Bitcoin address types use different version bytes in the serialization, producing distinct prefixes that tell wallet software which script type to use when generating addresses. These are registered in SLIP-0132:

These prefixes do not represent different keys. They are different serialization formats of the same underlying extended key. The prefix tells wallet software which Bitcoin address type to generate when deriving addresses from the key. For Taproot (P2TR) addresses defined in BIP-86, no widely adopted version prefix has been standardized yet.

Use Cases

Watch-Only Wallets

The most common use of extended public keys is creating watch-only wallets. A merchant or accounting system imports an xpub and generates fresh receiving addresses for every transaction without ever handling private keys. The private keys stay on a signing device or in cold storage, completely air-gapped from the internet-connected server.

Multi-Account Wallet Architecture

HD wallets use extended keys to organize funds into isolated accounts. Under BIP-44, each account gets its own hardened extended key at depth 3 (m/44'/0'/account'). This means compromising one account's keys cannot affect other accounts, because hardened derivation prevents upward key recovery.

Multisignature Coordination

In multisig wallets, cosigners share their xpubs to enable collaborative address generation. Each participant contributes their account-level xpub, and the wallet software combines them to produce multisig addresses. No cosigner reveals their private key, but all cosigners can independently verify and generate the same set of addresses. For more on this pattern, see the multisig wallets deep dive.

Payment Platforms and Wallet SDKs

Payment processors and wallet SDKs rely on extended keys to generate unique addresses per customer or invoice. Platforms like Spark use hierarchical key structures to enable self-custodial wallet experiences where the user controls the root key while the application derives payment addresses on the fly.

Risks and Considerations

xprv Exposure: Total Fund Loss

Leaking an extended private key is catastrophic. An attacker with an xprv can derive every child private key in the entire subtree, draining all funds at every derived address. This is equivalent to losing the seed phrase for that branch of the wallet tree. Extended private keys should never be stored on internet-connected devices: use air-gapped signing or a hardware signing device instead.

xpub + Child Private Key Vulnerability

BIP-32 explicitly warns about this: knowledge of a parent extended public key plus any non-hardened child private key is equivalent to knowing the parent extended private key. The math is straightforward. For non-hardened derivation:

child_key = parse256(I_left) + parent_key (mod n)

# If attacker knows xpub (chain code + public key) and child_key:
I_left = HMAC-SHA512(chain_code, public_key || index)  # computable from xpub
parent_key = child_key - parse256(I_left) (mod n)      # full compromise

This is why standard derivation paths use hardened derivation at account boundaries. Hardened derivation uses the parent private key as the HMAC input, so an attacker cannot compute the intermediate value without already having the private key.

Privacy Implications of xpub Sharing

Even without private key exposure, sharing an xpub reveals your complete financial history for that branch of the wallet. Anyone with the xpub can generate all past and future addresses, revealing total holdings, transaction history, business relationships, and payment patterns. Share the narrowest-scope xpub possible: prefer an account-level xpub over a master xpub when a service only needs to track one account. For a broader look at Bitcoin privacy techniques, see the Bitcoin privacy landscape analysis.

Address Gap Limits

When recovering a wallet from a seed, software scans forward through the derivation tree looking for used addresses. If it encounters a configurable number of consecutive unused addresses (the address gap limit, typically 20), it stops scanning. Generating addresses far ahead of the gap limit can result in funds that appear missing during recovery.

Why It Matters

Extended keys are the mechanism that makes modern Bitcoin wallets practical. Before BIP-32, wallets generated random independent keys that required frequent backups. A single missed backup could mean permanent fund loss. Extended keys replaced that fragile model with a deterministic tree: back up once, recover everything.

They also enable the separation of key generation from key signing, which is the foundation of secure key management. A hot wallet can generate addresses using an xpub while the corresponding xprv stays offline in cold storage. This pattern scales from individual users to exchanges handling billions in assets. For self-custodial platforms building on Bitcoin, the extended key hierarchy is the backbone of both security and usability.

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.