Research . Key derivation

BIP32 non-hardened parent-key escalation

A little-understood property of BIP32 means an xpub plus a single non-hardened child private key can reveal the parent key — a genuine risk, and, for an owner, a recovery lever.

Updated July 2026 · KeychainX — Wallet Recovery since 2017

BIP32 hierarchical deterministic wallets derive a whole tree of keys from one seed. Most people know the tree flows downward — parent to child. Fewer know that under specific conditions it can be climbed upward. This page documents the non-hardened escalation property: what it is, why it matters for security, and how it helps recover a wallet.

How HD derivation works

In a BIP32 wallet, each key derives child keys via a one-way function combining the parent key with a chain code and an index. There are two flavours: hardened derivation (indices above 2³¹), which requires the parent private key, and non-hardened derivation, which can be done from the parent public key. Non-hardened derivation is what makes an xpub useful — a watch-only server can generate fresh receiving addresses without ever holding a private key.

The escalation property

Here is the sharp edge. For non-hardened derivation, the relationship between a child private key and its parent is invertible if you also know the parent’s public key (the xpub). Concretely: given the xpub and any single non-hardened child private key, you can compute the parent private key — and from there the entire subtree. One leaked child key plus a public xpub equals total compromise of that branch.

Why it’s a security risk

This turns two seemingly safe things into a dangerous pair. Sharing an xpub for accounting or watch-only use feels harmless, and exposing a single child private key feels like a contained, one-address loss. Together, they aren’t: an attacker holding the xpub who obtains just one non-hardened child key can climb to the parent and drain every address in that account. It is a classic case where two individually-minor exposures combine into a full compromise, and it’s why hardened derivation exists at account boundaries.

How it helps recovery of your keys

The same property is a gift when you are the owner trying to recover your own funds. If you hold the account xpub and even one non-hardened child private key — perhaps a single exported key, or one address’s key you still have — the parent key and the whole branch can be reconstructed. A partial, fragmentary set of key material that looks useless can, through escalation, rebuild an entire wallet. It converts “I only have one old private key and an xpub” from a dead end into a full recovery.

When it applies

The conditions are specific: the derivation must be non-hardened (hardened children reveal nothing about the parent), you need the correct xpub for the parent, and a genuine child private key from directly beneath it. Many wallets use hardened derivation at the account level precisely to block this, so it doesn’t apply everywhere — but where a wallet used non-hardened derivation, it is a powerful and often overlooked route.

Assessing a case

Establishing whether escalation applies means identifying the wallet’s derivation scheme — which software created it, and whether the branch in question was hardened or not — then confirming the xpub genuinely corresponds to the parent of the child key you hold. Because the mathematics is exact, once those facts line up the reconstruction is deterministic: the parent key either falls out correctly or the inputs don’t match, with no guesswork in between.

Protecting yourself

The defensive lesson is simple: treat your xpub as sensitive, not public, and never expose an individual child private key while the corresponding xpub is known to anyone. If you must share an xpub for watch-only purposes, understand that a single leaked non-hardened child key beneath it compromises the account. Where possible, rely on wallets that harden at account boundaries so that even a leaked xpub and child key can’t be combined into an escalation.

A concrete illustration

Picture a wallet that gave an accountant a watch-only xpub to track incoming payments, and separately exported one address’s private key years ago to sweep a small balance. Individually, neither seemed to matter — an xpub reveals no keys, and one address’s key is one address’s risk. But if that address was a non-hardened child of the shared xpub, the two together reconstruct the parent key and every address beneath it. The same arithmetic that would let an attacker exploit that pairing is what lets the rightful owner, holding both pieces after losing the main wallet, climb back up and recover everything in the branch. It is the clearest demonstration of why the property is simultaneously a hazard and a lifeline.

Our documentation

KeychainX has used non-hardened escalation to rebuild wallets from fragmentary key material in real recoveries, and we document it here because it is as underappreciated as a recovery tool as it is as a risk. It sits alongside our broader key-derivation work, including Trezor derivation forensics. If you hold an xpub and a stray private key, don’t assume they’re useless.

Frequently asked questions