Zcash Elastic Subnet Bridge on Avalanche


As a “Long time listener, first time caller,” in the Zcash community, this is my first forum post. I’m doing so on the advice of Daniel Wolande after corresponding with him through the grants email address. He suggested that I share our preliminary proposal here to get feedback from the community before formally submitting it. This makes sense to me as it’s a substantial project.

Due to some formatting restrictions placed on topics created by new posters, I am including the proposal as a google doc: Zcash Elastic Subnet Bridge on Avalanche

Though I’ve followed Zcash since its inception, my main focus has been on Avalanche, but I am by no means a maxi. I find both our ecosystems incredibly interesting, and my thesis is that we will have our greatest successes when efforts are combined.

I will do my best to answer your questions and respond to your concerns.



One concern that Daniel already raised is about this proposed new staking token, ZAX. Though I believe a new token is the best solution for a few reasons (which I can describe in more detail later), I’ll just note that it is possible to stake an Avalanche Subnet with AVAX.

1 Like

How can we be assured of the security of the proposed bridge? There have been several infamous bridge exploits causing the loss of many billions of dollars. Which technologies and techniques are you going to use in the bridge to ensure security? Are you for example comfortable programming for SGX environments?

1 Like

Thanks for the question about this mission-critical issue, Milton. Our technical decisions will be based around three principles. (1) Redundancy, (2) Attack Surface Minimization, and (3) Humility. So often past exploits were possible because teams took the Zuckerburg approach while building, “Move fast and break things.” This is not our philosophy.

From the 50,000 ft view above, we will follow the architecture of the Ethereum and Bitcoin SGX bridges developed by Avalanche, except the wardens will be replaced by the Subnet’s validators. This will create a two-layer security model for redundancy. Not only will each validator approve bridge transactions using code running in its own SGX enclave, but then all the validators will also reach consensus with each other about the transactions. A byzantine actor not only would be blocked during the consensus-reaching step, but also prior, not even able to produce a valid transaction to submit for validation because their byzantine SGX code would not have been signed by the other validators.

Most groups who are building Avalanche Subnets are customizing a clone of the EVM. (Indeed, the red·dev team wrote a tutorial about how to do this.) However, Subnet architecture allows us instead to build a single-purpose VM in order to minimize the attack surface. This may sound difficult, but it is not. Ava Labs has provided two examples, SpacesVM, and BlobVM. In this way, we will minimize attack surfaces by (1) keeping the codebase concise, and (2) utilizing all the plug-and-play features provided by Subnets—which have been battle-tested and audited—to perform all the heavy lifting.

As for our team’s ability to build this bridge, we have a strong track record. With each new technological challenge that we have faced, we have not only learned well enough to win awards every single time, but also well enough to teach it to others. Not only that, but we have also brought a product to market based on technologies that we did not know when we started. You ask about SGX coding, and it is no different. While we do not yet have the expertise, we are more than capable of learning this new skill, and we are already familiar with its features, purpose, and prerequisites.

Also, of course, our code will be audited—which hopefully goes without saying. We also anticipate a gradual increase in bridge usage over time, giving us adequate in-the-wild exposure while stakes are still lower to correct any errors.

The sentence I just wrote takes us straight into our third guiding principle, humility. The amount of hubris and arrogance in crypto still astounds me. This is not in our nature. True, we tell you that we have the skills to build this bridge. However, we are sure to make mistakes, and the key to success then is to build sufficient error-correcting systems into our process. Open source code. Audits. Redundancy. Attack surface minimization. Relying on both the Zcash and Avalanche communities. These are just some of the things we will use to make sure that what we build is not hackable.

Thank you again for asking, and do let me know if you have follow-ups.

Also, please, more questions! I will try to answer at least one per day.


For your reference: More information about Avalanche’s Ethereum SGX Bridge


What do you think about this idea? Is this something your team would be able to do? If the bridged ZEC were able to remain shielded on Avalanche this would dramatically increase the value of the proposal, especially if the privacy pool was shared by both chains.


Holy crap! I guess the wheels are turning! We would enjoy helping with this endeavor. I would have to think more about whether a Subnet bridge would serve another complementary use as well. Will do so.


OK Milton, here’s my more considered opinion on Prof. Matthew Green’s tweets about a Subnet on Avalanche that runs Zcash code and is pegged 1:1 to ZEC, after a night’s sleep. Please keep in mind that what Green could convey in two tweets is limited, and on discovery of more details, my opinion may change.

My take is that his proposal is a much more complex endeavor, and not just twice as complex, but ten to one hundred times more complex. Here’s why.

The two chains, Zcash, and call it “Zcash-A,” would have very different properties. For one, Zcash is PoW; Zcash-A is PoS. This means, among other things:

  • A large amount of Zcash-A’s currency supply would be tied up with staking the network.
  • Reorgs are possibe on Zcash but not on Zcash-A.
  • ZEC-A coins would have a much much higher maximum velocity than ZEC coins.

While these differences are not problematic if the two chains are disjoint, this is not what Green is proposing. He proposes that the two coins be pegged 1:1 to each other. In essence—unless I misunderstand him—these two coins would be algorithmic stable coins to each other. This might be easier to accomplish if the two chains mirrored each other exactly, but as I just mentioned, they will not in a number of ways.

So then you would have to build a mechanism to stabilize the value of the two coins to each other. How to accomplish this? As far as I know, the tech does not exist yet, and Milton, going back to your initial concern about people losing their money, we all know what a disaster stable coins have been so far in this respect, not just UST/LUNA, but also USDC with its 10% de-peg just this week.

Perhaps the pegging problem becomes easier to solve since they are both cryptocurrencies, but there are still complications. For instance, pegged to what oracle? And what happens if one chain, over time, becomes more valuable than the other in people’s eyes, greatly stressing the peg?

You may say, “Well, if the peg doesn’t turn out to work, we still are left with Zcash code running on an Avalanche Subnet.” That’s true (and six months ago or so I heard an interview with someone working on just this), but that’s not desirable; all you would have at that point would be a Zcash fork running on Avalanche. It’s the community, not the code, that makes Zcash valuable. (The code matters of course, but it is the byproduct of the community.) Two disjoint chains would have the potential to split the community.

The bridge we propose—though obviously not a walk in the park—is much more simple tech. We have a roadmap of how to build it laid out by the SGX bridges built by Avalanche, we have a team assembled who are available to build it, and it appears that enthusiasm for this project is growing within the Zcash community. This is a recipe for success.

As always, comment welcome!


Hi! These are all great thoughts. And I won’t claim to have thought about these things deeply enough to have resolved all possible concerns.

Here is my thinking:

  • We need bridges for ZEC to other chains. The tokens running on those chains won’t be ZEC, but they will be “synthetic ZEC” equivalents powered by trust in the custodial multisig bridge. Think renZEC, for example. The value of these coins could theoretically float separately from ZEC (depending on weird market conditions and trust in the bridge) but presumably they wouldn’t float very far: after all they are 1:1 redeemable for real ZEC on the Zcash chain. Let’s call these “avaZEC” for fun.

Many of the problems you point out about pricing and reorgs on the main Zcash chain are risks in this proposal already. The bridge will be (initially) custodial I assume, so it might be hacked. The Zcash main chain can theoretically reorg and cause all manner of problems, but this can be mitigated by requiring a (long) lockup period before value crosses the bridge. None of this is really new territory: it’s just difficult engineering.

  • The problem with renZEC and any proposal that links to EVM chains is that the coins become “non-private” the second they leave the main Zcash chain. In other words, they’re just another ERC20. This isn’t great. It would be much better to have a full privacy solution present on the Avalanche side of the bridge. This would technically be an independent subnet but it would include Zcash’s privacy tech and would carry an independent version of avaZEC that could also be used for staking. This new subnet could be upgraded to support ZSAs and so it could also provide privacy for other tokens that already exist on different Avalanche subnets. This seems like a win for privacy, a win for Avalanche, and a win for ZEC holders (since staking would be a new use case.) Meanwhile avaZEC could easily travel into the Avalanche EVM chain to access DeFi. I’m assuming that moving tokens between Avalanche subnets is much easier than having another custodial bridge.

Yes, there are major questions about how staking rewards will be paid. A new protocol upgrade and pool on the main Zcash chain? A second token? I think there are many solutions and yes, I think they need a lot of thought and discussion. But these are opportunities not barriers.

  • In the long term, custodial bridges make me concerned. I think it would be excellent to eventually upgrade the bridge solution so that it supports ZK (or at least optimistic) proving, thus eliminating custodial risk from the bridge. I don’t want to get into the details here because there is a huge amount of design work to do here and it is a long-term process, not something you’d do in version 1. But between ECC and ZFnd I think there is enough expertise to make this work well.

  • I am not going to lie that I dislike the current PoW chain and the Zcash community has already discussed moving to PoS. The existence of an Avalanche PoS chain might be one way to bootstrap this transition. If the new Avalanche chain is successful and enough value is safely bridged over, maybe someday this can replace the PoW consensus. Or maybe the two chains will live harmoniously in parallel.

None of this is easy, but it seems to me that there is a lot of value from (1) having more privacy on other chains, (2) tying those new privacy subnets to ZEC, so they benefit ZEC-holders, (3) binding Zcash itself closer to other chains and giving it access to DeFi in case centralized exchanges decide to de-list privacy coins, (4) making brand-name Zcash (rather than Zcash clones like Tornado Cash, Railgun, etc.) the de-facto privacy layer of Web3.


Great to see more interest in connecting Zcash to other chains, although I’m not in love with the idea of the foundation owning the validators or thrilled with a separate token pre-mined that would be airdropped to the foundation. I think airdropping any token should be airdropped to ZEC holders at the snapshot of the block height duration creation, etc etc.


I don’t think the Foundation should own the token or the validators. I don’t even think a new token is a good idea. I think the PoS protocol should be open to anyone who wants to be a validator and the ZEC issuance should be updated to support staking validators as well as miners.


Agree. I would prefer a proposal without a new token. Ultimately dilutes the value of ZEC, IMO.


I’d like to talk about various issues re tokens, and then I’d like to respond to the points that Matt has raised.

First, a bit of background about how tokens work with Avalanche Subnets for those unfamiliar with Subnet architecture. A Subnet (they prefer a capital S) on Avalanche is a plug-and-play blockchain. It’s actually even more general than that; it’s a dataset that a group of Avalanche validators can keep in sync using Avalanche consensus, and the primary use-case is to validate one or more blockchains.

There is a requirement that each validator must help validate the Main Subnet, which contains the X, P, and C chains, which requires a minimum of 2,000 AVAX to be staked per validator. Having met this requirement, a validator may then validate as many subnets as it likes, only restricted by hardware.

Think of the the Zcash-Avalanche bridge Subnet as a special-purpose blockchain whose sole purpose is to bridge assets between Zcash and Avalanche. It is, if you will, an “app chain.” For decentralization reasons, this app chain needs to be permissionless, or what they call “Elastic.” Elastic Subnets insure that consensus is reached by requiring their validators to buy and stake a token.

Rules are very flexible on this, but it’s important to get them right because this staking is what insures that the validators behave well. Every Subnet also has a gas token which can be the same or different from the staking token. A small amount of this token is burned with each transaction so as to prevent denial-of-service attacks and so on.

Past this, other tokens can be created as needed. For instance, a ZEC.z token could be minted as a synthetic version of ZEC. Or the bridge could simply provide authorization for the ZEC.z to be minted elsewhere.

All Avalanche validators are able to communicate across Subnets very quickly (faster even than block production) using a messaging protocol called Avalanche Warp Messaging. AWM is a low-level protocol, leaving it up to the Subnets to decide the format and content of the messages. Using AWM, the Zcash-Avalanche bridge will be able to communicate with any other Subnet, or the C-Chain, about what has crossed over the bridge. Once a token has crossed over, the bridge can, for instance, authorize an ERC-20 contract on the C-Chain to mint a corresponding amount of ZEC.z. Likewise, the C-Chain smart contract could burn ZEC.z tokens and then instruct the bridge to release those tokens back to the Zcash blockchain.

There are decisions to make about what staking token and what gas token the bridging Subnet should use. But one decision already has been made for us: a minimum of 2,000 AVAX must be staked per validator. Let’s discuss this first. That’s a minimum of 6,000 AVAX for three validators that some entity needs to buy and stake as the Subnet bootstraps. It seems to me that the entity should be the Zcash Foundation, but I am new to how the various groups involved in Zcash interact, so there may be a better answer.

Then there is the staking token for the Subnet. Recall that this Subnet is a single-purpose blockchain, an app chain. The purpose of making validators stake this token is to insure that the validators behave well in respect to performing bridging, not only that they do not cheat, but also that they stay online, perform bridging validations quickly, etc. The value of this token should fluctuate in respect to bridging and nothing else. In this way, as the bridge is used more and holds more funds, the token’s value should increase, and as it is used less, its value should decrease. This value-correlation will insure that the bridge stays secure. It’s for this reason that it is best to have a separate token that is explicitly for this purpose. It’s also for this reason that the same token also should be used for gas, so there is a clear connection between bridge usage and the token’s value. That is why we propose a new token, ZAX, for this purpose.

A few things to note about ZAX. (1) It does not dilute or even mix with ZEC or the bridged ZEC.z. (2) The token is a true utility token since it must be staked to make the bridge function, so it probably would not be considered a security. I am no lawyer, and as they say, none of this is legal advice, but Avalanche Foundation uses the AVAX token in exactly this same way, and they have taken great pains as an organization to stay compliant with US law. Because of this, the closer ZAX can mirror AVAX in form and function, the more likely the project will be deemed compliant with US law, it seems to me.

Subnets are quite flexible. It would be possible to secure the bridge by staking more AVAX (in addition to the 2,000 per validator) or even to stake ZEC.z. But neither of these tokens’ value propositions has anything to do with whether the bridge functions well or not, so imo using these is not good design.

It does make sense to me to distribute ZAX widely in the Zcash community instead of just to the Zcash Foundation. However, please keep in mind that this bridge will require maintenance and development (for instance, to build additional features that Matt Green has proposed), and some ZAX should be reserved for this purpose. That is why the we propose that some be allocated to red·dev.

Matt, with all this in mind, I’d like to propose a framework that would give you the shielded ZEC.z on Avalanche that you would like. It’s out of scope of this bridging Subnet project, but could work along side of it. We could create another Subnet called “Shielded Zcash.” (This subnet could use the same validators, so no need to buy more AVAX.) It would have two chains. One would be a clone of the Zcash chain, except the token would be shielded ZEC.z. The bridge could be built to pass shielded ZEC only to this chain in the form of ZEC.z, the synthetic asset you mention. You’re absolutely right, this is an easy way to peg its value to ZEC since it can always just be passed back over the bridge for ZEC 1:1. The second chain in this Subnet could implement an EVM and could have ZEC.z as its native token. It would be easy to do atomic swaps back and forth, eventually (perhaps!) giving Zcash users full use of smart contracts in a shielded way—or not if they chose to transfer their ZEC to Avalanche’s C-Chain instead.

However, this is a huge project, so let’s start with the bridge!

I know you raised a few other issues, but this is all I have in me for today. More soon. Thanks everyone for the responses.

The incentives are perhaps better aligned with a new token, but the market cap of ZAX would likely be much lower than that of ZEC, and I think the economic security would likely be lower as well. I think there would be a lot of people holding ZEC willing to bridge it over to stake, but who would not be inclined to do so if they had to buy another token. Ultimately, I think it is better for the Zcash ecosystem to have ZEC.z as the staking and gas token.

There already was a guy who ported the Zcash protocol over to an Avalanche subnet. RFI – Zapa - Community Grants / RFI - RFP Grants - Zcash Community Forum. Apparently it was working on testnet, but has since been abandoned. I don’t think combining this with a bridge to Zcash is an unreasonably large project. Maybe you can even collab with the guy?

1 Like

I am so pleased to see that this project proposal is generating a discussion. This project has been in the back of my mind for our team for over a year, so it’s exciting for me to see the community engaging with it now. I’ll give some more thoughts and responses.

Bridge Subnet + Shielded Zcash Subnet

In our initial discussions about this project, the idea was to create a Subnet to handle bridging with support for bridging to the C-Chain, but to leave the architecture open enough to allow anyone else to also bridge to their Subnet as well. With Prof. Matthew Green’s interest in supporting shielded transactions on Avalanche (and as Milton points out, another project is already part way there) it does make sense to me to make sure these two projects (and two Subnets) can function together harmoniously. I do think that architecturally the way to implement this is with two Subnets (as described earlier). As far as project scope, it seems like there are a few options, and we are open to finding a project scope that works for the Grants Committee.

Tokens and Staking

Shielded Zcash Subnet

For the shielded Subnet running the Zcash chain, it makes sense to me to use ZEC.z as the staking and gas token, as Matt suggests. (By the way, I’m using the naming convention for ZEC.z that Avalanche uses for its bridged tokens. For instance, BTC.b, USDC.e, etc.) This is a win all around for the reasons that he describes.

Bridge Subnet

For the Zcash-Avalanche Bridge Subnet, I see from our discussion here that the staking token is perhaps the most controversial aspect of this project, so let me put some more time into explaining our reasoning behind creating a ZAX token for this purpose.

As described earlier, we propose that it be used for both staking and gas, but one thing also worth pointing out is that new ZAX would also be minted and then distributed as rewards to validators for participating in the Subnet.

The vision here is for the Bridge Subnet to follow the model that successful blockchains have already implemented and to avoid reinventing the wheel. This Bridge Subnet really is a small blockchain with all the benefits and complications that that entails, and by far the safest path is the path well-trod.

Pkr’s idea of providing ZAX proportionally to all Zcash holders appeals to me more and more, and this would also simplify the user experience when using the bridge. Fresh ZAX would be minted as users bridged ZEC to ZEC.z and would be automatically deposited into their wallets on the Avalanche side, with a small amount deducted for bridging fees. Bridge users would then have a choice what to do with the rest of their ZAX. Stake it? Save it for future transactions? Sell it? We would want to implement a locking period for ZAX to prevent a fast sell-off, but eventually everyone should be able to sell all their ZAX to others who would like to buy it. I could see this being very appealing to perspective bridge users: use the bridge, claim their ZAX, and initiate its unlocking clock. What a great way to organically get the community trying out the bridge!

To Zcash users who normally just think about one token, ZAX may seem unnecessarily complicated from a user experience point-of-view, but I assure you that once you’ve entered the Avalanche ecosystem, dealing with multiple special-purpose tokens is the norm; many projects have one.

Over the longer term, we envision that red·dev would take on the role of a smaller Electric Coin Company for this Bridging Subnet, and like the them, red·dev will require a dependable income stream. This is another reason to create ZAX, as a portion of staking rewards can be apportioned to red·dev. Also, ZAX aligns incentives; the more successful the bridge, the bigger the rewards. This also frees up the Grants Committee from ongoing funding; all this project requires is seed funding.

Along the same lines, not using ZAX raises another issue. If we were to use another token for staking—say AVAX or ZEC.z—the Bridge Subnet would have to pay rewards in this currency, and because we can’t mint it, a supply would have to be bought, diverted, or financed, creating a host of new questions and problems. For instance:

  • What is the source of these funds?
  • As values of tokens and bridge use fluctuates over time, how are adjustments made to staking requirements and reward amounts? If these must be done manually, who is responsible?

Another issue with using a token besides ZAX as the staking token is that the Subnet would have to implement slashing of funds for malfunctioning or misbehaving validators. Avalanche has avoided implementing slashing (the only funds at risk are your potential rewards). As someone who has run an Avalanche validator, let me tell you what a wonderful thing this is not to live under the specter of slashing day in and day out. Avalanche has been able to do this successfully because they are using the AVAX token for staking, and everyone realizes that if the Avalanche network were to malfunction or to be successfully attacked, the value of AVAX would plummet—in effect platform-wide slashing. This keeps everyone incentivized to validate the network with care and integrity. Some fudders have been skeptical that this would work, but at this point, the Avalanche platform has proven itself.

However, if Avalanche were to stake its validators with another token, say for instance BTC.b, the same incentives would not be in place. An Avalanche validator could misbehave with no concerns about tanking the price of bitcoin. The only way then to enforce good behavior would be to threaten to slash each validator’s BTC.b.

We would face a similar problem if another token besides ZAX were used to stake the Bridge Subnet. We would have to implement slashing of that other token in order to enforce good validator behavior. This is a huge minus imo, especially in the Avalanche ecosystem where the norm is no slashing.

An International Bridge

As we talk here in a Zcash forum, it’s easy to think of this bridge as a “Zcash property,” but in fact, this bridge is connecting two sovereign platforms, just like the Peace Bridge connects the US and Canada. I’d urge that everyone take on this mindset. Both platforms will benefit, and it serves both communities. Whereas the Shielded Zcash Subnet that Matt proposes would be much more closely connected to Zcash (with 1:1 pegging, etc.), this Bridge Subnet serves as a way station to parts of Avalanche that have nothing to do with Zcash as of yet and may not even yet exist. This “international” aspect is yet another reason to use an independent token for staking the Bridge Subnet validators.

Custody of Funds

Both Matt and Milton have raised an important security concern about funds custody. These wallets and smart contracts could become large honeypots indeed. Avalanche’s SGX Bitcoin bridge does something interesting to mitigate this problem. On the bitcoin side, it does keep the bridged bitcoin in a wallet, but on the Avalanche side, it never takes custody of the BTC.b. Each user’s BTC.b is protected by the same private key as secures their bitcoin wallet. These cryptography gymnastics are done by having the user sign some data with their bitcoin private key, then extracting their public key from the signature, and then using that public key to create a wallet on the Avalanche side that only the user’s bitcoin private key can unlock. (My team is familiar with this kind of thing already, as we had to use a similar technique to verify an X-Chain digital signature on the C-Chain for the tutorials that we wrote.) I’m sure there are other ways to further protect bridge assets, but I think it would be a good idea to start with something like this, especially considering the similarities between Zcash and bitcoin.

OK, that was a long one! :smiley:

I think is worth it writing all this down though as it helps us think about these issues clearly and in a documented manner. Thank you so much for the comments so far. We will be submitting a formal proposal soon.


For the source of these funds, they can simply be paid out of gas fees can’t they?

As for staking requirements (I am assuming you are talking about minimum stake required), why would we need a minimum staking amount? One of the advantages of Avalanche is that it can handle many thousands of validators, which I think we should take advantage of, and the AVAX required to become a validator will serve as an upper limit anyway.

Hey @mrkit2u would love to chat with you on this, we’re pretty deeply familiar with ZEC and possible bridge implementations for it AND we recently have been quite excited about the developments happening with AVAX Subnets.

It seems like there are a lot of parts that need to be built, we could possibly collaborate.
My telegram is @jommi, lets chat!

1 Like

Hi, just getting back to answering now.

Yes, you’re right, Milton, it could work that way, so perhaps that wasn’t my strongest point of the bunch!

One great development this week is from the Avalanche side in yesterday’s Avalanche Community Developer Call. The link joins about 2/3 of the way through, and if you’re really in tl;dr mode, skip to 51:10 and listen to what Patrick and Aaron say at the end. They are describing how a bridge exactly like this one would work on the Avalanche side, would be easy to implement, and could integrate ZK proofs as well.

What I got out of this discussion is that the platform team at Ava Labs is ready (and excited) to support a bridge of this type with their newly released Subnet and AWM tech.


We have submitted a formal proposal to the Zcash Community Grants Committee, and you can view it here:

We have narrowed the scope to building the bridge software and deploying it to testnets. This would allow us to begin building while discussions continue about how to fully deploy it to connect the Zcash and Avalanche mainnets (Part 2), and about how to connect it to a new Zcash-on-Avalanche Subnet (Part 3).

Thank you for your consideration.




200k is enormous, and we don’t have the guarantee that demand will be there… However, this is a good idea. This grant should also try to convince people like Barry Silbert to seed a decent sized liquidity pool so people can actually do things with their Zec.

Without such commitment, I don’t like this grant because Zcash community is paying high price for no tangible roi.