Agreed. I think this is the obvious decision so hopefully doesn’t need much debate but if the debate needs to be had we can extend the conversation.
But the short version is from a security perspective allowlist > denylist. On-chain strings are more likely to require a denylist then off-chain strings. We want to prevent the need for a denylist whenever possible.
Thanks for the response Daniel,
Per this approach, would the user need to take an action every time they need to disclose portions of information on to interested parties? e.g. Consider a 1 of 1 token minted as a NFT having some meta-data. Will the user need to take additional action manually, every time they need to disclose the meta-data to a custodial third party or a smart contract for publicly displaying the content?
If this is the case, it would be difficult to develop a Opensea like platform for zNFTs for the sheer amount of processing power required to access encrypted information via viewing keys for each asset, think 10,000 PFP project.
Ideally, if possible, we could have the “public facing data” benefits of a NFT
i.e. 1) the IPFS image/video/3d file link,
2) the minting policy signed by the creator, and
3) a flexible JSON to define category/rarity/description of the NFT all attached to a new field in the transaction type which will be public by default while still shielding the sender & receiver of the transaction.
This feature will allow public lookup of info for each asset while still keeping the privacy of the holder, sender and recipient.
@ml_sudo @Souptacular @Shawn
Would be fantastic to approve the first couple of milestones to allow Qedit to start working on this.
As a community we have been crying out for good teams, with good proposals to fund through the ZOMG. We couldn’t ask for a better team or a better grant.
Would be excellent if we can make life easy for them and let them get to work!
I also tend in this direction, it makes a lot more sense to free Zcash from land-grabbing mentality, and having an external registry for tracking assets and issuer’s identity makes the on-chain protocol design simpler (though not easy 
)
I am not sure yet what the “proof of ownership” mechanism would look like that would not reveal any transaction (this is critical), but I am positive that it could be somewhat automated through a wallet interface (e.g.: once you receive an NFT-type asset, the wallet generates a proof of ownership for block / epoch X).
The key here is that an NFT market place for zNFTs should
Maybe there needs to be two proofs of ownership:
Or maybe the proof will be automatically generated (with a confirm button) every day or every few hours. And the proof of ownership would look something like the Sapling spend circuit, but now potentially adapted to Orchard-ZSA.
In that sense, the metadata of the asset should show
What do you think about taking a vote on funding the first couple milestones now, with a requirement that the vote be unanimous among the three current zomg members? This way we can be sure that the milestones would have been approved even if there were still 5 members.
It seems this is one of most popular grant proposals yet, and @LeCryptoMath is eager to get started.
Just to be clear, all of the current “skeleton crew” ML, Hudson, and myself are in favor of funding this project.
We discussed approving it but felt that the sheer size ($1M+) of this Grant deserves a better approval process than a simple majority of two people. It’s not a project issue, it’s a ZOMG process issue.
Imagine if we did have a dissenting vote now, theoretically two of us could be a majority and we could push the approval through. But what precident would that set? When the community voted to approve a 5 member ZOMG committee via ZIP-1014 did they envision a skeleton crew where only 2 of 5 could push through an approval to spend over $1M? That could be very dangerous for unexpected situations like the one we have now, or if a ZOMG member were to suddenly quit mid-term, or if a member was very strongly opposed, etc…
ZOMG set a voting threshold for ourselves to try to push for unanimous vote 5/5 of a grant larger than $100k. The members present and voting thresholds we set were : 3/5 for under $20k, 4/5 for up to $100k, 5/5 for anything above $100k. This is to cover situations where a member is sick or not available to vote and to avoid simple majority overrule for large grants. The next ZOMG could choose to move those thresholds up or down if they want.
In this situation we would be effectively approving the entire amount and making the decision for the next ZOMG. I think that by approving now (even a first few milestones) we set a team in motion and set the communities expectations that the project will be completed. The next ZOMG may want to set thier own milestones or expectations for deliverables when they review the grant application. A partial approval now would short circuit that process.
I know lots of people are anxious to get this going, I just ask that you keep in mind the bigger picture of $10s of MMs that ZOMG will be charged with distributing for the community in the future.
We only have a few weeks left in this year, I fully expect the new ZOMG to be in place and ready to start discussing Grants by mid-January. After the election the new ZOMG could even call for an emergency session (rather than wait for the normal 2 week cadence) to hold a vote.
Hey Shawn, thanks for the thoughtful reply. I wasn’t aware of the process norms set by first committee. It makes sense and I understand why you guys made the decision in that context.
Thank you @Shawn for the detailed and thoughtful response.
We totally understand the situation and we are looking forward to hearing from the next committee.
Also, thank you for the amazing work and ground-setting rules and framework that you built this past year - your work will impact the community for years to come!
Hi @LeCryptoMath,
Would your team be interested in building products / protocols that enhance & leverage ZSA capability after this proposal is successfully executed? For example, Zswap, allowing anyone to swap in a permission-less fashion without relying on CEX. Ex-ZF engineer’s Penumbra project is building stuff in this space if you want some reference.
Reasoning: Adding Utility to ZSA.
Thanks.
So earlier in the topic I discussed some issuance mechanisms that might be useful. One of these included on chain voting…
After further reflection it appears we can think of issuance as simply a transaction rather then a specific issuance mechanism. We could have ZSA addresses where assets in a ZSA address are collectively controlled by the token holders.
So rather then having the ability to mint/issue new tokens over a period of time, the asset is minted only once. Someone might simply mint billions of tokens upfront. Then to protect the tokens from malicious action from a single user the tokens are transfered to a DAO (ZSA address) which allows the holders of those ZSA (could be 1 or many) the ability to transfer those tokens by voting.
While I imagine on-chain voting is outside the scope of this grant it does seem to allow, in some form, for many of the issuance mechanisms described to occur. Also, since a DAO could be automatically controlled by nodes these nodes could watch other chain addresses and control assets accordingly.
Hi @LeCryptoMath,
I am thrilled to announce that the @ZcashGrants has officially voted to approve this grant with the conditional requirement that the team posts monthly updates throughout the life of the grant.
Wonder if ZOMG can hire contractor to keep all funded projects in check, figuring out concerns, checking status & posting updates.
Hypothetically, if we needed to, we could use the discretionary budget to hire a contractor for this. However, right now the plan is for @decentralistdan to handle these responsibilities as part of his role as the Ecosystem Relations Manager. I think he will do an awesome job at it.
Amazing, congrats to all!
Thank you @decentralistdan for the news!
We are very excited to get things started. It will take us a couple of weeks to truly get going (as the team gets freed from previous commitments), but we are starting to imagine how the interaction with the community will look like, to ensure that we gain consensus on the feature’s usability and applications.
And of course, we will post monthly updates to the forum, and most likely more than just monthly as we hope to interact often with the community (at least in the first few months of the project).
Please do let us know how to move forward with the formalization of the grant and KYC requirements? Feel free to email me the details if it is easier.
Let’s build these shielded assets!!!
I love it.
Will be the cover of the kick-off post in a couple of weeks jaja
I wouldn’t expect that the zcashd and Zebra implementations have to be completely independent. A lot of the Rust libraries can be shared; Zebra already shares the circuit code in zcash_proofs, for example.
Going live on TwitterSpaces in 50minutes!
Congratulations to the QEDIT team!