We at Heliax, team working on Anoma and Namada, are investigating how to execute a shielded airdrop of NAM (native token of the Namada chain) to ZEC holders. We are developing airdrop tooling for users holding assets on the Sapling chain value pool, and investigating the legal requirements for including Orchard pool as well. We aim to design a process that requires a low-effort UX from the ZEC holder side.
The Sapling protocol is the original basis of our Multi Asset Shielded Pool (MASP) design, and as a result of this the two protocols are quite compatible. A Sapling note and a MASP note differ only in the presence of a note type in the latter. The presence of types in MASP notes allows for a burn-and-mint like process, in which notes type can be effectively changed. This conversion is carried on by the convert circuit, which operates as a generalization of the balance check done in the Sapling protocol. The convert circuit can take a Sapling note value commitment as input, and be used to transform a Sapling note into a MASP note.
The process flow of the airdrop would be:
- ZEC holders would input in the Namada airdop tool information about their ZEC holdings.
- The airdop tool would help the ZEC holder craft a transaction that has a Sapling spend description and a MASP output description (which involves generating Namada keys).
- This transaction would be submitted to and validated by the Namada chain (or some offchain host process which would aggregate and later submit to the chain).
- Users would receive they NAM reward in their new Namada wallet.
We would like to discuss with the Zcash community about how to go about step 1 above. The effort from the Zcash user point of view can increase on a spectrum:
- ZEC holders input their Incoming Viewing Key and nullifier deriving key nk. From that, the airdrop tool can perform a blockchain scan (as described in the ZCash specs on 4.21) to obtain all the unspent notes that have the relevant address as recipient.
- ZEC holders input their Full Viewing Key and the transaction description that they know has them as recipient. The airdrop tool would then decrypt according to zcash specs 4.19.3.
- ZEC holders input all the information needed to create an Spend Description about a note they are in possession “by hand”.
The first approach is more user-friendly for the Zcash users, but requires an expensive blockchain scan. The second approach is more heavy on the UX, but more efficient. The third approach is the most expensive for the Zcash UX, and we could use for a proof of concept prototype, but do not envision for a product.
Given the current Zcash wallet ecosystem, which approach makes more sense to you?