← ZEC Stats

Zcash Ironwood Pool

◈
Live since block 3,428,143
…
of Orchard coins have crossed the turnstile into Ironwood
 
…
Value migrating / day
…
Total value migrated
…
Migrated into Ironwood
…
Orchard remaining
…
Blocks since activation
…

How much supply is verified?

…verified

Every pool except the un-migrated Orchard balance is treated as verified supply; the remaining Orchard value is what has yet to cross the turnstile.

Ironwood is the newest official Zcash shielded pool, live since block 3,428,143. This page tracks the turnstile migration: value leaving the older Orchard pool and re-shielding into Ironwood. The headline percentage is Orchard coins that have crossed into Ironwood, over Orchard's coin balance at the activation block. Balances refresh every block, about every 75 seconds.

What that percentage counts, and what it leaves out

It counts crossings, not holdings. Coins that crossed and later left Ironwood still count.

It is Orchard only. Transparent and Sapling coins have flowed into Ironwood too. Those show up in “Migrated into Ironwood”, in the full Ironwood balance, and in the source breakdown further down this page.

The denominator is fixed: Orchard's balance at the activation block, never today's. So an ordinary Orchard→transparent spend moves neither half of the fraction. A live denominator would shrink on every such spend, and the percentage would climb on days when nothing migrated at all.

How many coins cross per day?

Orchard → Ironwood, ZEC per day

Ironwood inflow attributed to Orchard as its source, bucketed by the UTC day the block landed. These are crossings, not net holdings — coins that crossed and later left Ironwood still count — and they sum to the Orchard row of the source breakdown below. They deliberately won't match the “value migrating / day” card, which is the net change in the whole Ironwood balance (every source, minus what left) over the last 24 hours, in dollars.

fully attributed daypartial — day in progress or still being scanned

How big is a typical migration?

Cumulative distribution of migration size, ZEC per transaction

Every transaction that has moved value into Ironwood since activation, from all source pools — one point per transaction, not per block, since a single block can carry a dozen migrations. Read it as: y% of migrations were this size or smaller. The x-axis is logarithmic because migration sizes span several orders of magnitude, so a linear axis would flatten the whole retail end into the left edge. Amounts are what each transaction moved into Ironwood, before any of it later left.

Where did the migrated value come from?

Loading…

Per-transaction attribution: each Ironwood inflow is traced to the pool (or transparent funds) that supplied the value in the same transaction. These are cumulative inflows since activation, not a balance — outflows are not subtracted, so the total sits above the live Ironwood balance by whatever has since left the pool. Updated as new blocks are scanned.

What is in each pool today?

Loading…

Read this next