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.
TLDR; we should consider only allow for a single issuance of assets at asset creation time. My understanding of the issuance discussion was that allowing for multiple issuance calls was one of the likely options. That might be the best option but I want to make sure the team has thoroughly thought through if there are actually any benefits or if we are just complicating ZSAs for the sake of having nice sounding “issue” function.
It might be better for users to issue large amounts of assets at ZSA creation and disperse them as needed from a single/multisig address.
There are a few concerns I have with multiple issuance:
How does an owner of “wrapped Bitcoin” transfer the issuance keys to a new owner?
We can barely trust certificate authorities to never leak private keys let alone a $1B wrapped Bitcoin asset.
It adds extra consensus rules
There’s a meaningful amount of work for providers, exchanges, explorers, wallets, developers, and users to adapt to the idea of multiple issuance.
When we implement DAOs we have the extra complexity of DAOing transfers AND issuance.
How does burning work?
Single issuance answers a few of these questions:
An owner of “wrapped Bitcoin” can transfer the remaining issuance holding to a new owners address.
If the owner of “wrapped Bitcoin” was worried about the safety of their private keys (e.g. hardware lost/compromised) they can transfer assets to new address (with their backup).
Single issuance during asset creation simplifies implementation of ZSAs and reduces surface area for attack/audit.
Single issuance would mean explorers/wallets don’t have to worry about the UX concerns of multiple issuance.
Zcash DAOs might be simpler to implement if only having to deal with transactions and not issuance.
In most cases sending an asset back to the asset disperser/DAO would be equivalent to a burn.
Unfortunately we don’t have DAO like structures yet but I imagine sometime in the future we have something similar to ZSA-addresses.
I feel like multiple issuance adds unnecessary complexity to implementing DAOs. For example could a ZSA-address control issuance?
Reflecting on my reply if we were to have multiple issuance we need to make sure we implement burning correctly. If we advocate issuance should be transparent (in some way) we should have a native (and simple) transparent burn too.
I very much agree with the idea of keep it simple and I share your worry things will get complex. But I think its needless complexity we can eliminate and I think single issuance in the way you suggest would actually result in more work.
Each ZSA requires an identifier. The simplest way to do that is have it be the hash of the public key you sign the issuance statement with. Absent adding global state keeping and consensus rules, that allows unlimited issuance. (Ideally, we’d support keys and sigs people can already custody in hardware)
The easiest way to allow single issuance would be to support the same signing key as identifier trick, but append/prepend the blockhash its issued in before hashing.
Moreover, I suspect multi issuance is a key thing if you wanted to have, for example, shielded tether. The alternative would end up hurting privacy: whenever tether wanted to issue more, they’d have to make another distinct ZSA. This is a fungibility and privacy issue.