Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Wallet Architecture

HD Wallets and Derivation Paths

A modern Bitcoin wallet does not store a list of addresses. It stores one seed and derives every key it will ever need from that seed along a deterministic path. That is what makes a single backup sufficient to restore a whole wallet — and it is also why the same seed can produce different addresses in different software.

One seed, a tree of keys

The idea behind a hierarchical deterministic wallet is that a single piece of secret material can generate an arbitrarily large set of keys, and that the relationship between them is fixed by a rule rather than by a stored list. BIP 32 defines that rule. It takes a seed, derives a master key from it, and then defines a procedure for deriving child keys from a parent key, so that the whole set forms a tree.

The practical consequence is that a wallet only has to preserve the seed. Every address it has ever shown, and every address it will show, can be recomputed from that seed by walking the same tree. A backup is therefore small and does not grow as the wallet is used, which is a considerable improvement over the earlier practice of saving a wallet file that accumulated a new key each time an address was requested.

The tree is not merely a convenience. Because each branch can be derived independently, a wallet can hand out a branch for receiving payments while keeping the branch used for change separate, and it can do so without ever exposing the seed itself. That separation is what makes the next page in this section — the watch-only wallet — possible at all.

What a derivation path selects

A derivation path is a sequence of indices that names one position in the tree. It is written as a slash-separated list, and each element selects a child at that level. The path m/84'/0'/0'/0/0 is a common example: it names the first receiving address of the first account of a wallet that uses native SegWit. Reading it left to right, each segment narrows the selection until a single key remains.

The apostrophe marks a hardened derivation, which is a technical distinction with a practical consequence. A hardened child cannot be derived from the parent's public key alone, only from the parent's private key. That is what allows a wallet to publish an extended public key for a branch without exposing the ability to derive the private keys of its siblings. The convention of hardening the first few levels exists precisely to keep the account structure from being derivable from a single leaked public key.

The numbers in the path are not arbitrary. BIP 44 established the five-level structure — purpose, coin type, account, change, address index — and later proposals reused it with a different purpose number to signal a different address type. BIP 49 uses purpose 49' for P2SH-wrapped SegWit, BIP 84 uses 84' for native SegWit, and BIP 86 uses 86' for Taproot. The purpose number is how a wallet declares which script type its addresses will use.

Why the same seed can show different addresses

A seed does not by itself determine which addresses a wallet will show. It determines the keys, and the path convention determines which keys are used for which purpose. Two wallets given the same seed but following different conventions will derive different addresses from it, and each will report the other's addresses as empty. This is the single most common source of confusion during a restore.

The confusion is compounded because a wallet may support several address types and may scan more than one branch when restoring. A wallet that scans only the native SegWit branch will not find funds that were received at a legacy address derived from the same seed, even though the seed is correct and the funds are recoverable. The recovery procedure has to know which branch to look in, which is exactly the information a bare seed phrase does not carry.

This is why the descriptor, covered on the next page, matters as much as the seed. The seed provides the key material; the descriptor states which scripts those keys are meant to control. A backup that preserves one without the other is incomplete, and the failure only becomes visible at the moment someone tries to restore.

Sources and references

The description of the key hierarchy, the derivation procedure and the path conventions is taken from the Bitcoin Improvement Proposals that define them. No wallet implementation is endorsed and no address is asserted to be correct for any particular software.

Related reading