#Terminology

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

The character § is used when referring to sections of the Zcash Protocol Specification. ²

The terms below are to be interpreted as follows:

Pool snapshot

A pair $(𝗋{𝗍}^{𝖼𝗆},𝗋{𝗍}^{𝖾𝗑𝖼𝗅})$ consisting of the Orchard note commitment tree root and the nullifier non-membership tree root, both computed as of the end of a specified block height. The pool snapshot defines the set of notes eligible for claims.

Nullifier non-membership tree

An Indexed Merkle Tree (IMT) whose leaves represent contiguous intervals between consecutive revealed nullifiers. A Merkle path to a leaf, together with a range check, proves that a given nullifier does not appear in the set of revealed nullifiers at the snapshot height. See [Nullifier Non-Membership Tree].

Alternate nullifier

A value derived from an Orchard note and a nullifier domain, with similar cryptographic properties to the note's standard nullifier but unlinkable to it. A note has exactly one alternate nullifier for each nullifier domain. See [Alternate Nullifier Derivation].

Nullifier domain

A unique identifier, encoded as an element of ${𝔽}_{q_{\mathbb{P}}}$, that scopes alternate nullifiers to a particular application instance. Two claims in the same domain for the same note produce the same alternate nullifier; claims in different domains are unlinkable.

Claim

A zero-knowledge proof, together with a spend authorization signature, demonstrating that the prover holds an unspent Orchard note with a committed value at a given pool snapshot, and revealing the note's alternate nullifier in a specified domain.

Dummy signed note

A synthetic Orchard note with value 1 zatoshi that does not exist in any on-chain note commitment tree. It is constructed solely for obtaining a spend authorization signature from the holder's key. Its value does not contribute to the claimed balance. See [Wallet Signing] and [Dummy Signed Note].

#Abstract

This ZIP specifies a mechanism for proving ownership of unspent Orchard notes at a snapshot of the shielded pool, without revealing the notes' standard nullifiers or linking claims to past or future on-chain spending.

The mechanism introduces two primitives: a nullifier non-membership tree (an Indexed Merkle Tree of intervals between consecutive revealed nullifiers) that enables efficient in-circuit proofs that a note was unspent at the snapshot height, and alternate nullifiers (domain-separated values derived from a note's standard nullifier using Poseidon) that prevent double-claiming within an application domain while remaining unlinkable across domains and to on-chain activity.

A Claim circuit combines these primitives with standard Orchard note commitment integrity, Merkle membership, spend authority, and diversified address integrity checks to produce a single proof per note. An optional multi-note batching extension allows proving aggregate balance across several notes in one proof.

Possible applications include private air drops, private proof-of-balance, and private stake-weighted polling. Application-specific protocols (such as coinholder voting) are specified in separate ZIPs that reference this one.

#Motivation

Several applications in the Zcash ecosystem require a holder to demonstrate that they controlled a certain balance at a point in time, without revealing which specific notes they held or linking the demonstration to their on-chain transaction history. Examples include:

• Air drops: distributing tokens proportional to shielded holdings.
• Stake-weighted polling: weighting votes by ZEC balance.
• Proof-of-balance: demonstrating solvency or collateral without revealing addresses.

The naive approach of revealing standard nullifiers would link the claim to future spending, destroying the privacy that Zcash's shielded transactions are designed to provide. An alternative approach of actually spending the claimed notes (e.g., to oneself) with an anchor at the snapshot height has the disadvantage that the same notes cannot be used in concurrent applications, and it permanently commits the holder to the claim by recording it on the main chain.

Domain-separated alternate nullifiers resolve both problems: they are unlinkable to the standard nullifiers (even after the note is later spent on-chain), and they are scoped to a specific application instance so that the same notes can participate in independent, concurrent applications without interference.

The concept of alternate nullifiers and nullifier non-membership trees for proof-of-balance was first described by Daira-Emma Hopwood and Jack Grigg in a 2023 draft. ³ This ZIP builds on that work with a concrete instantiation informed by the implementation experience of the Zcash coinholder voting system.

A key practical consideration is that many holders custody their spending keys on hardware wallets such as Keystone. Without a delegation mechanism, hardware wallet users must either export their spending keys to software (negating the security benefit of hardware custody) or perform many more hardware wallet signing interactions (one per protocol action rather than a single delegation) each with limited ability to verify the signing context on screen. This ZIP therefore specifies a PCZT-based signing flow (see [Wallet Signing]) that works with any hardware wallet supporting Orchard PCZT signing today, requiring no firmware changes.

#Privacy Implications

Unlinkability to standard nullifiers. The alternate nullifier $𝗇{𝖿}_{𝖽𝗈𝗆}$ for a note is computed as a Poseidon hash keyed by the nullifier deriving key $𝗇𝗄$, which is secret. An observer who sees both $𝗇{𝖿}_{𝖽𝗈𝗆}$ (published during a claim) and the standard nullifier $𝗇{𝖿}^{𝗈𝗅𝖽}$ (published when the note is later spent on the Zcash chain) cannot link them without knowledge of $𝗇𝗄$. This property holds under the assumption that Poseidon is a pseudorandom function when keyed with a uniformly random field element (see [Security Argument]).

Cross-domain unlinkability. If the same note participates in two independent applications with different nullifier domains $𝖽𝗈{𝗆}_{\mathrm{𝟣}}$ and $𝖽𝗈{𝗆}_{\mathrm{𝟤}}$, the resulting alternate nullifiers $𝗇{𝖿}_{𝖽𝗈{𝗆}_{\mathrm{𝟣}}}$ and $𝗇{𝖿}_{𝖽𝗈{𝗆}_{\mathrm{𝟤}}}$ are unlinkable. This follows from the PRF property: distinct inputs produce outputs that are computationally indistinguishable from independent random values.

Spend authority prevents viewing-key delegation. The circuit constrains correct derivation of $𝗋𝗄$, and the protocol requires a valid spend authorization signature under $𝗋𝗄$ (see [Spend Authorization Signature]), ensuring that a party with only a viewing key cannot make claims on behalf of the holder.

Non-membership tree queries. Obtaining a Merkle path in the nullifier non-membership tree requires querying a data source that holds the full tree. A naive query reveals which path is being requested, potentially linking the querier to a nullifier range. Private information retrieval (PIR) techniques can mitigate this leakage ⁴; their specification is out of scope for this document.

Hardware wallet device exposure. When the PCZT-based hardware wallet signing flow (see [Wallet Signing]) is used, the device observes the PCZT but learns no information about the holder's real Orchard balance or delegation context. The PCZT contains a 1-zatoshi dummy note with no on-chain counterpart; the holder's actual note commitments, values, and nullifiers are never transmitted to the device. The application commitment, alternate nullifiers, and usage identifier are committed via the dummy note's nullifier inside the ZKP circuit and do not appear as plaintext fields in the PCZT. The output address (application hotkey) is visible on the device but is freshly generated per usage instance and is not linked to the holder's on-chain Orchard addresses. An attacker with physical access to the device during signing learns only that the holder is participating in a proof-of-balance instance and the declared balance.

#Requirements

• A holder can prove ownership of an unspent Orchard note at a pool snapshot without revealing the note's standard nullifier.
• Double-claiming the same note within the same nullifier domain is detectable.
• Claims are unlinkable to the holder's past or future on-chain spends, and to their claims in other nullifier domains.
• The holder proves spend authority (not merely viewing access).
• The construction allows a holder to participate in multiple independent applications using the same notes, provided each application uses a distinct nullifier domain.

#Non-requirements

• Privacy-preserving retrieval of non-membership Merkle paths (e.g., via PIR) is out of scope.
• Value denomination conversions (e.g., converting zatoshi to application-specific units) are out of scope.
• Transaction-level encoding of claims is out of scope; this ZIP specifies only the proof statement and its verification.

#Specification

#Pool Snapshot

A pool snapshot at block height $h$ is a pair $(𝗋{𝗍}^{𝖼𝗆},𝗋{𝗍}^{𝖾𝗑𝖼𝗅})$ where:

• $𝗋{𝗍}^{𝖼𝗆}$ is the root of the Orchard note commitment tree as of the end of block $h$. ⁵
• $𝗋{𝗍}^{𝖾𝗑𝖼𝗅}$ is the root of the nullifier non-membership tree constructed from the set of all Orchard nullifiers revealed on the consensus chain as of the end of block $h$.

The pool snapshot MUST be deterministically computable from the consensus chain state at height $h$. Any party with access to the chain state MUST be able to independently verify both roots.

#Nullifier Non-Membership Tree

The nullifier non-membership tree is a Merkle tree whose leaves are commitments to the gaps between consecutive revealed nullifiers, enabling efficient in-circuit proofs that a given nullifier is absent from the revealed set.

The relationship between the sorted nullifier set and the tree is illustrated below:

            /  \                          ..
           /    \                        /
       gcm_0    gcm_1               gcm_2      <-- Gap commitments (tree leaves)
      /\            /\              /\
  |(l_0, w_0)| |(l_1, w_1)|   |(l_2, w_2) ..  <-- Gap encodings (low, width)
s_0|          |s_1|         |s_2|          ..   <-- Sorted nullifier set + sentinels

Each gap between consecutive nullifiers is encoded as a $(𝗅𝗈𝗐,𝗐𝗂𝖽𝗍𝗁)$ pair, then committed via $𝖦𝖺𝗉𝖢𝗈𝗆𝗆𝗂𝗍$ (see [Hash Function]) to produce a tree leaf.

#Construction

Let $S=\{s_0,s_1,\dots ,s_{m-1}\}\subset {𝔽}_{q_{\mathbb{P}}}$ be the union of the set of all Orchard nullifiers revealed on the consensus chain as of block height $h$ and the sentinel values defined in [Sentinel Initialization]. Sort $S$ in ascending order. Because sentinel initialization is mandatory, $S$ is non-empty.

For each pair of consecutive elements $(s_i,s_{i+1})$ where $s_i<s_{i+1}$ and $s_{i+1}-s_i>1$, compute a gap encoding:

• $𝗅𝗈𝗐=s_i+1$: the first value in the gap
• $𝗐𝗂𝖽𝗍𝗁=s_{i+1}-s_i-2$: the number of additional values in the gap beyond $𝗅𝗈𝗐$

The gap encoding represents the closed interval $[𝗅𝗈𝗐,𝗅𝗈𝗐+𝗐𝗂𝖽𝗍𝗁]$, which contains exactly the field elements between $s_i$ and $s_{i+1}$ exclusive. The corresponding tree leaf is $𝖦𝖺𝗉𝖢𝗈𝗆𝗆𝗂𝗍(𝗅𝗈𝗐,𝗐𝗂𝖽𝗍𝗁)$.

After processing all consecutive pairs, if $s_{m-1}<q_{\mathbb{P}}-1$, a terminal gap MUST be added with:

• $𝗅𝗈𝗐=s_{m-1}+1$
• $𝗐𝗂𝖽𝗍𝗁=(q_{\mathbb{P}}-1)-𝗅𝗈𝗐$

This ensures that all unrevealed values above the largest element of $S$ are represented in the tree.

#Hash Function

The non-membership tree uses Poseidon ⁶ with the $𝖯\mathrm{𝟣𝟤𝟪}𝖯𝗈𝗐\mathrm{𝟧}𝖳\mathrm{𝟥}$ instantiation (width $t=3$, rate 2) over the Pallas base field ${𝔽}_{q_{\mathbb{P}}}$ for all hashing:

• Gap commitment: $𝖦𝖺𝗉𝖢𝗈𝗆𝗆𝗂𝗍(𝗅𝗈𝗐,𝗐𝗂𝖽𝗍𝗁)$, a 2-input Poseidon hash (one permutation).
• Internal node hash: $𝖯𝗈𝗌𝖾𝗂𝖽𝗈𝗇𝖭𝗈𝖽𝖾𝖧𝖺𝗌𝗁(𝗅𝖾𝖿𝗍,𝗋𝗂𝗀𝗁𝗍)$, a 2-input Poseidon hash (one permutation), where $𝗅𝖾𝖿𝗍$ and $𝗋𝗂𝗀𝗁𝗍$ are determined by the node's position bit at each level.

Both functions use $𝖯\mathrm{𝟣𝟤𝟪}𝖯𝗈𝗐\mathrm{𝟧}𝖳\mathrm{𝟥}$ with $𝖢𝗈𝗇𝗌𝗍𝖺𝗇𝗍𝖫𝖾𝗇𝗀𝗍𝗁⟨2⟩$. This is the same Poseidon instantiation used by Orchard for nullifier derivation ⁶.

#Tree Depth

$𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖾𝗑𝖼𝗅}$ MUST be large enough to accommodate the number of gap leaves. Each nullifier in the pool adds at most one leaf (by splitting an existing gap), so the tree requires capacity for at least $|N|+17$ leaves, where $|N|$ is the size of the Orchard nullifier set and 17 is the number of sentinels for the Pallas base field. Concretely:

$𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖾𝗑𝖼𝗅}\ge \lceil {\log }_2(|N|+17)\rceil$

A depth of $𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖾𝗑𝖼𝗅}=29$ is RECOMMENDED. This supports up to $2^{29}\approx 537$ million leaves. As of early 2026, the Zcash Orchard pool contains roughly 51 million nullifiers, so depth 29 provides about one order of magnitude of headroom.

Unused leaf positions MUST be filled with the canonical empty leaf value $𝖦𝖺𝗉𝖢𝗈𝗆𝗆𝗂𝗍(0,0)$. This is non-overlapping with every valid gap encoding because the sentinel set always includes $0$ (see [Sentinel Initialization]), so $𝗅𝗈𝗐=0$ can never appear in a valid gap.

#Sentinel Initialization

Before inserting any real nullifiers, the non-membership tree MUST be initialized with sentinel values that partition ${𝔽}_{q_{\mathbb{P}}}$ into intervals each of width strictly less than $2^{250}$. The sentinel set MUST include the value $0$.

For the Pallas base field ($q_{\mathbb{P}}\approx 2^{254}$), implementations MUST insert 17 sentinels $s_k\in {𝔽}_{q_{\mathbb{P}}}$ at:

$s_k=k\cdot 2^{250},k\in \{\mathrm{0,1},\dots ,16\}.$

This guarantees the width bound required by the in-circuit range checks:

• For $k=0,\dots ,15$, the interval between consecutive sentinels has width exactly $2^{250}-2$.
• The final tail interval has width $q_{\mathbb{P}}-16\cdot 2^{250}-2<2^{250}$.

The width bound is critical for the soundness of the in-circuit range checks. If any interval had width $\ge 2^{250}$, the range check could overflow, allowing a prover to falsely claim non-membership.

These sentinel values are constants defined by this specification.

#Nullifier Domains

A nullifier domain $𝖽𝗈𝗆$ is an element of ${𝔽}_{q_{\mathbb{P}}}$ that defines a double-claim detection scope. Each independent claim context (such as a specific air-drop event, a single poll, or an individual voting round) MUST use its own domain.

Applications MUST ensure that the domain value is unique across independent claim contexts. Two claims that share the same domain and the same underlying note will produce the same alternate nullifier, which is the mechanism for double-claim prevention.

Applications SHOULD derive the domain deterministically by hashing a protocol identifier with an application-specific instance value. The protocol identifier SHOULD be the application's ZIP number, encoded as a little-endian Pallas base field element, which guarantees cross-application uniqueness. The instance value (such as a round or event identifier) ensures uniqueness across instances of the same application.

Applications MAY define their own domain derivation scheme provided it satisfies the uniqueness requirement above.

#Alternate Nullifier Derivation

Given a nullifier domain $𝖽𝗈𝗆$ and an Orchard note with standard nullifier $𝗇{𝖿}^{𝗈𝗅𝖽}$, the alternate nullifier $𝗇{𝖿}_{𝖽𝗈𝗆}$ is computed as:

$𝗇{𝖿}_{𝖽𝗈𝗆}=𝖣𝖾𝗋𝗂𝗏𝖾𝖠𝗅𝗍𝖾𝗋𝗇𝖺𝗍𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾{𝗋}_{𝗇𝗄}(𝖽𝗈𝗆,𝗇{𝖿}^{𝗈𝗅𝖽})=𝖯𝗈𝗌𝖾𝗂𝖽𝗈𝗇(𝗇𝗄,𝖽𝗈𝗆,𝗇{𝖿}^{𝗈𝗅𝖽})$

where:

• $𝗇𝗄\in {𝔽}_{q_{\mathbb{P}}}$ is the nullifier deriving key from the holder's full viewing key.
• $𝖽𝗈𝗆\in {𝔽}_{q_{\mathbb{P}}}$ is the nullifier domain (see [Nullifier Domains]).
• $𝗇{𝖿}^{𝗈𝗅𝖽}\in {𝔽}_{q_{\mathbb{P}}}$ is the note's standard Orchard nullifier, computed as $𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾{𝗋}_{𝗇𝗄}({\text{ρ}}^{𝗈𝗅𝖽},{\text{ψ}}^{𝗈𝗅𝖽},𝖼{𝗆}^{𝗈𝗅𝖽})$.

This is a 3-input Poseidon hash. Using the standard $𝖯\mathrm{𝟣𝟤𝟪}𝖯𝗈𝗐\mathrm{𝟧}𝖳\mathrm{𝟥}$ instantiation (width $t=3$, rate 2), this requires two permutations.

#Properties

Deterministic. The same note in the same domain always produces the same alternate nullifier, enabling double-claim detection.

Unlinkable to standard nullifier. An adversary who observes $𝗇{𝖿}_{𝖽𝗈𝗆}$ and later observes $𝗇{𝖿}^{𝗈𝗅𝖽}$ (when the note is spent on-chain) cannot link them without knowledge of $𝗇𝗄$.

Cross-domain unlinkable. Alternate nullifiers for the same note in different domains are computationally indistinguishable from independent random values.

Collision resistant. Distinct notes in the same domain produce distinct alternate nullifiers, under the collision resistance of Poseidon.

#Security Argument

The security of the alternate nullifier derivation relies on Poseidon being a pseudorandom function (PRF) when keyed with a uniformly random element of ${𝔽}_{q_{\mathbb{P}}}$.

Unlinkability. Model $𝖯𝗈𝗌𝖾𝗂𝖽𝗈𝗇(𝗇𝗄,\cdot ,\cdot )$ as a PRF keyed by $𝗇𝗄$. An adversary who does not know $𝗇𝗄$ sees outputs that are indistinguishable from random. Given $𝗇{𝖿}_{𝖽𝗈𝗆}=𝖯𝗈𝗌𝖾𝗂𝖽𝗈𝗇(𝗇𝗄,𝖽𝗈𝗆,𝗇{𝖿}^{𝗈𝗅𝖽})$ and $𝗇{𝖿}^{𝗈𝗅𝖽}$, the adversary cannot verify the relationship without $𝗇𝗄$. The nullifier deriving key $𝗇𝗄$ is a 255-bit value derived from the spending key and is never revealed on-chain.

Cross-domain unlinkability. For two domains $𝖽𝗈{𝗆}_{\mathrm{𝟣}}\ne 𝖽𝗈{𝗆}_{\mathrm{𝟤}}$, the tuples $(𝖽𝗈{𝗆}_{\mathrm{𝟣}},𝗇{𝖿}^{𝗈𝗅𝖽})$ and $(𝖽𝗈{𝗆}_{\mathrm{𝟤}},𝗇{𝖿}^{𝗈𝗅𝖽})$ are distinct inputs to the PRF. Under the PRF assumption, their outputs are jointly indistinguishable from independent random values.

Collision resistance. If $𝗇{𝖿}_{\mathrm{𝟣}}^{𝗈𝗅𝖽}\ne 𝗇{𝖿}_{\mathrm{𝟤}}^{𝗈𝗅𝖽}$, then $(𝗇𝗄,𝖽𝗈𝗆,𝗇{𝖿}_{\mathrm{𝟣}}^{𝗈𝗅𝖽})$ and $(𝗇𝗄,𝖽𝗈𝗆,𝗇{𝖿}_{\mathrm{𝟤}}^{𝗈𝗅𝖽})$ are distinct Poseidon inputs, so their outputs collide with negligible probability under Poseidon's collision resistance.

#Claim Circuit

A valid instance of a Claim proof $\pi$ assures the following statement.

#Public Inputs

Given a primary input:

• $𝗋{𝗍}^{𝖼𝗆}⦂\{\mathrm{0..}{q}_{\mathbb{P}}-1\}$
• $𝗋{𝗍}^{𝖾𝗑𝖼𝗅}⦂\{\mathrm{0..}{q}_{\mathbb{P}}-1\}$
• $𝗋𝗄⦂𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖯𝗎𝖻𝗅𝗂𝖼$
• $𝖼𝗏⦂𝖵𝖺𝗅𝗎𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖮𝗎𝗍𝗉𝗎𝗍$
• $𝗇{𝖿}_{𝖽𝗈𝗆}⦂\{\mathrm{0..}{q}_{\mathbb{P}}-1\}$
• $𝖽𝗈𝗆⦂\{\mathrm{0..}{q}_{\mathbb{P}}-1\}$

#Auxiliary Inputs

the prover knows an auxiliary input:

• ${𝗀}_{𝖽}^{𝗈𝗅𝖽}⦂{\mathbb{P}}^{\ast }$
• $𝗉{𝗄}_{𝖽}^{𝗈𝗅𝖽}⦂{\mathbb{P}}^{\ast }$
• ${𝗏}^{𝗈𝗅𝖽}⦂\{{\mathrm{0..2}}^{{\ell }_{𝗏𝖺𝗅𝗎𝖾}}-1\}$
• ${\text{ρ}}^{𝗈𝗅𝖽}⦂{𝔽}_{q_{\mathbb{P}}}$
• ${\text{ψ}}^{𝗈𝗅𝖽}⦂{𝔽}_{q_{\mathbb{P}}}$
• $𝗋𝖼{𝗆}^{𝗈𝗅𝖽}⦂\{{\mathrm{0..2}}^{{\ell }_{𝗌𝖼𝖺𝗅𝖺𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}}-1\}$
• $𝖼{𝗆}^{𝗈𝗅𝖽}⦂\mathbb{P}$
• $𝗇{𝖿}^{𝗈𝗅𝖽}⦂\{\mathrm{0..}{q}_{\mathbb{P}}-1\}$
• $𝗉𝖺𝗍{𝗁}^{𝖼𝗆}⦂{\{\mathrm{0..}{q}_{\mathbb{P}}-1\}}^{[𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}]}$
• $𝗉𝗈{𝗌}^{𝖼𝗆}⦂\{{\mathrm{0..2}}^{𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}}-1\}$
• ${𝖺𝗄}^{\mathbb{P}}⦂{\mathbb{P}}^{\ast }$
• $𝗇𝗄⦂{𝔽}_{q_{\mathbb{P}}}$
• $𝗋𝗂𝗏𝗄⦂𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}.𝖳𝗋𝖺𝗉𝖽𝗈𝗈𝗋$
• $𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅⦂𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}.𝖳𝗋𝖺𝗉𝖽𝗈𝗈𝗋$
• $\alpha ⦂\{{\mathrm{0..2}}^{{\ell }_{𝗌𝖼𝖺𝗅𝖺𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}}-1\}$
• $𝗋𝖼𝗏⦂\{{\mathrm{0..2}}^{{\ell }_{𝗌𝖼𝖺𝗅𝖺𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}}-1\}$
• $𝗅𝗈𝗐⦂{𝔽}_{q_{\mathbb{P}}}$
• $𝗐𝗂𝖽𝗍𝗁⦂{𝔽}_{q_{\mathbb{P}}}$
• $𝗉𝖺𝗍{𝗁}^{𝖾𝗑𝖼𝗅}⦂{\{\mathrm{0..}{q}_{\mathbb{P}}-1\}}^{[𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖾𝗑𝖼𝗅}]}$
• $𝗉𝗈{𝗌}^{𝖾𝗑𝖼𝗅}⦂\{{\mathrm{0..2}}^{𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖾𝗑𝖼𝗅}}-1\}$

such that the following conditions hold:

#Conditions

Note commitment integrity. $$ $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼{𝗆}^{𝗈𝗅𝖽}}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}({𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽}^{𝗈𝗅𝖽}),{𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝗉{𝗄}_{𝖽}^{𝗈𝗅𝖽}),{𝗏}^{𝗈𝗅𝖽},{\text{ρ}}^{𝗈𝗅𝖽},{\text{ψ}}^{𝗈𝗅𝖽})\in \{𝖼{𝗆}^{𝗈𝗅𝖽},\perp \}$.

This is identical to the corresponding check in an Orchard Action statement. ⁸

Merkle path validity for $𝖼{𝗆}^{𝗈𝗅𝖽}$. $$ $(𝗉𝖺𝗍{𝗁}^{𝖼𝗆},𝗉𝗈{𝗌}^{𝖼𝗆})$ is a valid Merkle path of depth $𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$, as defined in § 4.9 'Merkle Path Validity' ⁹, from ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}(𝖼{𝗆}^{𝗈𝗅𝖽})$ to the anchor $𝗋{𝗍}^{𝖼𝗆}$.

Value commitment integrity. $$ $𝖼𝗏=𝖵𝖺𝗅𝗎𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗏}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}({𝗏}^{𝗈𝗅𝖽})$.

Nullifier derivation. $$ $𝗇{𝖿}^{𝗈𝗅𝖽}=𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾{𝗋}_{𝗇𝗄}({\text{ρ}}^{𝗈𝗅𝖽},{\text{ψ}}^{𝗈𝗅𝖽},𝖼{𝗆}^{𝗈𝗅𝖽})$.

Spend authority. $$ $𝗋𝗄=𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖱𝖺𝗇𝖽𝗈𝗆𝗂𝗓𝖾𝖯𝗎𝖻𝗅𝗂𝖼(\alpha ,{𝖺𝗄}^{\mathbb{P}})$.

Diversified address integrity. $$ Let $𝗂𝗏𝗄=𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝗂𝗏𝗄}^{𝗂𝗏𝗄}({𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}^{\mathbb{P}}),𝗇𝗄)$ and $𝗂𝗏𝗄\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅=𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅}^{𝗂𝗏𝗄}({𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}^{\mathbb{P}}),𝗇𝗄)$. Then $𝗉{𝗄}_{𝖽}^{𝗈𝗅𝖽}=[𝗂𝗏𝗄]{𝗀}_{𝖽}^{𝗈𝗅𝖽}$ or $𝗉{𝗄}_{𝖽}^{𝗈𝗅𝖽}=[𝗂𝗏𝗄\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅]{𝗀}_{𝖽}^{𝗈𝗅𝖽}$.

Nullifier non-membership. $$ Let $𝗅𝖾𝖺𝖿=𝖦𝖺𝗉𝖢𝗈𝗆𝗆𝗂𝗍(𝗅𝗈𝗐,𝗐𝗂𝖽𝗍𝗁)$ (see [Hash Function]). $(𝗉𝖺𝗍{𝗁}^{𝖾𝗑𝖼𝗅},𝗉𝗈{𝗌}^{𝖾𝗑𝖼𝗅})$ is a valid Merkle path of depth $𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖾𝗑𝖼𝗅}$ from $𝗅𝖾𝖺𝖿$ to the anchor $𝗋{𝗍}^{𝖾𝗑𝖼𝗅}$, using $𝖯𝗈𝗌𝖾𝗂𝖽𝗈𝗇𝖭𝗈𝖽𝖾𝖧𝖺𝗌𝗁$ (see [Hash Function]) at each level.

Additionally, let $x=𝗇{𝖿}^{𝗈𝗅𝖽}-𝗅𝗈𝗐mod{q}_{\mathbb{P}}$. Both of the following range checks MUST hold:

1. $x<2^{250}$
2. $2^{250}-1-𝗐𝗂𝖽𝗍𝗁+x<2^{250}$

These together enforce $𝗅𝗈𝗐\le 𝗇{𝖿}^{𝗈𝗅𝖽}\le 𝗅𝗈𝗐+𝗐𝗂𝖽𝗍𝗁$ over ${𝔽}_{q_{\mathbb{P}}}$, proving that the standard nullifier falls within an interval of unrevealed values.

Alternate nullifier integrity. $$ $𝗇{𝖿}_{𝖽𝗈𝗆}=𝖯𝗈𝗌𝖾𝗂𝖽𝗈𝗇(𝗇𝗄,𝖽𝗈𝗆,𝗇{𝖿}^{𝗈𝗅𝖽})$ (see [Alternate Nullifier Derivation]).

#Circuit Implementation Notes

The first six conditions (note commitment integrity through diversified address integrity) are adapted from the corresponding Orchard Action statement checks. In particular, note-commitment Merkle membership uses ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}(𝖼{𝗆}^{𝗈𝗅𝖽})$ as in the Orchard Action statement. ⁸ Implementations SHOULD share circuit gadgets with an Orchard implementation to minimize new code requiring review.

The nullifier non-membership check requires a Poseidon-based Merkle path verification (29 levels, 30 total Poseidon calls per note) and two 250-bit range checks.

The alternate nullifier integrity check is a single Poseidon hash (two permutations at width 3).

#Spend Authorization Signature

Each Claim proof MUST be accompanied by a spend authorization signature $\sigma$, which is a $𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ signature under the randomized key $𝗋𝗄$ that is a public input to the circuit.

The signature MUST be computed over a sighash that binds the signature to the specific claim, ensuring that it cannot be replayed for a different set of public inputs. Applications MAY achieve this binding directly (by including the public inputs in the sighash) or indirectly (through values that the Claim circuit constrains to be consistent with the public inputs).

The concrete sighash derivation is application-defined. The [Wallet Signing] section specifies a PCZT-based signing flow that reuses the standard ZIP 244 ¹⁰ sighash, enabling compatibility with existing hardware wallets.

#Out-of-Circuit Verification

A verifier that receives a Claim proof $\pi$ together with a spend authorization signature $\sigma$ MUST perform the following checks:

1. Verify $\pi$ against the public inputs $(𝗋{𝗍}^{𝖼𝗆},𝗋{𝗍}^{𝖾𝗑𝖼𝗅},𝗋𝗄,𝖼𝗏,𝗇{𝖿}_{𝖽𝗈𝗆},𝖽𝗈𝗆)$.

2. Verify $\sigma$ as a valid $𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ signature on the sighash (see [Spend Authorization Signature]), under the randomized key $𝗋𝗄$.

3. Verify that $𝗋{𝗍}^{𝖼𝗆}$ corresponds to the Orchard note commitment tree root at the declared snapshot height.

4. Verify that $𝗋{𝗍}^{𝖾𝗑𝖼𝗅}$ corresponds to the nullifier non-membership tree root at the declared snapshot height.

5. Verify that $𝖽𝗈𝗆$ is valid for the current application instance.

6. Verify that $𝗇{𝖿}_{𝖽𝗈𝗆}$ has not been previously accepted in the same nullifier domain. If it has, reject the claim as a double-claim.

#Multi-Note Batching

The Claim circuit defined in [Claim Circuit] proves a statement about a single note. Applications that require proving aggregate balance across multiple notes MAY use the following batching extension. Applications that use the PCZT-based signing flow (see [Wallet Signing]) MUST use the batched circuit, as the dummy signed note (see [Dummy Signed Note]) requires binding to the claimed note slots.

#Batched Claim Circuit

A batched Claim circuit for $N$ notes modifies the single-note circuit as follows:

• The public inputs $𝗋{𝗍}^{𝖼𝗆}$, $𝗋{𝗍}^{𝖾𝗑𝖼𝗅}$, $𝗋𝗄$, and $𝖽𝗈𝗆$ are shared across all $N$ notes.
• Each note $i$ contributes its own value commitment $𝖼{𝗏}_{𝗂}$ and alternate nullifier $𝗇{𝖿}_{𝖽𝗈𝗆,𝗂}$ as public inputs.
• A single $𝗂𝗏𝗄$ (derived from the shared $𝖺𝗄$ and $𝗇𝗄$) is constrained to own all $N$ notes, ensuring they belong to the same holder.
• All $N$ note commitment integrity, value commitment integrity, Merkle path, nullifier derivation, non-membership, and alternate nullifier checks are performed independently per note.

#Dummy Signed Note

When the PCZT-based signing flow (see [Wallet Signing]) is used, the batched circuit MUST include an additional slot for the dummy signed note alongside the $N_{\max }$ claimed note slots. This slot has the following additional public input:

• $𝗇{𝖿}^{𝗌𝗂𝗀𝗇𝖾𝖽}⦂\{\mathrm{0..}{q}_{\mathbb{P}}-1\}$

and the following additional auxiliary inputs:

• ${𝗀}_{𝖽}^{𝗌𝗂𝗀𝗇𝖾𝖽}⦂{\mathbb{P}}^{\ast }$
• $𝗉{𝗄}_{𝖽}^{𝗌𝗂𝗀𝗇𝖾𝖽}⦂{\mathbb{P}}^{\ast }$
• ${\text{ρ}}^{𝗌𝗂𝗀𝗇𝖾𝖽}⦂{𝔽}_{q_{\mathbb{P}}}$
• ${\text{ψ}}^{𝗌𝗂𝗀𝗇𝖾𝖽}⦂{𝔽}_{q_{\mathbb{P}}}$
• $𝗋𝖼{𝗆}^{𝗌𝗂𝗀𝗇𝖾𝖽}⦂\{{\mathrm{0..2}}^{{\ell }_{𝗌𝖼𝖺𝗅𝖺𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}}-1\}$
• $𝖼{𝗆}^{𝗌𝗂𝗀𝗇𝖾𝖽}⦂\mathbb{P}$
• $𝖺𝗉𝗉\_𝖼𝗈𝗆𝗆𝗂𝗍𝗆𝖾𝗇𝗍⦂{𝔽}_{q_{\mathbb{P}}}$
• $𝗂𝗇𝗌𝗍𝖺𝗇𝖼𝖾\_𝗂𝖽⦂{𝔽}_{q_{\mathbb{P}}}$

The following conditions MUST hold for the dummy signed note:

Signed note commitment integrity. $$ $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼{𝗆}^{𝗌𝗂𝗀𝗇𝖾𝖽}}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}({𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽}^{𝗌𝗂𝗀𝗇𝖾𝖽}),{𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝗉{𝗄}_{𝖽}^{𝗌𝗂𝗀𝗇𝖾𝖽}),1,{\text{ρ}}^{𝗌𝗂𝗀𝗇𝖾𝖽},{\text{ψ}}^{𝗌𝗂𝗀𝗇𝖾𝖽})\in \{𝖼{𝗆}^{𝗌𝗂𝗀𝗇𝖾𝖽},\perp \}$.

The value is fixed to 1 (zatoshi) to match the PCZT value used for hardware wallet display (see [Wallet Signing]). The dummy signed note's value does not contribute to the claimed balance.

Signed note nullifier derivation. $$ $𝗇{𝖿}^{𝗌𝗂𝗀𝗇𝖾𝖽}=𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾{𝗋}_{𝗇𝗄}({\text{ρ}}^{𝗌𝗂𝗀𝗇𝖾𝖽},{\text{ψ}}^{𝗌𝗂𝗀𝗇𝖾𝖽},𝖼{𝗆}^{𝗌𝗂𝗀𝗇𝖾𝖽})$.

Rho binding. $$ ${\text{ρ}}^{𝗌𝗂𝗀𝗇𝖾𝖽}=𝖯𝗈𝗌𝖾𝗂𝖽𝗈𝗇(𝖼𝗆{𝗑}_{\mathrm{𝟣}},\dots ,𝖼𝗆{𝗑}_{{𝖭}_{\max }},𝖺𝗉𝗉\_𝖼𝗈𝗆𝗆𝗂𝗍𝗆𝖾𝗇𝗍,𝗂𝗇𝗌𝗍𝖺𝗇𝖼𝖾\_𝗂𝖽)$

where $𝖼𝗆{𝗑}_{𝗂}={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}(𝖼{𝗆}_{𝗂}^{𝗈𝗅𝖽})$ is the extracted note commitment of the $i$-th claimed note slot (real or dummy). This binds the hardware wallet's signature to the exact set of notes being claimed and the application context.

Spend authority. $$ $𝗋𝗄=𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖱𝖺𝗇𝖽𝗈𝗆𝗂𝗓𝖾𝖯𝗎𝖻𝗅𝗂𝖼(\alpha ,{𝖺𝗄}^{\mathbb{P}})$.

This is the same $𝗋𝗄$ shared across the $N_{\max }$ claimed note slots.

Diversified address integrity. $$ $𝗉{𝗄}_{𝖽}^{𝗌𝗂𝗀𝗇𝖾𝖽}=[𝗂𝗏𝗄]{𝗀}_{𝖽}^{𝗌𝗂𝗀𝗇𝖾𝖽}$ where $𝗂𝗏𝗄$ is derived from the shared ${𝖺𝗄}^{\mathbb{P}}$ and $𝗇𝗄$ as in the claimed note conditions.

#Note Padding

To avoid leaking the number of notes a holder is claiming, the circuit SHOULD accept a fixed number of note slots $N_{\max }$ (for example, $N_{\max }=5$). Unused slots are filled with dummy notes (Orchard notes with ${𝗏}^{𝗈𝗅𝖽}=0$).

Dummy notes use the same Merkle path validity check as the standard Orchard Action circuit ⁸: if ${𝗏}^{𝗈𝗅𝖽}=0$, the Merkle path check is skipped.

All other conditions are enforced unconditionally:

• Dummy notes commit to value 0 with a fresh $𝗋𝖼𝗏$.
• Dummy notes are derived from the same full viewing key as real notes (using a distinct diversifier index per slot).
• Dummy notes MUST provide a valid non-membership proof against $𝗋{𝗍}^{𝖾𝗑𝖼𝗅}$. Because dummy nullifiers are random field elements, they fall within an unrevealed interval with overwhelming probability.
• The alternate nullifier is derived and published for every slot. The application verifier MAY ignore alternate nullifiers corresponding to zero-value slots.

#Sub-Circuit Instantiation

When the Claim circuit is used as a sub-circuit of an application-specific circuit, the application circuit has direct access to the private witnesses including the note value ${𝗏}^{𝗈𝗅𝖽}$. In this case, the value commitment $𝖼𝗏$ MAY be omitted from the public inputs if the application circuit binds to the note values through its own mechanism. For example, an application circuit that converts note values to application-specific units (such as vote weight) may bind to ${𝗏}^{𝗈𝗅𝖽}$ directly within the circuit and expose the converted result through its own public outputs. All other conditions of the Claim circuit MUST still be enforced.

#Application Requirements

An application instantiating this ZIP MUST define the following:

• An application hotkey: a key pair generated locally by the wallet, freshly generated per proof-of-balance instance, and not linked to the holder's on-chain Orchard addresses. When the PCZT-based signing flow is used, the output is addressed to this key (see [Wallet Signing]). All subsequent application-level operations use the hotkey in place of the holder's spending key.
• An application verifier: the component that accepts or rejects claims by performing the checks in [Out-of-Circuit Verification]. It MUST maintain a persistent set of accepted alternate nullifiers per domain for double-claim detection.
• A nullifier domain derivation, as specified in [Nullifier Domains].
• An application commitment ($𝖺𝗉𝗉\_𝖼𝗈𝗆𝗆𝗂𝗍𝗆𝖾𝗇𝗍$): a value that commits to application-specific context, included in the rho binding (see [Dummy Signed Note]). For example, a voting protocol might commit to the delegated vote weight and recipient address.
• An instance identifier ($𝗂𝗇𝗌𝗍𝖺𝗇𝖼𝖾\_𝗂𝖽$): a unique identifier for the proof-of-balance instance, included in the rho binding (see [Dummy Signed Note]).
• A sighash derivation: the method for computing the sighash for the spend authorization signature (see [Spend Authorization Signature]). Applications using the PCZT-based signing flow use the ZIP 244 ¹⁰ sighash.

#Wallet Signing

The signing flow proceeds in five steps:

1. The wallet generates an application hotkey on the local device.
2. The wallet constructs a dummy signed note whose nullifier commits to the delegation context.
3. The wallet builds a PCZT containing the dummy signed note.
4. The hardware wallet device signs the PCZT and returns the signature.
5. The wallet extracts the signature and assembles the delegation submission.

Each interaction with the hardware wallet device delegates up to $N_{\max }$ Orchard notes (we utilize the default batch size of 5). A holder with more than $N_{\max }$ notes repeats the flow for each batch, producing a separate application commitment per batch. The holder MAY choose to delegate fewer batches than their full note set, claiming only the balance covered by the delegated batches.

#Dummy Signed Note Construction

The wallet constructs a dummy Orchard note as follows:

1. Address. The signed note's address is derived from the holder's full viewing key at diversifier index 0 with external scope: ${𝖺𝖽𝖽𝗋}^{𝗌𝗂𝗀𝗇𝖾𝖽}=𝖿𝗏𝗄.𝖺𝖽𝖽𝗋𝖾𝗌𝗌\_𝖺𝗍(0,𝖤𝗑𝗍𝖾𝗋𝗇𝖺𝗅)$. A fixed index is used because the address is a private witness inside the ZKP circuit and is never publicly transmitted.

2. Nullifier commitment. The signed note's $\text{ρ}$ is set to the value specified by the rho binding condition in [Dummy Signed Note]. Because the dummy note has no on-chain existence, $\text{ρ}$ can be freely chosen; this design binds the hardware wallet's signature to the exact set of notes being claimed and the application context via the ZKP circuit, avoiding the need for a custom signing protocol.

3. Value. The note value MUST be set to 1 zatoshi (0.00000001 ZEC) in the PCZT, matching the value used in the signed note commitment integrity condition (see [Dummy Signed Note]).

4. Rseed. A fresh random $𝗋𝗌𝖾𝖾𝖽$ is sampled for the note.

5. Note construction. The note is constructed via standard Orchard note construction using the address, value (1 zatoshi), rho, and rseed above.

For fewer than $N_{\max }$ real notes, the wallet pads the remaining slots with zero-value dummy notes at diversifier indices $1000+i$ (external scope) from the holder's full viewing key. These padding notes enter the $\text{ρ}$ commitment via their $𝖼𝗆𝗑$ values but do not correspond to real on-chain notes.

#PCZT Construction

The wallet constructs a PCZT as a single-action Orchard transaction:

#Spend Side

• The single spend consumes the dummy signed note constructed above.
• A dummy Merkle authentication path (all-zero siblings, position 0) is used. The path is not verified on-chain; spend authorization is established by the ZKP circuit.
• The Orchard bundle builder generates the spend authorization randomizer $\alpha$ and the randomized verification key $𝗋𝗄=𝖺𝗄+[\alpha ]G$ internally.

#Output Side

• A single output of 1 zatoshi is addressed to the application hotkey.

• The output memo SHOULD contain a human-readable delegation description. For example, a voting application might use:

  "I am authorizing this hotkey managed by my wallet to participate in {instance_name} with {amount}.{frac} ZEC."

  where {instance_name} identifies the proof-of-balance instance and {amount}.{frac} is the holder's eligible ZEC balance.

#ZIP-32 Derivation

The spend MUST include a ZIP 32 ¹¹ derivation path so that the hardware wallet device can derive the correct spending key:

$𝗉𝖺𝗍𝗁=[{32}^{\prime },{𝖼𝗈𝗂𝗇\_𝗍𝗒𝗉𝖾}^{\prime },{𝖺𝖼𝖼𝗈𝗎𝗇𝗍}^{\prime }]$

where $𝖼𝗈𝗂𝗇\_𝗍𝗒𝗉𝖾$ is 133 for Zcash mainnet.

#Finalization

The wallet applies the PCZT Creator and IoFinalizer roles. The IoFinalizer computes the ZIP 244 ¹⁰ transaction identifier (sighash) that the hardware wallet device will sign.

#Device Display

During signing, the hardware wallet device displays the PCZT as a standard Orchard transaction. The user sees fields such as:

Amount: 0.00000001 ZEC
Fee: 0 ZEC

Orchard
From
#1 0.00000001 ZEC Mine
<shielded>

To
#1 0.00000001 ZEC
{application hotkey address}
Memo: I am authorizing this hotkey managed by my
      wallet to participate in {instance_name} with
      {amount}.{frac} ZEC

The 0.00000001 ZEC amount (1 zatoshi) and 0 ZEC fee confirm that no real funds are being transferred. The "To" address matches the application hotkey address displayed in the wallet application. The memo provides human-readable context for what the user is authorizing.

The hardware wallet device has no awareness of application semantics. It interprets the PCZT identically to any other Orchard transaction.

#Signature Extraction and Submission

After receiving the signed PCZT from the hardware wallet device, the wallet:

1. Parses the signed PCZT and reads the spend_auth_sig field from the relevant action.

2. Recomputes the sighash that the device signed. This is the ZIP 244 transaction identifier computed over the PCZT.

3. Assembles the delegation submission by combining the hardware wallet signature and sighash with the Claim proof and other public inputs. The submission format is application-defined.

The delegation submission is sent to the application verifier. The wallet does not need the hardware wallet device again for the remainder of the usage instance; all subsequent operations use the application hotkey.

#Rationale

#Why Alternate Nullifiers Instead of Actual Spends

The most obvious approach to proof-of-balance (actually spending the notes to oneself at the snapshot anchor) fails because it consumes the notes on-chain. A holder who participates in one application cannot reuse the same notes in a concurrent application. Alternate nullifiers avoid this by operating entirely off the main chain: the standard nullifiers are never revealed, and the notes remain spendable.

#Why Sentinel Initialization

Without sentinels, the initial non-membership tree would contain a single leaf spanning the entire field $[0,q_{\mathbb{P}}-1]$, with width $\approx 2^{254}$. The in-circuit range checks use 250-bit windows (25 limbs of the 10-bit lookup table). An interval wider than $2^{250}$ would allow the upper-bound range check to wrap, enabling a prover to falsely claim non-membership for a value outside the interval.

Sentinels partition the field into intervals each narrower than $2^{250}$ at initialization. Real nullifier insertions only split intervals into smaller ones, so the width bound is maintained permanently.

#Why 1 Zatoshi Instead of 0

The dummy signed note uses a value of 1 zatoshi (0.00000001 ZEC) in the PCZT rather than 0. When an Orchard Action has a 0-value note, Keystone's suppress the display of transaction fields (amount, fee, addresses, memo), presenting the user with insufficient information to make an informed signing decision. Setting the value to 1 zatoshi causes the device to render all fields normally.

The Batched Claim circuit uses the 1-zatoshi value in the signed note commitment integrity check (see [Dummy Signed Note]), matching the PCZT value. The dummy signed note's value does not contribute to the claimed balance.

#Why a Dummy Note Instead of a Real Note

A holder's real Orchard notes are not spent or consumed during delegation. The dummy signed note is constructed specifically for the proof-of-balance flow and never appears in any on-chain note commitment tree. This design has three advantages:

• No fund risk. Because the proof-of-balance transaction is never broadcast to the Zcash mainchain and the signed note has no on-chain existence, there is no scenario in which the delegation signing could result in loss of funds.
• Note reusability. Because real notes are never consumed on mainchain, they remain fully spendable and available for other applications that use the proof-of-balance mechanism. Alternate nullifiers are domain-separated by $𝗂𝗇𝗌𝗍𝖺𝗇𝖼𝖾\_𝗂𝖽$, so the same notes can participate in concurrent proof-of-balance instances without conflict.
• PCZT compatibility. The dummy note reuses the standard Orchard Action structure, allowing the PCZT to pass through the hardware wallet's existing PCZT parser and signer without modification.

#Why the Dummy Note's ρ Provides Non-Replayability

Because the dummy signed note does not correspond to any on-chain note, its inputs can be freely chosen. The design sets ${\text{ρ}}^{𝗌𝗂𝗀𝗇𝖾𝖽}$ to a Poseidon hash of the delegated note commitments, the application commitment, and the usage identifier. Because $\text{ρ}$ enters the note commitment (and therefore the sighash), the hardware wallet's signature is cryptographically bound to the exact delegation context. An attacker cannot replay the signature for a different set of notes, a different application commitment, or a different usage instance.

This binding is enforced by the Batched Claim circuit's rho binding condition (see [Dummy Signed Note]), which the application verifier checks. The hardware wallet device does not need to understand the binding; it is sufficient that the device signs the sighash derived from the PCZT containing the committed $\text{ρ}$. No custom signing protocol is required — the standard Orchard PCZT flow is reused, and all existing hardware wallets that support Orchard signing are compatible without firmware changes.

#Why ZIP 244 Sighash

The PCZT uses the standard ZIP 244 ¹⁰ transaction identifier as the sighash. This is the only sighash format that existing hardware wallet Orchard signing implementations can produce. Using an application-specific sighash would require firmware changes, which this specification explicitly avoids.

The ZIP 244 sighash commits to the full Orchard bundle structure (including the dummy note's commitment, which embeds the bound $\text{ρ}$), providing the necessary cryptographic binding without a custom signature scheme.

#Why Not a Custom Signing Protocol

A future version of this specification could define a custom signing protocol purpose-built for proof-of-balance, rather than reusing the standard Orchard PCZT format. This would require ecosystem-wide coordination (firmware updates to all participating hardware wallets) but could yield several improvements:

• Binding application actions to the signature. Many use cases want to prove balance and take an action in a single step (e.g., casting a vote). A custom signing protocol could commit to the application action directly in the signature, reducing the number of ZKPs required by downstream protocols.
• Removing the hotkey indirection. With a richer signing format, the holder could authorize actions directly from the hardware wallet without delegating to an application hotkey, simplifying the trust model.
• Improved on-device display. A custom format could present application-aware context (e.g., "Vote on proposal X with Y ZEC") rather than the generic Orchard transaction fields shown today.

This specification intentionally avoids a custom signing protocol to maximize compatibility with existing wallets. The trade-off is accepted: downstream protocols may require additional ZKPs or hotkey indirection that a purpose-built signing format could eliminate.

#Deployment

This ZIP does not specify a consensus change. Deployment considerations are application-specific.

The hardware wallet signing flow specified in [Wallet Signing] requires no firmware changes and no changes to Zcash mainchain consensus rules. Any hardware wallet that supports Orchard PCZT signing can participate immediately.

Software wallets that hold the spending key directly do not need the PCZT construction; they follow the same Claim proof specification but sign the application-defined sighash directly.

#Reference implementation

A reference implementation of the Claim circuit (including the non-membership tree, alternate nullifier derivation, and multi-note batching for $N_{\max }=5$) is available at valargroup/voting-circuits.

#Open issues

#References