Agreed on both counts. We will publish a blog post explaining the process in full along with code (once ready), and the code will be internally & externally audited and subject to a public bug bounty before we recommend that anyone use it. Before spending a lot of time implementing and auditing, however, we wanted to check in with the Zcash community - so in that spirit, let me explain briefly how we plan for the shielded airdrop to work (also answering @bloxster and @miodragpop’s questions, I think):
We plan to do an interactive, privacy-preserving shielded airdrop. It will be interactive in the sense that users have to make a proof to claim it - as you intuit @miodragpop, a non-interactive privacy-preserving airdrop, at least of the non-interactive sort common in Ethereum-land (ERC20 tokens sent to an address), is not possible because Zcash shielded notes are known only to their owner (and anyone with the viewing key). Our proposed airdrop mechanism consists of two parts:
Part of the Zcash network state is copied over to Namada. In particular, we would copy the note commitment tree and the nullifier set (and some information for transparent accounts, but that part works like regular transparent airdrops). These note commitments and nullifiers will be combined with the note commitments and nullifiers for Namada’s MASP, such that users who held ZEC on Zcash will also hold “ZEC” on Namada (let’s call this ZEC’ - to be clear, this is unrelated to ZEC which might be bridged in the future).
Namada would add an entry to the convert circuit which allows users holding this ZEC’ to convert their ZEC’ to NAM (Namada’s native token) at a fixed rate. This conversion will require a proof, and the created NAM will still be shielded (basically like a shielded-to-shielded transaction, but with different input and output assets). After that, users just have regular NAM in the shielded pool, which they could send, unshield, unshield & stake or send elsewhere, etc.
I think the privacy properties of claiming this airdrop should be basically equivalent to the privacy properties of privately spending a Zcash note you own on a fork of Zcash (e.g. Ycash) - the same nullifier is revealed, so if you spend on both chains an observer can see that someone both spent on Zcash and claimed the airdrop on Namada, but they don’t learn any more information than that. Of course, you still might want to be careful about timing and linkage as outlined in ECC’s blog post.
This topic deserves a comprehensive write-up (which we plan to provide in due time ), but I hope this summary gives a basic intuition.
I see potential for needing various protocol features to play well together which are being developed by different teams.
For example, depositing NAM into a future Sustainability Fund would need: the fund itself (thus Shielded Labs support, cc @aquietinvestor), and ZSA support (thus Qedit, cc @LeCryptoMath), and a good bridge support (thus ECC, cc myself), and these three different protocol features would need to be well integrated.
The go-to coordination point for cross-org protocol development is Arborist Calls and Zcash R&D Discord on one the realtime/conversational end, then on the very-nailed-down side we have ZIPs. The Zcash community needs better coordination on everything in between, including upgrade planning, one or more proposed “tech trees” (a DAG of protocol feature dependencies), and a good venue for long-form asynchronous technical collaboration (perhaps the Zcash R&D category on this forum).
I’ll bring up the need for more planning/collaboration tools on the next Arborist call. Hope to see Anoma there!
I assume zolders using hardware wallet will be receiving lesser amount of the airdrop compared to hot wallet zolder that able to shield their zec?
So I assume the airdrop proposal is considered an encouragement for cold wallet users to switch to hot wallet in order to shield their zec and get more airdrops? Some risk involved for certain users in transferring funds between cold & hot as none of hardware wallets supports shield zec yet.
Cold wallet support is possible right now with Ywallet which is currently the best Zcash wallet (a “cold” phone is required as the offline component).
I think anything that encourages more usage of the shielded pool is a good thing, plus I’m also eagerly awaiting the day we can use the shielded pool with standard hardware wallets.
With regard to the questions in this thread, it’s refreshing to see teams recognising the huge amount of effort that has gone into Zcash.
I love the idea of allowing teams to “give back” via the sustainability fund. I think airdrops are a good way to reward holders. And the more bridges to different protocols the better.
To be clear, our intention is not to encourage anyone to move their assets from a wallet they think is more secure to one they think is less secure - I don’t think that’s worth doing for any airdrop. The idea is mostly just to give back to ZEC holders who have contributed to the shared privacy set (which I understand may have been difficult to do if proper hardware wallet support wasn’t in place - hope that’s rectified soon!)
Dumb question. If a namada <> zcash bridge was built, could that bridge support the transfer of multiple asset types?
I.e. I have wBTC in the namada shielded pool, but want to move it to Zcash for whatever reason, could I do that?
Thinking about this while watching this talk from Zcon4.
I assume “yes” based on this comment from the bridge sketch.
“The user creates a transaction sending however many ZEC (or another asset) they would like to bridge to the z-address generated from the FROST threshold multisignature key…”
If (and when) Zcash implements ZSAs - in principle, yes!
(btw as a general note: we are currently working on the technical infrastructure required for the shielded airdrop, and finalizing some other stuff such as the Namada ledger app - more details soon!)
), but I hope this summary gives a basic intuition.
