BIP 0032

How can one seed grow an entire wallet?

One backup, billions of keys. The trick is a 32-byte companion to every key, and a rule about which branches an extended public key may follow.

When BIP 32 was written, the reference wallet generated each key at random. To avoid needing a new backup after every transaction, it kept a pool of a hundred spare keys. Every key was independent, so every key had to be saved.¹

BIP 32, assigned in 2012 and recorded as deployed, takes another route: derive every key from one seed, arranged as a tree. Branches of that tree can be shared with other systems, entirely or in part, with or without the ability to spend.^2,3,4

Source revision: bitcoin/bips @ 3a10b5b
Source checked: 1 October 2026
Review state: Draft — independent technical review applied; awaiting human sign-off

Source details

This chapter is an independent explanation, not the proposals themselves. Preamble fields are shown as recorded in the pinned files, with author e-mail addresses omitted. Status is the proposal’s own field, not an endorsement or a sign of consensus.

BIP 32: Hierarchical Deterministic Wallets

BIP: 32
Layer: Applications
Title: Hierarchical Deterministic Wallets
Authors: Pieter Wuille
Status: Deployed
Type: Informational
Assigned: 2012-02-11
License: BSD-2-Clause

Pinned source · Reader view on bips.dev
SHA-256 e5e00a8289db2f681052cf24a745320afc225e66b25d1e489a7c884d2fc7f11f
Git blob 558bbaab60d63e3e50648816d5e3449cfb887f85

FIG. A02.1 The first split

Seed · 16 bytes00010203 04050607 08090a0b 0c0d0e0f

HMAC-SHA512key = the text "Bitcoin seed", data = the seed

I_L · first 32 bytese8f32e72 3decf405 1aefac8e 2c93c9c5 b2143138 17cdb01a 1494b917 c8436b35→ master private key

I_R · last 32 bytes873dff81 c02f5256 23fd1fe5 167eac3a 55a049de 3d314bb4 2ee227ff ed37d508→ master chain code

Together they are the master extended key xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi, exactly as listed in BIP 32’s test vector 1 (lines 221–223).

HMAC-SHA512 turns a seed into 64 bytes. The left half becomes the master private key; the right half becomes the master chain code.^5,6

Keys with an extra 32 bytes

Every node in the tree is an extended key: an ordinary key plus a chain code, 32 more bytes of entropy. BIP 32 adds the chain code so that a node’s children do not depend on the key alone. The chain code is the same in the private and the public version of a node.⁷

Without it, a child would depend only on its parent’s key. With it, knowing a public key is not enough to find that key’s children: you need the extended public key, key and chain code together.^7,8

An extended private key is the pair (k, c): private key and chain code. Its public counterpart is (K, c), where K is the public key for k. Turning the first into the second is called neutering it, because the result can no longer sign transactions.^9,10

One step down the tree

To make child number i, run HMAC-SHA512 keyed with the parent’s chain code. The 64-byte output splits as the master did. The left half is added to the parent’s private key, modulo the order of the curve, to give the child’s private key. The right half becomes the child’s chain code.^11,12

What goes into the HMAC depends on the index. Indices 0 to 2³¹ − 1 are normal, and the input is the parent’s public key followed by the index. Indices from 2³¹ upward are hardened, and the input is the parent’s private key, padded with a zero byte, followed by the index. Paths mark hardened indices with an H: m/0H/1 is normal child 1 of hardened child 0 of the master.^12,13,14,15

In rare cases a step produces an invalid key, and the wallet moves on to the next index. BIP 32 puts the odds below one in 2¹²⁷. That one difference in the HMAC input, public key or private key, is what the figure below is about.^14,16

FIG. A02.2 Who can derive what Interactive

Static view: the whole tree as seen by someone holding the master extended private key. With JavaScript you can switch to the public view, flip a branch to hardened, and inspect any node.

mxprv9s21Zr…xrMPHiBIP 32 L221–223
- hardenedm/0Hxprv9uHRZZ…2bhkJ7BIP 32 L224–226
  - normalm/0H/0xprv9wTYmM…eypdKj
  - normalm/0H/1xprv9wTYmM…1xe8fsBIP 32 L227–229
    - hardenedm/0H/1/2Hxprv9z4pot…ZX7UiMBIP 32 L230–232
- normalm/1xprv9uHRZZ…MrPJih
  - normalm/1/0xprv9xANix…FXxJhZ

m/0H/1 · depth 2 · matches BIP 32 lines 227–229

Child number: 00000001 (normal)
Parent fingerprint: 5c1bd648
Chain code: 2a7857631386…adb37c19
Public key: 03501e454bf0…b3cd711c
Private key: 3c6cb8d0f6a2…9dc93368

Derived with HMAC-SHA512 keyed by m/0H’s chain code, over m/0H’s public key ‖ 00000001.

xprvxprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs

Seed: BIP 32 test vector 1 (line 220). Every key here is public test material; never use it for funds.

A hardened edge is a wall for public keys. Holding M, you can follow normal edges down to M/1/0, but you cannot cross into m/0H: deriving it needs a private key you do not have.^6,8,17,18

What an extended public key can do

Because a normal child’s HMAC input is the parent’s public key, someone holding only the extended public key can compute the child’s public key and chain code too: add the public point of the left half to the parent’s public key. BIP 32 notes that both routes give the same child, and that this is exactly what makes normal keys useful.^17,19

Its own example is a webshop. The shop’s server can hold one extended public key and generate a fresh address for every order, without ever holding a key that could spend the payments. If the server is broken into, BIP 32 says the attacker can at most see the incoming payments.^20,21

BIP 32 lists other kinds of partial sharing too. An auditor can be given every account’s extended public key and see all transactions without a single secret key. A business partner can be given one account’s external chain and use it as a kind of super address, without asking for a new address for each payment.^22,23

Hardened children are different. Their HMAC input contains the parent’s private key, so public derivation is simply not defined for them, and there is no way at all from a public parent to a private child. An extended public key reaches the public keys of descendants that are linked to it by normal steps only, and nothing else.^8,17,18,24

Why hardened keys exist

If normal derivation is so useful, why not use it everywhere? BIP 32 points to a weakness that is easy to miss. An extended public key, together with the private key of any descendant reached from it by normal steps only, is equivalent to the parent’s extended private key, and therefore to every key beneath it.²⁵

The tests behind this page check this on the published vector. From the extended public key of m/0H and the private key of its child m/0H/1, they recompute the private key of m/0H exactly: subtract the left half of the HMAC, which anyone holding the extended public key can compute.^25,26

This is why BIP 32 uses hardened derivation at the account level. A leak of one account’s private keys then cannot climb past the hardened edge to the master or to other accounts. It is also why BIP 32 says extended public keys must be treated more carefully than ordinary public keys. The risk to funds arises only when an extended public key meets a leaked private key reached from it by normal steps; on its own it reconstructs public keys and nothing more.^8,25,27

Writing a key down

An extended key travels as 78 bytes: a version, the depth in the tree, the parent’s fingerprint, the child number, the chain code and the key. Base58Check adds four checksum bytes and produces exactly 111 characters, beginning xpub or xprv on mainnet.²⁹

FIG. A02.3 One node, two serializations

Node m/0H, serialized both ways. Of the 78 payload bytes, only the version and the key data differ; the checksum then differs as a consequence.
Field	Bytes	xpub	xprv
Versionsays xpub or xprv, mainnet or testnet	4	`0488b21e`	`0488ade4`
Depth0 for the master	1	`01`	same
Parent fingerprintfirst 4 bytes of the parent key’s Hash160	4	`3442193e`	same
Child number≥ 0x80000000 means hardened	4	`80000000`	same
Chain codethe extra 256 bits	32	`47fdacbd0f10…236141`	same
Key data02/03 + x for public, 00 + k for private	33	`035a784662a4…fccc56`	`00edb2e14f9e…a0afea`
Checksumdouble SHA-256, for Base58Check	4	`b8b9c580`	`0a794dec`

xpub · 111 Base58 characters: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw
xprv · 111 Base58 characters: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7

Only the version and the key data differ. Depth, parent fingerprint, child number and chain code are identical: they describe the node’s place in the tree, and the chain code is shared by both forms. The checksum differs only as a consequence.^7,29

The fingerprint is the first four bytes of the Hash160 of a key’s public key. It only helps software spot parents and children quickly. Different keys can share a fingerprint, and BIP 32 says software must be willing to deal with such collisions.^30,31

Importing an extended public key also requires a check that its X coordinate corresponds to a point on the curve. BIP 32’s fifth test vector is a list of malformed keys of this and other kinds, and the decoder behind this page rejects all sixteen of them, each for its stated reason.^6,32

A tree, not a wallet layout

BIP 32 also suggests a default structure. Accounts are hardened children of the master, and each has an external chain for receiving addresses and an internal chain for change, written m/iH/0/k and m/iH/1/k. The proposal calls this layout a default that clients are encouraged to follow, and allows implementations to deviate for their own needs.³³

BIP 32 defines only this default, and explicitly lets implementations deviate from it. Path conventions defined in other proposals are layers built on the mechanism described here; they are not part of BIP 32 itself, and an unfamiliar path is not by itself a sign of a broken wallet.³³

Back to the seed

BIP 32 asks for a seed of 128 to 512 bits from a random number generator, and advises 256. The 64-byte seed that BIP 39 produces, described in the previous chapter, fits. The BIP 39 test vector file referenced by BIP 39 also lists the master extended key for each of its 24 English seeds, and the tests behind this page reproduce all of them.^5,34

From that one value, every node can have 2³¹ normal and 2³¹ hardened children, and every one of them can be recomputed from the seed alone. That is the whole promise of the title: a single backup covers the entire tree.^5,8,13

Evidence

Each numbered marker in the text points here. Quotes are verbatim from the BIP files at commit 3a10b5b, including their wiki markup; links open the exact lines; the quoted text sits under each entry. Labels say what kind of statement each is: a rule, the author’s rationale, history, a test vector, or our own inference.

History When BIP32 was written, the reference client used randomly generated keys and cached 100 reserve keys to avoid a backup after every transaction.

BIP 32 L34

Quoted source text (1)

The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys.

BIP 32, line 34
History BIP32 was assigned in 2012; its preamble records the type Informational and the status Deployed.

BIP 32 L16 BIP 32 L14 BIP 32 L15

Quoted source text (3)

Assigned: 2012-02-11

BIP 32, line 16

Status: Deployed

BIP 32, line 14

Type: Informational

BIP 32, line 15
Rule BIP32 first specifies deriving a tree of keypairs from a single seed, then a wallet structure on top of the tree.

BIP 32 L26

Quoted source text (1)

In the first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree.

BIP 32, line 26
Author’s rationale HD wallets can be shared partially or entirely with different systems, each with or without the ability to spend.

BIP 32 L22

Quoted source text (1)

wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.

BIP 32, line 22
Rule The seed is 128 to 512 bits from a (P)RNG, 256 advised; I = HMAC-SHA512("Bitcoin seed", S); I_L is the master secret key and I_R the master chain code.

BIP 32 L148 BIP 32 L149 BIP 32 L151

Quoted source text (3)

Generate a seed byte sequence S of a chosen length (between 128 and 512 bits; 256 bits is advised) from a (P)RNG.

BIP 32, line 148

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

BIP 32, line 149

Use parse256(IL) as master secret key, and IR as master chain code.

BIP 32, line 151
Test vector BIP32 embeds test vectors, including vectors for leading zeros and a list of invalid extended keys; the tested implementation reproduces all 17 valid chains and rejects all 16 invalid keys.

BIP 32 L220 BIP 32 L264 BIP 32 L291

Quoted source text (3)

Seed (hex): 000102030405060708090a0b0c0d0e0f

BIP 32, line 220

These vectors test for the retention of leading zeros.

BIP 32, line 264

These vectors test that invalid extended keys are recognized as invalid.

BIP 32, line 291
Rule Both private and public keys are extended with a 32-byte chain code, identical for corresponding private and public keys, so children do not depend solely on the key.

BIP 32 L62

Quoted source text (1)

In order to prevent these from depending solely on the key itself, we extend both private and public keys first with an extra 256 bits of entropy. This extension, called the chain code, is identical for corresponding private and public keys, and consists of 32 bytes.

BIP 32, line 62
Rule An extended private key reconstructs all descendant keys; an extended public key reconstructs all descendant non-hardened public keys.

BIP 32 L120 BIP 32 L116–117

Quoted source text (2)

knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public key allows reconstruction of all descendant non-hardened public keys.

BIP 32, line 120

N(m/a/b/c) = N(m/a/b)/c = N(m/a)/b/c = N(m)/a/b/c = M/a/b/c.

BIP 32, lines 116–117
Rule An extended private key is (k, c); an extended public key is (K, c) with K = point(k).

BIP 32 L64

Quoted source text (1)

We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = point(k) and c the chain code.

BIP 32, line 64
Rule N() gives the extended public key of an extended private key; it removes the ability to sign transactions.

BIP 32 L98

Quoted source text (1)

the "neutered" version, as it removes the ability to sign transactions

BIP 32, line 98
Rule I splits into I_L and I_R; the child private key is I_L + k_par (mod n) and the child chain code is I_R.

BIP 32 L78 BIP 32 L79 BIP 32 L80

Quoted source text (3)

Split I into two 32-byte sequences, IL and IR.

BIP 32, line 78

The returned child key ki is parse256(IL) + kpar (mod n).

BIP 32, line 79

The returned chain code ci is IR.

BIP 32, line 80
Rule For a normal child, the HMAC data is the parent public key || the index.

BIP 32 L77

Quoted source text (1)

If not (normal child): let I = HMAC-SHA512(Key = cpar, Data = serP(point(kpar)) || ser32(i)).

BIP 32, line 77
Rule Each extended key has 2^31 normal children (indices 0 to 2^31−1) and 2^31 hardened children (2^31 to 2^32−1).

BIP 32 L66 BIP 32 L66

Quoted source text (2)

Each extended key has 231 normal child keys, and 231 hardened child keys.

BIP 32, line 66

The hardened child keys use indices 231 through 232-1.

BIP 32, line 66
Rule For a hardened child, the HMAC data is 0x00 || the parent private key || the index.

BIP 32 L76

Quoted source text (1)

If so (hardened child): let I = HMAC-SHA512(Key = cpar, Data = 0x00 || ser256(kpar) || ser32(i)).

BIP 32, line 76
Rule Paths are written m/3H/2/5 for successive CKDpriv steps, with H marking a hardened index.

BIP 32 L115

Quoted source text (1)

we will write CKDpriv(CKDpriv(CKDpriv(m,3H),2),5) as m/3H/2/5.

BIP 32, line 115
Rule A derived key can be invalid, in which case the next index is used; this has probability lower than 1 in 2^127.

BIP 32 L81

Quoted source text (1)

In case parse256(IL) ≥ n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2127.)

BIP 32, line 81
Rule CKDpub is only defined for non-hardened children; the child public key is point(I_L) + K_par.

BIP 32 L87 BIP 32 L89 BIP 32 L92

Quoted source text (3)

It is only defined for non-hardened child keys.

BIP 32, line 87

If so (hardened child): return failure

BIP 32, line 89

The returned child key Ki is point(parse256(IL)) + Kpar.

BIP 32, line 92
Rule Deriving a private child from a public parent is not possible.

BIP 32 L107–109

Quoted source text (1)

====Public parent key → private child key==== This is not possible.

BIP 32, lines 107–109
Rule Computing a normal child's public key from the private or the public parent gives the same result; this is what makes non-hardened keys useful.

BIP 32 L105

Quoted source text (1)

The fact that they are equivalent is what makes non-hardened keys useful (one can derive child public keys of a given parent key without knowing any private key)

BIP 32, line 105
Author’s rationale Elliptic-curve maths lets a webshop server generate fresh addresses without access to the private keys needed to spend.

BIP 32 L36

Quoted source text (1)

This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds).

BIP 32, line 36
Author’s rationale An attacker who obtains a webserver holding one account's external-chain xpub can at most see incoming payments, not steal them.

BIP 32 L189

Quoted source text (1)

This means someone illegally obtaining access to the webserver can at most see all incoming payments but will not be able to steal the money

BIP 32, line 189
Author’s rationale Sharing account extended public keys lets an auditor see all transactions but not a single secret key.

BIP 32 L176

Quoted source text (1)

This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.

BIP 32, line 176
Author’s rationale A business partner can receive the extended public key of one account's external chain and use it as a kind of super address.

BIP 32 L184

Quoted source text (1)

one can use the extended public key for the external chain of a specific account (M/i h/0) as a sort of "super address", allowing frequent transactions that cannot (easily) be associated, but without needing to request a new address for each payment.

BIP 32, line 184
Rule N(m/aH) cannot be rewritten as N(m)/aH, because the latter is not possible.

BIP 32 L118

Quoted source text (1)

However, N(m/aH) cannot be rewritten as N(m)/aH, as the latter is not possible.

BIP 32, line 118
Rule A parent extended public key plus the private key of any descendant reached from it by non-hardened steps is equivalent to the parent extended private key; extended public keys must be treated more carefully than regular public keys.

BIP 32 L212

Quoted source text (1)

knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys.

BIP 32, line 212
Test vector From test vector 1's xpub for m/0H and the private key of m/0H/1, the tested implementation recomputes m/0H's private key exactly.

BIP 32 L212 BIP 32 L225 BIP 32 L229

Quoted source text (3)

knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key

BIP 32, line 212

ext pub: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw

BIP 32, line 225

ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs

BIP 32, line 229
Author’s rationale This weakness is why hardened keys exist and are used at the account level, so a leak of account-level or lower private keys never compromises the master or other accounts.

BIP 32 L213

Quoted source text (1)

It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private keys never risks compromising the master or other accounts.

BIP 32, line 213
Rule Leaking a private key means access to coins; leaking a public key can mean loss of privacy.

BIP 32 L208

Quoted source text (1)

Leaking a private key means access to coins - leaking a public key can mean loss of privacy.

BIP 32, line 208
Rule An extended key serializes to 78 bytes (version, depth, parent fingerprint, child number, chain code, key data); Base58Check adds 32 checksum bits for exactly 111 characters starting xpub or xprv on mainnet.

BIP 32 L131 BIP 32 L136 BIP 32 L138

Quoted source text (3)

4 bytes: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)

BIP 32, line 131

33 bytes: the public key or private key data (serP(K) for public keys, 0x00 || ser256(k) for private keys)

BIP 32, line 136

This 78 byte structure can be encoded like other Bitcoin data in Base58, by first adding 32 checksum bits (derived from the double SHA-256 checksum), and then converting to the Base58 representation. This results in a Base58-encoded string of exactly 111 characters.

BIP 32, line 138
Rule A key is identified by the Hash160 of its public key; the first 32 bits are its fingerprint.

BIP 32 L124 BIP 32 L126

Quoted source text (2)

Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized ECDSA public key K, ignoring the chain code.

BIP 32, line 124

The first 32 bits of the identifier are called the key fingerprint.

BIP 32, line 126
Rule The parent fingerprint is only a fast way to detect parents and children; software must be willing to deal with collisions.

BIP 32 L140

Quoted source text (1)

Note that the fingerprint of the parent only serves as a fast way to detect parent and child nodes in software, and software must be willing to deal with collisions.

BIP 32, line 140
Rule When importing an extended public key, implementations must verify that its X coordinate is on the curve.

BIP 32 L142

Quoted source text (1)

When importing a serialized extended public key, implementations must verify whether the X coordinate in the public key data corresponds to a point on the curve. If not, the extended public key is invalid.

BIP 32, line 142
Author’s rationale BIP32's default layout uses hardened account nodes with an external chain (m/iH/0/k) and an internal chain (m/iH/1/k); it is a default and advisory, and implementations may deviate.

BIP 32 L158 BIP 32 L165 BIP 32 L166 BIP 32 L193

Quoted source text (4)

The layout defined in this section is a default only, though clients are encouraged to mimic it for compatibility, even if not all features are supported.

BIP 32, line 158

m/iH/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.

BIP 32, line 165

m/iH/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.

BIP 32, line 166

However, implementations may deviate from it for specific needs; more complex applications may call for a more complex tree structure.

BIP 32, line 193
Test vector BIP39 seeds feed BIP32. The trezor vector file referenced by BIP39 also lists each seed's master extended key; the tested implementation reproduces all 24 English entries.

BIP 39 L99–100 BIP 39 L133

Quoted source text (2)

This seed can be later used to generate deterministic wallets using BIP-0032 or similar methods.

BIP 39, lines 99–100

https://github.com/trezor/python-mnemonic/blob/master/vectors.json

BIP 39, line 133