NozyWallet Ironwood (NU6.3): Migration Case Breakdown and v2.4.0 CLI Release

Technology Zebra
1

NozyWallet · LEONINE-DAO · July 2026

This post summarizes how NozyWallet approached Ironwood migration as a privacy decision, what we validated on Zcash testnet, and the v2.4.0 CLI release that ships that work. NozyWallet is an Orchard-first wallet built for Zebrad and lightwalletd with local witness derivation.

Context and links

  • Forum thread — Ironwood: Verifying the Soundness of Zcash’s Circulating Supply
  • ZIP 318 — wallet migration draft (PR #1317)
  • NozyWallet v2.4.0 release — CLI binaries (Windows, Linux, macOS)
  • IRONWOOD_WALLET_READINESS.md — full operator readiness log in the repo

Target mainnet NU6.3 activation: approximately 21 July 2026 (miner timeline; final activation height pending in zcash_protocol).

The migration question

Ironwood is not just a new pool name. NU6.3 introduces a new shielded pool, V3 notes, V6 transaction semantics, and a wallet migration story (ZIP 318) written to protect privacy during the move from Orchard.

NozyWallet is already Orchard-first. The design question was separate from “Orchard vs Sapling vs transparent”: how should we move existing Orchard funds into Ironwood without turning a protocol upgrade into a wallet fingerprinting event?

Case breakdown (Cases 1–4)

Case 1 — Do nothing after activation

I could keep scanning and spending only Orchard notes after NU6.3 activation. That is the smallest engineering change, but it makes the wallet lag the network, leaves users on a legacy shielded path, and risks distinctive Orchard-only behavior after activation.

Conclusion: acceptable only as a short safety stop. Post-activation, Ironwood routing is the target.

Case 2 — Migrate everything immediately

I could spend all Orchard notes into Ironwood as soon as activation happens. Simple to explain, but weak for privacy: one-shot migration clusters notes, creates unusual transaction shapes, and removes user control over timing, fees, and network conditions.

Conclusion: too blunt for a privacy-first wallet except as an explicit emergency path.

Case 3 — ZIP 318-style scheduled turnstile migration

NozyWallet’s preferred path: Orchard spend → Ironwood output, planned in staged windows.

  • ZIP 318 targets wallet migration behavior, not ordinary payments.
  • Canonical power-of-ten denominations reduce amount fingerprints.
  • Shared anchor-height buckets reduce timing fingerprints vs ad hoc sends.
  • Persisted schedules support recovery from missed windows.
  • User consent stays explicit before any migration broadcast.

Conclusion: the right default — Ironwood migration is a privacy operation, not just a balance transfer.

Case 4 — Post-migration normal sends

After migration, normal shielded sends should use Ironwood for recipient and change. Otherwise the wallet keeps recreating the same migration problem with new Orchard outputs.

Conclusion: migration is not complete until normal send routing stops producing new Orchard-only wallet state. Phase 3.4 shipped on testnet; v2.4.0 published the CLI.

Product decision

  1. Detect NU6.3 activation and Ironwood-capable RPC.
  2. Show Orchard and Ironwood pool status separately.
  3. Plan the ZIP 318-style schedule before broadcasting.
  4. Require user consent before migration execution.
  5. Prefer scheduled turnstiles over one large migration.
  6. Route post-activation normal sends to Ironwood once V6 builder support is validated.

Testnet validation (summary)

I ran the full operator loop on a dedicated testnet profile (Ironwood Testnet) against WSL Zebrad and ironwood-valar lightwalletd — not as compile-only checks, but with confirmed transactions on chain.

Operator tooling

ironwood status / plan / preflight / migrate / broadcast

Not in v2.4.0 by design: desktop Send wiring, Keystone Ironwood hardware sign path, API server on releases. The CLI is the authoritative state machine; other surfaces should consume it rather than reimplement migration logic.

Reflection — As a junior mid-level wallet developer

Shipping Ironwood in NozyWallet was one of the most meaningful stretches of work in the project’s first year. The work sits on a real protocol transition in Zcash history and not a cosmetic version bump.

Taking an Orchard-first, Zebra-backed wallet through testnet from mainet because we built Nozywallet on mainnet no testnet into ironwood. From spendable Orchard notes, through turnstile migration, to a confirmed normal Ironwood send and felt like participating in the ecosystem’s next chapter rather than reading about it from the sidelines. No delays in Nozywallet process and we ready for mainnet soon this history in making and the world watching, I had to get on top of this migration to Ironwood.

What made the experience good

  • Clear product cases. Cases 1–4 gave vocabulary for trade-offs. When testnet failed (empty Ironwood balance after turnstiles, missing witness hex, send blocked post-activation), we could name which case broke and fix the right layer.
  • Evidence over optimism. Milestones tie to commands, TXIDs, block heights, and script output — important when building on pre-release librustzcash pins.
  • Real infrastructure. WSL Zebrad, ironwood-valar lightwalletd, local witnesses, and the existing proving stack — integrated into a shielded-first wallet, not a demo.
  • Release as closure. v2.4.0 turned months of case notes into binaries other developers can download.

As a mid-level wallet developer, Ironwood was the right difficulty: deep enough to force learning (domains, pools, V6 PCZT, migration windows), bounded enough to ship a CLI milestone before mainnet activation. Remaining work and desktop UX, hardware signers, full compact sync the extends a validated core instead of replacing a guess.

What comes next

  1. Mainnet week — upgrade Zebrad + LWD, confirm activation height, repeat operator loop on mainnet.
  2. Desktop / API — wire Send and migration UX to the CLI state machine.
  3. Keystone — Ironwood hardware sign path (software send validated).
  4. Compact sync — full scan over Ironwood actions beyond LWD smoke.

Closing

The case breakdown started as a privacy decision document. It ends as a release backed by testnet proof: NozyWallet can scan Ironwood, migrate Orchard funds through ZIP 318-shaped turnstiles, and send normally in the Ironwood pool from the CLI.

That is a good place to be three years into wallet development — and a solid foundation for mainnet.

NozyWallet · LEONINE-DAO ·

NozyWallet · Release

9 Likes
2

Congrats on the release. I’ve been testing the desktop wallet against my own Zebra node over SSH and it’s been really interesting watching the Ironwood work progress. Looking forward to seeing the remaining desktop pieces land and trying the mainnet migration once NU6.3 activates.

1 Like
3

Yes, desktop is cooking now well done. I’m going to work on the buttons etc. with desktop as well so it can look nice for everyone.

4

Awesome, looking forward to it. The desktop has already been straightforward to navigate during testing, so the UI polish will make it even better. Happy to keep testing future builds.

1 Like
5

Your help been very helpful and keeping down bugs etc. testing is very important in shipping good stuff.

1 Like
6

Appreciate that, Happy to help. It’s been fun testing against my own setup, and I’m looking forward to seeing Nozy continue to evolve. I’ll definitely keep reporting anything I come across.

1 Like
7

When only some wallets follow the ZIP 318 turnstile shaping and others migrate ad hoc, do the power of ten buckets still give real cover, or does the anonymity set only hold once most Orchard funds move the same shaped way?

1 Like
8

The power-of-ten buckets still give real cover under partial adoption, but only among the wallets that follow ZIP 318. Ad-hoc migrations do not dilute that cohort and they mostly sit outside it. Full ecosystem cover only appears once most Orchard funds move with the same shaped schedule.

9

The Case 1–4 framing is genuinely useful; being able to name which case broke when testnet fails is how you fix the right layer instead of guessing.

Two things I’d add to the partial-adoption point from the exchange above. First, the anonymity set is really over (denomination × broadcast window), not just the denomination. Case 3 already leans on shared anchor-height buckets, which is the right instinct, but that timing only buys ecosystem cover if other wallets bucket on the same schedule. Two wallets both on power-of-ten denominations but broadcasting on different cadences stay separable by their temporal distribution, so the cohort in your #8 answer is “wallets that shape the same way,” and shape has to include timing, not only amounts.

Second, the residual is where I’d expect most of the real linkage to sit. Canonical denominations tile the round part of a balance, but the leftover that doesn’t fit a bucket is a distinctive amount, and a distinctive turnstile crossing is linkable by subset-sum back to a plausible origin. Case 3 handles the canonical buckets well but doesn’t say what happens to the remainder, and that call (sweep it, hold it in Orchard, which is its own signal now that the pool is sealing, or fold it into a later bucket) is arguably the highest-leverage privacy decision in the whole flow. It’s the same toxic-change problem equal-output CoinJoin designs spend most of their effort on, so that prior art should transfer fairly directly.

1 Like