Wallet Guide
The Zcash wallet layer: keys, transactions, and light-client synchronisation
Abstract
Assuming the cryptographic primitives of the Crypto Guide, the best-chain model of the Consensus Guide, and the Orchard protocol of the Ironwood Guide, this volume of The Zcash Arboretum documents the deployed wallet layer above them: hierarchical key derivation (ZIP-32), diversified and unified addresses (ZIP-316), the conventional fee (ZIP-317), the transaction-construction pipeline of librustzcash, partially created transactions (PCZT), the transaction lifecycle from broadcast through expiry (ZIP-203), payment requests (ZIP-321), and light-client synchronisation. The synchronisation chapters cover the compact-block format (ZIP-307) and its deployed divergences, the light-client service surface as lightwalletd, Zaino, and Zebra implement it, the scanning pipeline of librustzcash with its verify-first reorg discipline, commitment-tree synchronisation, and what the server learns. Every derived quantity carries its exact derivation.
The compact-block wire format is deployed but underspecified; where the draft ZIP and the deployed implementations disagree, this volume documents the deployment and flags the divergence. The protocol target is draft NU7, whose ZIP 259 leaves both activation heights unassigned as of 23 September 2026. Proposed rules and implementation-specific behaviour are distinguished where they affect the construction.
Contents
-
1 Hierarchical key derivation (ZIP-32)
- 1.1 Wallet seeds
- 1.2 Hardened-only derivation
- 1.3 The standard account path
- 1.4 From the account key to addresses: the layer already built
- 1.5 Internal keys: change and auto-shielding
- 1.6 Key validity and derivation failure
- 1.7 Fingerprints and tags
- 1.8 Extended-key encoding and test vectors
- 1.9 The lead-byte registry
- 2 Diversified and unified addresses (ZIP-316)
- 3 Fees (ZIP-317)
- 4 Transaction construction
-
5 Partially created transactions (PCZT)
- 5.1 Roles and lifecycle
- 5.2 Structure
- 5.3 Encoding
- 5.4 Creation and construction
- 5.5 IO finalization: the binding-signature key
- 5.6 Updating
- 5.7 Signing
- 5.8 Proving
- 5.9 Combining, redaction, and privacy
- 5.10 Transparent finalization and lock time
- 5.11 Extraction and verification
- 5.12 The deployed wallet pipeline
- 5.13 PCZT v2: deferred anchors and the Ironwood bundle
- 5.14 Divergences between ZIP-374 and the deployed code
- 6 Broadcast, expiry, and the transaction lifecycle
-
7 Payment requests (ZIP-321)
- 7.1 Requests, payments, and the single-transaction rule
- 7.2 URI syntax
- 7.3 Validity and address semantics
- 7.4 Amounts
- 7.5 Memos, labels, and messages
- 7.6 Custom assets: req-asset (specified, not deployed)
- 7.7 The deployed parser: the zip321 crate
- 7.8 From request to proposal to transaction
- 7.9 Divergences between ZIP-321 and the deployed stack
-
8 Compact blocks (ZIP-307)
- 8.1 Normative status and wire-format history
- 8.2 The deployed messages
- 8.3 NU7: block frequency and scanning work
- 8.4 Omissions and fetch-on-detect
- 8.5 Compact trial decryption
- 8.6 Scanning: spends, positions, and tree sizes
- 8.7 The scan pipeline: chain state, batching, caching
- 8.8 Server inclusion semantics and successor surface
- 8.9 Divergences between ZIP-307 and the deployed protocol
- 9 The light-client service
- 10 The scanning pipeline
- 11 Commitment-tree synchronisation
- 12 What the server learns