Extended keys

An extended key is a key that can have children. It carries the key itself plus 32 extra bytes, the chain code, and with both you can compute a whole family of related keys.

That’s how one 12-word backup covers thousands of addresses. The seed makes one master extended key. The master makes children, the children make grandchildren, and each address sits at a fixed spot in that tree. Pearl writes these keys as zprv (private) and zpub (public).

Try it

Type a phrase and watch the master key, the account key and the first addresses appear.

How is the master key made?

With one HMAC. The seed from the 12 words is hashed with HMAC-SHA512, using a fixed key, and the 64-byte result is cut in half:

Yes, the key is still the text “Bitcoin seed”. Pearl kept BIP-32’s constant unchanged. For the standard test phrase “abandon … about”:

The fingerprint is the first 4 bytes of HASH160 (RIPEMD-160 of SHA-256) of the compressed public key. It’s one of the few places RIPEMD-160 survives in Pearl.

What’s inside an extended key?

78 bytes, always in the same order:

Here is the test phrase’s master zprv, byte by byte:

Add a 4-byte checksum (the first 4 bytes of SHA256d of the 78 bytes) and write it in Base58Check:

Drop the private key, put the public key in its place, switch the version to 04b24746, and you get the matching zpub:

Why does Pearl use “z” prefixes?

Because Pearl’s developers picked existing version bytes. The comment in Pearl’s network settings reads “Using BIP-84 (SegWit) versions for Taproot-only wallet”.

The version bytes only change the label. Re-encode the master key above with Bitcoin’s xprv bytes and you get BIP-86’s official test-vector root, xprv9s21ZrQH143K3GJpoapnV8SFfukcVBSfeCficPSGfubmSFDxo1kuHnLisriDvSnRRuL2Qrg5ggqHKNVpxR86QEC8w35uxmGoggxtQTPvfUu. Same key, same chain code.

How are children derived?

Each child comes from one HMAC-SHA512, keyed with the parent’s chain code. There are two kinds.

1. Normal child (index below 2³¹)

   Data = parent’s compressed public key ‖ index (4 bytes, big-endian). The left half of the HMAC, added to the parent private key mod n, is the child private key; the right half is the child chain code.

2. Hardened child (index 2³¹ and up)

   Data = 00 ‖ parent’s private key ‖ index. Same split. Because the private key goes in, only someone holding it can derive a hardened child.

Normal children have a useful property: the same addition works on public keys. A zpub can derive every normal child’s public key without any private key. That’s what makes watch-only wallets possible.

Hardened children, marked with ’ in paths (86'), block that. They also limit the damage of a leak, as the next section explains. Which levels are hardened is set by the derivation path.

Pearl’s account key

Oyster’s default account sits at m/86’/808276’/0’. For the test phrase, its extended public key is:

That’s exactly the key a real Oyster wallet stores in its database for account 0. From it, anyone can compute every receive address (/0/i) and change address (/1/i) in the account, but no private key.

What can go wrong with extended keys?

• A zprv is the whole wallet. Treat it like the 12 words.
• A zpub is your whole history. It shows every address, past and future, in its branch. Share it only with software you trust.
• A zpub plus one child private key is the whole branch. For normal (non-hardened) children, the parent’s private key is just the child’s private key minus a value anyone with the zpub can compute. BIP-32 calls this out; hardened levels contain the damage to one account.

import { hmac } from '@noble/hashes/hmac.js';
import { sha512 } from '@noble/hashes/sha2.js';

const I = hmac(sha512, new TextEncoder().encode('Bitcoin seed'), seed);   // seed: Uint8Array(64)
const masterKey = I.slice(0, 32);   // 1837c1be… for the test phrase
const chainCode = I.slice(32);      // 7923408d…