The Zcash Foundation's Strategy

Over the past few days, several people have raised questions about the Zcash Foundation’s strategy or intimated that they don’t have a clear understanding of what our strategic objectives are, so I’m sharing this here to both inform, and invite feedback.

The Foundation’s mission is to be a public charity dedicated to building Internet payment and privacy infrastructure for the public good, primarily serving the users of the Zcash protocol and blockchain.

For Zcash, we have three strategic objectives:

  • Support the Zcash community
  • Foster the growth of the Zcash ecosystem
  • Make Zcash smarter

We support Shawn in making these forums available as a focal point for the Zcash community to discuss, campaign, debate, ideate, argue, provide feedback, and all the other types of interaction that you see happening here every day. We also run Zcon, to provide an opportunity for community members to get together in person. Obviously, we haven’t been able to do that for the past couple of years but we’re back on this year, so sign up if you’re interested in participating!

We ensure that the Zcash community has a voice in Zcash governance, both directly, through ZCAP, and indirectly, by listening to the community’s feedback, and inviting ZCAP’s advice on Zcash Foundation board appointments.

We also protect new and existing Zcash users by monitoring for trademark misuse, and taking down scams and fraudsters.

At present, one of the key ways that we foster the growth of the Zcash ecosystem is by doing “an excellent job supporting ZCG” (to quote @aquietinvestor).

In the longer term, Zebra will play an increasingly important role in supporting the growth of the Zcash ecosystem by providing a modern, modular Zcash node implementation, built using a memory-safe language (Rust) for others to build new tools, products and services upon, and to integrate into their own software in order to support Zcash.

Note that this isn’t intended to be a criticism of zcashd or the ECC engineers - they did a great job, and they’re continuing to do a great job of implementing new features (primarily in Rust). I’m sure that, given enough time and resources, the ECC engineers would love to rewrite zcashd from scratch (probably also in Rust). But that would be a huge effort, and distract them from the excellent work they’ve been doing, improving the Zcash protocol.

So the Zcash Foundation is doing that reimplementation instead.

As well as Zebra, we’re also working on FROST, which fills an important gap in Zcash functionality - providing the equivalent of multisig for shielded Zcash (both Sapling and Orchard), using threshold signatures. It will remove a key obstacle to greater support of shielded Zcash by exchanges and custodians (thus bolstering the Zcash ecosystem). It also contributes to the Foundation’s broader mission of building Internet payment and privacy infrastructure for the public good.

Finally, we believe that, in order to achieve mass adoption, Zcash needs to become “smart” (by which I mean “programmable”), so that it can evolve to become both a digital currency and a platform for commerce.

ZSAs are a great first step in that direction. We’re delighted that QEDIT are leading that effort, and we’re prepared to lend whatever support we can to ensure that their work gets deployed on mainnet.

In the longer term, however, we want to see Zcash become fully programmable. We aim to get Zebra to feature parity with zcashd (or, at least, as close as makes sense - we may never implement Equihash mining functionality, for example) and then look to implement programmability on top of it. We don’t know what that will look like yet - maybe we start off with something simple like Pay to Verification Key or look to implement a more complex, stateful solution like Zexe. We might even consider layering eWASM on top of Zcash as a first step, before adding more privacy-preserving features. It’s too early to make firm plans or lay out a roadmap at this point - we’ve got a lot of work to do first.

I’m sure someone will be along any moment to ask “What about ZEC?! What about the zodlers?!”

ZEC underpins the economics and the security of the Zcash network, both today and in the programmable future. As I’ve detailed elsewhere, growing the Zcash ecosystem, and improving the utility of ZEC itself, will benefit the entire Zcash community, including the zodlers.


Thanks for the post @Dodger

I want to echo this sentiment before commenting further.

I have one question: what about migration to proof of stake? Is this an objective for ZF or is ZF prioritizing programmability over the PoS transition?

I understand that the last ZCAP poll did not directly give the voters an option to choose for PoS transition as priority. Instead, most people who voted for “moving away from proof of work”, understands it specifically as PoS transition.

In the ZCAP poll above, the first priority is ZSA which is taken care of by the awesome QEDIT team. What is the next priority then? Is “Zcash transitioning away from proof-of-work” a priority for ZF? Will ZF actively support it? If not, why?

ZF is great for Zcash, but I can’t deny that I’m disappointed that I can’t figure out what this great organization wants to do regarding PoS transition, an issue a lot of folks care about. Even if ZF decides not to focus on PoS transition and prioritize programmability, it wouldn’t change my good opinion on ZF. At least I know that another great Zcash org, ECC, has planned to make PoS transition their priority.

TLDR: My concern can be addressed by ZF releasing its analogue to ECC roadmap calls for focus on wallet, proof of stake and interoperability - Electric Coin Company which OP kind of did above. Cheers!

Edit: I added some more things to clarify my question. Thanks again for the post.


When can we expect to see a roadmap for adding programability to Zcash? I know you said we are in the early stages (& this is so exciting!!) but just to keep chins up, could you give an estimated timeline on how this kind of project is planned for and executed? Thank you @Dodger :slight_smile:


Thanks for the post

Does ZF believe that ZCAP is fully representative, effective and accessible mechanism for the community to have a voice in governance and to give feedback?

Does ZF take community feedback on the telegram group, twitter or other platforms (e.g. reddit) into account?

What is ZF doing (and plans to do) besides supporting ZCG, building Zebra, Frost, to expand utility, adoption and growing the Zcash eco-system?

Great to see ZF supporting ZSAs and for Zcash to become fully programmable.


ECC website has this graphic with initial timelines where they intend to focus on Wallets in 2023 and POS Research in 2024. Is it possible to have something simple/similar for the foundation with tentative deliverables for next 2 to 3 years?


Great question. In an early draft of this strategy statement, I included “Deprecating PoW” under “Foster the growth of the Zcash ecosystem” because doing so will eliminate a key objection that many folks have about PoW cryptocurrencies, and hopefully attract the interest of those who are skeptical of cryptocurrency’s value in a world that’s becoming more environmentally aware. In the end, it felt a bit forced, and the statement was getting very long so I dropped it.


The Foundation is definitely in favour of transitioning away from Proof of Work. I wouldn’t say that we prioritize Programmability over Deprecating PoW (or vice versa). I think they’re both really important, and I hope that we - by which I mean the Zcash ecosystem as a whole, not just ZF - can make progress on both simultaneously, so that we don’t need to prioritize one over the other.

As you’ve noted, we currently talk in terms of “moving away from Proof of Work” and not “migration to Proof of Stake”. The reason for that distinction is because we need to be diligent about ensuring that we choose the best alternative to PoW, and that’s a decision that the Zcash community needs to be involved in. Proof of Stake is the obvious candidate (and Zooko has already decided that it’s the right solution) but it behooves us to look at other consensus mechanisms, and assess how they stack up alongside PoS in terms of suitability for Zcash.

There will be several hours of presentations and panel discussion about this topic at Zcon3.


I’ll be straight with you - I don’t feel comfortable laying out a detailed roadmap or making timeline predictions at this point. I have an extreme aversion to making promises that I’m not confident we can deliver on, and it’s very easy to be drastically over-optimistic when estimating timelines for a complex technical project like this.

Take NU5 as an example - it was originally scheduled to activate on mainnet at the end of July last year but for a variety of reasons, it’s been pushed back a number of times, to the end of this month. The fact that the NU5 target was moving had a knock-on effect on the Zebra project, delaying our ability to reach consensus compatibility and feature parity.

We’re working internally to improve the scoping, estimation and forecasting of engineering work. There’s no silver bullet - it’s an iterative process of continuous improvement. In time, I hope to be able to give more clarity on our short- to medium-term timelines.

I know it’s not what you want to hear but I simply don’t want to overpromise and underdeliver.


Fully representative? No. There’s definitely room for improvement. We are - and will continue - working to make it more representative and independent (and I don’t expect we’ll ever stop). We have some updates planned before the next ZCAP poll, and we’re always interested in hearing Ideas for expanding the Community Advisory Panel

Effective? Yes. It played an important role in establishing the Dev Fund (and the Zcash Community Grants program), and we at the Foundation genuinely take its input very seriously.

Can you elaborate on what you mean by “accessible”?

We certainly keep an eye on other platforms and channels. I’m not as active on other channels because of time constraints (I have to ruthlessly prioritize based on SNR) but @winfred and @decentralistdan keep their ears to the ground.

FYI, I’ve been lurking on your Telegram group for a long time. I don’t try to consume the entire firehose but I check in occasionally to see what people are saying about me and the Foundation, so I see your groans. :wink:

What do you think we should be doing?


Delays in any engineering project are inevitable. But if there is ample communication and good faith effort, the overall community is well intentioned and smart enough to understand. Personally, I don’t remember seeing many posts on this forum/twitter berating ECC for NU5 delays. Similarly with Zebra, the general sentiment is that engineering is hard and it takes time.

Without any tangible deliverables, it gets very hard to judge progress. With a roadmap we can at least evaluate what went wrong/right, whether we focused on correct projects or not, what can be improved There is a common goal that everyone is aware of. Even ZOMG funded projects have benchmarks/milestones for the funding requests for the very same reason I believe.


Expecting great things from this.

I don’t think people expect a detailed roadmap or timeline prediction. Just, “a roadmap” and order of priority. It can change like every plan but at least others will be able to gauge what lies ahead in Zcash lands and what kind of contribution to Zcash that they can give, that others haven’t thought about or planned for.

Today, ZF is working on Zebra and FROST which are great. Is there any plan for other projects? Is ZF working on implementing programmability today, or immediately after Zebra or FROST v1 is complete? What about Zecwallet? The community has some ideas but you have indicated that ZF also has some plan for Zecwallet. Can we know what kind plan do you have for Zecwallet? Can the community propose some collaboration on this? That’s the kind of questions that I would have when ZF doesn’t share what it thinks it wants to do next.

Just my 2 zats.


I think as a community it’d probably be helpful if we (the community) listed the outstanding needs/wants for Zcash and then gained an understanding about which organisation is taking responsibility for that item.

For example here’s a list off the top of my head (in no particular order):

  • Wallets (ECC + ZCG ?)
  • Proof Of Stake (ECC)
  • Scalability
    • Rollups
    • Sharding
  • ZSAs (Qedit)
  • Programmability


In many ways I think that’s one of the core details the community needs to know. So that when the community is concerned about the progress or priority if a specific need we know who to annoy :slightly_smiling_face:.


It really does feel like ZEC holders, the people funding you, are at best an afterthought in your strategy.

It is refreshing that you dare to be so open about it though, I will give you that.

1 Like

I strongly support the “no timelines” sentiment expressed here. How to implement private programmability is still a research problem.

Also, I’d like to call attention to how the core team at ECC is now organizing our work, in service of identifying predictable milestones: The ECC Core Project DAG

This directed acyclic graph shows the dependencies that we have laid out to reach various objectives. It has been an absolutely invaluable tool in the execution of the NU5 upgrade, and is the source of truth for the ordering of the ECC core team’s priorities going forward. Planned releases show up as vX.Y.Z nodes in this graph. Prioritizing tasks in terms of their dependencies is, in my opinion, both the most transparent and the most effective way to produce software: at any given time, the things that can be worked on are the “leaf” nodes to the left side of the graph.


This is great! May I ask what tool(s) you used for that, and in particular the GitHub relations?

Also, I wonder if we can work out an analogous high-level strategy DAG such as, just to pick a recent example, the dependencies of “usable ZSA NFTs”.


I built this from scratch using ZenHub’s “blocking / blocked-by” data as the source of edges (since GitHub provides no way to store this data itself, and we were already using ZenHub), and graphviz for rendering. The source is here:

It automatically renders several DAG views, which you can find here:


Recently, I’ve been starting to think economically about the Zcash ecosystem, so I’m trying to think of unmet needs, or useful services, that consumers have/want. I think the terms “programmability” or “smart money” or even “wallets” are just kind of darts that can be thrown at the board to answer “what should be built next?” But I think a better question to ask is what each of those things may be enabling (applications, utility), what are the real use cases, what are we missing?

Let’s start with the most basic function that a private currency would ideally have. And in the interest of time, I leave a lot of detail out for now.

(1) Store of Value → Ability to easily, safely, and privately self-custody or custody coins that maintain a user’s value over time. How are we doing there? I would say modest at best for average users. What do we need to improve?

(2) Medium of Exchange → Ability to easily, safely, privately use zec to pay for goods and services. How are we doing there? I would say we are at very nascent stages. What do we need to improve?

(3) Unit of Account → standard numerical monetary unit of measurement of the market value of goods, services, and other transactions. How are we doing there? Well, like most non-pegged cryptos, it is likely too early to tell, and may be out of our hands completely for a while.

In short, we should always be thinking about the end user when evaluating how we are doing and what we should be building next. How useful is everything we are doing in light of actual use cases?


Yes; I think that a high-level DAG would be incredibly helpful.

1 Like

I am so stealing this idea for feature planning!

Thanks @Dodger for putting this up for community.

  1. I would like to see ZF’s sole focus to be everything about Zcash — currency, network, protocol & community. Ideally the mission statement for ZF looks like this:

The Foundation’s mission is to be a public charity dedicated to serving the users of the Zcash protocol and blockchain.

instead of

  1. What percent of dev resources are currently directed at Zebrad?

  2. At which point do you think dev resources will be diverted to other efforts?

  3. How high is programmability in the list of priorities? It’s not clear what ZF is going to tackle in the near term, at-least for 2022.

  4. Any plans for ZEC Wallet?

  5. Can ZF be more hands on with Ledger shielded support?

  6. What plans does ZF have to onboard new users to Zcash & bring growth to shielded transactions?



That’s a really good way of putting it. This isn’t a situation where we know exactly what we need to do, and we just need to estimate the effort and plan it - there’s too many unknowns to be able to do that.

We were so impressed by the ECC DAG that we created our own!

I might experiment with creating a high-level DAG of our strategic objectives.