Api-Child-Control-Key header of POST /v2/transfers.
Derivation inputs
The derivation is deterministic: the same MCK and derivation path always produce the same child control key, so you can derive on demand and avoid storing child keys.
How derivation works
The scheme is standard BIP39 and BIP32, so mature libraries cover all of the cryptography:- Decode the MCK. If you hold the 24-word mnemonic, decode it to the 32-byte entropy (
mckFromMnemonicbelow). If you hold the MCK as a hex string, hex-decode it to the 32 bytes. - Re-encode the entropy as a BIP39 mnemonic and stretch it into the 64-byte BIP39 seed with an empty passphrase.
- Create a BIP32 master key from the seed and insert Anchorage Digital’s hardened purpose step
1097753448'as the first step afterm. The wallet’sderivationPathis relative to this purpose level. - Derive the remaining path steps and take the resulting node’s 32-byte private key.
- Hex-encode those 32 bytes (64 lowercase hex characters) for the
Api-Child-Control-Keyheader.
Derive a child control key
- TypeScript
- Python
- Go
The mnemonic in the examples is a published test key, not a real
organization’s MCK. Run your implementation against it and confirm you get
the same child control key before using a production Recovery Document.
Use the key in a transfer
- Call
GET /v2/wallets/{walletId}for the source wallet and readderivationPathfrom the response. - Derive the child control key and hex-encode it (64 lowercase hex characters).
- Include it when creating the transfer:
Api-Child-Control-Key header is required only for self-custody organizations initiating transfers through the API. The Api-Signature and Api-Timestamp headers carry the standard Ed25519 request signature that POST /v2/transfers always requires; see Signing requests for how to compute them.