Orchard → Ironwood Migration
NU6.3 moves shielded value from Orchard into the formally-verified Ironwood pool through a trustless turnstile. The migration is engineered to be uniform on purpose — power-of-ten amounts, shared timing cohorts — so that individual moves blend together. This is what that looks like from the chain.
Turnstile audit
Cohort waves
Migration volume per shared anchor boundary (~5.3h). Wallets that pick the same boundary mix together — each bar is one anonymity cohort.
Populates at activation
Denomination collisions
Every migration output is a canonical power of ten (100 / 10 / 1 / 0.1 …). Amounts collide across wallets on purpose — that's the privacy design working.
Populates at activation
Anonymity set per cohort
How many migrations share each anchor boundary. Larger cohorts mean a bigger crowd to hide in.
Populates at activation
How we read it
A ZIP-318 migration is a v6 transaction with no transparent inputs or outputs whose Orchard value balance is positive (value leaving Orchard) and Ironwood value balance is negative (value entering Ironwood). Because a compliant migration creates exactly one Ironwood output and spends no Ironwood notes, the magnitude of the Ironwood value balance equals the output denomination — which is how we can chart the power-of-ten collisions even though the note itself is shielded. Cohorts are grouped by anchor boundary (provisionally every 256 blocks, ~5.3h). Migrations are best practice, not a linkage risk — our privacy scanner treats these uniform patterns as intended privacy behavior rather than flagging them.