Key derivation (BIP32)

BIP32 defines two derivation modes. Non-hardened derivation (path index < 2³¹) computes a child key from the parent public key and a chain code. Any party that holds a private key share can locally derive the corresponding child share from that share alone — no interaction with other nodes required. Hardened derivation (index ≥ 2³¹, written with ') requires the full private key, which threshold MPC never reconstructs. The system supports only non-hardened path segments.

In practice, a full BIP44 path like m/44'/60'/0'/0/5 cannot be executed as written because the first three segments are hardened. The convention for MPC wallets is to treat the account-level key as the DKG root: the hardened prefix (m/44'/60'/0') is the key that DKG creates, and the chainPath in signing requests specifies only the non-hardened suffix — e.g. 0/5 for the fifth external address.

When a signing operation specifies a chainPath, derivation reduces to a public scalar offset. Non-hardened BIP32 defines the child private key as the parent private key plus a tweak t = HMAC-SHA512(chain_code, parent_pubkey ‖ index) reduced modulo the curve order. Every input to t is public — the parent public key, the chain code, and the index — so each node computes the same t with no exchange. Each participating node folds its portion of t into its signing share, so the reconstructed signing key is the child key (root key + t). No secret value crosses the network: derivation needs no inter-node communication, no additional ceremony, and no change to the stored root key state. The threshold signing protocol then runs against the derived shares the same way it runs against root shares.

Derivation is a local scalar computation with no inter-node round trip, so it adds no network latency to signing. One DKG ceremony serves the full derived address tree. One key refresh, resharing, or rotation applies to the root and transitively covers every derived address.

The chainPath field uses standard BIP32 relative path notation for the non-hardened suffix. A value of 0/5 means change index 0, address index 5 — corresponding to the fifth external address in the BIP44 convention. Paths starting with m/ are interpreted from the root keyId.

Common conventions by chain type: Ethereum and EVM-compatible chains use 0/N for the Nth address (account model, typically one address per account). Bitcoin segwit uses 0/N for external receive addresses and 1/N for change addresses. Solana and ed25519-based chains follow their own derivation standards; consult the backend family's L0 documentation for curve-specific constraints. The system supports secp256k1 derivation for all ECDSA and Schnorr backends.

Because all child keys are derived from the root, key rotation — which produces a new root public key — changes every derived address simultaneously. The new root's child addresses differ entirely from the old root's. Rotation is therefore the most operationally significant key lifecycle event for on-chain deployments: it is both a key-management event and a full address migration for the entire on-chain footprint.

Key refresh and resharing preserve the root public key, so all derived addresses remain stable. Only rotation changes them. Operators planning a rotation must account for: migrating on-chain balances from old to new addresses, updating external directories and settlement rails, notifying downstream systems, and maintaining the old root in Retiring state until all pending transactions referencing old addresses have settled. The retirement window in the DomainManifest gives this migration time to complete.

BIP32 derivation is a deterministic function of the root share and the path. Because the DVM score specifies chainPath as part of the signing instruction, the derivation step is part of the L1 operation — it appears in the DVM trace, it is covered by the same step permit and ingress validation as any other step, and it produces the same evidence format. A derived-key signing operation is a signing operation with a non-empty path.

The K formal specifications cover derivation by including the path in the operational envelope. A scenario test specifies a chainPath and asserts on the derived address with the standard .dvms authoring model.