HD Derivation Without a Seed: Child Keys in MPC Wallets

An HD wallet derives children from a seed. An MPC wallet has no seed, because the private key never exists in one place. Yet custody systems still want one address per customer or deposit. The way out is that non-hardened BIP32 derivation is only an addition, and addition works on shares. This note assumes the HD wallet and Shamir posts.

The tweak is public

For a normal child at index $i$, BIP32 computes:

Every input to $I$ is public: the chain code $c$, the parent public key $K$, and the index $i$. So anyone can compute the tweak $\delta = I_L$ and the child public key:

The only secret in the whole derivation is the final addition $k + \delta$. That is the part we need to do on shares.

Shifting the shares

Suppose the key $d$ is split with Shamir, so party $j$ holds $s_j = f(j)$ for a polynomial with $f(0) = d$. Define a new polynomial:

Its constant term is $d + \delta$, which is exactly the child key. Party $j$'s new share is $f'(j) = s_j + \delta$, so each party just adds the public $\delta$ to its own share. No communication is needed and nobody learns the child key.

If the shares are additive instead, $d = \sum_j x_j$, then one designated party adds $\delta$ and the rest leave their shares alone.

Signing then proceeds exactly as before, with shares of $d + \delta$ and public key $K + \delta G$. The signing protocol doesn't know or care that the key is derived.

The chain code

The derivation needs a chain code $c$, and in MPC no seed produces one. It is generated during key generation: each party contributes a random value, commits to it first, then reveals it, and the chain code is a hash of all contributions. Every party stores it, and it is not secret from the signers, so it must not be revealed to anyone who shouldn't be able to derive child public keys.

What you give up

• Hardened derivation. It puts the parent private key into the HMAC input. Doing that under MPC means computing an HMAC-SHA512 over secret-shared data, which is possible but far more expensive than an addition, so most systems derive non-hardened children only.
• BIP32's usual safety margin. In a normal HD wallet, leaking one child key plus the chain code exposes the parent. Under MPC, no single party holds a child key, but the chain code and public key are still enough to compute every child public key, so treat the chain code as sensitive.
• Ed25519. The additive trick works for any scalar-based scheme, but SLIP-0010 allows hardened children only for Ed25519. Threshold Ed25519 systems need a tweak scheme designed for it, with care around how the nonce prefix is derived.

Why bother

One MPC key can back a tree of addresses. A deposit service derives $K_i$ from the public data alone and hands out the address without touching any signing party. When funds need to move, the signers shift their shares by $\delta_i$ and sign. The public side scales to millions of addresses, and the private side never reassembles a key.