Shielded Labs has expressed concerns regarding the potential delay of Zcash’s Ironwood upgrade, highlighting worries about the readiness of exchanges, mining pools, and wallet service providers. The activation was initially planned for late July.

Preparation Challenges Ahead of Ironwood

According to the executive director of Shielded Labs, Jason McGee, ecosystem participants are facing challenges as they prepare for the switch from zcashd to the newly proposed Z3 software stack. This transition is concurrent with the Ironwood upgrade, which aims to enhance the security of Zcash’s shielded supply following the discovery of a bug dubbed the “infinity” flaw in Orchard.

On July 3, McGee took to the Zcash community forum to discuss the state of readiness among operators. While some believe they can make the upgrade on time, others have indicated they will require additional time for necessary testing and deployment of the new software.

Migration and Key Features

The transition involves the phasing out of zcashd, a long-utilized component for connecting to the blockchain and processing transactions. It will be replaced by:

  • Zebra for running network nodes.
  • Zaino for blockchain data services.
  • Zallet for wallet functionalities.

Both Zalet and Zaino are still in development and are not fully production-ready, complicating the timelines for many in the ecosystem. The Zcash migration guidelines suggest that not all features from zcashd will have direct counterparts, prompting operators to potentially tweak their existing setups.

The Dilemma of Timing

The dual migration of software and the Ironwood upgrade raises significant questions. If Ironwood is delayed, it could prolong uncertainty surrounding Zcash’s shielded supply. Conversely, moving forward without adequate preparation could present challenges for exchanges and other participants migrating to the new protocols.

The Ironwood upgrade was proposed in light of significant vulnerabilities found in Orchard, Zcash’s main shielded transaction pool. Developers noted that the identified bug could have allowed malicious actors to create unlimited counterfeit ZEC without immediate detection. Fortunately, they found no indications that this vulnerability had been exploited.