Ironwood migration features in Zodl (upcoming)
Our features to automate migration to Ironwood will be delivered soon in an forthcoming update. The latest release of Zodl supports sending and receiving ZEC with the Ironwood pool.
Please see our main article on Ironwood steps for Zodl users, which includes details on manually migrating your funds if you so choose.
What will Zodl's migration features do that I cannot do myself?
It does three things that you cannot do yourself.
It controls the amounts. Rather than publishing figures that are unique to you, it works your balance into standard sizes, in the same way that cash comes in fixed note sizes. Everyone using the feature draws from the same small set, so many wallets produce transfers of identical value and the amounts stop identifying anyone. Amounts too small to be worth moving are left alone rather than exposed.
It separates the timing from your actions. Transfers do not go out when you tap a button, and they do not go out all at once. They are released quietly in the background on a randomized schedule, typically a few hours apart, and shuffled so that they cannot be linked to each other or to anything you were doing at the time.
It separates the connections. The wallet never checks the network and sends a transfer in the same background session, and it enforces a gap between the two. Doing both together is what would let someone connect them.
Before anything moves, you will see your Orchard balance, a plain explanation that the amounts crossing pools will be public, and the full schedule up front. Nothing moves without your consent.
Will it work with my Keystone?
Yes. The migration feature supports Keystone.
Is it automatic?
It needs your consent before it starts, runs on a schedule rather than instantly, and it is not designed to survive you moving to a new device partway through.
When will it be available? Why wasn't it in the first update?
We are working to release it as soon as we can, and it will arrive on iPhone and Android at the same time. What remains is further strenuous testing, fixing what the testing finds, and fine-tuning. That is the part we are least willing to rush, because a missed defect here is not a bug we can patch later. It would be a permanent public disclosure. We chose to build the version that protects people properly rather than the version that ships fastest.