Hardened Derivation

What Is Hardened Derivation?

Hardened derivation is a key derivation method defined in BIP-32 that creates child keys in a way that severs the mathematical link between the parent public key and child keys. In a hierarchical deterministic (HD) wallet, keys are generated in a tree structure from a single seed phrase. Each level in the tree can use either normal (non-hardened) or hardened derivation to produce child keys.

The distinction matters because of how HD wallets are used in practice. Normal derivation allows anyone with the parent extended public key to derive all child public keys below it: useful for generating receiving addresses without exposing private keys. Hardened derivation sacrifices this convenience for stronger security, ensuring that exposure of a child private key cannot cascade upward to compromise the parent.

Hardened derivation is denoted with an apostrophe (') or the letter h after the index number. For example, m/44'/0'/0' means all three levels use hardened derivation.

How It Works

Both normal and hardened derivation use HMAC-SHA512 to produce child keys, but they differ in what data gets fed into that function. The parent chain code serves as the HMAC key in both cases. The critical difference is in the data input.

Normal (Non-Hardened) Derivation

For normal child keys (indices 0 through 2³¹ - 1), the HMAC input data is the serialized parent public key concatenated with the child index:

I = HMAC-SHA512(
  Key  = parent_chain_code,
  Data = serialize(parent_public_key) || serialize(index)
)

Because the input uses the public key, anyone with the parent extended public key (which contains both the public key and chain code) can compute the same HMAC output and derive child public keys. This enables watch-only wallets and payment processors to generate fresh addresses without access to private keys.

Hardened Derivation

For hardened child keys (indices 2³¹ through 2³² - 1), the HMAC input data uses the parent private key instead:

I = HMAC-SHA512(
  Key  = parent_chain_code,
  Data = 0x00 || serialize(parent_private_key) || serialize(index)
)

Since the parent private key is required as input, only someone who possesses the private key can derive children at this level. An xpub holder cannot compute hardened child keys at all: not the public keys, not the private keys, nothing.

Key Derivation Math

In both cases, the 64-byte HMAC output is split into two 32-byte halves. The left half (IL) is used to compute the child key, and the right half (IR) becomes the child chain code:

child_private_key = parse256(IL) + parent_private_key (mod n)
child_chain_code  = IR

This additive relationship is what makes normal derivation vulnerable. If an attacker knows IL (computable from the xpub) and the child private key, they can subtract to recover the parent private key:

parent_private_key = child_private_key - parse256(IL) (mod n)

With hardened derivation, the attacker cannot compute ILwithout already having the parent private key, breaking this attack chain.

The Security Vulnerability

The BIP-32 specification explicitly warns: knowledge of a parent extended public key plus any non-hardened child private key descending from it is equivalent to knowing the parent extended private key, and therefore every private key in that subtree.

This vulnerability arises because xpubs are designed to be shared. A merchant might export an account-level xpub to a payment processor so it can generate fresh receiving addresses. A user might load an xpub into a watch-only wallet on a less-secure device. If a single child private key from that non-hardened branch is ever exposed (through a compromised server, a leaked backup, or a software bug), the attacker can reconstruct the parent private key and drain every address in the branch.

Hardened derivation prevents this cascade entirely. Even if a hardened child's private key leaks alongside the parent xpub, the attacker cannot reverse the derivation because they lack the input data (the parent private key) needed to compute IL.

Notation and Index Ranges

BIP-32 divides the 32-bit child index space into two halves:

The apostrophe notation is shorthand: 0' means index 0 + 2^31 (which is 0x80000000 or 2,147,483,648). The BIP-32 specification itself uses an H subscript, but the apostrophe convention became standard through BIP-44 and common wallet implementations.

Which Levels Should Be Hardened

The BIP-44 standard defines a five-level derivation path where the first three levels are hardened and the last two are not:

m / purpose' / coin_type' / account' / change / address_index
     hardened    hardened     hardened    normal    normal

This design places the hardened boundary at the account level. An account-level xpub exported from a signing device can generate all receiving and change addresses below it, while maintaining security isolation between accounts. Other BIP standards follow the same pattern: BIP-84 (native SegWit) uses m/84'/0'/0' and BIP-86 (Taproot) uses m/86'/0'/0'.

Use Cases

Account Isolation in Wallets

Hardened derivation at the account level means each account in an HD wallet is cryptographically independent. A user can export the xpub for account 0 to a payment processor and the xpub for account 1 to an accounting system without either party being able to derive keys for the other account. Even if one account's child private key leaks, the other accounts remain safe because the hardened boundary prevents upward key recovery.

Hardware Wallet Security

Cold storage devices like hardware wallets enforce hardened derivation paths to prevent key compromise cascades. When a hardware wallet exports an account-level xpub, the hardened levels above it ensure that the xpub cannot be used to reconstruct the master key or keys for other accounts, even if a child private key is later exposed on a connected computer. In early 2026, Ledger strengthened this by enforcing strict hardened derivation prefix rules: each application on the device is confined to its own isolated subtree, and at least one component of each path prefix must be hardened.

Multi-Currency Wallet Separation

The hardened coin type level (0' for Bitcoin, 60' for Ethereum, etc.) creates cryptographically separate key trees for each cryptocurrency. This prevents a vulnerability in one chain's key handling from compromising keys on another chain, even though all keys derive from the same seed phrase.

Why It Matters

Hardened derivation is a foundational security mechanism for any wallet that manages Bitcoin keys. Understanding the distinction between hardened and normal derivation is essential for wallet developers building on Bitcoin infrastructure, including self-custodial solutions and Layer 2 protocols like Spark. Choosing the wrong derivation type at the wrong level can expose an entire key hierarchy to compromise from a single leaked child key.

For developers integrating Bitcoin wallet functionality, frameworks and SDKs handle much of this complexity, but understanding the underlying derivation model is critical for making correct key management decisions. For a deeper comparison of wallet development approaches, see the Bitcoin wallet SDK comparison.

Risks and Considerations

No Public Key Derivation at Hardened Levels

The primary tradeoff of hardened derivation is the loss of public-key-only derivation. A watch-only wallet holding an xpub cannot generate child public keys beyond a hardened boundary. This means payment processors, gap limit scanners, and any system that generates addresses from an xpub must operate below the hardened levels in the derivation path.

Non-Hardened Levels Remain Vulnerable

Hardened derivation only protects the levels where it is applied. Below the account level, BIP-44 paths use normal derivation. If an attacker obtains the account-level xpub and any child private key below it, they can still compute all other private keys at that non-hardened level. The security model assumes the account xpub is treated carefully: it should not be publicly shared, as it reveals all addresses and balances for that account.

Backup and Recovery Implications

Because hardened derivation creates independent subtrees, recovering a wallet from a seed phrase requires knowing which derivation paths were used. Most wallets follow standard paths (BIP-44, BIP-49, BIP-84, BIP-86), but non-standard hardened paths can make funds difficult to recover if the path is not documented. Always record which derivation paths your wallet uses alongside your seed phrase backup.

Performance Considerations

Hardened derivation requires the private key for every derivation step. In systems where the private key is stored on a secure element or HSM, each hardened derivation step requires a round trip to the secure hardware. For high-throughput address generation, the non-hardened levels below the account boundary avoid this bottleneck by allowing derivation from the xpub alone.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.