Zcash to sovereign rollup


This post only focuses on zk-rollups. Thank you to Cooper Kunz and c-node for feedback which influenced edits made to the original draft. Thank you to @joshs, @pacu and @aquietinvestor for their review.

Zcash community –

This post is to solicit discussion and feedback around the possibility of Zcash deprecating the Zcash Layer 1 (L1) blockchain, and seeing the Zcash protocol become a Sovereign Rollup. In this design, Zcash will become a lightweight blockchain that sovereignly operates its own execution environment via a network of nodes, and posts state updates to another L1 blockchain for data availability.

This idea comes after my spending time working in the Ethereum/Modular blockchain space, specifically working on sequencer layers (block producers for rollups). In this post, I will outline some designs, discuss their tradeoffs, and share why I feel having Zcash become a sovereign rollup is the best path forward for the project and the ZEC token.

The post will focus on:

  • Why Zcash should move away from being a L1
  • The various architecture pieces for rollups and different designs
  • Sovereign versus Smart Contract rollups
  • Competitive landscape
  • ZEC utility
  • Path forward and call to action

This post does not suggest any change in Zcash’s mission to bring transactional privacy to cryptocurrencies. On the contrary, this move might make Zcash more accessible across a growing internet economy where developers are interested in a world of interoperable application-specific, sovereign blockchains. Positioning ZEC as the digital cash within this ecosystem is a strong narrative that could reignite attention to the project, and it also enables ZEC to have significantly less sell pressure and more utility. Other key benefits include:

  • More accessibility for ZEC
  • Stronger security for the Zcash payment protocol
  • Opportunities to make design tradeoffs that L1s cannot enable
  • More opportunities to collaborate with builders in a growing modular blockchain ecosystem

This post is originally inspired by Josh Swihart’s question in this Zcon town hall thread.


Zcash is a L1 blockchain that is designed to enable private payments. It uses a Proof-of-Work (PoW) consensus algorithm, but is exploring a move to a hybrid Proof-of-Stake/Proof-of-Work model.

This initial research is beneficial because it gives Zcash strong finality guarantees. Finality is the assurance that your transaction will not be reverted. Proof-of-Stake (PoS) protocols offer stronger finality guarantees because the economic security is derived collateral put up by validators. If they maliciously try to revert a transaction, their stake will be slashed and they lose their money. Stronger finality can improve things like bridging. PoS is also argued to give the Zcash token more utility and have normal users earn rewards via DPoS/liquid staking protocols.

While this research is promising, I believe a move to a sovereign rollup has better long-term benefits for scaling, interoperability, and network effects, while still maintaining the decentralization and liveness of an external L1 (i.e. Celestia).

Regarding scalability, L1 blockchains are inhibited by the throughput they enable. In some of the proposed PoS algorithms, block times and finality are 10 seconds. That’s really fast! But, to maintain decentralization of the L1 protocol, you need to ensure that block sizes are low enough so you have enough validators able to participate in consensus and block production and also ensure that non-consensus participants can run a full node to verify the state of the blockchain. For a transparent blockchain with shielded payment pools, maintaining decentralization for block production and node operators is important because block producers can be pressured to not include shielded transactions. Additionally, liveness and dynamic availability are key properties that also require decentralization.

So even if you have fast block times and finality, you’re still bottlenecked by the amount of data the L1 can effectively process. This creates scalability issues in the event that Zcash sees more adoption. We saw some of these issues play out during the spam attack. Changing the consensus algorithm to PoS (in my opinion) does not solve these issues.

Additionally, Zcash was recently vulnerable to a 51% attack. While I understand a move to PoS might strengthen Zcash security short-term, I’m skeptical that the project can continue to bootstrap its own economic security as an independent Layer 1 protocol. To my knowledge, the current Proof-of-Stake algorithms ECC is reviewing wouldn’t see Zcash be victim to reorgs via an attack on the L1, but more rather liveness failures (which could lead to a socially led reorg via a fork).

What are rollups?

Rollups are Layer 2 (L2) blockchains that take transaction execution off the L1 blockchain offchain. This means they create “another blockchain” to handle execution. This blockchain can be a permissioned server, a permissioned, federated group of nodes, or a decentralized network.

So, we’re just taking execution offchain? Not quite. First, let’s go through how a transaction would happen in a PoS Zcash.

  • User initiates a transaction with a client. I.e. Sending a shielded love note through Ywallet
  • User generates a proof and the transaction is sent to the mempool
  • Validator wins the right to build a block. Takes transactions in the mempool, orders them into a block, and proposes the state update to the network
  • Validators review proposed block, accept the state update and finalize + settle the transactions
  • Data is available for full nodes to download

In the modular ecosystem, the thesis is that you can break down these roles into different protocols. These protocols all have their own fancy term. We’ll focus on zk-rollups as Zcash already leverages zero-knowledge proofs.

  • Execution (VM): the virtual environment within a blockchain where transactions are processed. It also determines rules for how the blockchain updates its state
  • Sequencer: the role of including and ordering transactions in rollup blocks, and proposing them (aka block producer)
  • Prover: the role of taking a proposed block, executing them, and compressing transaction data into a proof that proves that execution was done correctly
  • Data availability: the role of receiving and storing the transaction data or state changes
  • Settlement layer: the role of verifying a validity proof for execution of the rollup’s state transition function

So a now a transaction would look like:

  • User submits transaction and generates proof (within the limits that the execution layer enables)
  • The sequencer operator/protocol takes that transaction (w/ proof), orders it in a block and proposes it
  • The prover takes the sequencer block, executes it, and creates a proof proving correct execution and the latest state update
  • The state change and validity proof is sent to the L1 for data availability
  • The settlement layer reads the proof to verify the latest state update [1]

Sovereign versus Smart Contract rollups

This section can be largely debated, and I’m not going to dive into definition wars here. To be honest, it’s all a bit fuzzy. A good way to look at it is that smart contract rollups are generally scaling solutions for Ethereum, and sovereign rollups are similar to L1s and appchains.

But we carry on!

Smart contract rollups are probably what most of you all are familiar with. These are how rollups operate on Ethereum.

Smart contract rollups verify their state updates with a smart contract that lives on the L1. After transactions are ordered into rollup blocks, and executed, a prover will submit a zero-knowledge proof to the L1, and a smart contract will read that proof and verify that the transactions were executed correctly. This is a great model if you want to directly align your protocol with a L1.

However, in this model, the community outsources its sovereignty to token-weighted voting governance processes. This is antithetical to decentralization, in my opinion, and creates perverse incentives for people who own massive amounts of the token supply. Tl;dr? The richest people make all of the decisions. So if you want to upgrade the chain, per se, who makes that decision? The people with the most tokens, not individual node operators. [2]

The section above is currently under review due to feedback mentioned in a response to this post.

So sovereignty?

Sovereign rollups operate similarly to smart contract rollups. The difference is that individual nodes are the ones that agree on the updated state of the blockchain.

So instead of a verifier in an L1 smart contract, nodes verify the zk-proof for each block, verify DA, and agree on the updated state of the rollup. There’s a couple benefits to this:

Currently, running a Zcash node is very difficult because it takes a lot of data. In sovereign rollups, you don’t need to download the full state of the rollup. You can use various models, like Data Availability Sampling and ZKP compression techniques, to make verifying the state of the Zcash protocol easier.

This means that it would be easier for people to run Zcash “nodes”, and increase decentralization of the protocol.

Also, when upgrading the protocol, the sovereign rollup would operate the same as a L1 protocol versus smart contract rollups. Development teams would propose new software updates, and nodes would agree to these updates by updating their node software to match the update. Super simple.

There are other arguments around economic sovereignty as well, but I want to focus solely on decentralization and how the protocol is upgraded.

Censorship resistance

In either of these models, you’re outsourcing some censorship resistance properties to other protocols. Let’s analyze some of the tradeoffs here:

Sequencer censorship

The sequencer is the role of receiving and ordering transactions within rollup blocks. They handle block production for rollups.

All rollups today use a centralized server that handles block production. If the sequencer wanted to, it could effectively censor any transaction that it wants [3]. This isn’t good!

But, you can work around this via a few different mechanisms:

  • Use your data availability layer for sequencing. Likely the strongest for censorship resistance, but doesn’t give you pre-confirmations which lead to better speed
  • Use an external consensus protocol for sequencing. There are protocols like Espresso and Astria that allow rollups to share a sequencer via a fast, decentralized protocol
  • Build your own consensus protocol for sequencing which could lead to more token utility
  • Use a centralized sequencer for pre-confirmations, but allow users to directly submit transactions to L1 if they need to

This design space is very large and all rollups today are looking to decentralize their sequencer operator.

It’s also been said that a centralized prover network can lead to censorship. You can decentralize the prover network as well, and people are exploring how you can build a single consensus protocol for sequencing and proving.

Layer 1 censorship

Let’s say we live in a world where the entire L1 is censoring the rollup and not allowing it to post its latest state update.

Let’s look at a few ways you could avoid this scenario. You could simply opt to using the most decentralized L1s for data availability, Bitcoin or maybe Ethereum. But, Ethereum has had issues with censorship due to the OFAC sanctioning of Tornado Cash, so having the rollup be managed by an L1 smart contract would not (in my opinion) be an optimal design for a Zcash rollup.

Sovereign rollups have more flexibility here because even if the L1 has censored the rollup entirely, the network of nodes can fork and choose a new DA layer. While I assume this would be a difficult process, it is much more preferable than having to reconstruct your design entirely because you can no longer operate with a smart contract on a censoring L1.

So in either model, you can mitigate against censorship by decentralizing the sequencer or enabling users to bypass the sequencer. But, this is going to be the standard across all rollups, so it doesn’t make the sovereign rollup design unique. An additional benefit for being a sovereign rollup is that you can fork DA layers in the event of censorship.

Again, I don’t think this is a major concern for this post, but wanted to clarify it anyways. It should also be noted that this type of censorship can be applied to Zcash anyways because validators would simply just produce blocks containing public transactions if a shielded transaction ban was applied in some way.

For the sake of brevity, I won’t dive any deeper into censorship resistance in this post, but it’s worth noting that censorship would have to be enforced across the entire shielded set because you can’t censor what you can’t see.

Competitive landscape

There are a few projects that are building privacy preserving Layer 2 solutions, but the space is still relatively small [4]. Today, there are no projects building privacy-preserving sovereign rollups.

In this space, it’s my hypothesis that Zcash would be more widely accepted if it could interoperate among a number of blockchains where sufficient liquidity already exists. To do this, it could create bridges with other rollup networks, perhaps using some zk-proof mechanism, to be able to leverage ZEC across a number of protocols. Or, it could leverage a shared sequencer protocol to guarantee cross-chain atomicity (inclusion is guaranteed, execution is guaranteed if users trust an honest builder or proposer) and cross-chain pre-confirmations with other rollups using the same sequencer. Other connected protocols could leverage ZSAs to privatize their assets for a specific use case.

And by having a more flexible design, Zcash could make design decisions that optimize for performance, and leverage a decentralized DA layer as a fall back network.

For example, Zcash could have near instant finality if it used a fast sequencer for pre-confirmations, which would improve its payment UX. If the sequencer started censoring users, the protocol could use the Layer 1 temporarily for block production and simply fork out the malicious sequencer through a protocol upgrade. DA Layers like Celestia already have similar block times to Zcash today, so this downgrade in performance would be no different than using an L1 Zcash.

This flexibility could see Zcash make different design tradeoffs and trust assumptions to improve performance, while still maintaining the security of the L1 protocol it’s integrated with.

This could give the protocol a competitive advantage when competing with Penumbra and Namada. Both protocols would offer similar execution environments to a Zcash rollup (assuming the Zcash rollup has added functionality via ZSAs, programmability, etc.), but the tradeoffs Zcash makes could see it optimize for different things that might be more desirable to a broader user base.

But what about other privacy-centric rollups? Again, the design space is so large that we could make different design choices to theirs and simply compete with them in the market.

What if Penumbra and/or Namada’s route of a L1 is best in the end?

Maybe it is. Maybe we lose. But in this direction, we at least try something novel and risk getting it right. More risk, but more reward!

ZEC utility

In the sovereign rollup model, the ZEC token would be the native token to the rollup/blockchain. We could use it to pay for gas for Zcash and ZSA transactions, and also use it to secure decentralized sequencer/prover networks [5]. Any network secured with the token would likely be a proof-of-stake model, which would decrease sell pressure on Zcash, give the token more utility, and have stakers earn rewards. You can also do delegated proof-of-stake, or liquid staking, to ensure normal users can stake their ZEC within specific pools or validators.

Moving to a rollup model is an extremely interesting proposition of the ZEC token. Moving to a sovereign rollup would drastically lower Zcash’s security budget (even more than a move to PoS). Validating blocks is expensive, and inflation might have to be the mechanism for which this cost is paid. This will certainly be the case in Zcash PoW, but I’d also argue it for PoS.

Moving to a sovereign rollup model could easily mitigate security concerns from the 21m supply cap. You could even implement fee mechanisms that burn tokens in certain environments leading to a deflationary narrative for Zcash. This narrative, along with significantly reduced sell pressure, could reverse the negative impacts of Zcash’s token issuance model.

In a world where ZEC can be used to pay for things in a vast rollup economy, and also be the gas token that powers private stablecoin sends and private swaps via a ZSA protocol? And that token is also paying out rewards to stakers? And the token supply is deflationary if the network is being used frequently?

Oh my!

A path forward

I’m interested in hearing feedback from the community around this idea. Note that I did not include any specific recommendations on design, as I am not a member of a Zcash development organization.

As a next step, I’d love to discuss some of these ideas on an upcoming Arborist call and simply hear feedback. I would also like to invite some more technically capable people to discuss some of the tradeoffs outlined here. I’ll also try to address any questions/feedback in this forum post.

I’m planning on attending Zeboot, and want to moderate a research discussion around this topic. It’d be great to host a livestream and/or Twitter Spaces with Zcash researchers and members of the modular blockchain community to discuss potential design tradeoffs here.

After analyzing feedback, I will work with members of the modular ecosystem in creating a formal proposal with a proposed architecture with concrete next steps included.

If there is negative feedback, or a lack of feedback, I will discuss other options to bring privacy to the modular blockchain ecosystem.

Thank you all for reading. I look forward to discussing this with you all.

Disclaimer: I work for Espresso Systems who are building the Espresso Sequencer, which is mentioned in this post. In this post, I am not advocating for any adoption of the sequencer, I am simply using it as an example I’m familiar with.

[1] Sovereign rollups don’t have a settlement layer, they just gossip the headers. I used the term settlement layer for familiarity: Setting up a Celestia light node | Celestia Docs (use their GPT and ask “What does “gossip the headers” mean?”)

[2] Aztec are currently reviewing ways to not solely rely on token voting for upgrades: https://forum.aztec.network/t/the-empire-stakes-back-again/2351

[3] Some L2s on Ethereum today fully inherit the security of the L1. This means that users can bypass the sequencer and have their transaction sequenced by the L1. When I say “effectively”, I mean that there is a high fee market on the L1, and many users can not pay the gas to get their transaction sequenced by the L1, leaving them effectively stuck in the L2: https://twitter.com/EspressoSys/status/1686851505339453440/video/1

[4] I would consider Aztec a competitor in the privacy rollup landscape, but perhaps not a direct competitor because the sovereign rollup design is quite different.

[5] I believe that using ZEC as the gas token is the most important thing we can do for its utility. Further discussions around design tradeoffs for token utility and interoperability are needed for sequencer and prover network design choices.


IMO the existence of Zcash arose out of the understanding that fully transparent blockchains are essentially broken (see one of my fav Zooko tweets / threads below) – of which I fully agree. For this reason alone, I would never support Zcash becoming an L2 to a fully transparent L1.


Quite interesting @januszgrze thank you!

My first reaction is: “not another engineering effort!”

We’ve just come out the other side of sandblast with preparations underway for NU6.
Many of the utility functions such as ZSA fees, dPoS etc. are already possible in our current upgrade path.
My one question, is this adding Trust Assumptions or removing them?


Really love the research done here, in general I’m a fan of breaking big problems into smaller pieces. I’m not sure how, but I think somewhere in the mix IBC will be needed in the ultimate solution.

Since this is ground breaking stuff, would it be better and or even possible, to build a test chain via ZSA’s, as a PoC?

1 Like

Wait, I’m a bit murky on this proposal, is @battbot correct?

Zcash would become a token reliant on other blockchains with (insert transparent chain here) on L1 and Zcash on L2?

So we do disagree here, well at least right now! I don’t think Zcash can argue it’s more censorship resistance (CR) due to the large percentage of transparent transactions. What’s stopping an OFAC ban on shielded transactions and miners or validators simply not producing blocks with shielded transactions?

Now, if you deprecated t-addresses, then the argument is stronger! But I still think you can have strong CR with blockchains like Bitcoin. So again, I guess I just disagree with the point there.

1 Like

Good question! I’m not sure how hard this would be to scope out originally, but I’d imagine it’d be a lower engineering lift to maintain and upgrade a blockchain where liveness is ultimately dependent on the external L1.

Re ZSAs and DPoS, those efforts would translate nicely. I think ZSAs would provide a use case for Zcash for other protocols it can interoperate with, and their assets, and you could use DPoS research to design a decentralized sequencer protocol.

This is something we should ask people development in this design space :slight_smile:


Thank you! I’m not an expert on IBC but I’m pretty sure that it could support interoperability protocols between rollups!

WRT a PoC, it’d be awesome to see if a development team could work with the Rollkit team to build something like this out and compare benchmarks.

1 Like

I think @battbot and I disagree. WRT privacy, I don’t believe there’s any difference between a shielded pool on an L2 or a shielded pool on an L1.

WRT CR, if Zcash had no t-addrs, then yes that argument would be stronger. In that world, and the event of an all out ban on shielded transactions, then you could fork Zcash to another DA layer (e.g. Bitcoin in current state) that has better CR a blockchain with a smaller number of validators.

What are the implications of the L2 validators having to pay variable fees to the L1? I was under the impression that variable gas fees were negative for privacy, and if the L2 validators have to pay variable fees to the L1 then the L2 probably needs variable fees too right?

1 Like

Hey @Milton - thanks for the question :slight_smile: I’ll spend some time reviewing Aztec’s approaches here and get back to you. My assumption is that there are a number of ways to solve this.

I strongly believe the most important thing that ZEC that asset can do is migrate away from the current chain as the host for the asset and primary Schelling point for the community.

Being anchored to the ~2015 era Bitcoin code base is an anchor that slowly drags Zcash toward irrelevance. The dev fund could be put much better use extending a cutting edge technical platform and building novel user experiences on top of it.

Resources are limited and the time for adopting a custom proof of stake tech stake has passed.

I think this could be an incredibly exciting direction for ZEC.


This is beyond my pay grade atm, but I do think that questioning our fundamental assumptions can be really healthy. I appreciate Ian for taking the time to write what he did - I could tell a lot of thought went into it. I hope energetic discussion of informed participants leads to something fruitful from this.

And if I’ve said this once, I’ve said it a thousand times. Group discussions are way, way better than async forum posting. Don’t get me wrong, forum-based discussions have their time and place, but I hope someone takes the initiative to organize something to talk about this, as well as other fundamental questions pertaining to Zcash’s strategy and direction. It’s easy to get stuck in the weeds of what one is doing and forget how helpful it is to take a step back and talk about the big picture.


That’s exactly why we are moving Zcashd to Zebra, modern codebase (Rust) that will make it easier to build stuff on.


Thanks for the comment David.

And yeah, I agree. I’ll go to zeboot hopefully and discuss with the ECC team. Also will reach out to ZF to get their feedback.


This might be relevant from the Namada team: https://www.youtube.com/watch?v=749xiX2ETf4

100% agree with this

My message to the Zcash developer community in the R&D Discord.

1 Like

No one wants Zcash to become an L2 and by default a little keyring on someone else’s project. L2s have failed miserably and gained zero traction thus far.

We’ve gone from being the next Bitcoin/the true Bitcoin to please sir can I be your side piece :man_facepalming:t2:.

Just as the narrative is about to switch due to CBDCs and privacy coins are about to have their moment, Zcash is capitulating, no thank you.

Let’s double down on privacy so when the wave comes, there’s no confusion or excuses. It worked for Monero, it can work for Zcash.


total number of L2 users on Ethereum.

Zksync (ethereum l2) recently passed ethereum for number of transactions processed in a month.

In this chart, you can see that overall Ethereum L2s have surpassed the activity of Ethereum L1.

Today, Arbitrum did over 1 million transactions. Zcash did 3 thousand. Monero did 22 thousand.

So I think the claim “L2s have gained no traction” is incorrect.

Re comment “be like Monero”. That’s another direction Zcash could go! Zcash could deprecate t-addresses and introduce tail emissions to pay for long term network security, because with 3k transactions a day, the 21m supply cap cannot stay in place.

Although, with Monero adding membership proofs, and thus potentially fixing its biggest privacy weakness (last I checked on GitHub they’re still researching this) I doubt we’ll capture any significant adoption from their user community. DarkFi recently choosing to merge-mine with Monero was a huge signal of Monero’s strength imo.

I’m a huge fan of Monero, and a Monero user. It’d be great if Zcash could learn from their success. But, is the broader Zcash ecosystem willing to deprecate t-addrs, stay proof-of-work, introduce inflation, and more? To compete directly with Monero?