Derivation paths

A derivation path is a list of child numbers that leads from the master key to one particular key. Pearl’s first receive address lives at:

m/86'/808276'/0'/0/0

Read it left to right like a street address: master, then purpose, coin, account, branch, house number. Every Pearl wallet walks the same path, which is why the same 12 words give the same addresses in Oyster, oystercli and the desktop wallet.

Try it

Type a phrase and choose a path level. The tool shows each node of the tree and the address at the end.

What does each level mean?

The ’ marks a hardened level: its child number has 2³¹ added, and deriving it needs the parent’s private key. The first three levels are hardened, the last two are not. That split lets an account’s zpub derive every address in the account while keeping other accounts and coins separate.

Where does 808276 come from?

From the letters P, R, L. Their ASCII codes are 80, 82 and 76; write the three decimal numbers side by side and you get 808276. Pearl’s code says so in a comment: “Derived from ASCII ‘PRL’: 808276 (0xC5554)”.

Note what it is not: the hex bytes of “PRL” (50 52 4c) read as one number would be 5,263,948. And as of 2026-10-20, 808276 is not registered in SLIP-44, the public list of coin types.

How does a phrase become an address?

Here is the BIP-39 test phrase (“abandon … about”, public, never use it) walked down the path with Pearl’s derivation:

The last key is an ordinary private key. Its x-only public key e0cafb2d…f4ec4e gets the Taproot tweak, giving the output key 1e89c01f…0a4f76, and that becomes the address:

These match what a real Oyster wallet produced for the same phrase in the research for this site.

What is the m/222’ branch?

Pearl’s quantum-safe option. Every Oyster wallet also creates a second key scope, purpose 222, which is 0xDE, the byte of OP_CHECKXMSSSIG. It is used only when someone calls getnewaddress … pq=true:

1. The normal Schnorr key comes from m/86’/808276’/0’/branch/index as usual.
2. A second key comes from m/222’/808276’/0’/branch/index. Its public key is never used. Its private key is stretched with HKDF-SHA256 (info “XMSS-SEED-EXPANSION”) into the seeds of an XMSS key pair.
3. The XMSS public key goes into a script leaf, and the leaf is committed into the Taproot tweak of the normal key.

Both keys come from the same 12 words, and the pq address takes the next index on the same branch counter. The desktop wallet never requests one, and change addresses never use it.

Why does Oyster’s README say m/44’?

It’s out of date. The wallet’s README and some comments describe a m/44'/<coin type>'/… path, from the BIP-44 wallets Oyster’s code was forked from. Pearl’s code registers only the BIP-86 scope and the PQ scope; BIP-44, 49 and 84 are commented out. “BIP-44 coin type” in the comments just names the coin-type level. Trust the code: purpose 86.

Why can another wallet show different addresses?

Because Oyster inherited an old bug from btcd, the Go library Pearl’s node and wallet are built on.

btcd stores a private key as a big number, which drops a leading zero byte: a key starting 00 is kept as 31 bytes. Its old hardened derivation, now called DeriveNonStandard, then copied those 31 bytes into the HMAC input one position off. The child it computes is a valid key, just not the one BIP-32 specifies. Oyster still uses that routine for the three hardened levels.

So when a hardened step’s parent key starts with a zero byte, Oyster’s child differs from everyone else’s, and every key below it does too. A real example:

The master key is kept as 32 bytes, so only two hardened steps (from m/86’ and from m/86’/808276’) can be hit, each with a 1-in-256 chance. About 2 in 256 seeds are affected: the research for this site measured 160 of 20,000 seeds, 0.8%. The test phrase “abandon … about” is not one of them.