zip-0032.rst

ZIP: 32
Title: Shielded Hierarchical Deterministic Wallets
Owners: Jack Grigg <str4d@electriccoin.co>
        Daira Hopwood <daira@electriccoin.co>
Credits: Sean Bowe
         Kris Nuttycombe
         Ying Tong Lai
         Pieter Wuille
         Marek Palatinus
         Pavol Rusnak
Status: Final
Category: Standards / Wallet
Created: 2018-05-22
License: MIT

Terminology

The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. ¹

"Jubjub" refers to the elliptic curve defined in².

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³.

Abstract

This proposal defines a mechanism for extending hierarchical deterministic wallets, as decribed in BIP 32 ⁴, 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⁵ 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⁶ is the standard mechanism by which wallets for Bitcoin and its derivatives (including Zcash's transparent addresses⁷) 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 word phrase⁸) 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 ⁹. They are reproduced here for convenience:

• truncate_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.
• LEOS2IP_ℓ(S) is the integer in range {0 .​.2^ℓ − 1} represented in little-endian order by the byte sequence S of length ℓ/8.
• I2LEBSP_ℓ(k) is the sequence of ℓ bits representing k in little-endian order.
• LEBS2OSP_ℓ(B) is defined as follows when ℓ 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.
• repr_𝕁(P) is the representation of the Jubjub elliptic curve point P as a bit sequence, defined in¹⁰.
• BLAKE2b-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.
• BLAKE2b-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.
• PRF^expand(sk, t):=BLAKE2b-512(“Zcash_ExpandSeed”,sk || t)
• r_𝕁 is the order of the Jubjub large prime subgroup.
• r_ℙ is the order of the Pallas curve.
• ToScalar^Sapling(x):=$\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{J}}$.
• ToScalar^Orchard(x):=$\mathsf{LEOS2IP}_{512}(x) \pmod{r_\mathbb{P}}$.
• DiversifyHash^Sapling(d) maps a diversifier d to a base point on the Jubjub elliptic curve, or to ⊥ if the diversifier is invalid. It is instantiated in¹¹.

The following algorithm standardized in¹² is used:

• FF1-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 “” as the tweak. x is a sequence of 88 bits, as is the output.

We also define the following conversion function:

• I2LEOSP_ℓ(k) is the byte sequence S of length ℓ/8 representing in little-endian order the integer k in range {0 .​.2^ℓ − 1}. It is the reverse operation of LEOS2IP_ℓ(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¹³ to describe shielded HD paths, using prime marks (′) to indicate hardened derivation (i′ = i + 2³¹) as in BIP 44¹⁴:

• CDKfvk(CDKfvk(CDKfvk(m_Sapling, a), b), c) is written as m_Sapling/a/b/c.

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 (ask, nsk, ovk, dk, c), where (ask, nsk, ovk) is the normal Sapling expanded spending key, dk is a diversifier key, and c is the chain code.

We represent a Sapling extended full viewing key as (ak, nk, ovk, dk, c), where (ak, nk, ovk) is the normal Sapling full viewing key, dk is the same diversifier key as above, and c is the chain code.

Sapling helper functions

Define

• EncodeExtSKParts(ask, nsk, ovk, dk):=I2LEOSP₂₅₆(ask)|| I2LEOSP₂₅₆(nsk)|| ovk|| dk
• EncodeExtFVKParts(ak, nk, ovk, dk):=LEBS2OS₂₅₆(repr_𝕁(ak))|| LEBS2OSP₂₅₆(repr_𝕁(nk))|| ovk|| dk

Sapling master key generation

Let S be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.

• Calculate I = BLAKE2b-512(“ZcashIP32Sapling”, S).
• Split I into two 32-byte sequences, I_L and I_R.
• Use I_L as the master spending key sk_m, and I_R as the master chain code c_m.
• Calculate ask_m, nsk_m, and ovk_m via the standard Sapling derivation¹⁵:
  • ask_m = ToScalar^Sapling(PRF^expand(sk_m, [0x00]))
  • nsk_m = ToScalar^Sapling(PRF^expand(sk_m, [0x01]))
  • ovk_m = truncate₃₂(PRF^expand(sk_m, [0x02])).
• Calculate dk_m similarly:
  • dk_m = truncate₃₂(PRF^expand(sk_m, [0x10])).
• Return (ask_m, nsk_m, ovk_m, dk_m, c_m) as the master extended spending key m_Sapling.

Note that the master extended key is invalid if ask_m is 0, or if the corresponding ivk derived as specified in¹⁶ 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

CDKsk((ask_par, nsk_par, ovk_par, dk_par, c_par), i) → (ask_i, nsk_i, ovk_i, dk_i, c_i)

• Check whether i ≥ 2³¹ (whether the child is a hardened key).
  • If so (hardened child): let I = PRF^expand(c_par, [0x11]|| EncodeExtSKParts(ask_par, nsk_par, ovk_par, dk_par)|| I2LEOSP₃₂(i)).
  • If not (normal child): let I = PRF^expand(c_par, [0x12]|| EncodeExtFVKParts(ak_par, nk_par, ovk_par, dk_par)|| I2LEOSP₃₂(i)) where (nk_par, ak_par, ovk_par) is the full viewing key derived from (ask_par, nsk_par, ovk_par) as described in¹⁷.
• Split I into two 32-byte sequences, I_L and I_R.
• Let I_ask = ToScalar^Sapling(PRF^expand(I_L, [0x13])).
• Let I_nsk = ToScalar^Sapling(PRF^expand(I_L, [0x14])).
• Return:
  • :math:mathsf{ask}_i = (I_mathsf{ask} + mathsf{ask}_{par}) pmod{r_mathbb{J}}
  • :math:mathsf{nsk}_i = (I_mathsf{nsk} + mathsf{nsk}_{par}) pmod{r_mathbb{J}}
  • :math:ovk_i = truncate₃₂(PRF^expand(I_L, [0x15]||,mathsf{ovk}_{par}))
  • :math:dk_i = truncate₃₂(PRF^expand(I_L, [0x16]||,mathsf{dk}_{par}))
  • :math:mathsf{c}_i = I_R.

Note that the child extended key is invalid if ask_i is 0, or if the corresponding ivk derived as specified in¹⁸ is 0.

Deriving a child extended full viewing key

Let 𝒢^Sapling be as defined in¹⁹ and let ℋ^Sapling be as defined in²⁰.

CDKfvk((ak_par, nk_par, ovk_par, dk_par, c_par), i) → (ak_i, nk_i, ovk_i, dk_i, c_i)

• Check whether i ≥ 2³¹ (whether the child is a hardened key).
  • If so (hardened child): return failure.
  • If not (normal child): let I = PRF^expand(c_par, [0x12]|| EncodeExtFVKParts(ak_par, nk_par, ovk_par, dk_par)|| I2LEOSP₃₂(i)).
• Split I into two 32-byte sequences, I_L and I_R.
• Let I_ask = ToScalar^Sapling(PRF^expand(I_L, [0x13])).
• Let I_nsk = ToScalar^Sapling(PRF^expand(I_L, [0x14])).
• Return:
  • :math:mathsf{ak}_i = [I_mathsf{ask}],mathcal{G}^mathsf{Sapling} + mathsf{ak}_{par}
  • :math:mathsf{nk}_i = [I_mathsf{nsk}],mathcal{H}^mathsf{Sapling} + mathsf{nk}_{par}
  • :math:ovk_i = truncate₃₂(PRF^expand(I_L, [0x15]||,mathsf{ovk}_{par}))
  • :math:dk_i = truncate₃₂(PRF^expand(I_L, [0x16]||,mathsf{dk}_{par}))
  • :math:mathsf{c}_i = I_R.

Note that the child extended key is invalid if ak_i is the zero point of Jubjub, or if the corresponding ivk derived as specified in²¹ 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²², 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 (ask, nsk, ovk, dk) be the external spending key.

• Derive the corresponding ak and nk as specified in²³.
• Let I = BLAKE2b-256("Zcash_SaplingInt", EncodeExtFVKParts(ak, nk, ovk, dk)).
• Let I_nsk = ToScalar^Sapling(PRF^expand(I, [0x17])).
• Let R = PRF^expand(I, [0x18]).
• Let $\mathsf{nsk_{internal}} = (I_\mathsf{nsk} + \mathsf{nsk}) \pmod{r_\mathbb{J}}$.
• Split R into two 32-byte sequences, dk_internal and ovk_internal.
• Return the internal spending key as (ask, nsk_internal, ovk_internal, dk_internal).

Note that the child extended key is invalid if ak is the zero point of Jubjub, or if the corresponding ivk derived as specified in²⁴ is 0.

Deriving a Sapling internal full viewing key

Let ℋ^Sapling be as defined in²⁵.

Let (ak, nk, ovk, dk) be the external full viewing key.

• Let I = BLAKE2b-256("Zcash_SaplingInt", EncodeExtFVKParts(ak, nk, ovk, dk)).
• Let I_nsk = ToScalar^Sapling(PRF^expand(I, [0x17])).
• Let R = PRF^expand(I, [0x18]).
• Let nk_internal = [I_nsk]ℋ^Sapling + nk.
• Split R into two 32-byte sequences, dk_internal and ovk_internal.
• Return the internal full viewing key as (ak, nk_internal, ovk_internal, dk_internal).

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 ak) as the original, but viewing authority only for internal transfers.

The values of I, I_nsk, 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:

Diagram of Sapling internal key derivation

(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²⁶.

Note that the internal extended key is invalid if ak is the zero point of Jubjub, or if the corresponding ivk_internal derived from the internal full viewing key as specified in²⁷ is 0.

Sapling diversifier derivation

The 88-bit diversifiers for a Sapling extended key are derived from its diversifier key dk. 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⁸⁸ − 1.
• d_j = FF1-AES256.Encrypt(dk, “”, I2LEBSP₈₈(j)).

A valid diversifier d_j is one for which DiversifyHash^Sapling(d_j) ≠ ⊥. For a given dk, 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: Orchard 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 only support hardened key derivation for Orchard.

Orchard extended keys

We represent an Orchard extended spending key as (sk, c), where sk is the normal Orchard spending key (opaque 32 bytes), and c is the chain code.

Orchard master key generation

Let S be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.

• Calculate I = BLAKE2b-512(“ZcashIP32Orchard”, S).
• Split I into two 32-byte sequences, I_L and I_R.
• Use I_L as the master spending key sk_m.
• Use I_R as the master chain code c_m.
• Return (sk_m, c_m) as the master extended spending key m_Orchard.

Orchard child key derivation

CDKsk((sk_par, c_par), i) → (sk_i, c_i)

• Check whether i ≥ 2³¹ (whether the child is a hardened key).
  • If so (hardened child): let I = PRF^expand(c_par, [0x81] || sk_par || I2LEOSP₃₂(i)).
  • If not (normal child): return failure.
• Split I into two 32-byte sequences, I_L and I_R.
• Use I_L as the child spending key sk_i.
• Use I_R as the child chain code c_i.

Note that the resulting child spending key may produce an invalid external FVK, as specified in²⁸, 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 ask be the spend authorizing key if available, and let (ak, nk, rivk) be the corresponding external full viewing key, obtained as specified in²⁹.

Define DeriveInternalFVK^Orchard(ak, nk, rivk) as follows:

• Let K = I2LEBSP₂₅₆(rivk).
• Let rivk_internal = ToScalar^Orchard(PRF^expand(K, [0x83] || I2LEOSP₂₅₆(ak) || I2LEOSP₂₅₆(nk)).
• Return (ak, nk, rivk_internal).

The result of applying DeriveInternalFVK^Orchard to the external full viewing key is the internal full viewing key. The corresponding expanded internal spending key is (ask, nk, rivk_internal),

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 rivk_internal field relative to the external full viewing key, which results in different dk_internal, ivk_internal and ovk_internal fields being derived, as specified in³⁰ and shown in the following diagram:

Diagram of Orchard internal key derivation, also showing derivation from the parent extended spending key

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³¹.

Note that the resulting FVK may be invalid, as specified in³².

Orchard diversifier 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.

Given an Orchard extended spending key (sk_i, c_i):

• Let (ak, nk, rivk) be the Orchard full viewing key for sk_i.
• Let K = I2LEBSP₂₅₆(rivk) and let B = repr_ℙ(ak) || I2LEBSP₂₅₆(nk).
• dk_i = truncate₃₂(PRF^expand(K, [0x82] || LEBS2OSP₅₁₂(B))).
• Let j be the index of the desired diversifier, in the range 0 .​.2⁸⁸ − 1.
• d_i, j = FF1-AES256.Encrypt(dk_i, “”, I2LEBSP₈₈(j)).

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

The default diversifier for (sk_i, c_i) is defined to be d_i, 0.

Specification: Wallet usage

Existing Zcash-supporting HD wallets all use BIP 44³³ 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 0x80000020) 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 ³⁴. 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³⁵.

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³¹ − 1}:

• m_Sapling/purpose′/coin_type′/account′.

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⁸⁷ 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³⁶:

• m_Sapling/purpose′/coin_type′/account′/address_index.

zcashd version 4.6.0 and later uses this to derive "legacy" Sapling addresses from a mnemonic seed phrase under account 0x7FFFFFFF, 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³¹ − 1}:

• m_Orchard/purpose′/coin_type′/account′.

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⁸⁸ 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 FVK (as specified in³⁷) is given by:

• BLAKE2b-256(“ZcashSaplingFVFP”, 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 FVK (as specified in³⁸) is given by:

• BLAKE2b-256(“ZcashOrchardFVFP”, 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:

• BLAKE2b-256(“Zcash_HD_Seed_FP”,[length(S)] || S).

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

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³⁹ encoding.

Sapling extended spending keys

A Sapling extended spending key (ask, nsk, ovk, dk, c), at depth depth, with parent full viewing key tag parent_fvk_tag and child number i, is represented as a byte sequence:

• I2LEOSP₈(depth)|| parent_fvk_tag|| I2LEOSP₃₂(i)|| c|| EncodeExtSKParts(ask, nsk, ovk, dk).

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 (ak, nk, ovk, dk, c), at depth depth, with parent full viewing key tag parent_fvk_tag and child number i, is represented as a byte sequence:

• I2LEOSP₈(depth)|| parent_fvk_tag|| I2LEOSP₃₂(i)|| c|| EncodeExtFVKParts(ak, nk, ovk, dk).

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 (sk, c), at depth depth, with parent full viewing key tag parent_fvk_tag and child number i, is represented as a byte sequence:

• I2LEOSP₈(depth) || parent_fvk_tag || I2LEOSP₃₂(i) || c || sk.

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⁴⁰.

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 BLAKE2b-512 personalization “ZcashIP32_Sprout”, formerly specified for derivation of the master key of the Sprout tree;
• the BLAKE2b-256 personalization “Zcash_Sprout_AFP”, formerly specified for generation of Sprout address fingerprints;
• the PRF^expand prefix 0x80, 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

TBC

Reference Implementation

• https://github.com/zcash-hackworks/zip32
• zcash/librustzcash#29
• zcash/zcash#3447
• zcash/zcash#3492

References

---

1. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels↩

2. Zcash Protocol Specification, Version 2022.2.19. Section 5.4.9.3: Jubjub↩

3. Zcash Protocol Specification, Version 2022.2.19. Section 3.12: Mainnet and Testnet↩

4. BIP 32: Hierarchical Deterministic Wallets↩

5. BIP 44: Multi-Account Hierarchy for Deterministic Wallets↩

6. BIP 32: Hierarchical Deterministic Wallets↩

7. SLIP 44: Registered coin types for BIP-0044↩

8. BIP 39: Mnemonic code for generating deterministic keys↩

9. Zcash Protocol Specification, Version 2022.2.19 or later [NU5 proposal]↩

10. Zcash Protocol Specification, Version 2022.2.19. Section 5.4.9.3: Jubjub↩

11. Zcash Protocol Specification, Version 2022.2.19. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions↩

12. NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption↩

13. BIP 32: Hierarchical Deterministic Wallets↩

14. BIP 44: Multi-Account Hierarchy for Deterministic Wallets↩

15. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components↩

16. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components↩

17. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components↩

18. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components↩

19. Zcash Protocol Specification, Version 2022.2.19. Section 5.4.6.1: Spend Authorization Signature↩

20. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components↩

21. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components↩

22. BIP 44: Multi-Account Hierarchy for Deterministic Wallets↩

23. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components↩

24. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components↩

25. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components↩

26. ZIP 316: Unified Addresses and Unified Viewing Keys↩

27. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components↩

28. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components↩

29. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components↩

30. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components↩

31. ZIP 316: Unified Addresses and Unified Viewing Keys↩

32. Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components↩

33. BIP 44: Multi-Account Hierarchy for Deterministic Wallets↩

34. SLIP 44: Registered coin types for BIP-0044↩

35. BIP 44: Multi-Account Hierarchy for Deterministic Wallets↩

36. BIP 44: Multi-Account Hierarchy for Deterministic Wallets↩

37. Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.3: Sapling Full Viewing Keys↩

38. Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.4: Orchard Raw Full Viewing Keys↩

39. BIP 173: Base32 address format for native v0-16 witness outputs↩

40. Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.5: Orchard Spending Keys↩