BIP-32 specifies hierarchical deterministic key derivation: a seed produces a master extended key, and indexed derivation produces descendants in a tree. An extended key includes a chain code alongside key material. This structure lets a wallet generate many addresses without requiring a new independent seed backup for each one. The hierarchy also permits controlled sharing of subtrees, which is useful when separating accounts, receiving addresses, or organizational responsibilities while retaining a coherent recovery scheme.

A service can receive an extended public key for a suitable non-hardened branch and derive receiving addresses without receiving the corresponding private keys. For example, a merchant's website can issue a fresh payment address for each order while signing authority remains elsewhere. This does not make the extended public key harmless: it can expose an entire branch's transaction history. Share only the branch needed for the task, and confirm how that branch relates to the wallet's recovery structure.

Hardened derivation prevents deriving the corresponding child branch from an extended public key alone. BIP-32 also explains an important hazard: combining a parent extended public key with a related non-hardened child private key can compromise the parent's private derivation capability. This is why extended-key handling deserves more care than sharing a single receiving address. BIP-32 does not itself specify a mnemonic word backup or every application's path convention. BIP-39 and BIP-44 address different layers, and restoring a wallet requires those layers to line up correctly.