Ironwood: Verifying the Soundness of Zcash’s Circulating Supply

General
1

By: Zooko Wilcox, Jason McGee, and Taylor Hornby of Shielded Labs

Summary

Shielded Labs is working with The Zcash Foundation, Tachyon Group, Valar Group, and the Zcash Open Development Lab (ZODL) on a proposal called “Ironwood” to restore the ability for users to verify the soundness of the circulating supply of Zcash.

Last week, a critical counterfeiting vulnerability was discovered in Zcash’s Orchard pool. The vulnerability was remediated through an emergency network upgrade coordinated by ZODL and other ecosystem participants, and was completed on June 2.

Although we believe it was unlikely that the vulnerability was exploited (for reasons given in our disclosure), the privacy properties of Orchard prevent users from verifying that for themselves.

Ironwood would allow users to verify that the circulating supply of Zcash is correct. Users would gain this ability immediately upon the activation of Ironwood, by simply summing up the balances of the active pools. They would not need to reason about other people’s incentives or actions, nor wait for migration from the Orchard pool, in order to verify that the total circulating supply of Zcash is correct.

Ironwood

The objective of Ironwood is to restore each Zcash user’s ability to verify the supply integrity of Zcash. This verifiability was impaired by the existence of the counterfeiting vulnerability. Immediately upon activation, users will be able to independently verify that the circulating supply of Zcash is sound, just by running a node.

To accomplish this, Ironwood would:

  • Create a new shielded pool using the Orchard circuit with the recent counterfeiting vulnerability fixed.

  • Reject as invalid any transaction that creates a new output in the old Orchard pool.

  • Increase assurance about the codebase, using such techniques as AI-assisted security auditing and formal verification, all aimed at assuring the absence of additional counterfeiting bugs.

Why Ironwood Works

Ironwood changes what can happen inside the Orchard pool.

Upon activation, any transaction that creates a new output in the Orchard pool would be rejected. This means ZEC could no longer continue circulating within that pool. From that point forward, funds in the Orchard pool could move only by exiting the pool through a turnstile.

Turnstiles are Zcash’s on-chain accounting mechanism for transfers between pools. They track how much ZEC has entered and exited each pool and reject any transaction that attempts to move out more ZEC than legitimately entered.

Together, these rules mean users do not need to wait for all, or even any, Orchard funds to migrate. As soon as Ironwood activates, users can verify from the consensus rules that no more than the correct amount of ZEC can be circulating. This provides an immediate, trustless guarantee of the soundness of the Zcash circulating supply. Excess ZEC cannot be secretly circulating between users of the Orchard pool, nor can it escape into another pool.

Generating Evidence of Whether or Not The Vulnerability Was Exploited

Ironwood may also provide evidence regarding whether the Orchard vulnerability was ever exploited, but achieving its objective does not depend on whether such evidence emerges.

As users migrate funds from the existing Orchard pool to the new pool, any hypothetical counterfeiter faces a choice: attempt to move counterfeit funds and risk exposing their existence, or leave them behind and risk being unable to move them in the future.

This creates two possible outcomes:

Outcome A: No excess ZEC attempts to leave the existing Orchard pool. This would be strong evidence that the vulnerability was never exploited, since a counterfeiter would have a strong incentive to move counterfeit funds before legitimate users completed their migrations.

Outcome B: Excess ZEC attempts to leave the existing Orchard pool. In this case, the excess funds would be unable to leave the pool and would effectively be destroyed. Unfortunately, this is necessary to preserve the current circulating supply across all pools. This would also provide publicly verifiable evidence that counterfeiting had occurred. Since we think the vulnerability was not exploited, we think this outcome is unlikely.

Wallets

We recommend that all wallets that support the existing Orchard pool add support for the new pool.

Wallets should continue to support the existing Orchard pool normally until Ironwood activation, and then migrate user funds from the existing Orchard pool to the new pool. While migration has privacy implications (namely, it exposes the amount of ZEC transferred and the time that the transfer took place), we believe the impact on user privacy is modest and can be further mitigated by wallet behavior.

Existing Orchard receivers (i.e. addresses) remain valid and would not need to be rotated. ZEC sent to Orchard receivers created before Ironwood activation would automatically be received as ZEC in the new pool.

Timing

Like most network upgrades, Ironwood will require development, testing, review, and coordination across the ecosystem. Experience has shown that this work often takes longer than expected, so we believe it is better to be conservative when discussing timelines than to overpromise and underdeliver.

One additional source of uncertainty is the ongoing deprecation of zcashd. While Shielded Labs has not been directly involved in that effort, the migration of exchanges, mining pools, wallets, and other infrastructure providers to Zebra may affect the timing of this network upgrade.

We expect to have a better understanding of the timeline as implementation plans mature and discussions continue.

Conclusion

We want to emphasize that we believe prior exploitation of the Orchard vulnerability is unlikely. But users should not have to trust our assessment, or anyone else’s, when it comes to the integrity of the Zcash supply.

Ironwood is designed to restore a guarantee of Zcash’s circulating supply that anyone can verify for themselves. Whether the vulnerability was ever exploited or not, the goal is the same: make the integrity of the Zcash supply something that can be verified.

We believe Ironwood is the best path forward and look forward to discussing this proposal with the Zcash community.

Acknowledgements

Thanks to Sean Bowe, Dev Ojha, David Campbell, Alex Bornstein, Nate Wilcox, Kris Nuttycombe, Vitalik Buterin, Balaji Srinivasan, and Taylor Hornby, Josh Swihart, and Tatyana for review and feedback. Especially thanks to Kris Nuttycombe for suggesting that the Ironwood upgrade disable transactions which create outputs in the old Orchard pool. This turns out to be critical for Ironwood to achieve its goal.

37 Likes
The Orchard Counterfeiting Vulnerability—And Next Steps
The Orchard Counterfeiting Vulnerability—And Next Steps
Four Questions About the Orchard Vulnerability
Four Questions About the Orchard Vulnerability
2

1500×600 171 KB

ZODL, working alongside Tachyon, Valar Group, the Zcash Foundation, and Shielded Labs, is proposing a new network upgrade and shielded pool called Ironwood. The new pool uses the existing Orchard protocol but backed by formal verification and additional independent audits. The total supply moved from Orchard to Ironwood will be verified by a turnstile, allowing anyone to audit Zcash’s circulating supply. For users, migration will be simple.

Ironwood is the next step in hardening the Zcash protocol. We plan to target its activation for late July 2026, following the zcashd end-of-support (block height 3,417,100). As with any network upgrade, timing depends on testing, review, and coordination across the ecosystem.

Current State

The recent Orchard soundness issue was discovered through ongoing security research, responsibly disclosed, and remediated through a coordinated network upgrade. There is no evidence that it was exploited, no evidence of impact to user funds, and no evidence of any change to the total ZEC supply. The issue did not affect the privacy of funds in any pool, and Orchard is live and operating normally.

Ironwood

The current Orchard pool will be closed to new deposits and internal transactions so that the funds in that pool can only move forward through the turnstile before entering Ironwood. Because the turnstile rejects any attempt to move out more ZEC than entered, users gain an immediate, trustless guarantee that no more than the correct amount of ZEC can be circulating, without waiting for anyone to migrate. The upgrade is paired with independent audits and formal verification of the circuit with the goal of ruling out any further soundness bugs.

The User Experience

Today, users can simply receive and send Orchard funds as usual. Following the upgrade, wallets that support Orchard will be able to prompt users to migrate funds with a single click.

The new pool will use the user’s existing Orchard receiver, so previously used addresses will continue to work.

Where ZODL is contributing

We have already begun this work on behalf of the community and ecosystem, including coordination with other core contributors. This work includes:

  • Completion of work necessary for zcashd deprecation. This includes Zallet, a new command-line wallet that replaces the wallet built into zcashd. In parallel, Valar Group is building a wrapper so that current users of the zcashd wallet can keep using it until they migrate to Zallet.
  • Participation in the formal verification of the new pool.
  • Working with the Zcash Foundation on the rollout of zebrad to node operators still running zcashd.
  • Updating the ZODL wallet and SDKs to support Ironwood.
  • Coordinating across the community, including infrastructure and wallet providers, to ensure readiness.
  • New tooling to support Zcash users and the ecosystem.

We will continue to share more as our work progresses.

24 Likes
Zcash Z3 updates (formerly Zcashd Deprecation)
3

I think Ironwood is a necessary and valuable proposal, but there is one risk that I believe the community should discuss more explicitly: the tail-risk of a “run” on the old Orchard pool if a large amount of counterfeit ZEC had actually been created.

1. If there was no counterfeiting, Ironwood works very well

If there was no counterfeit ZEC in the old Orchard pool, then migration is straightforward:

Old Orchard → turnstile → Ironwood

In that case, the benefits are clear:

  • the old Orchard pool is gradually retired;
  • Ironwood becomes the new shielded pool;
  • nodes can once again verify circulating supply by checking pool balances;
  • market confidence may partially recover.

Under this scenario, the main risks are implementation risk, wallet upgrade risk, user experience risk, and some privacy leakage during migration.

2. If the counterfeit amount was small, the problem may still be manageable

If a small amount of counterfeit ZEC existed, for example hundreds, thousands, or even tens of thousands of ZEC, then relative to the several million ZEC in Orchard, the impact may be manageable.

In that case, counterfeit funds attempting to exit may only become visible near the end of the migration process.

The possible impact would be:

  • some tail-end migrations may fail;
  • the community may observe an attempted excess exit from the old Orchard pool;
  • the market may react negatively in the short term;
  • but the overall supply would not become uncontrolled.

In this case, the community could still discuss possible compensation, emergency support, community funding, donations, or governance-based remedies. The difficulty would be relatively limited.

3. The real danger is if the counterfeit amount was large

The hard question is what happens if a large amount of counterfeit ZEC was created inside Orchard.

Because Orchard is private, the chain cannot easily distinguish:

  • which note belongs to an honest user;
  • which note was created by a counterfeiter;
  • which note exits first;
  • which note exits later.

So if a large amount of counterfeit ZEC exists, a very difficult situation could arise:

Whoever exits through the turnstile first may consume the available exit capacity of the old Orchard pool.

If a counterfeiter moves early and sends counterfeit funds into Ironwood before the turnstile limit is reached, those funds may appear to have migrated successfully. Later, if honest users try to migrate after the old Orchard exit capacity has been exhausted, their funds may fail to migrate.

This means that the supply may be protected, but the loss could fall on the users who migrate last.

In other words:

The turnstile is a supply-integrity firewall, but it is not necessarily a fair-loss-allocation mechanism.

This is why I think this concern is not FUD. It is a real edge case that the Ironwood proposal should address directly.

4. The loss would not be borne by all ZEC holders equally

This distinction is important.

If Ironwood activates successfully, the transparent pool, Sapling, Ironwood, and future inflows should be protected by the turnstile mechanism.

The highest risk is concentrated among users who still hold old Orchard notes after activation and migrate late.

Their risk is not general ZEC dilution. Their risk is that:

  • the old Orchard exit capacity may be consumed;
  • their old Orchard funds may not migrate successfully;
  • they may need to rely on dispute resolution, compensation, or governance remedies.

This is why wallet migration design, migration timing, user communication, and a compensation plan are very important.

5. The community should define a loss-handling plan in advance

I think the community should publicly answer several questions before activation.

First: if an excess exit from old Orchard is detected, who bears the loss?

It may not be enough to say “we believe exploitation was unlikely.” There should be a clear contingency plan.

For example:

  • Would the Zcash community governance fund compensate affected users?
  • Would Shielded Labs, ZF, ZODL, or other ecosystem organizations coordinate a backstop?
  • Would a future block reward or dev fund mechanism be used?
  • Or would the protocol explicitly state that no compensation is possible and users bear the risk themselves?

If this is not clarified in advance, a real incident could create a major governance and trust crisis.

Second: how would an affected user prove that they are a legitimate victim?

This is probably the hardest part.

A user may be able to prove control of Orchard notes, provide viewing keys, wallet records, or failed migration evidence. But this may harm privacy. Also, even if someone proves control of a note, it may still be difficult to prove that the note originated from legitimately entered ZEC rather than from counterfeit creation, because Orchard’s internal transfer history is private.

So a compensation plan cannot simply say “victims must prove their loss.” The proof and privacy tradeoffs need careful design.

Third: should migration be rate-limited, queued, or batched?

If migration is completely open and instant, users may rationally rush to migrate early, creating a “first out wins” dynamic.

Possible mitigations include:

  • batch migration;
  • wallet-level staggered migration;
  • a longer migration window;
  • stronger warnings for large migrations;
  • coordination with exchanges, wallets, miners, and infrastructure providers.

But each mitigation has tradeoffs. The more complex the process becomes, the more users may panic. The more restrictive it becomes, the more it may feel like social intervention rather than neutral protocol behavior.

Fourth: should there be an emergency compensation pool?

I think this is very important.

Even if the team believes exploitation was unlikely, there should be a contingency fund or emergency backstop.

Even a principle-level plan would help reduce market fear.

For example:

  • if the excess shortfall is below a certain threshold, such as 10,000, 50,000, or 100,000 ZEC, the ecosystem fund may cover it;
  • if it exceeds that threshold, it goes to community governance;
  • if it is extremely large, then the network upgrade strategy may need to be reassessed.

Otherwise, affected users may ask:

“You protected the total supply, but my funds cannot migrate. Who is responsible?”

6. Other risks to consider

Besides the run-risk, I think there are several other important risks.

Technical risk.
Ironwood is a new network upgrade involving a new pool, wallets, SDKs, nodes, exchanges, mining pools, Zallet, and Zebra migration. Implementation or coordination failures could cause chain splits, wallet recognition issues, or exchange deposit and withdrawal suspensions.

Privacy risk.
Migration reveals the amount and timing of transfers. Even if existing Orchard receivers continue to work, the migration from old Orchard to Ironwood creates observable on-chain events. If many users migrate around the same time, analysts may use timing, amount, and wallet behavior to make correlations.

User experience risk.
Ordinary users may not know whether they need to migrate, when they should migrate, or what happens if they do not migrate. Poor wallet messaging could easily create panic.

Market confidence risk.
Even if no counterfeiting occurred, public discussion of “late migrators may bear the loss if counterfeit funds existed” could itself affect market confidence and price.

Responsibility-boundary risk.
Zcash is a decentralized protocol, not a bank with a clearly defined insurer. If the responsibility boundary is not clarified before activation, a crisis could turn into a blame game: users blame wallets, wallets blame the protocol, protocol developers say the chain cannot distinguish valid and counterfeit notes, and foundations may say they have no legal compensation obligation.

Conclusion

I support the direction of Ironwood, and I agree that restoring supply verifiability is critical.

But I think Ironwood needs a clear contingency plan for the extreme case where old Orchard contains a large amount of counterfeit ZEC.

Ironwood can answer the question:

“Can the total circulating supply be made verifiable again?”

But the community also needs to answer:

“If old Orchard contains a large counterfeit amount, and late-migrating honest users cannot exit, who bears that loss and how is it handled?”

Without answering that question in advance, the protocol may restore technical supply integrity while still leaving a serious social and governance risk unresolved.

6 Likes
4

Turnstile in this case would be Orchard → Taddress → Ironwood address?

1 Like
5

Is it possible in the future to cryptographically verify the integrity of a shielded pool without relying on turnstile like this? Forced migration to new pool just to audit its soundness, in my opinion, is not ideal user experience.

But more importantly, many users would not have confidence in the integrity of new pool, wondering if there is any actively exploited vulnerability. It has happened with Sprout and Orchard. We need users to have confidence in shielded pool, otherwise they’d just park money in transparent pool, or not using Zcash at all.

1 Like
6

I don’t think we need contingency planning for this case. The Orchard pool was not exploited. Full stop. The idea that any attacker wouldn’t have dumped the coins by now, knowing they will become worthless shortly, is laughable. Let’s do the upgrade as quickly as it can be done safely and get back to talking about Project Tachyon instead of endless low-information FUD.

5 Likes
7

We can’t know for sure that Orchard was not exploited. But i agree that this proposal seems like a panic and desperate attempt to ‘fight the FUD’, likely driven by obsession with market price of Zcash.

Real solution would be formal proof of integrity for shield pool, without leaving it.

3 Likes
8

I support Ironwood for NU7

4 Likes
9

I understand the reason for this proposal to truly verify that the bug wasn’t exploited. It’s not ideal, but I understand it’s necessary for the good of Zcash, as it would eliminate a constant source of uncertainty regarding the ZEC supply. I believe this measure will incentivize users to migrate even before the proposal is approved, since there is a possibility (albeit a very small percentage) that there will be more ZEC than there should be, activating the turnstile.

One suggestion I’d like to make is that if someone wants to withdraw their ZEC from Orchard to minimize risk, they shouldn’t do it in a transparent address, as some suggest in monero, but rather towards sapling. This way, the protected ZEC count won’t decrease, which has been a major point of contention since the supply was increased from 1 to 5 million coins.

2 Likes
10

it would be good to also mention how we would respond in the worst case

3 Likes
11

Agree with this in principle, but in practice it’s not likely workable for many if not most. @hanh-designed wallets can do this (pretty easily in Ywallet, possible but a little tricky with Zkool), but I think ZODL/Keystone are the most used shielded options these days.

2 Likes
12

1780779328577
17807793285771408×768 492 KB

5 Likes
13

Hi Zooko :slight_smile: Here’s an idea: If counterfeit $ZEC is ever confirmed, we immediately send the fake coins to a burn address to protect the 21 million supply cap. Then, depending on the scale, we create a voluntary community recovery fund. We ask ZEC holders to donate what they can to make the victims whole again.Think about it if we as a community actually step up and take care of our brothers and sisters in liberty, it would be the first time in crypto history this has ever happened. The world would take notice. This kind of unity and integrity could easily send $ZEC to the #2 spot.I’ll personally donate some of my own ZEC if we do this. What do you all think?

14

A note here on “Poor wallet messaging could easily create panic.” - I suggest that the ideal approach to making the user experience as positive as possible is to frame Ironwood in wallet messaging as exactly what it is, which is a significant upgrade for ZEC. The old saying that “trust is earned” is relevant here, because practically speaking, migration simply results in added security and peace of mind. Couple that with regular AI-assisted vulnerability probing and you have a much stronger currency capable of retaining additional earned trust.

3 Likes
15

It would be the same kind of turnstile we’ve already used (for transparent<-> Sprout, transparent<->Sapling, Sprout<->Sapling, transparent<->Orchard, Sprout<->Orchard, and Sapling<->Orchard). It doesn’t involve an actual t-address, but it does reveal the exact amount and block height of the transaction, so it functions kind of like it would if you used a t-address but you used that one t-address only for that one transaction.

So there are… let’s see… 6 turnstiles in effect right now, although the ones that border Sprout are one-way turnstiles because you can’t send money from outside of Sprout into Sprout.

I guess when Ironwood activates there will be four additional turnstiles. So maybe as the number of pools grows we should stop talking about turnstiles sitting between pools (of which there will soon be ten) and start just focusing on the pools (of which there are currently four and will soon be five). The important technical fact is that each separate pool has its own balance, and that the consensus rules enforce supply soundness (non-inflation) of each pool’s balance without disclosing anything about the individual transactions that occur within that pool.

Does that answer your question?

I guess the answer to your question is, the turnstile would be Orchard → Ironwood (or Orchard → some other pool!), but would not involve a separate t-address.

1 Like
16

This is a great question.

The negative side of the answer is that there is no way to audit transactions that happen within a shielded pool (in order to verify that they don’t counterfeit money and inflate the supply) without also thereby compromising the privacy of those transactions.

The positive side is: yes there is! It’s zero-knowledge-proofs. Every Zcash shielded transaction comes with a zero-knowledge-proof that it does not inflate the supply. That’s the first line of defense against counterfeiting!

The negative side is, but wait, that’s the line of defense that failed in 2019 in Sprout (CVE-2019-7167) and just failed again in Orchard!

The positive side is, yes, but we can further strengthen the first line of defense! (While also noting that the second line of defense—turnstiles and Ironwood-style remediation—turns out to be extremely valuable by limiting the blast radius in case of a failure of the first line of defense.)

How to strengthen the first line of defense? :slight_smile:

There are multiple ways to do that! Here are a few starting with the earliest:

(I’m using “zero-knowledge-proof” here as a shorthand for the ZKP system and the circuits, for any geeks reading this.)

  1. There is a right-now way to do that — more and better AI-assisted auditing of the zero-knowledge-proof verifier — which Shielded Labs (and others) have already been doing and we are doubling down on it as we speak. (This is how the Orchard counterfeiting vuln was discovered and fixed before any attackers discovered it.)
  2. There is a medium-term way to do that — it’s called “formal verification” and it means writing (with computer/AI assistance) a proof that the zero-knowledge-proof-verifier is bug-free. (Note that there are two different kinds of “proof” in this story — zero-knowledge-proofs and formal-verification-proofs. Confusing!) Tachyon Group and Valar Group have already started on doing that for the Orchard logic and they might be able to complete it before Ironwood activates. Shielded Labs will help if we can.
  3. There is a longer-term way to do that — design the cryptography of the zero-knowledge-proof system from the ground up to be easier to ensure it is correct. Tachyon Group is currently doing that for their future Tachyon pool (for an intensely technical description of that work, see their blog post).
  4. Another longer-term option would be to layer two ZKP systems together, so that in order to counterfeit ZEC an attacker would have to find and exploit bugs in both of them at the same time—and the bugs would have to “line up” so that a single malicious proof could exploit both of the separate bugs in the separate verifiers. Ethereum has been researching how to do that for their zkEVM project(s), so maybe we could learn something from their experience.

Anyway, those are the first four ideas that come to mind for strengthening our first line of defense. The first three of them are already in flight!

5 Likes
17

I actually agree. There has never been a counterfeiting vulnerability discovered in Sapling. If I were worried that the Orchard counterfeiting vuln was exploited, I would move my ZEC from Orchard to Sapling. One limitation is that not all wallets support Sapling. But anyway, I’m comfy in Orchard for now. :slight_smile:

2 Likes
18

It would take less than 20 transactions to exploit the attack to have counterfeit notes equal to the size of the orchard pool.

If there are either zero or a huge number of counterfeit notes in the orchard pool.

The small percentage of counterfeit notes scenario is implausible

4 Likes
19

@fivelittleducks I’ve made some (bolded for visibility) edits above in your number three scenario and I’m curious whether you think my edit is more or less accurate than what you originally wrote. And if it’s more accurate, I’m really curious why you chose to write it the way you wrote it in the first place.

This is an honest question: I really don’t know if there is something I don’t know that makes your ambiguous wording more accurate than my definite wording and if there is, I’m curious to know.

Personally, I think that the only really fair thing to do is to acknowledge in the unlikely case that an actual exploitation took place that the collective value in the pool was compromised and to equally socialize that loss over everyone. Plain old inflation just like in the fiat money supply. The only real difference is that instead of happening via the actions of bad actors wearing suits at the Fed, it’s happening via the actions of bad actors in a basement somewhere, almost certainly wearing a t-shirt. Maybe under a hoodie, season-depending.

If the inflation was small-ish, then zcash probably survives. If the inflation was large-ish, then it probably goes the way of the Weimar Papiermark. But in either case, no favored winners and losers.

1 Like
21

If a large counterfeit loss is ever confirmed, I do not think any small group of users should be forced to bear that loss alone. Users should not be made to absorb the entire consequence simply because they migrated later, used a specific pool, or happened to be in the wrong place at the wrong time.

In that scenario, the collective value of the ZEC monetary system has been impaired. The loss should be shared proportionally across the broader ZEC monetary base through dilution, rather than concentrated on old Orchard users or any other narrow group.

2 Likes