# ZIP 32: Shielded Hierarchical Deterministic Wallets

Status: Final

Owners: Jack Grigg, Daira-Emma Hopwood

Snapshot: a34cfc091434275120ff017c92c3b50d3cef623a

Source date: 2026-10-16T02:56:04+01:00

[Source revision](https://github.com/zcash/zips/commit/a34cfc091434275120ff017c92c3b50d3cef623a)

[Official source](https://zips.z.cash/zip-0032) · [Source file](https://github.com/zcash/zips/blob/a34cfc091434275120ff017c92c3b50d3cef623a/zips/zip-0032.rst)

## Document parts

[Part 1](https://zip-tools-web.harpocrates.workers.dev/zip/32) · [Part 2](https://zip-tools-web.harpocrates.workers.dev/zip/32?part=2)

Reading part 2 of 2. Follow all parts for the complete proposal.

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

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

- $\mathsf{Adhoc.CKDDomain} = \mathtt{0xAB}$

<a id="ad-hoc-master-key-generation-deprecated"></a>

### Ad-hoc master key generation (deprecated)

Let $S$ be a seed byte sequence meeting the requirements in [Specification: Wallet seeds](/zip/32#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)$.

<a id="ad-hoc-child-key-derivation-deprecated"></a>

### Ad-hoc child key derivation (deprecated)

$\mathsf{CKDarb}((\mathsf{sk}_{par}, \mathsf{c}_{par}), i)$ $\rightarrow (\mathsf{sk}_i, \mathsf{c}_i)$ :

- Return $\mathsf{CKDh}^\mathsf{Adhoc}((\mathsf{sk}_{par}, \mathsf{c}_{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 $\mathsf{sk}_i\,||\,\mathsf{c}_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](/zip/32#full-width-child-cryptovalue-derivation) provides a safe way to obtain the same functionality for new application protocols.

<a id="specification-wallet-usage"></a>

## Specification: Wallet usage

Existing Zcash-supporting HD wallets all use BIP 44<a id="fnref43"></a>
[43](#fn43) 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.

<a id="key-path-levels"></a>

### 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 $\mathtt{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 <a id="fnref44"></a>
  [44](#fn44). 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<a id="fnref45"></a>
  [45](#fn45).

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.

<a id="sapling-key-path"></a>

### 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_\mathsf{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^{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<a id="fnref46"></a>
[46](#fn46):

- $m_\mathsf{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 $\mathtt{0x7FFFFFFF}$, using hardened derivation for $address\_index$.

<a id="orchard-key-path"></a>

### 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_\mathsf{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^{88}$ payment addresses (unlike Sapling, all Orchard diversifiers are valid).

<a id="specification-fingerprints-and-tags"></a>

## Specification: Fingerprints and Tags

<a id="sapling-full-viewing-key-fingerprints-and-tags"></a>

### Sapling Full Viewing Key Fingerprints and Tags

A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding $\mathit{FVK}$ (as specified in<a id="fnref47"></a>
[47](#fn47)) 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.

<a id="orchard-full-viewing-key-fingerprints-and-tags"></a>

### Orchard Full Viewing Key Fingerprints and Tags

An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding $\mathit{FVK}$ (as specified in<a id="fnref48"></a>
[48](#fn48)) 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.

<a id="seed-fingerprints"></a>

### 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”},$ $[\mathsf{length}(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.

<a id="specification-key-encodings"></a>

## 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<a id="fnref49"></a>
[49](#fn49) encoding.

<a id="sapling-extended-spending-keys"></a>

### Sapling extended spending keys

A Sapling extended spending key $(\mathsf{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:

- $\mathsf{I2LEOSP}_{8}(depth)$ $||\,parent\_fvk\_tag$ $||\,\mathsf{I2LEOSP}_{32}(i)$ $||\,\mathsf{c}$ $||\,\mathsf{EncodeExtSKParts}(\mathsf{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.

<a id="sapling-extended-full-viewing-keys"></a>

### Sapling extended full viewing keys

A Sapling extended full viewing key $(\mathsf{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:

- $\mathsf{I2LEOSP}_{8}(depth)$ $||\,parent\_fvk\_tag$ $||\,\mathsf{I2LEOSP}_{32}(i)$ $||\,\mathsf{c}$ $||\,\mathsf{EncodeExtFVKParts}(\mathsf{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.

<a id="orchard-extended-spending-keys"></a>

### Orchard extended spending keys

An Orchard extended spending key $(\mathsf{sk, c})$, at depth $depth$, with parent full viewing key tag $parent\_fvk\_tag$ and child number $i$, is represented as a byte sequence:

- $\mathsf{I2LEOSP}_{8}(depth)\,||\,parent\_fvk\_tag\,||\,\mathsf{I2LEOSP}_{32}(i)\,||\,\mathsf{c}\,||\,\mathsf{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<a id="fnref50"></a>
[50](#fn50).

<a id="values-reserved-due-to-previous-specification-for-sprout"></a>

## 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 $\mathsf{PRF^{expand}}$ prefix $\mathtt{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.

<a id="test-vectors"></a>

## Test Vectors

Test vectors are available at <[https://github.com/zcash/zcash-test-vectors](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.

<a id="reference-implementation"></a>

## Reference Implementation

- [https://github.com/zcash-hackworks/zip32](https://github.com/zcash-hackworks/zip32)

- [https://github.com/zcash/librustzcash/pull/29](https://github.com/zcash/librustzcash/pull/29)

- [https://github.com/zcash/zcash/pull/3447](https://github.com/zcash/zcash/pull/3447)

- [https://github.com/zcash/zcash/pull/3492](https://github.com/zcash/zcash/pull/3492)

<a id="references"></a>

## References

---

1. [Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"](https://www.rfc-editor.org/info/bcp14)[↩︎](/zip/32#fnref1)

2. [Zcash Protocol Specification, Version 2022.2.19. Section 5.4.9.3: Jubjub](protocol/protocol.pdf#jubjub)[↩︎](/zip/32#fnref2)

3. [Zcash Protocol Specification, Version 2022.2.19. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks)[↩︎](/zip/32#fnref3)

4. [BIP 32: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)[↩︎](/zip/32#fnref4)

5. [BIP 44: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)[↩︎](/zip/32#fnref5)

6. [BIP 32: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)[↩︎](/zip/32#fnref6)

7. [SLIP 44: Registered coin types for BIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)[↩︎](/zip/32#fnref7)

8. [BIP 39: Mnemonic code for generating deterministic keys](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)[↩︎](/zip/32#fnref8)

9. [SLIP 39: Shamir's Secret-Sharing for Mnemonic Codes](https://github.com/satoshilabs/slips/blob/master/slip-0039.md)[↩︎](/zip/32#fnref9)

10. [Zcash Protocol Specification, Version 2022.2.19 or later [NU5 proposal]](protocol/protocol.pdf)[↩︎](/zip/32#fnref10)

11. [Zcash Protocol Specification, Version 2022.2.19. Section 5.4.9.3: Jubjub](protocol/protocol.pdf#jubjub)[↩︎](/zip/32#fnref11)

12. [Zcash Protocol Specification, Version 2022.2.19. Section 5.4.1.6: DiversifyHash^Sapling and DiversifyHash^Orchard Hash Functions](protocol/protocol.pdf#concretediversifyhash)[↩︎](/zip/32#fnref12)

13. [NIST Special Publication 800-38G — Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption](https://dx.doi.org/10.6028/NIST.SP.800-38G)[↩︎](/zip/32#fnref13)

14. [BIP 32: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)[↩︎](/zip/32#fnref14)

15. [BIP 44: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)[↩︎](/zip/32#fnref15)

16. [ZIP 315: Best Practices for Wallet Implementations — Specification: Wallet seeds](/zip/315#wallet-seeds)[↩︎](/zip/32#fnref16)

17. [Understanding the Security of Zcash. Presentation by Daira-Emma Hopwood at Zcon3](https://www.youtube.com/watch?v=f6UToqiIdeY) ([slides](https://raw.githubusercontent.com/daira/zcash-security/main/zcash-security.pdf)).[↩︎](/zip/32#fnref17)

18. [Understanding brute force. Daniel Bernstein, 2005.](https://cr.yp.to/papers.html#bruteforce)[↩︎](/zip/32#fnref18)

19. [Hybrid Encryption in the Multi-User Setting. Gregory M. Zaverucha, 2012.](https://eprint.iacr.org/2012/159)[↩︎](/zip/32#fnref19)

20. [Understanding the Security of Zcash. Presentation by Daira-Emma Hopwood at Zcon3](https://www.youtube.com/watch?v=f6UToqiIdeY) ([slides](https://raw.githubusercontent.com/daira/zcash-security/main/zcash-security.pdf)).[↩︎](/zip/32#fnref20)

21. [ZIP 2005: Orchard Quantum Recoverability](/zip/2005)[↩︎](/zip/32#fnref21)

22. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components](protocol/protocol.pdf#saplingkeycomponents)[↩︎](/zip/32#fnref22)

23. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components](protocol/protocol.pdf#saplingkeycomponents)[↩︎](/zip/32#fnref23)

24. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components](protocol/protocol.pdf#saplingkeycomponents)[↩︎](/zip/32#fnref24)

25. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components](protocol/protocol.pdf#saplingkeycomponents)[↩︎](/zip/32#fnref25)

26. [Zcash Protocol Specification, Version 2022.2.19. Section 5.4.6.1: Spend Authorization Signature](protocol/protocol.pdf#concretespendauthsig)[↩︎](/zip/32#fnref26)

27. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components](protocol/protocol.pdf#saplingkeycomponents)[↩︎](/zip/32#fnref27)

28. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components](protocol/protocol.pdf#saplingkeycomponents)[↩︎](/zip/32#fnref28)

29. [BIP 44: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)[↩︎](/zip/32#fnref29)

30. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components](protocol/protocol.pdf#saplingkeycomponents)[↩︎](/zip/32#fnref30)

31. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components](protocol/protocol.pdf#saplingkeycomponents)[↩︎](/zip/32#fnref31)

32. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components](protocol/protocol.pdf#saplingkeycomponents)[↩︎](/zip/32#fnref32)

33. [ZIP 316: Unified Addresses and Unified Viewing Keys](/zip/316)[↩︎](/zip/32#fnref33)

34. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.2: Sapling Key Components](protocol/protocol.pdf#saplingkeycomponents)[↩︎](/zip/32#fnref34)

35. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components](protocol/protocol.pdf#orchardkeycomponents)[↩︎](/zip/32#fnref35)

36. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components](protocol/protocol.pdf#orchardkeycomponents)[↩︎](/zip/32#fnref36)

37. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components](protocol/protocol.pdf#orchardkeycomponents)[↩︎](/zip/32#fnref37)

38. [ZIP 316: Unified Addresses and Unified Viewing Keys](/zip/316)[↩︎](/zip/32#fnref38)

39. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components](protocol/protocol.pdf#orchardkeycomponents)[↩︎](/zip/32#fnref39)

40. [Zcash Protocol Specification, Version 2022.2.19. Section 4.2.3: Orchard Key Components](protocol/protocol.pdf#orchardkeycomponents)[↩︎](/zip/32#fnref40)

41. [ZIP 316: Unified Addresses and Unified Viewing Keys — Usage of Outgoing Viewing Keys](/zip/316#usage-of-outgoing-viewing-keys)[↩︎](/zip/32#fnref41)

42. [ZIP 0: ZIP Process](/zip/0)[↩︎](/zip/32#fnref42)

43. [BIP 44: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)[↩︎](#fnref43)

44. [SLIP 44: Registered coin types for BIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)[↩︎](#fnref44)

45. [BIP 44: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)[↩︎](#fnref45)

46. [BIP 44: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)[↩︎](#fnref46)

47. [Zcash Protocol Specification, Version 2022.2.19. Section 5.6.3.3: Sapling Full Viewing Keys](protocol/protocol.pdf#saplingfullviewingkeyencoding)[↩︎](#fnref47)

48. [Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.4: Orchard Raw Full Viewing Keys](protocol/protocol.pdf#orchardfullviewingkeyencoding)[↩︎](#fnref48)

49. [BIP 173: Base32 address format for native v0-16 witness outputs](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)[↩︎](#fnref49)

50. [Zcash Protocol Specification, Version 2022.2.19. Section 5.6.4.5: Orchard Spending Keys](protocol/protocol.pdf#orchardspendingkeyencoding)[↩︎](#fnref50)

## Citation relationships

Cites: [ZIP 0](https://zip-tools-web.harpocrates.workers.dev/zip/0), [ZIP 315](https://zip-tools-web.harpocrates.workers.dev/zip/315), [ZIP 316](https://zip-tools-web.harpocrates.workers.dev/zip/316), [ZIP 2005](https://zip-tools-web.harpocrates.workers.dev/zip/2005)

Cited by: [ZIP 173](https://zip-tools-web.harpocrates.workers.dev/zip/173), [ZIP 216](https://zip-tools-web.harpocrates.workers.dev/zip/216), [ZIP 222](https://zip-tools-web.harpocrates.workers.dev/zip/222), [ZIP 224](https://zip-tools-web.harpocrates.workers.dev/zip/224), [ZIP 227](https://zip-tools-web.harpocrates.workers.dev/zip/227), [ZIP 252](https://zip-tools-web.harpocrates.workers.dev/zip/252), [ZIP 308](https://zip-tools-web.harpocrates.workers.dev/zip/308), [ZIP 310](https://zip-tools-web.harpocrates.workers.dev/zip/310), [ZIP 315](https://zip-tools-web.harpocrates.workers.dev/zip/315), [ZIP 316](https://zip-tools-web.harpocrates.workers.dev/zip/316), [ZIP 320](https://zip-tools-web.harpocrates.workers.dev/zip/320), [ZIP 324](https://zip-tools-web.harpocrates.workers.dev/zip/324), [ZIP 325](https://zip-tools-web.harpocrates.workers.dev/zip/325), [ZIP 326](https://zip-tools-web.harpocrates.workers.dev/zip/326), [ZIP 374](https://zip-tools-web.harpocrates.workers.dev/zip/374), [ZIP 400](https://zip-tools-web.harpocrates.workers.dev/zip/400), [ZIP 2005](https://zip-tools-web.harpocrates.workers.dev/zip/2005)