#Terminology

The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 [1] when, and only when, they appear in all capitals.

"Jubjub" refers to the elliptic curve defined in [15].

A "cryptovalue" is a high-entropy value used in a cryptographic protocol that is not necessarily a key.

A "chain code" is a cryptovalue that is needed, in addition to a spending key, in order to derive descendant keys and addresses of that key.

The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.12 of the Zcash Protocol Specification [10].

#Abstract

This proposal defines a mechanism for extending hierarchical deterministic wallets, as described in BIP 32 [2], to support Zcash's shielded addresses.

The initial parts of the specification define (mostly) equivalent, but independent, systems for deriving a tree of key components from a single seed, for the following shielded pools (which have different internal key structures):

• Sapling

• Orchard

Previous versions of this document also defined a similar derivation system for the Sprout shielded pool. This has been removed since it was never used, and is unlikely to be used given that zcashd no longer generates Sprout addresses (and neither Zebra nor the mobile SDKs have ever done so).

The last part shows how to use these trees in the context of existing BIP 44 [6] wallets.

This specification complements the existing use by some Zcash wallets of BIP 32 and BIP 44 for transparent Zcash addresses, and is not intended to deprecate that usage (privacy risks of using transparent addresses notwithstanding).

#Motivation

BIP 32 [2] is the standard mechanism by which wallets for Bitcoin and its derivatives (including Zcash's transparent addresses [7]) generate keys and addresses deterministically. This has several advantages over random generation:

• Wallets only need to store a single seed (particularly useful for hardware wallets).

• A one-time backup of the seed (usually stored as a BIP 39 mnemonic [3] or SLIP 39 shares [4]) can be used to recover funds from all future addresses.

• Keys are arranged into a tree of chains, enabling wallets to represent "accounts" or other high-level structures.

• Viewing authority or spending authority can be delegated independently for sub-trees without compromising the master seed.

At present, no such equivalent exists for Zcash's shielded addresses. This is of particular concern for hardware wallets; all currently-marketed devices only store a seed internally, and have trained their users to only backup that seed. Given that the Sapling upgrade will make it feasible to use hardware wallets with shielded addresses, it is desirable to have a standard mechanism for deriving them.

#Conventions

Most of the notation and functions used in this ZIP are defined in the Zcash protocol specification [9]. They are reproduced here for convenience:

• ${𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾}_k(S)$ means the sequence formed from the first $k$ elements of $S$.

• $a||b$ means the concatenation of sequences $a$ then $b$.

• $[k] P$ means scalar multiplication of the elliptic curve point $P$ by the scalar $k$.

• ${𝖫𝖤𝖮𝖲\mathrm{𝟤}𝖨𝖯}_{\ell }(S)$ is the integer in range $\{0..2^{\ell }-1\}$ represented in little-endian order by the byte sequence $S$ of length $\ell /8$.

• ${𝖨\mathrm{𝟤}𝖫𝖤𝖡𝖲𝖯}_{\ell }(k)$ is the sequence of $\ell$ bits representing $k$ in little-endian order.

• ${𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{\ell }(B)$ is defined as follows when $\ell$ is a multiple of $8$: convert each group of 8 bits in $B$ to a byte value with the least significant bit first, and concatenate the resulting bytes in the same order as the groups.

• ${𝗋𝖾𝗉𝗋}_{𝕁}(P)$ is the representation of the Jubjub elliptic curve point $P$ as a bit sequence, defined in [15].

• \mathsf{BLAKE2b}\textsf{-}\mathsf{256}(p, x) refers to unkeyed BLAKE2b-256 in sequential mode, with an output digest length of 32 bytes, 16-byte personalization string $p$, and input $x$.

• \mathsf{BLAKE2b}\textsf{-}\mathsf{512}(p, x) refers to unkeyed BLAKE2b-512 in sequential mode, with an output digest length of 64 bytes, 16-byte personalization string $p$, and input $x$.

• $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗌𝗄,t):=$ \mathsf{BLAKE2b}\textsf{-}\mathsf{512}(\texttt{“Zcash\_ExpandSeed”}, $𝗌𝗄||t)$.

• $r_{𝕁}$ is the order of the Jubjub large prime subgroup.

• $r_{\mathbb{P}}$ is the order of the Pallas curve.

• $𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(x):=$ ${𝖫𝖤𝖮𝖲\mathrm{𝟤}𝖨𝖯}_{512}(x)(\mathrm{mod}{r}_{𝕁})$.

• $𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(x):=$ ${𝖫𝖤𝖮𝖲\mathrm{𝟤}𝖨𝖯}_{512}(x)(\mathrm{mod}{r}_{\mathbb{P}})$.

• $𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌{𝗁}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(d)$ maps a diversifier $d$ to a base point on the Jubjub elliptic curve, or to $\perp$ if the diversifier is invalid. It is instantiated in [13].

The following algorithm standardized in [22] is used:

• \mathsf{FF1}\textsf{-}\mathsf{AES256.Encrypt}(key, tweak, x) refers to the FF1 encryption algorithm using AES with a 256-bit $key$, and parameters $radix = 2$, $minlen = 88$, $maxlen = 88$. It will be used only with the empty string \texttt{“”} as the $tweak$. $x$ is a sequence of 88 bits, as is the output.

We also define the following conversion function:

• ${𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{\ell }(k)$ is the byte sequence $S$ of length $\ell /8$ representing in little-endian order the integer $k$ in range $\{0..2^{\ell }-1\}$. It is the reverse operation of ${𝖫𝖤𝖮𝖲\mathrm{𝟤}𝖨𝖯}_{\ell }(S)$.

Implementors should note that this ZIP is consistently little-endian (in keeping with the Sapling and Orchard specifications), which is the opposite of BIP 32.

We adapt the path notation of BIP 32 [2] to describe shielded HD paths, using prime marks \textsf{(}\kern0.1em{}'\textsf{)} to indicate hardened derivation ($i\text{'}=i+2^{31}$) as in BIP 44 [6]:

• $𝖢𝖪𝖣𝖿𝗏𝗄(𝖢𝖪𝖣𝖿𝗏𝗄(𝖢𝖪𝖣𝖿𝗏𝗄(m_{𝖲𝖺𝗉𝗅𝗂𝗇𝗀},a),b),c)$ is written as $m_{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}/a/b/c$.

Note: no corresponding notation is currently defined for the result of Hardened-only child key derivation with non-zero $𝗅𝖾𝖺𝖽$ and/or non-empty $𝗍𝖺𝗀$.

#Specification: Wallet seeds

Several of the key derivation algorithms specified in this ZIP derive a master key from a seed byte sequence. Any such seed byte sequence MUST be at least 32 and at most 252 bytes.

The method of generating such a seed byte sequence for Zcash purposes MUST ensure that it has at least 256 bits of entropy. This requirement also applies to any mnemonic or input randomness used to obtain the seed byte sequence. See ZIP 315 [27] for further guidance.

#Rationale for the 256-bit entropy requirement

Click to show/hide

Zcash consistently uses cryptovalues of length at or close to 256 bits, throughout its cryptographic design. Although the target security level for the protocol against classical cryptanalytic attacks is $2^{125}$ (i.e. any such attack should take at least $2^{125}$ operations, as explained in [23]), this does not imply that 128-bit keys or seeds are sufficient. The apparent gap between the security target and the key length is well motivated: it provides better resistance to attacks using parallel hardware [24] in the multi-user setting [25]; it takes into account small entropy losses in the key derivation process; and it simplifies the analysis of the protocol against quantum attacks for unknown addresses [23], or in the context of a future post-quantum recovery protocol [30].

In particular, for the hierarchical key derivation method described in this ZIP, if the seed or mnemonic has entropy less than 256 bits, it will be a weak link in the derivation of all keys belonging to that wallet.

It should be noted that an adversary can search for uses of lower-entropy mnemonics across multiple wallets simultaneously. They can collect a large set of (transparent or shielded) target addresses and/or viewing keys, and then perform a brute-force search over mnemonics in a lower-entropy subspace, efficiently checking whether the first few addresses or viewing keys that would be generated from each mnemonic match any of the targets.

#Specification: Sapling key derivation

#Sapling extended keys

BIP 32 defines a method to derive a number of child keys from a parent key. In order to prevent these from depending solely on the parent key itself, both the private and public keys are extended with a 32-byte chain code. We similarly extend Sapling keys with a chain code here. However, the concepts of "private" and "public" keys in BIP 32 do not map cleanly to Sapling's key components. We take the following approach:

• We derive child Sapling expanded spending keys, rather than Sapling spending keys. This enables us to implement both hardened and non-hardened derivation modes (the latter being incompatible with Sapling spending keys).

• We do not derive Sapling public keys directly, as this would prevent the use of diversified addresses. Instead, we derive Sapling full viewing keys, from which payment addresses can be generated. This maintains the trust semantics of BIP 32: someone with access to a BIP 32 extended public key is able to view all transactions involving that address, which a Sapling full viewing key also enables.

We represent a Sapling extended spending key as $(𝖺𝗌𝗄,𝗇𝗌𝗄,𝗈𝗏𝗄,𝖽𝗄,𝖼)$, where $(𝖺𝗌𝗄,𝗇𝗌𝗄,𝗈𝗏𝗄)$ is the normal Sapling expanded spending key, $𝖽𝗄$ is a diversifier key, and $𝖼$ is the chain code.

We represent a Sapling extended full viewing key as $(𝖺𝗄,𝗇𝗄,𝗈𝗏𝗄,𝖽𝗄,𝖼)$, where $(𝖺𝗄,𝗇𝗄,𝗈𝗏𝗄)$ is the normal Sapling full viewing key, $𝖽𝗄$ is the same diversifier key as above, and $𝖼$ is the chain code.

#Sapling helper functions

Define

• $𝖤𝗇𝖼𝗈𝖽𝖾𝖤𝗑𝗍𝖲𝖪𝖯𝖺𝗋𝗍𝗌(𝖺𝗌𝗄,𝗇𝗌𝗄,𝗈𝗏𝗄,𝖽𝗄):=$ ${𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝖺𝗌𝗄)$ $||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝗇𝗌𝗄)$ $||𝗈𝗏𝗄$ $||𝖽𝗄$

• $𝖤𝗇𝖼𝗈𝖽𝖾𝖤𝗑𝗍𝖥𝖵𝖪𝖯𝖺𝗋𝗍𝗌(𝖺𝗄,𝗇𝗄,𝗈𝗏𝗄,𝖽𝗄):=$ ${𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}({𝗋𝖾𝗉𝗋}_{𝕁}(𝖺𝗄))$ $||{𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}({𝗋𝖾𝗉𝗋}_{𝕁}(𝗇𝗄))$ $||𝗈𝗏𝗄$ $||𝖽𝗄$

#Sapling master key generation

Let $S$ be a seed byte sequence meeting the requirements in Specification: Wallet seeds.

• Calculate I = \mathsf{BLAKE2b}\textsf{-}\mathsf{512}(\texttt{“ZcashIP32Sapling”}, S).

• Split $I$ into two 32-byte sequences, $I_L$ and $I_R$.

• Use $I_L$ as the master spending key ${𝗌𝗄}_m$, and $I_R$ as the master chain code ${𝖼}_m$.

• Calculate ${𝖺𝗌𝗄}_m$, ${𝗇𝗌𝗄}_m$, and ${𝗈𝗏𝗄}_m$ via the standard Sapling derivation [11]:

  • ${𝖺𝗌𝗄}_m=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}({𝗌𝗄}_m,[\mathrm{𝟶}𝚡\mathrm{𝟶𝟶}]))$

  • ${𝗇𝗌𝗄}_m=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}({𝗌𝗄}_m,[\mathrm{𝟶}𝚡\mathrm{𝟶𝟷}]))$

  • ${𝗈𝗏𝗄}_m={𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾}_{32}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}({𝗌𝗄}_m,[\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}]))$.

• Calculate ${𝖽𝗄}_m$ similarly:

  • ${𝖽𝗄}_m={𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾}_{32}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}({𝗌𝗄}_m,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟶}]))$.

• Return $({𝖺𝗌𝗄}_m,{𝗇𝗌𝗄}_m,{𝗈𝗏𝗄}_m,{𝖽𝗄}_m,{𝖼}_m)$ as the master extended spending key $m_{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$.

Note that the master extended key is invalid if ${𝖺𝗌𝗄}_m$ is $0$, or if the corresponding $𝗂𝗏𝗄$ derived as specified in [11] is $0$.

#Sapling child key derivation

As in BIP 32, the method for deriving a child extended key, given a parent extended key and an index $i$, depends on the type of key being derived, and whether this is a hardened or non-hardened derivation.

#Deriving a child extended spending key

$𝖢𝖪𝖣𝗌𝗄(({𝖺𝗌𝗄}_{par},{𝗇𝗌𝗄}_{par},{𝗈𝗏𝗄}_{par},{𝖽𝗄}_{par},{𝖼}_{par}),i)$ $\to ({𝖺𝗌𝗄}_i,{𝗇𝗌𝗄}_i,{𝗈𝗏𝗄}_i,{𝖽𝗄}_i,{𝖼}_i)$ :

• Check whether $i\ge 2^{31}$ (whether the child is a hardened key).

  • If so (hardened child): let $I=𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}({𝖼}_{par},[\mathrm{𝟶}𝚡\mathrm{𝟷𝟷}]$ $||𝖤𝗇𝖼𝗈𝖽𝖾𝖤𝗑𝗍𝖲𝖪𝖯𝖺𝗋𝗍𝗌({𝖺𝗌𝗄}_{par},{𝗇𝗌𝗄}_{par},{𝗈𝗏𝗄}_{par},{𝖽𝗄}_{par})$ $||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{32}(i))$.

  • If not (normal child): let $I=𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}({𝖼}_{par},[\mathrm{𝟶}𝚡\mathrm{𝟷𝟸}]$ $||𝖤𝗇𝖼𝗈𝖽𝖾𝖤𝗑𝗍𝖥𝖵𝖪𝖯𝖺𝗋𝗍𝗌({𝖺𝗄}_{par},{𝗇𝗄}_{par},{𝗈𝗏𝗄}_{par},{𝖽𝗄}_{par})$ $||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{32}(i))$ where $({𝗇𝗄}_{par},{𝖺𝗄}_{par},{𝗈𝗏𝗄}_{par})$ is the full viewing key derived from $({𝖺𝗌𝗄}_{par},{𝗇𝗌𝗄}_{par},{𝗈𝗏𝗄}_{par})$ as described in [11].

• Split $I$ into two 32-byte sequences, $I_L$ and $I_R$.

• Let $I_{𝖺𝗌𝗄}=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I_L,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟹}]))$.

• Let $I_{𝗇𝗌𝗄}=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I_L,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟺}]))$.

• Return:

  • ${𝖺𝗌𝗄}_i=(I_{𝖺𝗌𝗄}+{𝖺𝗌𝗄}_{par})(\mathrm{mod}{r}_{𝕁})$

  • ${𝗇𝗌𝗄}_i=(I_{𝗇𝗌𝗄}+{𝗇𝗌𝗄}_{par})(\mathrm{mod}{r}_{𝕁})$

  • ${𝗈𝗏𝗄}_i={𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾}_{32}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I_L,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟻}]$ $||{𝗈𝗏𝗄}_{par}))$

  • ${𝖽𝗄}_i={𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾}_{32}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I_L,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟼}]$ $||{𝖽𝗄}_{par}))$

  • ${𝖼}_i=I_R$.

Note that the child extended key is invalid if ${𝖺𝗌𝗄}_i$ is $0$, or if the corresponding $𝗂𝗏𝗄$ derived as specified in [11] is $0$.

#Deriving a child extended full viewing key

Let ${𝒢}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ be as defined in [14] and let ${\mathscr{H}}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ be as defined in [11].

$𝖢𝖪𝖣𝖿𝗏𝗄(({𝖺𝗄}_{par},{𝗇𝗄}_{par},{𝗈𝗏𝗄}_{par},{𝖽𝗄}_{par},{𝖼}_{par}),i)$ $\to ({𝖺𝗄}_i,{𝗇𝗄}_i,{𝗈𝗏𝗄}_i,{𝖽𝗄}_i,{𝖼}_i)$ :

• Check whether $i\ge 2^{31}$ (whether the child is a hardened key).

  • If so (hardened child): return failure.

  • If not (normal child): let $I=𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}({𝖼}_{par},[\mathrm{𝟶}𝚡\mathrm{𝟷𝟸}]$ $||𝖤𝗇𝖼𝗈𝖽𝖾𝖤𝗑𝗍𝖥𝖵𝖪𝖯𝖺𝗋𝗍𝗌({𝖺𝗄}_{par},{𝗇𝗄}_{par},{𝗈𝗏𝗄}_{par},{𝖽𝗄}_{par})$ $||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{32}(i))$.

• Split $I$ into two 32-byte sequences, $I_L$ and $I_R$.

• Let $I_{𝖺𝗌𝗄}=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I_L,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟹}]))$.

• Let $I_{𝗇𝗌𝗄}=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I_L,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟺}]))$.

• Return:

  • ${𝖺𝗄}_i=[I_{𝖺𝗌𝗄}]{𝒢}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}+{𝖺𝗄}_{par}$

  • ${𝗇𝗄}_i=[I_{𝗇𝗌𝗄}]{\mathscr{H}}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}+{𝗇𝗄}_{par}$

  • ${𝗈𝗏𝗄}_i={𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾}_{32}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I_L,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟻}]$ $||{𝗈𝗏𝗄}_{par}))$

  • ${𝖽𝗄}_i={𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾}_{32}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I_L,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟼}]$ $||{𝖽𝗄}_{par}))$

  • ${𝖼}_i=I_R$.

Note that the child extended key is invalid if ${𝖺𝗄}_i$ is the zero point of Jubjub, or if the corresponding $𝗂𝗏𝗄$ derived as specified in [11] is $0$.

#Sapling internal key derivation

The above derivation mechanisms produce external addresses suitable for giving out to senders. We also want to be able to produce another address derived from a given external address, for use by wallets for internal operations such as change and auto-shielding. Unlike BIP 44 that allows deriving a stream of external and internal addresses in the same hierarchical derivation tree [6], for any external full viewing key we only need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.

#Deriving a Sapling internal spending key

Let $(𝖺𝗌𝗄,𝗇𝗌𝗄,𝗈𝗏𝗄,𝖽𝗄)$ be the external spending key.

• Derive the corresponding $𝖺𝗄$ and $𝗇𝗄$ as specified in [11].

• Let $I = textsf{BLAKE2b-256}(texttt{“Zcash_SaplingInt”}, mathsf{EncodeExtFVKParts}(mathsf{ak}, mathsf{nk}, mathsf{ovk}, mathsf{dk}))$.

• Let $I_{𝗇𝗌𝗄}=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟽}]))$.

• Let $R=𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟾}])$.

• Let $𝗇𝗌{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}=(I_{𝗇𝗌𝗄}+𝗇𝗌𝗄)(\mathrm{mod}{r}_{𝕁})$.

• Split $R$ into two 32-byte sequences, $𝖽{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$ and $𝗈𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$.

• Return the internal spending key as $(𝖺𝗌𝗄,𝗇𝗌{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅},𝗈𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅},𝖽{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅})$.

Note that the child extended key is invalid if $𝖺𝗄$ is the zero point of Jubjub, or if the corresponding $𝗂𝗏𝗄$ derived as specified in [11] is $0$.

#Deriving a Sapling internal full viewing key

Let ${\mathscr{H}}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ be as defined in [11].

Let $(𝖺𝗄,𝗇𝗄,𝗈𝗏𝗄,𝖽𝗄)$ be the external full viewing key.

• Let $I = textsf{BLAKE2b-256}(texttt{“Zcash_SaplingInt”}, mathsf{EncodeExtFVKParts}(mathsf{ak}, mathsf{nk}, mathsf{ovk}, mathsf{dk}))$.

• Let $I_{𝗇𝗌𝗄}=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟽}]))$.

• Let $R=𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}(I,[\mathrm{𝟶}𝚡\mathrm{𝟷𝟾}])$.

• Let $𝗇{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}=[I_{𝗇𝗌𝗄}]{\mathscr{H}}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}+𝗇𝗄$.

• Split $R$ into two 32-byte sequences, $𝖽{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$ and $𝗈𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$.

• Return the internal full viewing key as $(𝖺𝗄,𝗇{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅},𝗈𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅},𝖽{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅})$.

This design uses the same technique as non-hardened derivation to obtain a full viewing key with the same spend authority (the private key corresponding to $𝖺𝗄$) as the original, but viewing authority only for internal transfers.

The values of $I$, $I_{𝗇𝗌𝗄}$, and $R$ are the same between deriving a full viewing key, and deriving the corresponding spending key. Both of these derivations are shown in the following diagram:

(For simplicity, the proof authorizing key is not shown.)

This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in zcashd as part of support for ZIP 316 [28].

Note that the internal extended key is invalid if $𝖺𝗄$ is the zero point of Jubjub, or if the corresponding $𝗂𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$ derived from the internal full viewing key as specified in [11] is $0$.

#Sapling diversifier derivation

The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key $𝖽𝗄$. To prevent the diversifier leaking how many diversified addresses have already been generated for an account, we make the sequence of diversifiers pseudorandom and uncorrelated to that of any other account. In order to reach the maximum possible diversifier range without running into repetitions due to the birthday bound, we use FF1-AES256 as a Pseudo-Random Permutation as follows:

• Let $j$ be the index of the desired diversifier, in the range $0..2^{88}-1$.

• d_j = \mathsf{FF1}\textsf{-}\mathsf{AES256.Encrypt}(\mathsf{dk}, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j)).

A valid diversifier $d_j$ is one for which $𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌{𝗁}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(d_j)\ne \perp$. For a given $𝖽𝗄$, approximately half of the possible values of $j$ yield valid diversifiers.

The default diversifier for a Sapling extended key is defined to be $d_j$, where $j$ is the least nonnegative integer yielding a valid diversifier.

#Specification: Hardened-only key derivation

The derivation mechanism for Sapling addresses specified above incurs significant complexity to support non-hardened derivation. In the several years since Sapling was deployed, we have seen no use cases for non-hardened derivation appear. With that in mind, we now have a general hardened-only derivation process that retains compatibility with existing derivation path semantics (to enable deriving the same path across multiple contexts).

The functions defined in this section are intended for internal use by context-specific mechanisms in subsequent sections, rather than for direct use.

#Instantiation

Let $𝖢𝗈𝗇𝗍𝖾𝗑𝗍$ be the context in which the hardened-only key derivation process is instantiated (e.g. a shielded protocol). We define two context-specific constants:

• $𝖢𝗈𝗇𝗍𝖾𝗑𝗍.𝖬𝖪𝖦𝖣𝗈𝗆𝖺𝗂𝗇$ is a sequence of 16 bytes, used as a domain separator during master key generation. It SHOULD be disjoint from other domain separators used with BLAKE2b in Zcash protocols.

• $𝖢𝗈𝗇𝗍𝖾𝗑𝗍.𝖢𝖪𝖣𝖣𝗈𝗆𝖺𝗂𝗇$ is a byte value, used as a domain separator during child key derivation. This should be tracked as part of the global set of domains defined for $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$.

#Hardened-only master key generation

Let $𝖨𝖪𝖬$ be an input key material byte sequence, which MUST use an unambiguous encoding within the given context, and SHOULD contain at least 256 bits of entropy. It is RECOMMENDED to use a prefix-free encoding, which may require the use of length fields if multiple fields need to be encoded.

${𝖬𝖪𝖦𝗁}^{𝖢𝗈𝗇𝗍𝖾𝗑𝗍}(𝖨𝖪𝖬)\to ({𝗌𝗄}_m,{𝖼}_m)$ :

• Calculate I = \mathsf{BLAKE2b}\textsf{-}\mathsf{512}(\mathsf{Context.MKGDomain}, \mathsf{IKM}).

• Split $I$ into two 32-byte sequences, $I_L$ and $I_R$.

• Use $I_L$ as the master secret key ${𝗌𝗄}_m$.

• Use $I_R$ as the master chain code ${𝖼}_m$.

• Return $({𝗌𝗄}_m,{𝖼}_m)$.

#Hardened-only child key derivation

As well as the integer child index $i$, the child key derivation function defined here supports a lead byte $𝗅𝖾𝖺𝖽$ (used for domain separation) and byte sequence $𝗍𝖺𝗀$. Each triple $(i,𝗅𝖾𝖺𝖽,𝗍𝖺𝗀)$ produces an independent output.

${𝖢𝖪𝖣𝗁}^{𝖢𝗈𝗇𝗍𝖾𝗑𝗍}(({𝗌𝗄}_{par},{𝖼}_{par}),i,𝗅𝖾𝖺𝖽,𝗍𝖺𝗀)$ $\to ({𝗌𝗄}_{child},{𝖼}_{child})$ :

• If $i<2^{31}$ (non-hardened child index): return failure.

• Let $mathsf{lead_enc} = begin{cases} ,[,],&!!textsf{if } mathsf{lead} = 0 textsf{ and } mathsf{tag} = [,] \ ,[mathsf{lead}],&!!textsf{otherwise.}end{cases}$

• Let $I = mathsf{PRF^{expand}}(mathsf{c}_{par}, [mathsf{Context.CKDDomain}],||,mathsf{sk}_{par},||,mathsf{I2LEOSP}_{32}(i),||,mathsf{lead_enc},||,mathsf{tag})$.

• Split $I$ into two 32-byte sequences, $I_L$ and $I_R$.

• Return $(I_L,I_R)$.

Note that in the input to $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$, the case $𝗅𝖾𝖺𝖽=0$ and $𝗍𝖺𝗀=[]$ is encoded in a way compatible with the definition of $𝖢𝖪𝖣𝗁$ in previous versions of this specification (before $𝗅𝖾𝖺𝖽$ and $𝗍𝖺𝗀$ were added).

#Specification: Orchard key derivation

We only support hardened key derivation for Orchard. We instantiate the hardened key generation process with the following constants:

• \mathsf{Orchard.MKGDomain} = \texttt{“ZcashIP32Orchard”}

• $𝖮𝗋𝖼𝗁𝖺𝗋𝖽.𝖢𝖪𝖣𝖣𝗈𝗆𝖺𝗂𝗇=\mathrm{𝟶}𝚡\mathrm{𝟾𝟷}$

#Orchard extended keys

We represent an Orchard extended spending key as $(𝗌𝗄,𝖼)$, where $𝗌𝗄$ is the normal Orchard spending key (opaque 32 bytes), and $𝖼$ is the chain code.

#Orchard master key generation

Let $S$ be a seed byte sequence meeting the requirements in Specification: Wallet seeds.

• Return ${𝖬𝖪𝖦𝗁}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(S)$ as the master extended spending key $m_{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$.

#Orchard child key derivation

$𝖢𝖪𝖣𝗌𝗄(({𝗌𝗄}_{par},{𝖼}_{par}),i)$ $\to ({𝗌𝗄}_i,{𝖼}_i)$ :

• Return ${𝖢𝖪𝖣𝗁}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(({𝗌𝗄}_{par},{𝖼}_{par}),i,0,[])$

Note that the resulting child spending key may produce an invalid external FVK, as specified in [12], with small probability. The corresponding internal FVK derived as specified in the next section may also be invalid with small probability.

#Orchard internal key derivation

As in the case of Sapling, for a given external address, we want to produce another address for use by wallets for internal operations such as change and auto-shielding. That is, for any external full viewing key we need to be able to derive a single internal full viewing key that has viewing authority for just internal transfers. We also need to be able to derive the corresponding internal spending key if we have the external spending key.

Let $𝖺𝗌𝗄$ be the spend authorizing key if available, and let $(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄)$ be the corresponding external full viewing key, obtained as specified in [12].

Define $𝖣𝖾𝗋𝗂𝗏𝖾𝖨𝗇𝗍𝖾𝗋𝗇𝖺𝗅𝖥𝖵{𝖪}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄)$ as follows:

• Let $K={𝖨\mathrm{𝟤}𝖫𝖤𝖡𝖲𝖯}_{256}(𝗋𝗂𝗏𝗄)$.

• Let $mathsf{rivk_{internal}} = mathsf{ToScalar^{Orchard}}big(mathsf{PRF}^{mathsf{expand}}_{K}big([mathtt{0x83}] ,||, mathsf{I2LEOSP_{256}}(mathsf{ak}) ,||, mathsf{I2LEOSP_{256}}(mathsf{nk})kern-0.1embig)kern-0.15embig)$.

• Return $(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅})$.

The result of applying $𝖣𝖾𝗋𝗂𝗏𝖾𝖨𝗇𝗍𝖾𝗋𝗇𝖺𝗅𝖥𝖵{𝖪}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ to the external full viewing key is the internal full viewing key. The corresponding expanded internal spending key is $(𝖺𝗌𝗄,𝗇𝗄,𝗋𝗂𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅})$.

Unlike Sapling internal key derivation, we do not base this internal key derivation procedure on non-hardened derivation, which is not defined for Orchard. We can obtain the desired separation of viewing authority by modifying only the $𝗋𝗂𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$ field relative to the external full viewing key, which results in different $𝖽{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$, $𝗂𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$ and $𝗈𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$ fields being derived, as specified in [12] and shown in the following diagram:

$\ast$ The derivations of $𝖺𝗌𝗄$ and $𝗋𝗂𝗏𝗄$ shown in the diagram are not the only possibility. For further detail see § 4.2.3 ‘Orchard Key Components’ in the protocol specification [12]. However, if $𝖺𝗌𝗄$, $𝖺𝗄$, $𝗇𝗄$, $𝗋𝗂𝗏𝗄$, and $𝗋𝗂𝗏{𝗄}_{𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}$ are not generated as in the diagram, then it may not be possible to recover the resulting notes as specified in ZIP 2005 [30] in the event that attacks using quantum computers become practical.

This method of deriving internal keys is applied to external keys that are children of the Account level. It was implemented in zcashd as part of support for ZIP 316 [28].

Note that the resulting FVK may be invalid, as specified in [12].

#Orchard diversifier and OVK derivation

As with Sapling, we define a mechanism for deterministically deriving a sequence of diversifiers, without leaking how many diversified addresses have already been generated for an account. Unlike Sapling, we do so by deriving a diversifier key directly from the full viewing key, instead of as part of the extended spending key. This means that the full viewing key provides the capability to determine the position of a diversifier within the sequence, which matches the capabilities of a Sapling extended full viewing key but simplifies the key structure.

Let $𝖣𝖾𝗋𝗂𝗏𝖾𝖣𝗄𝖠𝗇𝖽𝖮𝗏{𝗄}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ be as defined in [12].

Given an Orchard full viewing key $(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄)$ (which may be either external or internal):

• $(𝖽𝗄,𝗈𝗏𝗄)=𝖣𝖾𝗋𝗂𝗏𝖾𝖣𝗄𝖠𝗇𝖽𝖮𝗏{𝗄}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗋𝗂𝗏𝗄,𝖺𝗄,𝗇𝗄)$.

• Let $j$ be the index of the desired diversifier, in the range $0..2^{88}-1$.

• $mathsf{d}_j = mathsf{FF1}textsf{-}mathsf{AES256.Encrypt}big(mathsf{dk}, texttt{“”}, mathsf{I2LEBSP}_{88}(j)kern-0.1embig)$.

Note that unlike Sapling, all Orchard diversifiers are valid, and thus all possible values of $j$ yield valid diversifiers.

The default diversifier for $(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄)$ is defined to be ${𝖽}_0$.

No mechanism is provided to derive distinct Outgoing Viewing Keys ($𝗈𝗏𝗄$) for each diversified address. This is because payments are sent from accounts (with external or internal scope), not from specific diversified addresses [29].

#Specification: Registered key derivation

In the context of a particular application protocol defined by a ZIP, there is sometimes a need to define an HD subtree that will not collide with keys derived for other protocols, as far as that is possible to assure by following the ZIP process [26].

Within this subtree, the application protocol may use derivation paths related to those used for existing key material — for example, to derive an account-level key. The following instantiation of the hardened key generation process may be used for this purpose.

It is strongly RECOMMENDED that implementors ensure that documentation of the context string(s), and the usage and derivation paths of the application protocol's key tree in the corresponding ZIP are substantially complete, before public deployment of software or hardware using this mechanism. The ZIP process allows for subsequent updates and corrections.

Let $𝖢𝗈𝗇𝗍𝖾𝗑𝗍𝖲𝗍𝗋𝗂𝗇𝗀$ be a globally-unique non-empty sequence of at most 252 bytes that identifies the desired context.

We instantiate the hardened key generation process with the following constants:

• \mathsf{Registered.MKGDomain} = \texttt{“ZIPRegistered\_KD”}

• $𝖱𝖾𝗀𝗂𝗌𝗍𝖾𝗋𝖾𝖽.𝖢𝖪𝖣𝖣𝗈𝗆𝖺𝗂𝗇=\mathrm{𝟶}𝚡𝙰𝙲$

#Registered subtree root key generation

Let $S$ be a seed byte sequence meeting the requirements in Specification: Wallet seeds.

The registered subtree root is obtained as:

$𝖱𝖾𝗀𝖪𝖣(𝖢𝗈𝗇𝗍𝖾𝗑𝗍𝖲𝗍𝗋𝗂𝗇𝗀,𝖲,𝖹𝗂𝗉𝖭𝗎𝗆𝖻𝖾𝗋)$ $\to ({𝗌𝗄}_{subtree},{𝖼}_{subtree})$ :

• Let $(mathsf{sk}_{m}, mathsf{c}_{m}) = mathsf{MKGh}^mathsf{Registered}([mathsf{length}(mathsf{ContextString})],||,mathsf{ContextString},||,[mathsf{length}(S)],||,S)$.

• Return ${𝖢𝖪𝖣𝗁}^{𝖱𝖾𝗀𝗂𝗌𝗍𝖾𝗋𝖾𝖽}(({𝗌𝗄}_m,{𝖼}_m),𝖹𝗂𝗉𝖭𝗎𝗆𝖻𝖾𝗋+2^{31},0,[])$.

Note: The intermediate key $({𝗌𝗄}_m,{𝖼}_m)$ would grant the ability to derive the subtree root for application protocols defined in any ZIP using the same $𝖢𝗈𝗇𝗍𝖾𝗑𝗍𝖲𝗍𝗋𝗂𝗇𝗀$ and seed. This is a potentially dangerous scope of grant since it cannot be known what future protocols will use this mechanism; therefore, $({𝗌𝗄}_m,{𝖼}_m)$ SHOULD NOT be used or stored directly without careful consideration of security consequences.

#Registered child key derivation

As well as the integer child index $i$, the child key derivation function defined here supports a byte sequence $𝗍𝖺𝗀$; each pair $(i,𝗍𝖺𝗀)$ produces a different child key. If an explicit tag is not required, $𝗍𝖺𝗀$ is set to the empty byte sequence.

Note: The tag MUST use an unambiguous encoding within the given context. It is RECOMMENDED to use a prefix-free encoding, which may require the use of length fields if multiple fields need to be encoded.

$𝖢𝖪𝖣𝗋𝖾𝗀(({𝗌𝗄}_{par},{𝖼}_{par}),i,𝗍𝖺𝗀)$ $\to ({𝗌𝗄}_{child},{𝖼}_{child})$ :

• Return ${𝖢𝖪𝖣𝗁}^{𝖱𝖾𝗀𝗂𝗌𝗍𝖾𝗋𝖾𝖽}(({𝗌𝗄}_{par},{𝖼}_{par}),i,0,𝗍𝖺𝗀)$.

#Full-width child cryptovalue derivation

If the application protocol requires a 64-byte cryptovalue (for example, to avoid an entropy bottleneck in its subsequent operations), then a similar process to Registered child key derivation above can be used to obtain such a cryptovalue at a given child index; again with optional tag. The same considerations about encoding of the $𝗍𝖺𝗀$ apply as above.

$𝖽𝖾𝗋𝗂𝗏𝖾\_𝖼𝗁𝗂𝗅𝖽\_𝖼𝗋𝗒𝗉𝗍𝗈𝗏𝖺𝗅𝗎𝖾(({𝗌𝗄}_{par},{𝖼}_{par}),i,𝗍𝖺𝗀)$ $\to {𝖪}_{child}$ :

• Let $(I_L,I_R)={𝖢𝖪𝖣𝗁}^{𝖱𝖾𝗀𝗂𝗌𝗍𝖾𝗋𝖾𝖽}(({𝗌𝗄}_{par},{𝖼}_{par}),i,1,𝗍𝖺𝗀)$.

• Return $I_L||I_R$.

For the avoidance of doubt, the output of $𝖽𝖾𝗋𝗂𝗏𝖾\_𝖼𝗁𝗂𝗅𝖽\_𝖼𝗋𝗒𝗉𝗍𝗈𝗏𝖺𝗅𝗎𝖾$ MUST NOT be provided as input to any key derivation function defined in ZIP 32. In particular, it MUST NOT be reinterpreted directly or indirectly as an input to $𝖢𝖪𝖣𝗁$.

#Specification: Ad-hoc key derivation (deprecated)

For compatibility with existing deployments, we also define a mechanism to derive ad-hoc key trees for private use by applications, without ecosystem coordination. This was called "arbitrary key derivation" in previous iterations of this ZIP, but that term caused confusion as to the applicability of the mechanism.

Since there is no guarantee of non-collision between different application protocols, and no way to tie these key trees to well-defined specification or documentation processes, use of this mechanism is NOT RECOMMENDED for new protocols.

Let $𝖢𝗈𝗇𝗍𝖾𝗑𝗍𝖲𝗍𝗋𝗂𝗇𝗀$ be a globally-unique non-empty sequence of at most 252 bytes that identifies the desired context.

We instantiate the hardened key derivation process with the following constants:

• \mathsf{Adhoc.MKGDomain} = \texttt{“ZcashArbitraryKD”}

• $𝖠𝖽𝗁𝗈𝖼.𝖢𝖪𝖣𝖣𝗈𝗆𝖺𝗂𝗇=\mathrm{𝟶}𝚡𝙰𝙱$

#Ad-hoc master key generation (deprecated)

Let $S$ be a seed byte sequence meeting the requirements in Specification: Wallet seeds.

The master extended ad-hoc key is:

$m_mathsf{Adhoc} = mathsf{MKGh}^mathsf{Adhoc}([mathsf{length}(mathsf{ContextString})],||,mathsf{ContextString},||,[mathsf{length}(S)],||,S)$.

#Ad-hoc child key derivation (deprecated)

$𝖢𝖪𝖣𝖺𝗋𝖻(({𝗌𝗄}_{par},{𝖼}_{par}),i)$ $\to ({𝗌𝗄}_i,{𝖼}_i)$ :

• Return ${𝖢𝖪𝖣𝗁}^{𝖠𝖽𝗁𝗈𝖼}(({𝗌𝗄}_{par},{𝖼}_{par}),i,0,[])$.

Note: a previous iteration of this ZIP suggested that, if $i$ is the last element of an HD path (i.e. no extension of this path is used), then the concatenation ${𝗌𝗄}_i||{𝖼}_i$ could be used as a 64-bit key. This is NOT RECOMMENDED, because it is difficult to define safe APIs that enforce the restriction that a given node in the key tree must not be used both in this way and to derive further child keys. Full-width child cryptovalue derivation provides a safe way to obtain the same functionality for new application protocols.

#Specification: Wallet usage

Existing Zcash-supporting HD wallets all use BIP 44 [6] to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.

#Key path levels

Sapling and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:

• $purpose$: a constant set to $32'$ (or $\mathrm{𝟶}𝚡\mathrm{𝟾𝟶𝟶𝟶𝟶𝟶𝟸𝟶}$) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.

• $coin\_type$: a constant identifying the cryptocurrency that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 [7]. Note that in keeping with that document, all cryptocurrency testnets share $coin\_type$ index $1$.

• $account$: numbered from index $0$ in sequentially increasing manner. Defined as in BIP 44 [6].

Unlike BIP 44, none of the shielded key paths have a $change$ path level. The use of change addresses in Bitcoin is a (failed) attempt to increase the difficulty of tracking users on the transaction graph, by segregating external and internal address usage. Shielded addresses are never publicly visible in transactions, which means that sending change back to the originating address is indistinguishable from using a change address.

#Sapling key path

Sapling provides a mechanism to allow the efficient creation of diversified payment addresses with the same spending authority. A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.

The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Sapling ZIP 32 derivation MUST support the following path for any account in range $\{0..2^{31}-1\}$:

• $m_{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}/purpose\text{'}/coin\_type\text{'}/account\text{'}$.

Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier as defined above) for any account they support. They MAY also support generating a stream of payment addresses for a given account, if they wish to maintain the user experience of giving a unique address to each recipient.

Note that a given account can have a maximum of approximately $2^{87}$ payment addresses, because each diversifier has around a 50% chance of being invalid.

If in certain circumstances a wallet needs to derive independent spend authorities within a single account, they MAY additionally support a non-hardened $address\_index$ path level as in [6]:

• $m_{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}/purpose\text{'}/coin\_type\text{'}/account\text{'}/address\_index$.

zcashd version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase under account $\mathrm{𝟶}𝚡\mathrm{𝟽}𝙵𝙵𝙵𝙵𝙵𝙵𝙵$, using hardened derivation for $address\_index$.

#Orchard key path

Orchard supports diversified addresses with the same spending authority (like Sapling). A group of such addresses shares the same full viewing key and incoming viewing key, and so creating as many unlinkable addresses as needed does not increase the cost of scanning the block chain for relevant transactions.

The above key path levels include an account identifier, which in all user interfaces is represented as a "bucket of funds" under the control of a single spending authority. Therefore, wallets implementing Orchard ZIP 32 derivation MUST support the following path for any account in range $\{0..2^{31}-1\}$:

• $m_{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}/purpose\text{'}/coin\_type\text{'}/account\text{'}$.

Furthermore, wallets MUST support generating the default payment address (corresponding to the default diversifier for Orchard) for any account they support. They MAY also support generating a stream of diversified payment addresses for a given account, if they wish to enable users to give a unique address to each recipient.

Note that a given account can have a maximum of $2^{88}$ payment addresses (unlike Sapling, all Orchard diversifiers are valid).

#Specification: Fingerprints and Tags

#Sapling Full Viewing Key Fingerprints and Tags

A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding $𝐹𝑉𝐾$ (as specified in [18]) is given by:

• \mathsf{BLAKE2b}\textsf{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK}).

It MAY be used to uniquely identify a particular Sapling full viewing key.

A "Sapling full viewing key tag" is the first 4 bytes of the corresponding Sapling full viewing key fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to uniquely identify a particular key.

#Orchard Full Viewing Key Fingerprints and Tags

An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding $𝐹𝑉𝐾$ (as specified in [20]) is given by:

• \mathsf{BLAKE2b}\textsf{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK}).

It MAY be used to uniquely identify a particular Orchard full viewing key.

An "Orchard full viewing key tag" is the first 4 bytes of the corresponding Orchard full viewing key fingerprint. It is intended for optimizing performance of key lookups, and MUST NOT be assumed to uniquely identify a particular key.

#Seed Fingerprints

A "seed fingerprint" for the master seed $S$ of a hierarchical deterministic wallet is given by:

• \mathsf{BLAKE2b}\textsf{-}\mathsf{256}(\texttt{“Zcash\_HD\_Seed\_FP”}, $[𝗅𝖾𝗇𝗀𝗍𝗁(S)]||S)$.

It MAY be used to uniquely identify a particular hierarchical deterministic wallet.

The string encoding of a seed fingerprint uses Bech32m with the Human-Readable Part zip32seedfp, and the fingerprint bytes as the data.

No corresponding short tag is defined.

Note: a previous version of this specification did not have the length byte prefixing the seed. The current specification reflects the implementation in zcashd.

#Specification: Key Encodings

The following encodings are analogous to the xprv and xpub encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 [8] encoding.

#Sapling extended spending keys

A Sapling extended spending key $(𝖺𝗌𝗄,𝗇𝗌𝗄,𝗈𝗏𝗄,𝖽𝗄,𝖼)$, at depth $depth$, with parent full viewing key tag $parent\_fvk\_tag$ and child number $i$, is represented as a byte sequence:

• ${𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_8(depth)$ $||parent\_fvk\_tag$ $||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{32}(i)$ $||𝖼$ $||𝖤𝗇𝖼𝗈𝖽𝖾𝖤𝗑𝗍𝖲𝖪𝖯𝖺𝗋𝗍𝗌(𝖺𝗌𝗄,𝗇𝗌𝗄,𝗈𝗏𝗄,𝖽𝗄)$.

For the master extended spending key, $depth$ is $0$, $parent\_fvk\_tag$ is 4 zero bytes, and $i$ is $0$.

When encoded as Bech32, the Human-Readable Part is secret-extended-key-main for the production network, or secret-extended-key-test for the test network.

#Sapling extended full viewing keys

A Sapling extended full viewing key $(𝖺𝗄,𝗇𝗄,𝗈𝗏𝗄,𝖽𝗄,𝖼)$, at depth $depth$, with parent full viewing key tag $parent\_fvk\_tag$ and child number $i$, is represented as a byte sequence:

• ${𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_8(depth)$ $||parent\_fvk\_tag$ $||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{32}(i)$ $||𝖼$ $||𝖤𝗇𝖼𝗈𝖽𝖾𝖤𝗑𝗍𝖥𝖵𝖪𝖯𝖺𝗋𝗍𝗌(𝖺𝗄,𝗇𝗄,𝗈𝗏𝗄,𝖽𝗄)$.

For the master extended full viewing key, $depth$ is $0$, $parent\_fvk\_tag$ is 4 zero bytes, and $i$ is $0$.

When encoded as Bech32, the Human-Readable Part is zxviews for the production network, or zxviewtestsapling for the test network.

#Orchard extended spending keys

An Orchard extended spending key $(𝗌𝗄,𝖼)$, at depth $depth$, with parent full viewing key tag $parent\_fvk\_tag$ and child number $i$, is represented as a byte sequence:

• ${𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_8(depth)||parent\_fvk\_tag||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{32}(i)||𝖼||𝗌𝗄$.

For the master extended spending key, $depth$ is $0$, $parent\_fvk\_tag$ is 4 zero bytes, and $i$ is $0$.

When encoded as Bech32, the Human-Readable Part is secret-orchard-extsk-main for Mainnet, or secret-orchard-extsk-test for Testnet.

We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users [21].

#Values reserved due to previous specification for Sprout

The following values were previously used in the specification of hierarchical derivation for Sprout, and therefore SHOULD NOT be used in future Zcash-related specifications:

• the \mathsf{BLAKE2b}\textsf{-}\mathsf{512} personalization \texttt{“ZcashIP32\_Sprout”}, formerly specified for derivation of the master key of the Sprout tree;

• the \mathsf{BLAKE2b}\textsf{-}\mathsf{256} personalization \texttt{“Zcash\_Sprout\_AFP”}, formerly specified for generation of Sprout address fingerprints;

• the $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$ prefix $\mathrm{𝟶}𝚡\mathrm{𝟾𝟶}$, formerly specified for Sprout child key derivation;

• the Bech32 Human-Readable Parts zxsprout and zxtestsprout, formerly specified for Sprout extended spending keys on Mainnet and Testnet respectively.

#Test Vectors

Test vectors are available at <https://github.com/zcash/zcash-test-vectors> in the sapling_zip32, sapling_zip32_hard, orchard_zip32, zip_0032_registered, and zip_0032_arbitrary files for each format.

#Reference Implementation

• https://github.com/zcash-hackworks/zip32

• https://github.com/zcash/librustzcash/pull/29

• https://github.com/zcash/zcash/pull/3447

• https://github.com/zcash/zcash/pull/3492

#References