Would a shared Orchard to Ironwood migration library be useful, or is everyone building it in-house?

Community Grants
1

Hi all. I’m a Rust dev looking at where I could contribute something durable
around Ironwood, and I want to sanity check an idea with the people who’d
actually use it before writing any code.

The situation as I understand it: once Ironwood is live, every wallet, exchange
and SDK that supports migration has to write its own turnstile-aware transaction
construction, track which funds have and haven’t moved, and handle edge cases
like partial migrations and retries. Shielded Labs flagged the failure modes
(value leaking across migration, funds getting stuck, replay of already-migrated
notes, incorrect cap handling) as a readiness risk.

What already exists: nuttycom sketched a migration-tool design in Zallet #481
(a migration bundle plus a background executor), Zaino #1343 tracks the indexer
side, and a “Turnstile Migration Integration Kit” grant application was declined.
So the need is acknowledged, but I don’t see a shared, reusable implementation
that multiple wallets could embed rather than each reinventing it.

The idea would be a small, reusable Rust crate that any wallet or SDK can use to:
construct turnstile-aware migration transactions, track migrated vs unmigrated
balances, and handle partial/retry edge cases, plus a set of conformance test
vectors so implementations can check they agree.

My honest questions, and a “no” to any of these is genuinely useful:

  1. Are wallet teams already solving this well enough in-house that a shared
    library wouldn’t get adopted? (The kit grant was declined roughly on “no
    developer ready to adopt it,” so I’d rather find that out first.)
  2. Is it too late to matter for activation itself, given the real migration
    window is the weeks and months after, as users actually move Orchard funds?
  3. If a shared library would help, what would you need from it to actually adopt
    it: what API shape, and at what layer (inside librustzcash vs a standalone
    crate)?

@nuttycom, since the Zallet #481 design is yours, I’d especially value your read
on whether a separate reusable crate makes sense or whether this belongs in the
wallet stack directly. And wallet teams (Zkool, Zingo, Zodl and others), would
you use something like this?

Thanks for any candid feedback.

2 Likes
2

Oh, I just saw this post. Migration from Orchard to Ironwood in Zcash wallets

1 Like
3

If smaller wallets end up building their own migration path under time pressure, does a shared library make it more likely they include the privacy-preserving option Zooko mentioned instead of just the bare turnstile-safe one, or is that a per-wallet choice regardless of tooling?

4

Good question, and honestly you just named the strongest reason to build it.

A library can’t force privacy on anyone. But it can make the privacy preserving
migration the easy default, so a wallet under deadline gets it for free instead
of hand-rolling the bare version and quietly dropping the privacy parts to ship
on time.

So it’s less “a library makes wallets choose privacy” and more “it makes the
private path the cheap one instead of the expensive extra.”

That said, the real question is for the wallet teams: is the privacy preserving
path already handled in-house, or is there a genuine risk smaller wallets ship

Would value a wallet team’s read here.

5

Making the private path the cheap default instead of forcing seems right, since deadlines are what strip privacy features first. Would the library ship with the private option on by default, or does a wallet still have to opt in and risk skipping it?

1 Like
6

Default on. That is the whole point.

If privacy were opt in, we would just recreate the problem: a wallet on a
deadline skips the flag and ships the bare version. So the private path is what
you get out of the box, with sane defaults already set.

Turning it off is still possible, but you have to do it on purpose, not by
accident.