I’d like to start off by thanking you all for the discussion here! It was great to hear the support and dig together into the concerns. The different perspectives here help create better proposals.
This discussion goes together with a grant proposal - we had a draft with ideas presented here, so we can hear from the community and to better inform us on the goals. We recently submitted the grant proposal for this effort, which you can find here. We have updated the timelines and the budget in this proposal on the basis of the discussions raised in this thread and in our conversations with the Grants Committee and others. The main updates are:
A focus on first getting ZSA ready for merge, by prioritising Zebra work for the ongoing grant and having Asset Swap implementation lined-up next.
We have also proposed a dedicated compliance advisory effort in preparation for ZSA deployment.
A lowered budget and initial scope for each milestone to allow the Grants Committee more budget flexibility.
We broke the milestones into a smaller research phase, with checkpoints to allow the Grant Committee to make ongoing decisions whether to develop specific features in the grant.
We think the features discussed in this thread are very important for the future of the Zcash ecosystem, and as always, we look forward to hearing from you!
After talks with the ZCG, we are revising the current grant proposal as follows.
We will be working on the Research and ZIP Design portions of the proposal:
Verifiable Encryption, Enhanced Keys – Research and ZIP design
Transaction Acceptance and User Control – Research and ZIP design
The estimated delivery is December 2024, budgeted at around $85k per month.
This work will allow the Zcash community / ZF / ECC to provide early feedback on the design of these important features. We already have some ideas and early drafts in mind, and we’re excited to share them with you!
It would be nice if you could breakdown and explain this value in details.
Because, at first glance, $85/month or $510.000* a.k.a half a million dollars looks insanely overpriced for researching and writing a document (a Zcash Improvement Proposal in this case).
Hi James, this phase covers 3 milestones (1.1, 1.2, 2.1) in our initial proposal above, and the deliverables are 2 research reports followed by 2 fully spec’d ZIPs. It’s a lot of work…
Each review by e.g. ECC is then followed by iterating on the proposals, more than once.
Thanks for you continued involvement with zcash R&D.
However, it is my opinion that we are in need for more practical usage of the devfund. I think efforts should be put into delivering ZSA. Then we can judge if there is an appetite for Stablecoins.
At this stage of Zcash, further non actionable tech would only be further material that other projects would “steal”.
@vivek at the most recent meeting, the @ZcashGrants Committee voted to approve this proposal and has requested that you provide monthly updates via the forum in this thread.
I want to echo this point as I think this grant is a waste of money. Looking to stables to be a solution that saves zcash is borderline insanity. There is:
Likely no way that stablecoin issuers will work with Zcash. You can use technologies on Ethereum that are much better suited to enable “private”, compliant stablecoins.
Likely no way that even if the tech, plus relevant partnerships, existed that we can take marketshare away from Tron, Ethereum, Solana, etc.
Just build a multi-currency wallet with some swapping solution in the back end. If users swap zec for stables, then use that data point to justify a grant like this.
Maybe this works out in the end. But, Zcash community needs to work on the definition of done. “Done” in my world means merged, in production, and at least 1 customer giving a thumbs up that it does what they want.
If it has been decided that there is some inconvenient cutover that needs to happen because it is blocking everything, some >70% of resources should be devoted to that cutover until it’s “done” done.
>$600,000 for a couple of research papers in the current circumstances doesn’t seem frugal.
Hopefully I’m wrong and this investment pays off. But, I would rather see the resources for:
Deprecate zcashd
Deliver improvements to mainnet that will make further improvements easier
I agree with a lot of your concerns, but I still support the ZSA/ Zstablecoin initiative. It is the most cohesive way for Zcash to actually support the private digital cash use case that Josh/ ECC continue to try and force ZEC into.
ZEC is not designed for use as private digital cash, so that means Zcash needs something that is: stablecoins
The crypto world already has plenty of stablecoins, so what next? Zcash must provide quality distinction for its stablecoin implementation. That is where ZSA comes in. We’re attempting to let Zcash users become stablecoiners with the cutting edge Zcash L1 zkp technologies.
Yep, it is very ambitious, Yes, there are perpetual regulatory and compliance risks, and Yes, it will not be cheap, fast, or easy to get done. But if we’re never giving up on the private digital cash use case, then private, local stablecoins/ stable assets are a critical part of the equation.
We can’t target those markets because those are all programmable L1s, meant to be built on/ meant for entire crypto 2,3,4 application layers/ economies. The Zcash stablecoin market would more closely resemble the market for people today who prefer to hold physical cash or metals (private fiat/ private SoV-wealth).
This grant covers the first part of the ZSA roadmap. The choices were:
Fund the entire thing at $2.2mm, including the ZIPs first.
Don’t fund it at all.
Fund it in stages.
There was never a proposal to implement ZSAs without first writing a ZIP. The ZIP is a community sanity check and consensus mechanism for upgrade inclusions.
The idea that the ZIP provides “material that other projects would steal”, implies and acknowledges that the ZIP contains real, valuable work, in which case we should have no problem funding it.
Advocating for implementation first, keeping development discussions secret until they are revealed by the implementation prevents the cooperation we need as a community. And it doesn’t prevent “stealing”.
If I recall correctly, we had a mechanism for trying to slow the ability for other projects to reuse Zcash code via the BOSL license , but it was widely despised and eventually removed.
To start with, we’d like to point to our work on a proof-of-concept for implementing verifiable encryption over Halo2, and a draft write-up for the same.
We’d love to hear comments from the community, and we encourage you to do so on the GitHub repo.