Dashboard/Pools/Ironwood

Zcash Ironwood Upgrade & Migration Tracker

Zcash Ironwood is the formally-verified shielded pool introduced by NU6.3. CipherScan tracks its activation, Orchard migration, verified shielded supply, anonymity cohorts, and trustless turnstile activity directly from the chain.

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.

testnet

What the Zcash Ironwood upgrade changes

Ironwood keeps Orchard's Action and Halo2 proof system while adding its own note commitment tree, nullifier set, chain value pool, chain-history metadata, and v6 transaction format. Mainnet activation is fixed at block 3,428,143; testnet activation is block 4,134,000.

Turnstile audit

BALANCED
Verified shielded supply
26,362 ZEC
ZEC that has been cryptographically proven valid by passing through the turnstile into Ironwood.
26,362 ZEC
Migrated total
2,118
Migration txs
1,193 ZEC
Orchard out
26,362 ZEC
Ironwood in

Cohort waves

Migration volume per shared anchor boundary (~5.3h). Wallets that pick the same boundary mix together — each bar is one anonymity cohort.

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.

Anonymity set per cohort

How many migrations share each anchor boundary. Larger cohorts mean a bigger crowd to hide in.

19.4
Avg cohort
1
Smallest
164
Largest

Migration privacy analysis

Each dot is one migration. Green = common denomination (blends in with the crowd). Orange = distinctive amount (unique fingerprint that weakens privacy). The dashed lines show ideal denominations.

No migrations indexed yet

How wallets migrate Orchard funds to Ironwood

Wallet teams are implementing ZIP 318 as the production migration plan now. The specification reaches its finalized state through the behavior proven in production, so supported wallets can ship the migration flow while those operational details are settled.

  1. 01 · PREPAREThe wallet identifies Orchard funds and can split notes into migration-sized transfers.
  2. 02 · SCHEDULEThe user approves a plan that spreads transfers across shared anchor-height windows.
  3. 03 · BROADCASTSupported wallets submit pre-signed transfers in the background when the operating system allows.
  4. 04 · RECOVERIf a scheduled window is missed, the wallet prompts on the next open and continues the plan.

Ironwood uses the same address as the user's Orchard receiver; wallets track it as a distinct pool. Follow your wallet's release notes for availability and migration controls. CipherScan observes the resulting chain activity but does not initiate wallet transfers.

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.