Four Questions About the Orchard Vulnerability

By: Jason McGee and Zooko Wilcox of Shielded Labs

The recent Orchard vulnerability raised important questions about the Zcash supply and the safety of user funds. Discussions have mixed together several distinct issues, making it difficult to understand what the vulnerability actually means for users.

This post attempts to separate those questions and explain what each one means for users.

Four Different Questions

The Orchard vulnerability raises four important questions:

  1. Was the Orchard vulnerability ever exploited?
  2. Will legitimate Orchard funds be recoverable?
  3. Can users verify that the supply of Zcash has not been inflated?
  4. How do we know there aren’t other counterfeiting vulnerabilities?

Was the Orchard vulnerability ever exploited?

Unknown. We believe prior exploitation is unlikely, though we cannot rule it out with certainty. There are three reasons we think exploitation probably did not occur:

  1. The vulnerability was not previously discovered despite years of scrutiny by many of the world’s best cryptographers and security researchers. Its eventual discovery was not accidental; it was found by Taylor Hornby, working for Shielded Labs, as part of a deliberate effort to identify vulnerabilities of this kind before malicious actors could. Taylor used advanced AI-assisted security research techniques and custom-built tooling specifically designed to find subtle flaws that others had missed, which would be more difficult for someone not already an expert on the Zcash codebase.
  2. Once the vulnerability was discovered, the Zcash devs (led by the Zcash Open Development Labs team) quickly coordinated with the mining pools to temporarily freeze the Orchard pool and deploy the fix, limiting the window of opportunity for any attack.
  3. Cryptocurrency exploits are common, and attackers generally try to monetize as fast as they can, especially once the vulnerability becomes public knowledge. For an attacker to profit from this vulnerability, they would need to exchange their counterfeit ZEC for something of value, which would typically result in ZEC exiting the Orchard pool through the turnstile. If this vulnerability had been exploited before it was remediated, we would expect evidence to have emerged by now. Historically, cryptocurrency exploits have been “smash-and-grab” operations, not “4D chess” strategies that remain hidden for months or years.

Will legitimate Orchard funds be recoverable?

We think so, because we think that the vulnerability was never exploited. If that is correct, all legitimate Orchard funds remain fully recoverable.

On the other hand, if counterfeiting has occurred in Orchard, the existing turnstile will limit total migrationswithdrawals to the amount of ZEC that legitimately entered the pool. As a result, if counterfeit funds were migratedwithdrawn before legitimate funds, a user would be unable to recover some or all of their legitimate Orchard funds.

We believe this scenario is unlikely. Nevertheless, users who prefer to be extra cautious may choose to move their ZEC out of Orchard. Before doing so, however, they should be aware of several other considerations:

  • Moving your funds to the transparent pool (i.e. to a t-address) reveals both the amount transferred and the time of the transfer. Those funds also become publicly linked to that t-address.

  • Moving your funds from the Orchard pool to the Sapling pool reveals the amount transferred and the time of the transfer. However, unlike a transfer to a t-address, it does not link those funds to a specific address or transaction history.

  • The Sapling pool relies on a trusted setup ceremony that was performed in 2018. Reliance on the security of that trusted setup is an additional risk users should be aware of.

  • As far as we know, YWallet and Zkool are currently the only widely used self-custody Zcash wallets that support the Sapling pool.

  • Moving funds to a new wallet or custodial service introduces additional risks, including user error, software bugs, custodian risk, or other unforeseen issues.

On balance, we believe the risks discussed above are moderate. If your funds are currently held in a shielded self-custody wallet, leaving them there is a reasonable choice given our assessment that prior counterfeiting is unlikely. Moving funds elsewhere may also be a reasonable choice if you have a safe way to do so. Users may reach different conclusions based on their circumstances.

Can users verify that the supply of Zcash has not been inflated?

Not today. The prior existence of this vulnerability has made it impossible for users to independently verify that no more than the correct amount of ZEC is circulating within the shielded pool today.

However, as we noted in our previous blog post, Ironwood restores that ability. The diagram below illustrates why.

The proposed network upgrade addresses this problem by adding assurance that there are no more unknown counterfeiting vulnerabilities and by sealing the Orchard pool. No new funds can enter it, and funds can no longer circulate within it. The only remaining path is out through the existing turnstile, which prevents more ZEC from leaving the Orchard pool than the amount that legitimately entered it.

This change restores the ability to verify the soundness of the Zcash supply.

Today, if counterfeit funds exist inside Orchard, they can continue circulating within the pool. After the upgrade, that is no longer possible. Regardless of whether counterfeiting occurred, anyone running a node can verify that no more than the correct amount of ZEC can be circulating.

Users do not need to wait for funds to migrate out of Orchard, nor do they need to reason about how attackers or other users might behave. The protocol itself provides a verifiable guarantee that excess ZEC cannot continue circulating within Orchard and inflating the supply.

This matters because the long-term credibility of Zcash depends on users being able to verify the soundness of its supply for themselves. Ironwood restores users’ ability to independently verify that the protocol’s supply limits are being enforced.

How do we know there aren’t other counterfeiting vulnerabilities?

We don’t know for sure yet, but we have reason to think there are no more. Shielded Labs and multiple other teams have been carefully scrutinizing the Zcash protocol for other counterfeiting vulnerabilities. This has included, with the help of Anthropic, using the unreleased Mythos AI model to search for additional vulnerabilities shortly before Mythos was suspended. We plan to share more details about this review and its findings in a future post.

So far, no more counterfeiting vulnerabilities have been identified. The high level of expertise, effort, and advanced AI-assisted analysis involved in this search gives us additional confidence that no similar vulnerabilities remain undiscovered.

Additionally, we are working with the Tachyon Project and others to develop additional assurance that no more counterfeiting vulnerabilities exist in Zcash. We’ll explain more about that in a future post as well.

Conclusion

The Orchard vulnerability presents four important questions: whether the vulnerability was ever exploited, whether legitimate Orchard funds are recoverable, whether users can verify that the supply of Zcash has not been inflated, and whether other undiscovered counterfeiting vulnerabilities remain.

We believe prior exploitation is unlikely and therefore that legitimate Orchard funds are recoverable and the current supply of Zcash is sound. We also have increasing confidence that no other undiscovered counterfeiting vulnerabilities exist, based on ongoing review by multiple independent researchers and teams. However, users cannot currently verify that the Zcash supply is sound, and they should not have to rely on our assessment—or anyone else’s.

The proposed network upgrade solves that problem. By sealing the Orchard pool, it restores users’ ability to independently verify the soundness of the Zcash supply. Users no longer need to determine whether counterfeiting occurred in order to verify that the protocol’s supply limits are upheld.

Acknowledgements

The diagrams and some of the text in this post were created with assistance from Anthropic’s Claude Fable 5 (before it was suspended) and OpenAI’s GPT 5.5. Thanks to Sean Bowe, Mark Henderson, and Haseeb Qureshi for their review and feedback.

13 Likes

I believe that vulnerability hasn’t been exploited, but the lack of certainty scares me a little. The pleasure of life is dealing with uncertainties and risks; if there were no fear, life would be dull.

I didn’t quite understand one thing. Assuming there had been an exploitation of the vulnerability, and assuming many people holding Zec (Zero Emission Credits) are unaware of what happened, how would they recover their Zec after the alleged exploitation? This would be a hypothetical worst-case scenario if the vulnerability had been exploited. Would it be possible to transfer the funds to address Z or T, then sell them on an exchange and recover the value?

I disagree that the risk is moderate and I think labelling as such contributes to further runs on Orchard. The risk is low. Anyone watching the blockchain and making resonable assumptions about how a rationale exploiter would act can confidently conclude that there has been no prior exploit. I think that should be included in your risk framework and if it was the risk would drop from moderate to low.

1 Like

Yes, in the hypothetical scenario where the vulnerability had been exploited, users could still recover their funds by moving them out of Orchard and selling them. The concern is that if counterfeit funds were withdrawn first, they could consume some of the turnstile’s withdrawal capacity, potentially preventing later users from withdrawing some or all of their legitimate Orchard funds. However, we believe the likelihood that the vulnerability was exploited is low.

1 Like

The word “moderate” was not intended to describe the likelihood of prior exploitation, but the overall risk users face when deciding whether to move funds out of Orchard. We agree that prior exploitation is unlikely and make that point throughout the post. We can edit the sentence to make it more clear that we are referring to the risks associated with moving funds out of Orchard.

1 Like

I think it should be stated more strongly than just “unlikely.” That is a more accurate assessment. Unlikely could mean there’s a 1% chance or a 49% chance. Nearly 500k ZEC has been pulled from Orchard out of a combination of panic and caution since.

Chances were higher initially and it was prudent to be straight up about that in Zooko’s initial post that got viewed millions of times and it did cause a massive panic, but in the days since analysis of fund flows have given zodlers and the market confidence there was no hidden ZEC inflation. This is the main reason you should be able to say “very unlikely.” Maybe Im being pedantic, but I want to see the run on orchard stop and stablise from here.

2 Likes

Thank you for taking the time to break this down in a way that is accessible to the broader community.

One thing that stood out to me is the distinction between confidence and verifiability. Even if the probability of exploitation is considered low, the ability for users to independently verify the integrity of the supply seems critical for long-term trust.

Looking forward to seeing how the ecosystem approaches that challenge moving forward.

  • Crypto Epoch
2 Likes

Hello. Could you please advise if anyone understands:
After the update, will the amounts be revealed for transactions from the Orchard pool to Ironwood? How do the chains differ:
1 Orchard > turnstile > Ironwood
2 Orchard > t-address > Ironwood

It would be somewhat reassuring to stay in Orchard if someone could explain what would happen if funds get stuck there, after the limit has been withdrawn from the pool.
Could one say goodbye to their notes? Would it be necessary to prove their legitimacy somehow? To whom? Would someone exchange them for legitimate funds? If so, at whose expense?

They would be stuck there and unrecoverable. You’d have two different prices. The price of ZEC outside orchard = current_price*0.2 and ZEC inside Orchard = 0, since if counterfeiting happened the market would also tank.

But, your concerns are misplaced because if the possibility existed that your funds could get stuck in there they would already be stuck in there if an exploiter behaved in any way rationally; a bigger run on orchard would have happened by now and your funds would be unrecoverable. You are looking for a theoretical comfort that only exists in your imagination and maybe the OPs post shouldn’t be endulging these theoretical ideas that have no basis to ever exist in any permutation of an exploit happening. They’re just going to confuse people with funds in Orchard and lead them to panic pulling them when by all means by having the opportunity to do so now is evidence in itself that you do not need to do so.

1 Like

Hello! These are good questions.

Yes, amounts will be revealed of transactions from Orchard to Ironwood. This is the same thing that has happened in the past when people moved ZEC from Sprout to Sapling and from Sapling to Orchard. In fact, if you use Zkool today you can move ZEC from Orchard to Sapling, and it will do the same thing — reveal the amount and the time of the transaction but nothing else.

Your wallet can make it even more private by moving your money over in multiple smaller transactions. There is no information on the blockchain linking your turnstile transactions to each other, so the only thing revealed is like “On this day, 100 ZEC moved from Orchard to Ironwood. On the next day, 5 ZEC moved from Orchard to Ironwood. On the next day, 10 ZEC moved from Orchard to Ironwood.”. There’s no way for observers to tell that those were all owned by the same person.

The Valar Group and Vizor Wallet teams have already demonstrated this on an Ironwood testnet!

These are basically the same thing except that with the turnstile there is t-address linked to the transaction.

These are great questions. There is no way anyone can prove legitimacy of their notes, so in my opinion the outcome would be say goodbye to your notes. I think we found and fixed the bug before any bad guys found it, thank goodness!

6 Likes
You are looking for a theoretical comfort ...

Your response made my monitor tremble… I had to grip the table to keep it from falling :sweat_smile:
I didn’t actually ask anything about the probability of compromising Orchard pool or the price of a zec in the near future.
Anyway, thanks. Don’t worry so much. Everything gonna be okay.

We are fantasizing, so here is my fantasy…

Some amount of good $ZEC will never leave the orchard pool because of, you know, boat accidents. A number of years after orchard deprecation we can be quite sure that all remaining $ZEC are good lost zec. A hypothetical attacker could then move that exact amount of bad (now cleaned) zec out of orchard.

Corollary: ironwood experiment will give us an estimation of lost on total zec ratio, we can maybe generalize to all (10yo) coins.

I understand the concern, but I don’t think the answer is to avoid talking about it. People were already asking these questions and spreading FUD. Not addressing them doesn’t make them go away; it just leaves people to speculate and creates more room for confusion and FUD.

It sounds like your view is that because counterfeiting is highly unlikely, publicly discussing it creates more harm than benefit because most readers will overweight the downside risk. I disagree. People are already discussing what happened. The best response is to explain it accurately so people know the facts and understand our assessment.

6 Likes

From Understanding and Using Advanced Statistics by Jeremy J. Foster, 2006:

It is conventional to accept that ‘unlikely’ means having a 5% (0.05) probability or less.

There is another obvious alternative to the gated turnstile in ironwood. That alternative is that in the highly unlikely case of an exploit having taken place, allow all the ZEC to migrate and just accept that an inflation happened and everybody’s ZEC are equally devalued. That is actually the ethically correct thing to do. If you don’t believe that is true, please write your ethical argument in favor of a policy that creates arbitrary winners and losers (aka “bag holders”) on the basis of how quickly you are able to migrate your coins through the turnstile.

I think that everyone associated with Zcash development and governance that supports ironwood as-is should make a public pledge not to move any of their own ZEC from the orchard pool through the turnstile until 6 months after the ironwood network upgrade.

Of course nobody could ever know that they kept those pledges because… privacy! (which is why we’re all here, I think), but I think it would nevertheless be appropriate for people who support the arbitrary winners and losers policy with the most expertise and likelihood of being able to make sure they are at or near the front of the line, to make (and keep) that public pledge. If you disagree I would like to see your reasoning. If your reasoning is some variation of “I don’t believe an exploit occurred so there is no reason to have a discussion about what if it did”, then I humbly submit that you are unqualified to participate in this conversation.

The purpose of Ironwood is not to allocate losses in the fairest possible way if counterfeiting occurred. The primary objective is to preserve the integrity of the Zcash supply and restore users’ ability to independently verify that the circulating supply is sound.

Your proposal requires the network to recognize counterfeit ZEC as legitimate ZEC. That would abandon the 21 million supply cap and undermine one of the core monetary properties that gives Zcash value in the first place.

Yes, I understand that and I am questioning the ethics of that purpose.

My proposal does not require the network to recognize counterfeit ZEC as legitimate ZEC. My proposal acknowledges the reality that in the unlikely event that any counterfeiting took place (which I doubt) that the network itself cannot tell the difference between counterfeit and legitimate ZEC and that therefore, in reality, there is a paradox that though counterfeiting did take place, there are no counterfeit ZEC for practical purposes because all ZEC are perfectly fungible. My proposal says that in the event of counterfeiting, the total value of the ZEC “network” has been compromised and that the right thing to do - ethically - is to acknowledge that reality and spread the value loss fairly across all holders of ZEC and not arbitrarily create two classes of ZEC holders; those who bear none of the losses and those who bear all of the losses.

Do you not recognize that the ironwood proposal as you have correctly described it is making an ethical judgement and creating arbitrary winners and losers? Because your wording is making it sound like some kind of force of nature that nobody has any choice about.

Edit / PS: I think your (@aquietinvestor ) and also @zooko 's positions are actually that if an exploit were found to have happened, it is BETTER (value judgement / ethical position) to try to restore the original value proposition of zcash by throwing whoever happens to exit the turnstile last under the bus. But you (both) seem quite hesitant to simply state that preference.

If that is your position, it’s a valid position which I think is ethically wrong but I’m fine with agreeing to disagree and simply stating my alternate position as clearly as I can. What I don’t think is valid is advocating a proposal that has the effect that I’m pointing to here of creating winners and losers while failing to clearly state that outcome. I call that obfuscation.

The ethics are not as one-sided as you’re suggesting. Your proposal avoids creating winners and losers among Orchard users, but it does so by socializing losses and inflating the supply. Many people would consider that unethical as well.

ZEC holders acquire ZEC with the expectation that the protocol will enforce its monetary rules and supply limits. Under your proposal, all ZEC holders would bear the costs of counterfeiting, including those who never held funds in the Orchard pool.

Your proposal doesn’t eliminate winners and losers. It just changes who bears the cost.

I agree that Ironwood reflects a value judgment. The value judgment is that preserving the integrity and verifiability of the Zcash supply should take precedence over socializing losses by accepting an inflated supply.

However, I disagree with your claim that we’re obfuscating the consequences of that choice. We have been transparent that, in the unlikely event counterfeiting occurred, some legitimate Orchard users could be unable to withdraw funds. For example, in the OP, we state:

As a result, if counterfeit funds were withdrawn before legitimate funds, a user would be unable to recover some or all of their legitimate Orchard funds.

The diagrams in the OP also make that consequence clear. We make similar points in our previous Ironwood proposal. Given that, I don’t think it’s accurate to characterize our discussion as obfuscation. We have been explicit about that possibility rather than avoiding it.

1 Like

@aquietinvestor I appreciate your willingness to engage.

FWIW, I’m very much not a “socialist” although I agree that I am arguing here for socializing the loss. Here’s where I’m coming from on that specifically:

  1. There was an exploitable vulnerability in the zcash source
  2. the code is open source
  3. to me that means that everyone who holds ZEC is equally individually responsible for their own decision to hold value in the form of ZEC.

I’m honestly not sure I understand the basis for distinguishing between holders of ZEC in one vs. another pool with respect to that socialization of loss since ZEC are freely exchangeable from pool to pool and I’d contend that ZEC is ZEC regardless of which pool they are in, but I agree that my proposal is that all ZEC holders regardless of pool should bear whatever losses there are in an equally distributed way because I think that in the unlikely event that an inflation happened, that inflation would affect the entire quantity of ZEC regardless of pool.

In your current version of this post you are criticizing my proposal as “inflating the suppply” but I am not advocating to inflate the supply. I’m suggesting that in the unlikely event that a counterfeit inflation actually took place, that arbitrarily disinflating the supply in the manner that ironwood would do is unethical.

Prior to your edit which substituted in “inflating the supply” you originally criticized my proposal as “recognizing counterfeit ZEC as legitimate ZEC”. I think you deleted that phrase because you realized that since it is impossible for the network to distinguish between counterfeit and legitimate ZEC ironwood would also “recognize counterfeit ZEC as legitimate ZEC” if any exploiters of the vulnerability happened to successfully transit the turnstile with their ill-gotten tokens.

And that’s my main point. Do we agree that if someone were capable of exploiting this extremely subtle vulnerability that has gone unrecognized through several internal and external security audits that they are likely sophisticated and plugged in enough that they will be among the first to transit the turnstile as soon as ironwood is activated? What’s your bet on that? In which case, it’s all but guaranteed that if there were in fact exploiters of the vulnerability, then some or all of their counterfeit ZEC are going to exit the turnstile and be recognized by the post-ironwood new orchard pool as “legitimate ZEC”. And at the same time the legitimate ZEC of some holders who are not as sophisticated and quick to act are going to lose all of their value.

To me that is all self-evidently wrong.

I never said anywhere that I was proposing something that would eliminate winners and losers. I’m saying if there is an exploit, we’ve all (all ZEC holders) already lost and I’m saying that the (ethically) best solution in that case is to spread the loss evenly over all ZEC holders. Is my proposed solution perfect? Absolutely not and I don’t think there is a perfect solution. Mine’s just ethically superior to ironwood in a situation where a shared mistake (vulnerability in open source code) potentially creates a situation that has no perfect solutions.