Hardened Derivation

Hardened derivation is a BIP32 safety mechanism used when deriving child keys at indices 2³¹ and above. In wallet paths these indices are written with an apostrophe or an "h" (for example m/84'/0'/0'). Hardened derivation exists to close a specific and dangerous leak in non-hardened derivation — one that turns a single leaked child key plus a shared xpub into a total wallet compromise.

The vulnerability it prevents

With normal (non-hardened) derivation, child keys are derived using the parent public key. This is what makes watch-only wallets possible: a server holding only the xpub can generate fresh receive addresses without ever seeing a private key. The trade-off is stark: if an attacker holds a parent extended public key (xpub) and just one non-hardened child private key, they can algebraically recover the parent private key, and from there every sibling and descendant. The math is simple subtraction — the child private key equals the parent private key plus a tweak that anyone with the xpub can compute, so rearranging exposes the parent. BIP32 states this plainly: knowing a parent xpub plus any non-hardened child private key is equivalent to knowing the parent extended private key.

How hardening closes it

Hardened derivation instead mixes the parent private key into the HMAC-SHA512 computation. As a result, you cannot derive hardened children from an xpub alone, and crucially the leak above no longer works: a compromised hardened child reveals nothing about its parent or its siblings. Each hardened branch becomes a cryptographic bulkhead — flooding one compartment does not sink the ship. The cost is that hardened branches cannot be used for watch-only public derivation, since deriving them requires the private key.

How real wallets split the difference

Standard derivation paths harden exactly the levels where a breach would be catastrophic and leave open the levels where public derivation is useful. In the common m/84'/0'/0'/0/0 layout, the purpose, coin type, and account levels are hardened, while the final change and address-index levels are not. That structure means you can safely export the account-level xpub to a watch-only wallet or a node-monitoring dashboard: it can enumerate all your addresses, but even if that machine is compromised and somehow obtains one address's private key, the damage stops at the account boundary. Accounts are also isolated from each other — leaking everything about account 0 tells an attacker nothing about account 1, because crossing that boundary requires a hardened step. A hardware wallet enforces this physically: hardened derivation happens only inside the secure device, because only it holds the parent private keys, while your desktop software works happily from the exported xpub.

Practical takeaways

The notation itself encodes the mechanism. BIP32 gives every parent a 32-bit index space for children: indices 0 through 2³¹-1 derive normally, while indices 2³¹ through 2³²-1 derive hardened. Writing m/84'/0'/0' is shorthand — the apostrophe means "add 2³¹ to this index," so 0' is really index 2,147,483,648. This split gives every node in the tree both options simultaneously: the same parent can have non-hardened children for watch-only convenience and hardened children for compartmentalization, chosen per-index rather than per-wallet. It is a small design decision with outsized consequences, and it explains an otherwise cryptic rule of thumb: apostrophes above the account level, none below it, and never trust a tool that treats the two notations as interchangeable.

When restoring or auditing a wallet, respect the apostrophes: m/84'/0'/0' and m/84/0/0 are entirely different keys, and mistyping the hardening marks is a classic recovery failure. Modern descriptor wallets record the exact path, hardening included, which removes the guesswork. This is why a shared extended public key (xpub) exposes addresses but not spending keys, and it is a core guarantee of the BIP32 HD wallet design that sovereign Bitcoiners — and every seed phrase backup — rely on.