What to build?

The @zomg published our draft whitepaper in June 2021. In it are many suggestions for projects that our community builders can work on.

We’d like to host live discussions with interested builders in order to stimulate interest in some of these projects. We’d also like to understand what barriers they may face (so we can help to solve them!).

Whitepaper: zomg/ZOMG_whitepaper_v1.0_published.pdf at master · ZcashFoundation/zomg · GitHub

If you’d like to join, please fill in this Google Form so we can get organized: https://forms.gle/6WnyEKQNrTiQiojVA

Note that we will be gatekeeping the sessions in order to keep them small and productive. We intend to host more than one such session.


So finally after 4 tries, I’ve finished reading the entire ZOMG white paper. I see that a lot of effort went in to putting it together and I believe the stakeholder segmentation is a strong foundation, which can be used to categorize grants & call for RFPs from the broader crypto community.

Personally, I would like to see RFPs for the Media, narrative & advocacy from contributors with experience in crypto media & outreach to strenghten the Zcash value proposition with the Exchanges, Institutional/Business users, and everyday crypto investors with a possibly unified narrative. We’ve seen many new users flock to well marketed coins(example Chainlink), which are yet to build out their potential and rely on third-party chains; but still they’ve managed to capture the interest of a wide variety of users.

Overall, I am happy we have a structure in place, and I’d be signing up to join the brainstorming session.


Haha, sorry it was so dense as to require the determination of four attempts to read it. I am hoping to create a user-friendly interactive website version of it, though I am gated by funding from ZF (ZOMG itself doesn’t seem to be able to spend any funds independently, which has been a problem for speed and quality of execution).

I will be organizing the calls soon. Look forward to chatting live!


I havent had time to read this yet I will get to it over the weekend.

it looks really good.

one idea i want to kina lay claim to or a least be considered to be invoved would be zcash based stable coins, either through zda’s, pegging (via arbitrage through zfnd funds) or an honest to goodness zecstable (ive been reading about usdt and usc privacy versions.)

This is important to me as an mgrc recipient. you lose upto 9% of funds z2z btc to gbp. a lot of us exchanges wont deal with euro or stering, coinbase for example is virtually impossible to withdraw funds. A lot of exhanges use that model and people accept it because thats how banks work - it is a signficant risk mitigation to use a stable coin.

i will get you some more constructive feedback on the stuff ou wrote

Algorand recently went live on Gitcoin with a bunch of RFPs (including non-dev ones) worth checking out : Issue Explorer | Gitcoin


Last week, the ZOMG hosted a call with some community members and representatives from the ECC and ZF. We went through the whitepaper and brainstormed areas where community members showed interest in getting involved with.

Here are some follow ups that we discussed. I am tagging those who volunteered, with the request that you all respond with what you think good next steps are.

  1. Private spending via a browser extension
    Ishan / @mrbabble talked about working on a browser extension to spend ZEC, like privacy.com. Could you please talk to the Zephyr team about this (Zephyr = metamask for zec; search the forum for this keyword)? They are looking for someone to work with. FYI @mistfpga @fireice_uk; maybe we found you the replacement you wanted!

  2. Bootstrapping cheaper ways of running a client
    Currently running one requires hosting a 26 GB blockchain. @gygaxis @zancas and @aserrano, could you please followup?

  3. DeFi applications
    @hanh mentioned that some of these are very easy to do, some potentially taking only a week. The only question that remains is: which to do? I will follow up with Hanh.

  4. Project tracking platform
    An online platform that will aggregate information regarding awarded grants, with the intention of achieving better, more consistent tracking. This would also provide better ZOMG support for and communications with grantees. This will ensure projects deliver well, and also allow us to course correct in case unexpected events/discoveries happen.
    This is a serious pain point, current burdening both the @zomg and the ZF (who support us). We would really love to see someone step in to build this. We can provide input on the design and specification, if you lead with project management and asking the right questions.

  5. Mastering Zcash book
    Many of us recognize the importance of this, to help people onboard onto Zcash more easily. @mrbabble put his hand up for this and has already created a draft outline. @mrbabble, let us know what a good next step would be.

  6. @hanh also put together a very thoughtful presentation with ideas for improving a wide range of topics, from the tracker for ZOMG projects, to server and wallet related improvements. I highly recommend taking a quick flip through. There are no clear action items at the moment, though I am incorporating some of these ideas into the main body of the whitepaper ZOMG - Google Slides

  1. Zcash support on Tor3
    On 15 October 2021, Tor2 will be disabled. This will expose Zcash nodes running on Tor today, making it an eminent and urgent problem. @zancas has stepped up to backport existing Bitcoin Tor3 support onto Zcash.

I will also be posting unofficial minutes taken by @holmes in the next 48 hours or so. [EDIT: posted. see message below]


^^ For those who couldn’t join this time, flagging this so you have context: @adityapk00 @adityapk00 @aquietinvestor @mitchellpkt

@alchemydc @teor thanks for joining - FYI above.

1 Like

Here are the unofficial minutes. I have also edited my earlier to add a seventh item to the list of follow up projects, RE Tor3 support for Zcash.

Community Brainstorm - Minutes (by Holmes)


  1. Zingo Labs (3 persons, including forum member @zancas)
  2. Ishan/@mrbabble (engineer)
  3. Hanh (projects funded by zomg: coldwallet, coinpayments. Also creator of zwallet)
  4. ECC: David Campbell (COO), Andre Serrano (BD). ZF: Teor (engineer). ZOMG: Michelle/ML_sudo, Holmes, Shawn/Minezcash, Hudson Jameson

Note: Aditya Zecwallet and Adi Nighthawk were registered but didn’t join due to coordination failures.

Hanh’s presentation (ZOMG - Google Slides)

DC echoes usefulness of making zcash easier to use in privacy focused distributions, and in Monero doing a good job at community.

Auto Senescence feature/limitation was a discussion

Discussion of improvements on speed increases

Discussion of difficulties using exchanges, and interest in Fiat onramps and exchanges for users in Canada. It’s difficult to sign up for international exchanges and it’s difficult to find Canadian exchanges in Canada. Gemini has almost no tech support and I have technical issues with them.

Ishan expressed interest in using Zcash on ecommerce websites using a privacy.com-like UI. We suggested being in touch with Zephyr.

Discussion re: prioritization of z-address vs. t-address.

Holmes expressed that it’s context dependent e.g. we would really want to fund z-transaction work in wallets, but might be okay with funding t-address work for DEX’s as long as privacy was considered, since those can be privacy preserving.

Andre and DC echoed this.

Documentation and developer experience (SDKs available for different popular languages) has come up a few times. Hanh brought it up and Andre echoed.

Holmes welcomed feedback on ZOMG’s grantmaking process from Hanh perhaps on a separate call.

Hanh expressed that it would be helpful to have more HALO 2 documentation.

DC answered Hanh’s specific question about smart contracts on HALO 2.

Hanh thought that ZSAs would have to be done by an internal Zcash team.

Hanh is interested in programmability and smart contracts.

DC says halo 2 introduces ability to add functionality without doing another parameter-generation ceremony. But what those look like and what they expose is up to the community to direct.

Zancas points out that there are features in Bitcoin that would be helpful in Zcash. “Our hope is that we can leverage features from Bitcoin in Zcash”.

Hanh points out that there are new opportunities opening up with Halo 2 to do some things that open up new functionality and that we might want to wait and see what kinds of things people apply for.

Hanh points out that it’s very hard to work on every aspect of the ecosystem, but that there are places for improvements.

There are some optimizations that would help light clients. Batch decryption. Hardware extensions? GPU usage? (See slides)

Zebra is batching most of our signatures so as long as there is appropriate cryptography that allows us to batch trial decryption we’d be able to batch trial decryption as well. I don’t know whether zcashd architecture would support that.

DC mentioned that zcashd is not working on optimization, but that there have been some changes for some specific things, e.g. diversified addresses for letting you check lots of transactions with one spending key.

Zcash is hard. It’s three coins in one. And the complexity of adding a new server implementation could keep growing.

Going between zcashd and rust is pretty hard because the structures are really different. Helping people approach this code.

DC isn’t sure if Bitcoin catchup is worth it, especially because of how attractive Rust. Zancas agrees re: working on Bitcoin code probably not being the highest priority.

How do we do big lifts of the scale that Hanh is pointing out?

Teor: can we make the lifts smaller?

Hanh: yes, it’s super hard to start from scratch, especially if you start with a language that doesn’t have any of the basics of Zcash.

Asks if reimplementation is a priority

Holmes asks about wrapping librustzcash, or zebra, or zecwalletlite

Holmes raises issue with chicken/egg.

DC reiterates that bindings for Zcash and lightclient everywhere. And there should be more lightwalletd’s. But he thinks it’s better to focus on that layer of bindings before focusing on backend.

Teor notes: this is Zebra’s network library, which has a Rust API based on microservices: init in zebra_network - Rust

Hanh points out that we’re using polling, even between zcashd and lightwalletd, instead of a streaming API for transactions.

More suggestions, from hanh slides

Integration of lightwalletd from Google or Apple services so that you can receive push notifications.

And it would be good to have more deployments.

DC: looking at how we can make the user experience better for syncing is great. And can we reward people for relaying transactions to the rest of the network. Can we incentivize people to run this infrastructure, so that we don’t have to keep writing grants.

Question about Zebra, whether Zebra is likely to become the prime implementation of Zcash. Is Zcashd already in the process of being phased out.

DC: there have not been any official decisions made, and the legacy code is a potential developer experience issue internally at ECC. It’s likely and possible that Zebra would become the official implementation. The ECC might fork it and build on top of it but there’s a lot of interest.

Teor: That’s not an official foundation position. We’d love for it to be the official implementation but it’s just not ready yet.

Zancas expresses value in improving zcashd.

DC: One area where we have pain right now with missing upstream changes is v3 onion support for Tor. Tor support is about to break in zcashd. It would be great to catch us up to v3 onion support and we would be able to offer help getting those accepted.

Holmes asks DC if there are any other priorities that they might not be aware of?

DC notes to Zancas that Larry Ruane is the person to talk to.

The good thing about librustzcash is that it’s a reference implementation. But it would be good to have this library usable from other languages. Also the API is agnostic of storage.

For librustzcash the documentation is basically the code. It’s not super easy to understand the API boundaries —hanh

So it would be great to have examples of how you do basic things. My hope is that eventually it would be easy to create multi currency wallets for Zcash without having so much knowledge of the Zcash protocol.

ECC’s one person on librustzcash is just working on Orchard/Halo 2

Holmes: Why don’t multicurrency wallets use the lightwallet SDK’s?

Right now these SDK’s are wrapping librustzcash so you have to wait until SDK opens up an API. lots of areas of librustzcash are simply not exposed. And if you look at what the SDK does it’s very close to the librustzcash API.

And these SDK’s target mobile. They don’t target browser extensions. Or desktop.

Other coins have done a good job with this. You have a lot of tools in python like pybitcoin, where in a couple of lines you can make a transaction or query your wallet status, or query the mempool. But right now that takes some work in zcash. It’s not like it’s not there but it takes a lot of work to get it.

As a newcomer I see a lot of people coming to the forums like how do I do this, but you start explaining it and they never come back. If the goal is to have more developers at different levels of knowledge. Or people who who to do a little experimental script. I don’t think ZOMG should give a grant to such a small project, but I think we should make it easier.

I’m keen on having simple scnarios doable in python because you reach a lot of tpopel.

Right now we have several developer teams working on zcash ecosystem and these people are working on it for a long time. It’s rare to have a new person and have them stick around. When they see they barrier to entry they get discouraged.

It’s cool when you can see that you can do this in ten lines and you’re not limited by knowledge but rather by their imagination.

Teor’s suggestion with this as someone who’s had to do the rampup over the past year is that there are a bunch of simple tasks, but often you’re using the zcashd RPC APIs or the command line or something like that instead of using these low level interfaces.

Zebra would love to know what the minimum set of RPC’s to support are.

Holmes says the RPC interface requires babysitting, more so than lower level libraries or bindings.

Hanh says that a lot of the stuff comes from a very old world of bitcoind. And it’s hard because if you want to use shielded you have to use one API where if you use transparent you have to use another API. So it may not be a good entry experience to users.

Also, this is the first level of programmatic access. If you’d rather do something more specific you’d rather have something linked to a lightwalletd. Before you even get started you have to wait 6 hours with a full node.

Suggestion, take people coming from other crypto projects and walk them through it and ask them what they’d like to improve, and I think you’ll see it’s not that easy.

Hanh notes on wallets. Performance improvements especially on synchronization.

Michelle solicits questions about stablecoins on Zcash. Hanh points out it’s easy if they’re transparent, and it depends on what your brand is, since it could come at a price in terms of image.

DC says it’s more about storing in shielded vs. t2t.

Michelle, if I want to do stuff in Defi with my Zcash, I have to liquidate.

DC points out you can do this with renzec.

Michelle asks whether Hanh would be interested in building the quick non-shielded version of tokens on Zcash. Both are interested in having another call.

Michelle wonders if anyone would be interested in working on a “Matering Zcash” book. Ishan expressed interest.

Michelle mentions docs for regulators on AECs, and joining up with privacy protection watchdogs. It might be good to join with privacy watchdogs, and make use of their reach and message.

Final one is partnerships with humanitarian organizations. Where people for safety require financial privacy.

Re: Weekly Zcash newsletter, Ishan says that kind of exists with the arborist calls, but that’s maybe 50-300 views on a weekly basis. But maybe the idea with a newsletter would be to broaden it to a wider audience.

(See slides)

DC thinks there’s a void around simple layperson messaging.

Michelle responds in addition to this simple information it’d be great to have in-depth but easily scannable pieces. The videos that are posted assume a lot of context.

A great example is the bitcoin videos But how does bitcoin actually work? - YouTube.

Hanh’s point, to be fair, if it took him 8 videos to explain bitcoin it’d take him 100 videos to explain Zcash.

Zingolabs (who?) said they’ve worked with media before and could reach out to people.

Holmes said that we would be able to find applicants for political work, and (in response to Teor concern) Holmes and Michelle said we thought they would be able to do this within 501c3 rules.

Hanh invited everyone to his Zcash gardening club presentation tomorrow.

1 Like

Just to clarify a bit here:

Only Tor v2 Onion Services are being disabled. So wallets can still get some privacy by contacting public Zcash nodes via Tor Exits. But Exits can be less private than Onion Services, because the traffic between the Exit and Zcash node is not protected by Tor.

@zancas is only backporting Bitcoin Tor Onion Service v3 changes to the zcashd node implementation.

Any wallets or nodes that aren’t based on zcashd will have to add their own support.
In particular, any network protocol changes to address messages will need to be coordinated with the Zebra team.


I note that Bitcoin included their AddrV2 format as part of the migration to handle tor v3 addresses (and other variable length address formats). We were planning to follow use bitcoin’s V2 BIP155 implementation (as much as possible).


Thank you! I needed the help.

1 Like

It looks as though BIP 155 is straightforwardly applicable to Zcash, except that the sendaddrv2 message does not correspond to how we normally signal compatibility with peer protocol changes. We normally use the peer protocol version.

I consider Bitcoin’s approach to peer protocol changes to be problematic for long-term protocol maintenance, since it leads to an exponential increase in the space of supported feature combinations. In Bitcoin’s approach, peer protocol features are independently supported or not by a node (signalled either by a feature flag or by whether it has sent a particular message), and nothing can be assumed about support for a later feature implying support for earlier ones. In Zcash’s approach, a given peer protocol version implies support for all features added up to that version — so the space of feature combinations only grows at most linearly. In fact it is effectively constant, as a side effect of older nodes dropping off the network if they do not upgrade to support a Network Upgrade. (Peer protocol version numbers are bumped either for Network Upgrades, or for peer protocol changes outside a Network Upgrade.)


@zancas, do you have a rough timescale for when the BIP 155 changes are likely to be ready? (I know there’s a deadline for Tor v2 addresses to be removed in October. In fact support for Tor v2 has already been removed from the latest Tor release according to that timeline.)

I’m somewhat inclined to say that support for addrv2 should be signalled by Zcash peer protocol version 170015 (the same version that signals support for NU5 on mainnet). zcashd v5.0.0, that would set the mainnet NU5 activation height and advertise peer protocol version 170015, is currently scheduled to be released in early October.

Another option is to have addrv2 signalled by 170015 but NU5 by 170016 (updating ZIP 252). However, at least as far as zcashd is concerned, there is currently no plan to have an intermediate release between v4.5.0 that supports testnet NU5 activation, and v5.0.0 that supports mainnet NU5 activation (see the planned schedule). Therefore adding an intermediate protocol version seems to be unnecessary complexity.

1 Like

The draft of ZIP 155 specifies this option.

Thanks so much @daira! I have commented on ZIP 155. Thus far I don’t understand any compelling argument against signalling protocol support via peer-protocol version numbers, so I assume that’s the mechanism that I need to implement.

Per my timeline, I am currently working to understand the scope and structure of the problem. I had hoped to get a point estimate on code ported/written per time, today, but thus far I have been studying github history, reading specs etc. I don’t have any good estimate for how long this phase will take.

My hope is that after timing myself for two more days, I’ll have completed more different kinds of tasks, and be able to extrapolate from that data.

My current focus is on (a) understanding what is entailed (b) organizing an approach to solving it.

It’s clear (thanks @str4d) that an early task is to understand where and how the backort of the P2P lib refactor in bitcoin: https://github.com/bitcoin/bitcoin/pull/19954 overlaps with the upgrade to bitcoin v2 addresses (which are necessary for torv3 addresses).

My sense is that concerns might be fairly separable, but more research is needed. It’s clear that there’s some overlap, for example the first commit referenced by Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub involves tests of ResolveSubnet, which is not implemented (in the same way) on zcash master (or at least it’s not tested in the same way if it is).

Barring feedback to the contrary:

I intend to follow the pattern of using a meta-issue to track relevant progress as bitcoin did for torv3:

In order to help keep the process coherent I’d like to minimze the number of sources of truth that contributors need to track.

If we need a distinct source within forum.zcashcommunity, then I vote we move it somewhere besides this thread.

Outside of the forum I intend to use three github issues:

  1. A Tor v3 support · Issue #18884 · bitcoin/bitcoin · GitHub style meta-issue tracking other issues, I vote for this one:
    [ZIP 155] addrv2 message · Issue #542 · zcash/zips · GitHub
  2. A draft PR against zcash/zcash as a single source of truth for potentially mergeable commits:
    WIP: A draft PR for collaborating on ZIP155 by zancas · Pull Request #5276 · zcash/zcash · GitHub
  3. A zip outlining the required changes:

For chat I intend to use the Zcash R&D discord server’s “General Dev” category “Node-Dev” channel:

Thanks to @teor for bringing this topic up in that channel and helping me to understand some of the issues around interoperating between peers with different peer protocol versions.


It’s fine to use [ZIP 155] addrv2 message · Issue #542 · zcash/zips · GitHub to discuss the specification, but that will be closed when the ZIP is merged. Use #node-dev for chat and addrv2 support in zcashd · Issue #5277 · zcash/zcash · GitHub for the support in zcashd.