How to airdrop shielded asset to ZEC holders


Is it technically feasible / possible to airdrop ZSA token to every Zcash holder? cc @LeCryptoMath @str4d

I’m interested in airdropping tokens to ZEC holders.For example:

  1. The older your t-address is more ZSA you can claim
  2. All z-address get ZSA amount proportional to their holding.



Such as the ECC Agoric BLD tokens?

Nope. It will be a new token inspired by successful airdrops like SOS. I’m super interested in this!!


There seems to be a fundamental misunderstanding of shielded transactions and addresses in this question. So maybe someone smarter than me can clarify.

For #1, you can get the balance of every transparent address, but for #2, you can’t even get the set of all shielded addresses… and even if you could do that, you wouldn’t have the fvk to calculate the balance for every single shielded address.

I thought this was the beauty of sapling/shielded? We don’t get spam to our shielded addresses. On ETH and BSC spam coin from drops are out of control.

For your #1 it also seems a little odd that the transparent hodler use case is somehow more valuable than the shielded hodler or even folks who actually transact in zcash. Kinda moot at this point but just giving my opinion.

Unless I’m misunderstanding something, either 1) folks would have to opt-in somehow to reveal the portion of their stake that they wanted to apply toward a drop OR 2) there’d have to be some proof of position ownership mechanism at a certain point in time. I think this was discussed in other threads regarding shielded stake-weighted voting.

I might be missing something though

1 Like

Great points. I’m not proposing solutions. I’m poking intellectual minds to come up with a general privacy-preserving solution, that might lead to architectural changes to the way Zcash works.

1 Like

What about dropping to notes? You couldn’t weight it by amount yet each note spend could specify a specific block checkpoint, instead of a recent one with its full privacy offerings, to prove historic existence and add an additional OP_RETURN output specifying a transparent address to redeem coins to. Since this operation only costs the TX fee, no privacy is leaked since a new note is immediately created and usable with the full privacy set.

This works for colored coins as described, where OP_RETURN outputs are used as an additional TX DAG. For ZSAs specifically, you could specify a shielded address and then have a central server execute the airdrop. This would place a shielded address on chain though, which has relevance to the recently posted quantum computing thread.


You kinda lost me at this part. So, someone with 1000 ZEC distributed on 1000 notes is better off than someone with one 1000 ZEC note? The former would get a bigger airdrop? That seems gameable.

Also, tbh I didn’t understand your ZSA specific suggestion (it seemed to me like you were crossing wires with what can be done with shielded notes vs transparent eg p2sh)… maybe it’s just me though.

I guess if your suggestion makes more sense than what I got, then others might be able to comment too. :grinning:

I think its possible. I could probably make a really cheesy demo on top of something like BabyZoE if it helps. Basically the way i would think of it is, you would be defining a new kind of nullifier associated with each note. You can think of the nullifier as like hash(tag, noteSecret). Then to claim the airdrop, it would be similar to an unshielding transaction, just with the new nullifier instead, hash(tag2, noteSecret). This way the airdrop claims are completely separated from other uses of the note, but the value can be used to weight the airdrop claim


I like cheesy ELI5 demos :smiley:

1 Like

I also would advocate for these kinds of minting strategies but I’m doubtful either of these would be included in ZSA v1. My understanding is v1 will only allow for minting on transparent addresses only. We are also yet to verify if we can airdrop based asset allocation of another asset (E.g. zcash).

There may also be a few complications that may need to be addressed with regards to shielded minting like auditablity of tokens etc. For example once asset has a shielded “mint” the total number of assets may be unknowable. While freedom to do these kinds of asset allocations would be awesome we also need to have a pretty in-depth discussion about what we want the ZSA ecosystem to look like.

This isn’t completely true because presently we do know how many ZEC exist in each pool. So if we were to airdrop to all ZEC holder in a pool we know the total assets required.

My personal view is we may want to keep the minting actions simple and only to transparent addresses and allow for more complex transactions.

For example:

  • Weighted transfer of 1,000,000 of an assets to all ZEC holders.
  • Weighted transfer of 100ZEC worth of dividends to all holders of asset.

I didn’t read the OP very carefully, reading again I see it’s about future ZSAs in Zcash proper (which will have a different design space), whereas I’ve been trying to answer the related question: could an entirely separate project (a friendly fork?) create an airdrop to ZEC shielded pool holders?
So anyway, yolo, this is work-in-progress but I won’t be able to take it any further for a week or so
There’s not a whole lot to it, it’s a clone of the TornadoCash circuit, except that the nullifierHash function is replaced with a different function airdropifierHash that just uses different generators.
tornado-core/claimairdrop.circom at snarky-airdrop · amiller/tornado-core · GitHub
It should be possible to demo this by minting an airdrop to the TornadoCash shielded pool on testnet or something


This is a correct analysis and why this idea is flawed. You could also force revealing the amount of the note while you’re at it, also via OP_RETURN to include the keys, but…

Very interested in amiller’s work though.

1 Like


[It’s quite possible new zkp L1s that are popping up might want to airdrop their token to ZEC holders in shielded pool. It’s a neat way to acquire users! I’m glad you figured high-level design for the problem you originally thought of]

I’m more interested in native ZSA airdrop to a shielded pool. Claiming process could reveal some information but based on what you said, my gut feeling says this can be done in privacy-preserving manner!

Is it possible to build a demo with str4d code for ZSA to create airdrop on Zcash Testnet?

Just found your previous tweets: