ZAIR: Zero-Knowledge Selective Disclosure for Zcash Notes

At a Glance

What it is: A zero-knowledge tool for proving ownership of Zcash notes privately without revealing which note you own, how much it's worth, or its nullifier. 

What it solves: The fundamental trade-off between public accountability (proving you own something) and privacy (not revealing what you own); enables use cases like airdrops, private voting systems, gated access, and stake-based governance, all without compromising the privacy guarantees that make Zcash valuable. 

Who it's for: Zcash users engaging in protocols that require proof of note ownership; chains and protocols designing privacy-respecting incentive and governance mechanisms; builders creating systems where membership or stake matters, but privacy does too. 

Key differentiator: First end-to-end implementation of privacy-preserving selective disclosure, supporting both Sapling notes (which use Groth16 proofs) and Orchard notes (which use Halo2 proofs).

Introduction

Many protocols and incentive systems need to verify ownership before they can grant access or distribute rewards: who holds which tokens, who has staked how much, who owns a particular note. Airdrops are one familiar example, but the pattern extends further: voting systems that weigh power by holdings, gated services based on note ownership, stake-based governance where participation rights depend on what you hold. All of them force the same uncomfortable choice on privacy-conscious users: reveal what you own to participate, or protect your privacy and sit out.

For Zcash users, people who chose privacy as a core principle, that trade-off is especially sharp, and ZAIR is how we eliminate it.

At its core, ZAIR is a system for proving ownership of Zcash notes privately without revealing which note you own, how much it's worth, or its nullifier (a unique tag that marks a note as spent without revealing which note it is). 

As a concrete example, consider airdrops: you prove "I own an eligible Zcash note" without revealing which note, its value, or its nullifier. ZAIR also works for voting systems where voting power is distributed according to owned notes, membership systems that require proof of stake, or any scenario where you need to prove note ownership without exposing your on-chain activity.

Across all of these use cases, the same guarantees hold: the proof is cryptographically binding, you can't double-claim, and the chain verifying it doesn't need to trust anyone. 

This post walks through the design, architecture, and Namada integration.

Why This Matters

Privacy infrastructure is usually thought of narrowly: transaction protocols that hide amounts and addresses. But privacy has edges, and the boundary between private holdings and public participation is one of them. 

If a privacy chain or protocol wants to distribute benefits based on holdings (whether that's tokens, voting power, or access rights), it faces a real problem. These systems are inherently public events, you need to know who claimed what and verify their eligibility. Run it openly and users deanonymize, keep it private and verification becomes untrusted. 

This matters for three audiences: 

For Zcash users: participating in ecosystem incentives, governance, or other note-ownership-based systems shouldn't require revealing your transaction history or spending patterns. ZAIR lets you claim airdrops, vote, access gated services, or participate in governance while maintaining the privacy guarantees you signed up for. 

For new protocols: if you're building on privacy-first principles, you need infrastructure that extends privacy all the way, including to on-chain events. ZAIR is a reference implementation of that idea. 

For builders: creating note-ownership-based systems for privacy communities is currently an unsolved problem. We've published a complete, auditable approach that other protocols can adapt for their use cases. 

The core principle is simple: don't trust, verify, but do it privately.

What We Built

ZAIR lets you prove ownership of a Zcash note with a single zero-knowledge proof, a cryptographic proof that a statement is true without revealing anything beyond the statement itself. Point the CLI tool at your Zcash wallet and it scans your eligible notes across both Zcash shielded pools (Sapling and Orchard) and generates a proof that you own one.

In our Namada integration, that proof is cryptographically bound to a claim intent: who you're claiming as, the amount, and fresh randomness to prevent replays. Integrators can define their own message format, either a universal message reused across every proof or a unique one per proof.

You submit this proof to a chain as part of a claim transaction; an airdrop claim, a vote, a membership assertion, or another protocol-specific application. The chain verifies it and, if valid, credits your airdrop, records your vote, grants access, or processes your claim. No one; not the chain, observers, or anyone else; learns which Zcash note you owned, what amount it contained, or its nullifier. 

ZAIR includes a complete prover/verifier SDK for direct integration into other clients and tooling. For our integration with Namada, ZAIR integrates directly into the standard client, enabling in-memory scanning and claiming of notes as a native protocol feature. To prevent double-claims while preserving privacy, we use domain-separated airdrop nullifiers. A domain separator is a unique prefix string that ensures the same input produces different outputs in different contexts; think of it as a namespace. These airdrop nullifiers are derived from your original Zcash note but use a different domain separator than regular Zcash spending nullifiers, making them unlinkable to your actual spends. The chain can track them to prevent duplicates without linking them back to your identity. 

Zcash holders participating in note-ownership-based protocols or other systems that integrate ZAIR should use this, as should protocols designing incentive and governance structures for privacy-first communities.

How It Works

The system solves several distinct problems in sequence.

The Core Challenge

Standard proof systems are straightforward: prove you own an address, sign a message, claim tokens or access. But Zcash notes are shielded and hidden from the public. You can't prove note ownership the way you would on Ethereum, and revealing your note to prove it means losing privacy. 

ZAIR bridges this gap using zero-knowledge proofs: you prove ownership of a note without revealing the note itself.

The Snapshot

ZAIR starts by generating a frozen snapshot of the Zcash chain at a specific block height, containing the canonical data needed for proofs: Merkle roots of all Sapling note commitments at that height, Merkle roots of all Orchard note commitments, and Merkle roots of the "gaps" between spent nullifiers (more on this below). 

The snapshot is public and immutable, serving as the ground truth that proofs verify against. This is critical: everyone verifying a claim can do so independently, trusting only the snapshot and the proofs themselves, not a centralized verifier.

Proving Non-Membership

To prove you own a specific note without revealing it, you need to prove two things: your note's commitment is in the snapshot, and your note hasn't been spent. The second part is tricky in a privacy-preserving way. Zcash tracks spending via nullifiers, a private tag revealed only when the note is spent. Revealing your nullifier to prove it's unspent breaks privacy, since the nullifier is linkable to you. 

Instead, ZAIR uses non-membership proofs. Take all the spent nullifiers from the snapshot, sort them, and compute the "gaps" between them. If your note's nullifier falls in one of these gaps, it's unspent. The proof verifies that your nullifier falls in a specific gap without revealing it, using a Merkle path to the gap and a range proof showing it's strictly between the boundaries. 

Think of it as a sorted list of people who've exited a room; you prove you never exited by showing your name falls alphabetically between two who did. You're in the gap.

Proves nullifier is not in the spent set without revealing it

Airdrop Nullifiers

To prevent double-claims while staying unlinkable, we derive special nullifiers just for this application. 

For Sapling notes, we replace the standard Zcash_nf prefix in the nullifier PRF (pseudorandom function, the cryptographic function that generates nullifiers from a spending key and note randomness) with the claim target (e.g., Namada_claim). For Orchard notes, we change the group hash domain used to derive the curve point. 

The result is a claim nullifier that's deterministic (the same note always produces the same nullifier for a given application) but completely unlinkable to your actual Zcash spending. The verifying chain stores these nullifiers and checks them on every claim. 

If a nullifier has already been used, the claim is rejected.

The Zero-Knowledge Proof

The actual proof ties everything together. It proves, in zero-knowledge: you own a note (commitment is in the snapshot), the note is unspent (non-membership proof), you possess the spending key for that note (signature verification), and you're making a specific claim with specific parameters. 

How the note's value is proved is configurable. ZAIR supports two modes: the value can be proved as a private commitment, or included as a plaintext value in the proof itself. When using private commitments, the system supports native Pedersen commitments for the respective Orchard and Sapling fields, as well as SHA256 for a unified commitment scheme across both note types. 

While private commitments are more privacy-preserving, many practical use cases rely on plaintext values. Keeping amounts fully private requires careful integration design, for example systems where the verifier can't have a known total amount. Without that, the privacy of committed amounts can break down in practice: if a system has a fixed total and a known number of participants, individual amounts may be inferrable. This matters for fixed-pool distributions and for voting where amounts map to power. 

For Sapling, we use Groth16 proofs: compact and fast to verify, but they require a trusted setup (a one-time ceremony where cryptographic parameters are generated; if the ceremony is compromised, proofs can be forged). 

For Orchard, we use Halo2, which has larger proofs but doesn't require a trusted setup. Both proof systems are cryptographically sound, with different trade-offs in proof size and verification time.

Namada Integration

On the Namada side, we added a new transaction type, ClaimAirdrop. This invokes a validity predicate (a Namada-native mechanism that defines the conditions under which state changes are accepted, similar to smart contract validation logic) called AirdropVP that performs five checks: 

• Nullifier check: Is the claim nullifier already spent? If yes, reject (prevents double-claims). 

• Claim message validation: Is the claim message (recipient, amount, randomness) well-formed? 

• Signature verification: Does the spend-auth signature match the intent message, proving the claimer has the spending key? 

• Value commitment check: Does the submitted commitment to the amount match what's in the proof, binding the proof to a specific amount? 

• Proof verification: Is the zero-knowledge proof valid, tying everything together? 

If all five checks pass, the nullifier is stored (to prevent replays) and the claim is processed. If any step fails, the transaction is rejected and no state changes are committed. 

Note that in the Namada integration, the private commitment mode does not fully hide the value: the amount is leaked in this implementation. The commitment verification was included to demonstrate how an integration could verify commitments if needed, for example in a bridging proof, rather than as a production privacy guarantee.

The recipient address is publicly visible in the claim transaction. In a future iteration, this could be hidden with additional protocol layers (e.g., a shielded recipient address or a commit-and-reveal scheme), but for this implementation, we kept it simple. 

Tradeoffs & Open Problems

ZAIR solves the core problem, but it's not universal. Here are the constraints: 

Performance: Groth16 proofs (Sapling) are smaller and faster to verify but require a trusted setup. Halo2 proofs (Orchard) are larger but don't require one. Users trade off between proof generation time and verification speed. 

Value privacy in practice: Using plaintext values is faster and simpler but reveals the amount. Using private commitments hides the amount in the proof, but the integration layer must be carefully designed to preserve that privacy end-to-end. As shown in the Namada integration, the committed value can still leak. Protocols should evaluate whether their use case benefits from committed amounts or whether plaintext values are the more practical choice. 

Scope: ZAIR is designed for self-custody. It doesn't currently integrate with custodial solutions or exchanges, expecting you to hold a Zcash wallet with viewing keys.

Getting Started

Everything is open-source and documented:

• ZAIR Documentation — Full technical specification, design rationale, and usage guide

• ZAIR GitHub — The tool itself, including Sapling and Orchard proof implementations

• Namada ZAIR Integration (Commitments) — Reference Namada integration

We've tested the system end-to-end and welcome audits, feedback, and further testing. If you're a protocol looking to design privacy-preserving airdrops, the code is a starting point.

The broader principle is simple: privacy shouldn't have boundaries, not at the protocol level or distribution time. ZAIR is proof that you can distribute airdrops and keep the recipient private.