Grant Application - ZEC-NAM shielded airdrop protocol

Community Grants Applications
22

Wonderful! Thank you for your trust in us. We’re excited to get started.

4 Likes
23

I’m enthusiastic about this grant not only because it unlocks a NAM airdrop, but because the underlying research could become for future Zcash mechanisms that we don’t fully know how to build yet.

There are two directions where I believe this work might become strategically important for the community.

1) Deprecation paths for legacy shielded pools
As discussed in the Sprout thread, Zcash will inevitably need to retire old protocols over time. Whether it’s Sprout today, or Sapling pool, the recurring challenge is the same: how do we give users a safe, private and realistic way to “claim” assets from a pool that is no longer maintained?

When I raised this idea earlier (link below), it was just a rough thought, but this grant now makes it feel less hypothetical. A carefully designed “claim by proving private ownership at snapshot height” abstraction could become a standardized exit mechanism for deprecated pools.

@str4d proposed very interesting pathway using ZSA, which I truly like, but it requires those assets to exist.

2) Making coinholder voting more accessible and less risky
I deeply respect the work done so far. We have real progress, but participation numbers show that the current process is still too heavy for most holders. Running nodes, carefully timing for votes and exposing seed to a standalone voting tool is intimidating, especially once ZEC is more valuable. Many holders understandably don’t want to move funds or manage technical risks just to vote.

One idea is to use a shielded snapshot mechanism to mint temporary voting tokens in another network (for example Namada today, or ZSA later). These tokens could represent voting power proportional to shielded ZEC holdings and allow users to vote without touching their actual ZEC, without timing windows, and without exposing secrets to additional software.

This is just a sketch, but the key is separation between ownership assets and governance.

I’m excited to follow the progress, and I appreciate everyone involved for pushing this frontier forward.

5 Likes
24

Dear Zcash Community,

We report on the completion of milestone 1 for the ZEC-NAM shielded airdrop protocol. In this first of four milestones, the focus has been on the Zcash side regarding specification and implementation, closely following the design and discussions from, see [1].

The core functionality in this milestone is the generation of a chain snapshot frozen at a given height to be used as the public parameters for the airdrop. In addition, we have the specification and implementation of airdrop nullifiers, used for protection against airdrop double-claims.

For verifying airdrop claims, the public parameters include for a given height:

  1. Merkle-root of Sapling note commitments,

  2. Merkle-root of Orchard note commitments,

  3. Merkle-root committing to the gaps of sorted Sapling nullifiers, and

  4. Merkle-root committing to the gaps of sorted Orchard nullifiers.

To claim an airdrop, one furthermore needs the explicit nullifier gaps for Sapling and Orchard, to prove a given note was not spent, via a Merkle non-membership proof as described below:

Merkle Non-Membership Proofs

Let S=\{x_1,...,x_n\} be the set of nullifiers sorted by integer value such that

0 < x_1 < … < x_i < x_{i+1} < … < x_n < \textsf{U256::MAX}

Define the complement gaps G_0=(0,x_1), G_1=(x_1,x_2), G_2=(x_2,x_3), … , G_n=(x_n,\textsf{MAX}) as open intervals between values (a,b) such that a and b are excluded. From each gap, we compute a Merkle leaf L_i = H(pp || G_i) given public parameters pp and a hash function H to be fixed later - in the current implementation the pp are empty and H=\textsf{SHA-256}. This naturally defines a Merkle root and standard Merkle-paths used for proving inclusion of a leaf.

A non-membership proof for any nullifier y in the open interval G_i = (a,b) is

(L_i, merklePath(L_i), intervalProof)

Here intervalProof is used to verify the statement a<y<b. The verification of the interval proof together with the Merkle path guarantees a given gap between spent nullifiers is valid for this snapshot, and that the claimed nullifier y was indeed in this gap.

We note the use of 0 and \textsf{U256::MAX} as fixed gap-bounds, which imply nullifiers with these special-case values cannot be used to prove non-membership, and therefore cannot be used to claim airdrops. Further, checking if y is also a valid field element (e.g. y<p) must be done separately. The intervalProof is to be specified in the next phase using appropriate zk-systems.

Airdrop Nullifiers

To guard against airdrop double-claims while ensuring user privacy, we derive deterministic airdrop nullifiers from notes while ensuring unlinkability to later spends on Zcash, see also [1].

For Sapling, we derive airdrop nullifiers like standard Sapling nullifiers, but change the pp prefix used by the outer-most hash function for proper domain separation. In more detail, section 5.4.2 (Pseudo Random Functions) in [2] specify Sapling nullifiers as:

\mathsf{PRF^{nfSapling}_{nk^\star}}(\rho^\star) = \mathrm{BLAKE2s\text{-}256}(\text{"Zcash\_nf"}, \mathsf{LEBS2OSP_{256}(nk^\star)} \Vert \mathsf{LEBS2OSP_{256}(\rho^\star)})

Here we generalize to below, where {targetS} is a fixed public airdrop target chain parameter:

\mathsf{PRF^{nfSaplingAirdrop}_{nk^\star}}(\rho^\star) = \mathrm{BLAKE2s\text{-}256}(\text{"\{targetS\}"}, \mathsf{LEBS2OSP_{256}(nk^\star)} \Vert \mathsf{LEBS2OSP_{256}(\rho^\star)})

For Orchard, we derive airdrop nullifiers like standard Orchard nullifiers, but change the pp preimage used by the hash generating the curve point for proper domain separation. In more detail, section 4.16 (Computing ρ values and Nulliers) in [3] specify Orchard nullifiers as:

\mathsf{DeriveNullifier}_{\textsf{nk}}(\rho,\psi,\textsf{cm}) = \mathrm{Extract}_{\mathbb{P}}\left(\left[\left(\mathsf{PRF^{nfOrchard}_{nk}}(\rho) + \psi\right) \bmod q_{\mathbb{P}}\right] \cdot \mathcal{K}^{\mathrm{Orchard}} + cm\right)

Here the curve generator \mathcal{K}^\textsf{Orchard} is derived as:

\mathcal{K}^\textsf{Orchard} := \textsf{GroupHash}^\mathbb{P}(\text{“z.cash:Orchard”},\text{“K”})

We use the below, where \text{\{targetO\}} is a fixed public airdrop target chain parameter:

\mathcal{K}^\textsf{Orchard} := \textsf{GroupHash}^\mathbb{P}(\text{"\{targetO\}"},\text{“K”})

An airdrop can be set up with any \text{target}S and \text{targetO}, that must be different from \text{“Zcash\_nf"} and \text{“z.cash:Orchard”} respectively.

Implementation

The implementation contains the necessary tools and building blocks to integrate with Zcash, for example generating public airdrop parameters incl. nullifier gaps and resolving note indices.

https://github.com/eigerco/zcash-namada-airdrop/

The implementation primarily consists of two modules:

  • non-membership-proofs: The core library of the implementation. It contains utilities for:

    • Snapshot creation
    • Finding user notes. Takes a viewing key and returns the notes that can be viewed with that key.
    • Create the non-membership proofs

  • airdrop: Orchestrates non-membership-proof functions to provide the necessary functionalities to the users of the airdrop

Summary and Next Steps

In summary, the delivery of milestone 1 marks the primary integration with Zcash as completed, that mainly include snapshot generation, nullifier gaps, locating notes and Merkle-trees.

The next milestone estimated for mid February focuses on using these building blocks to specify and implement the central zero-knowledge proof that a given airdrop claim is valid.

Best regards,

Eiger Co

  1. Status for ZEC-NAM shielded airdrop protocol

  2. Sapling Protocol Specification

  3. Orchard et al. Protocol Specification

10 Likes
25

Dear Zcash Community,

Below is a monthly update on the status of the ZEC-NAM shielded airdrop protocol.

In December 2025, we completed milestone 1, which focused on the Zcash side incl. setting up an airdrop configuration. Since then, we have been working towards milestone 2, which cover the central zero-knowledge proof for claiming an airdrop on the Zcash side. As of late January 2026, we are completing the specification and implementation of the proof for Sapling and shifting our focus to Orchard design and implementation. Full details will be included in the Milestone 2 delivery, but below is a preview of key design considerations:

  • Domain Separating Airdrops: A design choice regards domain separation ensuring airdrops and cryptographic outputs meant for one (airdrop) instance cannot be used for another. For example, airdrops claims made for one target chain (Namada) should be independent of claims made on others, and similarly, a single target chain could arrange multiple independent airdrop rounds. A classical approach is to hash all parameters (from airdrop target height to fields/curves used) and use the resulting entropy to seed primitives. For simplicity, we only use the \text{targetS} and \text{targetO} as domain separation for Sapling and Orchard respectively.

  • Value Binding and Commitment Scheme: The full airdrop claim proof needs to bind value of zcash notes to a value minted on the target chain. To keep a loose coupling for target chains, this can be done as a proof separate from the zcash airdrop claim, as designed by the target chain.
    However, the value commitment scheme often heavily depends on the target chain: A value commitment over one field or curve requires heavy non-native arithmetic to verify in a proof system working over a different algebra, that can blow up the proofs and render them non-viable in practice. For example, for Namada, the minted values work naturally with Sapling algebra, but not with the algebra from Orchard – while another chain may not work natively with either Sapling or Orchard.
    To accommodate a way to claim airdrop proofs without proving non-native curve arithmetic, we instead choose an optional value commitment scheme using \text{SHA-256}. This hash is viable to compute in most modern zk-proof systems, and we plan a proof-of-concept by supporting airdrop claims from Orchard in Namada using this commitment scheme, where-as Sapling support can be done in a more algebraically native way.

  • Orchard Gap Tree: For Sapling we use the natural Pedersen hash in the gap tree. We however note for Orchard, that a natural choice aligns with the note commitment tree for the non-membership proofs (proving a note was not spent) is the Sinsemille hash tree. We however find that a Poseidon-based Merkle Tree may be faster in practice, issuing a trade-off between a more standardized vs performant design.

Summary

In summary, milestone 2 is underway and is expected in February 2026, focusing on the central zero-knowledge proof for an airdrop claim. The Sapling proof specification and implementation is currently under review, while our focus has moved to the Orchard proof implementation.

During this second phase, we made concrete design decisions covering simplified domain separation, value commitment schemes and concrete Merkle Tree definitions as described above. We welcome feedback these decisions ahead of the February milestone delivery, where we will present the full details.

Best regards,
Eiger Co

6 Likes
26

Will you need to do a MPC to generate the sapling parameters for your circuit? If so, would a different MPC be needed for each airdrop ?

Thanks

27

Thanks for the great question!

Yes - a new Groth16 setup is required for Sapling airdrop claims as the circuit differs from the original Sapling spend-circuit. This setup must be derived in a trusted manner (e.g. via MPC).

And yes - new circuit parameters for Groth16 are currently needed for each airdrop configuration, given we hard-code the personalization tag \{targetS\} into the circuit.

Our design reasoning: There a pros and cons, and we did review a construction with \{targetS\} as public circuit input instead as to obtain fixed circuit/parameters. However, this may add overhead/constraints and begs to ask the question: Who will organize these universally trusted airdrop-parameters? We answer this by requiring the target chain to organize it, noting the target chain already have a degree of trust in designing/distributing the airdrop more generally, while also allowing a smaller and/or customized circuit e.g. useful for binding Sapling to Namada. The proof could be adapted in the future if global trusted airdrop parameters are preferred and organized, noting this will limit target chains wanting a single custom (Groth16) proof.

28

Dear Zcash Community,

We report on the completion of milestone 2 for the ZEC-NAM shielded airdrop protocol. In this second of four milestones, the focus has been on concluding the Zcash side, in particular the central zero-knowledge proof for ownership of eligible notes. Our construction is described in more detail in the published documentation [0] and repository [1], and we welcome and appreciate testing and feedback! We note that this phase has focused on completeness and not soundness.

The presented system consists of a zair tool for shielded Zcash airdrops, supporting both Sapling (Groth16) and Orchard (Halo2) proofs. This tooling, among other things, supports the main airdrop flow:

  • Generating an airdrop snapshot
  • Proving ownership of eligible notes
  • Verifying ownership of eligible notes

This is designed to keep the note value, position and the Zcash nullifier private, where-as double-claims are prevented by deduplicating domain-separated airdrop nullifiers.

As described in the documentation, this involves design-choices for snapshots, domain separation, non-membership Merkle-proofs and a custom SHA256 commitment scheme for interoperability. Further, we bind the proofs of eligible notes to an intent message via a pool-specific signature (Sapling/Orchard), that will be used to bind the proof-of-ownership to the airdropped amount.

Going forward, we focus on the next phase and milestone 3, where we will showcase the zair tooling by integrating an airdrop for Namada.

Best regards,
Eiger Co

[0] Introduction - ZAIR documentation
[1] GitHub - eigerco/zair: Zcash airdrop utility

3 Likes
29

Dear Zcash Community,

We are pleased to announce the completion of milestone 3 for the ZEC-NAM shielded airdrop protocol. In this third milestone, we demonstrate the zair tooling in action through a concrete integration with Namada. The implementation is described in our documentation[0] and available in our repositories[1][2], with feedback and testing welcome.

The integration introduces a new ClaimAirdrop transaction type to Namada, which invokes a custom validity predicate called AirdropVP to verify ZAIR claims. The verification process takes place across several stages:

The predicate validates airdrop nullifiers to ensure they have not been previously spent and are properly persisted to storage.

  1. It checks that the claim message - including the recipient address, claim amount, and randomness - is correctly formed.

  2. The signature verification uses ZAIR’s public API to compute a digest and confirm the spend-auth signature, thereby establishing that the claimant possesses the corresponding spending key.

  3. The SHA256 value commitment is validated by recomputing the hash from the amount and randomness fields and comparing against the submitted commitment.

  4. Finally, the zero-knowledge proof is verified through ZAIR’s standard zero-knowledge verifier API.

Upon successful validation, the claimed tokens are transferred to the target address and the nullifier is stored to preclude any future double-claims. Should any verification step fail, the transaction is rejected and no state changes are commited.

For this implementation we choose to reveal the following private inputs, rcv and amount. Additionally we reveal the target address on Namada, as an illustrive example of ZAIR integration. For milestone 4, we’re considering a plaintext commitment scheme that would reveal these directly within the ZAIR claim proofs, for use in applications where full secrecy is not needed.

We note that further work could integrate ZAIR with the shielded MASP pool by introducing an additional bridging proof, proving the correct derivation of the ZAIR commitment value from the native MASP sapling zero-knowledge circuit.

With this milestone complete, our efforts now turn toward milestone 4, which will finalize the full ZEC-NAM end-to-end airdrop workflow.

Best regards,

Eiger Co

[0] Integration: Namada - ZAIR documentation

[1] GitHub - eigerco/zair: Zcash airdrop utility

[2] GitHub - eigerco/namada: Namada ZAIR integration

6 Likes
30

nice work team. really impressive

31

Dear Zcash Community,

We are pleased to announce the completion of milestone 4 for the ZEC-NAM shielded airdrop protocol. In this last milestone, we have focused on end-to-end testing, polishing and delivery of the zair tool and the Namada integration.

Notably, this last phase includes plain values, that allow users to reveal the note amounts for each note claimed, rather than a commitment to the note values. This functionality is particularly useful for simpler integrations where revealed plain values are acceptable, and we show how to integrate this into the Namada chain allowing much faster airdrop claims avoiding the heavier unified SHA-256 value commitment.

Furthermore, the last phase includes an end-to-end modification of the SDK for a more direct integration hence avoiding managing files and seeds on disk.

As usual, we welcome feedback and testing, with our tooling available at:

This final phase concludes the deliverables of the ZEC-NAM shielded airdrop protocol project. For further extensions and phases to the tooling, we propose possible directions:

  • Security audit of the main zair tooling and zk-proofs.
  • Support for claiming airdrops requiring only the viewing key.

Best regards,
Equilibrium Co

8 Likes