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 counts coins, not dollars, and is Orchard-only: Orchard-sourced ZEC that has entered Ironwood, over Orchard's ZEC balance at activation. It counts crossings, not current holdings — coins that crossed and later left still count — and it excludes the transparent and Sapling coins that also flowed into Ironwood — that appears in "Migrated into Ironwood" (the full Ironwood balance) and in the source breakdown below. That denominator — Orchard's balance at the activation block — is fixed, not recalculated. An ordinary Orchard→transparent spend that isn't part of the migration doesn't move the percentage either way; only value actually crossing the turnstile does. A live denominator (current Orchard balance instead of the activation-time one) would creep upward from that kind of ordinary spending even with no new migration, so we deliberately don't use one. Balances refresh every block (~75-second target spacing).
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.
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.
| 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.
| Loading… |