Wonderful! Thank you for your trust in us. We’re excited to get started.
4 Likes
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
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:
-
Merkle-root of Sapling note commitments,
-
Merkle-root of Orchard note commitments,
-
Merkle-root committing to the gaps of sorted Sapling nullifiers, and
-
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
10 Likes
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
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
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.