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.
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.
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
not give the possibility of a marketplace transfer to be linked to the on-chain transfer
selling an NFT only if you really are the owner at that time (and cannot double-spend)
Maybe there needs to be two proofs of ownership:
one for the onbaording of the asset onto the marketplace
another one for right before the sale is final
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
the jpeg/mp3, etc… which can be uploaded by the user or from IPFS
the proof of validity with reference to the public data on chain (or at least an easy way to verify its connection with the Zcash state)
the time / block of last verification of ownership (not nullified asset)
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.
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.
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.
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.
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.
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.