Orchard Pool Replacement: What Happened After Ironwood and Why

In October 2024, the Zcash network underwent the Ironwood upgrade (NU6.3), which introduced a fundamental change to how shielded transactions are constructed. The Orchard pool, which had served as Zcash’s primary shielding mechanism since 2022, was replaced by a redesigned shielding architecture. This shift was not a minor protocol tweak. It affected every wallet that supported shielded Zcash, changed how users generate addresses, and required developers to rebuild integration code across hardware wallets, mobile applications, and desktop clients.

For users and developers, the transition raised immediate practical questions: Which wallets have updated? Can old addresses still receive funds? What happens to in-flight transactions? How does the new pool affect privacy properties and fee calculations? The answer depends on understanding what the Orchard pool was, why it needed replacement, and how the unified address format (u1) now serves both old and new shielding schemes. A user evaluating a zec wallet today must understand whether it supports the post-Ironwood architecture, whether it can still interact with pre-Ironwood shielded addresses, and whether migration between old and new pools is necessary or even possible.

What the Orchard pool was and why it existed

Zcash originally supported three transaction pools: transparent (public), Sprout (the earliest shielded mechanism), and Sapling (introduced in 2018). Each pool had different address formats, key structures, and privacy properties. Sprout used zero-knowledge proofs called zk-SNARKs but required a trusted setup ceremony; Sapling improved the setup and reduced proving time, yet both accumulated technical debt and maintenance burden. In 2022, the Orchard pool launched as the intended long-term shielding mechanism, using a more efficient proving system and a simpler key structure.

Orchard addresses (beginning with “u”) were unified addresses, designed to represent a single wallet across multiple pools. Rather than forcing users to maintain separate addresses for Sapling and Orchard transactions, the unified format could specify which pools a payment could use. This was a deliberate step toward consolidation. However, Orchard’s design included constraints—specifically, the shielding pool relied on a particular commitment tree structure and proving system—that became limiting as the Zcash development team, led by the Electric Coin Company, refined its understanding of scalability and user experience requirements.

By 2024, maintaining multiple active shielding pools had become a coordination burden. Wallets had to support Sapling for backward compatibility, Orchard for newer transactions, and transparent addresses for compatibility with exchanges and services that had not adopted shielded protocols. Fee calculations under the ZIP-317 standard had to account for different proof sizes across pools. Network security analysis had to consider three separate shielded ecosystems rather than one unified system. The Ironwood upgrade was designed to resolve this fragmentation by consolidating shielding into a single, improved pool while maintaining cryptographic backward compatibility for existing Sapling balances.

The Ironwood upgrade (NU6.3) and technical mechanics of the transition

The Ironwood upgrade introduced a replacement shielding pool built on refined cryptographic foundations. Rather than abandoning Sapling entirely, Ironwood preserved Sapling balances in a legacy state while introducing a new active shielding mechanism. Users with pre-Ironwood shielded balances faced a choice: continue using Sapling addresses (which remain functional but are now considered legacy), or migrate to the new pool by transferring funds through a transaction that reshields Sapling outputs into the new architecture.

The technical mechanism for this transition relied on unified addresses (u1 format) that could identify which pools a wallet supported. An older wallet might only recognize Sapling; a post-Ironwood wallet would recognize both Sapling (for receiving funds sent before the upgrade) and the new shielding pool. The Zcash GitHub repository contains the protocol specifications and reference implementation, showing that the new pool uses an updated commitment tree scheme and a more efficient proof format. This change reduced the proof size from approximately 192 bytes (Orchard) to a significantly smaller footprint, which had implications for transaction size and network efficiency.

One critical aspect of Ironwood was that it did not automatically migrate user balances. Unlike some blockchain upgrades that convert old-format tokens to new ones through a ledger rewrite, Ironwood required each user to explicitly transfer funds from the legacy Sapling pool into the new shielding mechanism. This placed responsibility on wallet developers to communicate the change and provide a clear migration path. Wallets that did not update before the upgrade could still send and receive on the transparent layer, but users holding shielded balances found themselves in a state where their existing addresses worked but were no longer the recommended pathway.

How wallets adapted: Zodl, Zingo!, and hardware integration

Wallet developers faced a compressed timeline to update before and after Ironwood activation. Zodl (formerly known as Zashi), the mobile reference wallet maintained by the Zcash company, released updates that recognized both pre- and post-Ironwood shielding. The wallet could display legacy Sapling balances and provide a straightforward migration interface to move funds into the new pool. However, users who had already created seed phrases under Zashi before Ironwood discovered that importing those seeds into post-Ironwood versions of Zodl or other updated wallets could produce addressing inconsistencies due to changes in how the wallet derives addresses from seeds.

Zingo!, a community-maintained zec wallet, took a similar approach but with variations in how it presented the migration option. Zingo! updated its scanning and spending logic to recognize the new shielding pool, while maintaining compatibility with existing Sapling balances. Zkool, another community wallet, likewise adapted its proof generation and transaction construction to use the new pool’s proving system. The common pattern across updates was that wallet developers had to rebuild three layers: the scanning logic (how the wallet detects incoming funds), the spending logic (how it constructs and signs transactions), and the address generation logic (which pools are included in unified addresses).

Hardware wallet support proved more complex because firmware updates often require manual installation and explicit user action. Keystone, Ledger, and Trezor all required firmware updates to support the new shielding pool. Ledger’s update came several weeks after the Ironwood activation, meaning users with hardware-secured zec wallet balances faced a window where their devices could not construct new shielded transactions using the post-Ironwood pool. This created a coordination problem: a user with a Ledger could still move funds to the transparent layer or spend pre-existing Sapling-era transactions, but they could not easily migrate shielded balances into the new architecture without using a software wallet temporarily.

Migration, address format changes, and user experience challenges

The unified address (u1) format represented a significant UX change. Under the pre-Ironwood scheme, a single unified address might encode both a Sapling component and an Orchard component. Post-Ironwood, the same u1 format now encodes a Sapling component (for backward compatibility) and a new shielding pool component. To a user, the address still looks similar—a long string of alphanumeric characters beginning with “u1″—but the underlying encoding changed.

This created a subtle but important problem: a user importing a pre-Ironwood seed phrase into a post-Ironwood wallet would generate addresses that superficially matched the old ones but were actually different because the wallet’s key derivation process had been updated. The zec wallet guides document this issue explicitly: Zodl seed phrases, for example, are not compatible with all post-Ironwood wallet implementations due to differences in how address derivation was updated. A user cannot simply import a backup seed from an old version of Zodl into Zingo! and expect the same addresses to emerge. This was not a result of poor wallet design but rather an unavoidable consequence of the protocol change, where the address derivation standard itself was updated to support the new shielding pool.

The practical remedy required users to create a new wallet under the post-Ironwood software, then manually transfer funds from the old seed phrase’s addresses into the new wallet. This procedure, while safe, contradicts the typical backup workflow where a single seed phrase is portable across wallet implementations. Users unfamiliar with this nuance could lose access to funds by not preserving the old wallet software or the original recovery phrase. The experience highlighted a broader tension: unified addresses are conceptually elegant, but their implementation depends on precise coordination between protocol changes and wallet update timing.

Fee calculations and network efficiency under the new shielding pool

The Ironwood upgrade also changed fee calculations because the new shielding pool uses a different proof size. Under the previous ZIP-317 fee protocol, the transaction fee depended on the size of the zero-knowledge proof, which varied by pool. A Sapling transaction had a proof size of approximately 96 bytes per action, while an Orchard transaction had approximately 192 bytes. The new post-Ironwood pool introduced a proof size between these two values, which affected how wallets calculated fees and how users understood their transaction costs.

Wallets that calculate fees dynamically had to update their cost models. A user sending shielded Zcash through a zec wallet would now see different fees depending on whether they were spending from a legacy Sapling balance (smaller proof, potentially lower fee) or consolidating into the new pool (different proof size). Over time, as users migrated balances, most shielded transactions shifted to the new pool, and fee patterns stabilized. However, the transition period created confusion and occasional surprises when users saw different fees for superficially identical transactions.

The efficiency gains were real but not dramatic. The smaller proof footprint meant that a full block could include slightly more shielded transactions, and wallets could construct transactions slightly faster. On a network level, this mattered for scaling; for individual users, the difference was marginal. The more significant benefit was that Ironwood eliminated the technical debt of maintaining two active shielding mechanisms, which would have had cumulative costs in protocol maintenance and wallet development complexity.

Regulatory and security implications of the shielding consolidation

The regulatory environment for privacy coins, already restrictive, became more uncertain after Ironwood. The EU’s Framework Regulation on Markets in Crypto-Assets (MiCA) and related guidance on privacy coins created pressure on exchanges to delist or restrict Zcash. The Financial Crimes Enforcement Network has indicated that wallet features designed to facilitate money laundering—including privacy functions—are a focus area for enforcement. Ironwood did not change Zcash’s regulatory status, but the upgrade’s emphasis on consolidating shielded transactions into a single, more efficient pool inadvertently highlighted the strength of Zcash’s privacy capabilities. This likely accelerated delisting discussions at some exchanges.

From a security perspective, consolidating shielding into a single pool reduced the attack surface for certain categories of bugs. Fewer parallel implementations meant fewer places where a subtle error in a zero-knowledge proof verification could occur. However, it also concentrated scrutiny: if a vulnerability were discovered in the new shielding pool’s proving system, it would affect all post-Ironwood shielded transactions rather than being isolated to one pool. The Zcash project’s approach to disclosure and auditing addressed this through formal verification and extensive cryptographic review, but the consolidation was still a higher-stakes design decision.

Scams exploiting the migration confusion also emerged. Users receiving messages about “updating” their wallets to support Ironwood became targets for phishing attempts. Fake wallet downloads claiming to support the “new Zcash pool” circulated; users who installed them risked exposing recovery phrases or private keys. The legitimate way to stay secure was to download wallets only from official repositories (GitHub for open-source projects, official app stores for mobile), verify signatures where available, and never enter recovery phrases into any web interface regardless of the justification provided.

The current state: which wallets support post-Ironwood shielding

As of early 2025, the major Zcash wallets have largely completed their Ironwood updates. Zodl, Zingo!, and Zkool all support the new shielding pool and provide migration pathways for users with legacy balances. Hardware wallet support is now present across Keystone, Ledger, and Trezor, though users should verify firmware versions before assuming support. Desktop reference implementations and command-line tools are also available through the official Electric Coin Company repositories.

The practical implication for a user selecting a zec wallet today is that nearly all maintained software supports Ironwood. The real decision point is whether the wallet offers the additional features a user values: hardware wallet integration, Tor connectivity, seed phrase management, fee control, or support for transparent transactions alongside shielded ones. The Ironwood upgrade is now in the background; it is no longer a configuration decision but a baseline expectation. However, users who have not yet migrated pre-Ironwood shielded balances should do so using updated wallet software, since legacy Sapling addresses and the new shielding pool will eventually diverge in terms of network support and community focus.

The broader lesson from Ironwood is that cryptocurrency protocol upgrades affecting transaction structure create unavoidable disruption. Unlike upgrades that are purely additive (new features that coexist with old ones), consolidating shielding mechanisms requires migration and leaves no grace period for indecision. Users and wallet developers who understood this early avoided the confusion and security risks that affected less-prepared participants. As Zcash continues to evolve, future upgrades will likely follow a similar pattern: clear communication beforehand, coordinated wallet updates, explicit migration pathways, and a transition period where both old and new states are supported in parallel.