Skip to main content

Key management

Custody manages keys at the granularity of a wallet. Each wallet has its own master key, generated by a DKG ceremony, and every address inside the wallet is derived from that master key via BIP-32 unhardened derivation.

The mechanics of how shares are stored, refreshed, and recovered are covered in dedicated pages; this page focuses on the key-creation and derivation model.

One master key per wallet​

A new wallet is provisioned by running a fresh DKG with the chosen set of nodes. The output is:

  • One public key, recorded against the wallet.
  • Five shares (3-of-5 threshold), one per participating node.
  • An associated chain code for BIP-32 derivation.

Two wallets — even within the same tenant — never share a master key. Each has its own DKG, its own share set, and its own backup record. A cryptographic failure or operational compromise affecting one wallet does not propagate to the others.

The alternatives we evaluated and ruled out:

  • Per-tenant master key with derivation per wallet. Lower backup surface, easier finance ops, but a single failure compromises every wallet under that tenant. The blast radius was unacceptable.
  • Per-platform master key. Same problem, larger blast radius.
  • No HD wallet, fresh key per address. Backup grows unbounded; finance ops become impractical.

The wallet-scoped model is the standard institutional shape and is what external tooling expects.

Address derivation​

For each wallet, addresses are derived using the unhardened BIP-32 path. Two important consequences:

  • Operational nodes never reconstruct the master key to derive a child address. Unhardened BIP-32 derivation is computable from the public key and chain code alone. Nodes derive the next address locally, and signing for that address still requires the threshold protocol against the master shares.
  • For Ethereum-family chains, one wallet = one address space. Ethereum has an account-based model, so a single derived key serves indefinitely; child paths are used for accounting separation rather than UTXO hygiene.
  • For Bitcoin, child paths follow standard wallet derivation. Each receive address corresponds to a child at the next index.

Operations​

The platform exposes a narrow management API:

  • Create wallet — runs DKG, registers the resulting public key + chain code, persists encrypted shares.
  • Refresh wallet — re-randomises shares without changing the public key. See Key lifecycle for triggers and cadence.
  • Reshare — replaces participants without changing the public key (e.g. swapping out one custodian for another).
  • Decommission — marks a wallet as no longer signable; existing shares are deleted from the operational store but retained in the dead-drop backup, in case the wallet's funds need to be swept later.

Decommissioning is intentionally not "destroy". A signing capability that is permanently destroyed is identical to a signing capability that has lost its threshold — the funds are unreachable. Custody never produces that outcome from an admin action; recovery flows have to remain possible.

Out of scope here​