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.