How we count

The exact start height hasn't been assigned yet. Until it is, we use the height where ZIP 237's reissuance starts, as Zcash node software computes it:

• mainnet: block 16,026,474 − 2 × A
• testnet: block 16,235,274 − 2 × A

A is the NU7 activation heightActivation heightThe block number at which NU7's rules start. The network sets it; Burnwood reads it from the nodes.More on /method →. It's an estimate, and it will change if the proposals change.

ZIP 259 currently labels this height "February 2031" on both networks. For testnet that label is an error, and a correction has been proposed.

Blocks remaining

where A is the activation height reported by the network's nodes. The height is never hard-coded; if the network changes it, the countdown follows.

Estimated time of activation (ETA) and range

• Window: the last W = min(576, available) blocks (576 blocks ≈ 12 hours at 75 s). Below 48 blocks there's no ETA.
• Average interval: t̄ = (time(tip) − time(tip − W)) ÷ W. Only the first and last timestamps matter, so one odd timestamp can't distort it.
• ETA = seen time of the tip + blocks remaining × t̄.
• Range: the window is split into stretches of 48 blocks (about an hour each). Each stretch's average interval is computed the same way. The range uses the 10th and 90th percentile of those averages: earliest = seen + remaining × P10, latest = seen + remaining × P90.
• In plain words: "if blocks keep coming at the pace of the last 12 hours, NU7 arrives around here; the range shows how much that pace has varied hour to hour." We use hourly averages rather than single block times, because single intervals vary wildly (from seconds to several minutes) and would give a range several days wide.
• After activation there's no ETA.

Block interval

using the timestamps miners put in blocksMiner time / seen timeMiner time is the timestamp inside the block. Seen time is when Burnwood first saw it.More on /method →. Miner clocks are loose, so an intervalBlock intervalThe time between two blocks, from the timestamps miners write into them. Miner clocks are loose, so single intervals are noisy.More on /method → can be zero or negative. We display at least 1 s and mark it "clock skew"; the raw value is in the block's details. We never use a single interval as a headline; headline block times are averages.

Time windows (last hour / 24 h / 7 days / 30 days): a window ends at the last checked block and covers the blocks since the chain's clock was that far behind it. The chain's clock is the latest block timestamp seen so far, because miners' clocks can be slightly out of order. So a window is always an unbroken run of blocks, and no block inside it is left out. Daily history uses the same clock: a block counts on the UTC day of the latest block timestamp seen so far, so each day is also an unbroken run of blocks.

Average block time (1 h / 24 h): the same telescoping average over the blocks in the last hour or 24 hours. Blocks in the last hour counts the blocks in that window; after NU7 the target is 144 (3,600 s ÷ 25 s).

Fees per block

• Primary: the block's total fees as reported by CipherScan.
• Second path (from a ZebraZebraZcash node software developed by the Zcash Foundation. QuickNode and Tatum host the Zebra nodes Burnwood can read the chain from.More on /method → node): a cross-check before NU7, and a fallback when CipherScan is unavailable.
  • before NU7: fees = coinbase transparent outputs − (block subsidy − Lockbox share). The LockboxLockboxA protocol-held fund that receives part of every block reward (0.06249999 ZEC from NU7 until the current funding streams end). It isn't in circulation, so it's left out of the shielded share.More on /method → share is the only part of the block subsidyBlock subsidyThe new ZEC created with each block, split between the miner, ZCG and the Lockbox. From NU7 until the next halving it's 0.52083333 ZEC per block.More on /method → that isn't paid out in the coinbase, and the miner claims every fee there, so this is exact and independent of CipherScan.
  • after NU7 (provisional, pending the specification text for the NU7 coinbase total): the miner receives only 40% of fees, so fees = removed(h) + (coinbase transparent outputs − (block subsidy − Lockbox share)). It reuses removed(h), so it isn't an independent check. We use it only to fill in a fee when CipherScan is unavailable.
  • Correction note: an early version of our spec used "coinbase outputs − subsidy" after NU7 as well. That would count only 40% of fees.
  • When the coinbase has shielded outputs this path can't see the amounts, and it reports no value.
• SproutSproutZcash's first shielded pool, from 2016. NU7 disables spending from it; its funds stay in the pool.More on /method → before NU7: CipherScan can't see Sprout JoinSplits (transactions that move ZEC in or out of the Sprout pool). For a block that contains them, the fee comes from the second path, and those transactions are left out of the median fee per transaction. From NU7 on, no transaction can carry a JoinSplit (ZIP 2003).

ZEC removed per block (from the NU7 activation block on). Three methods, all in zatoshi, used in this order:

1. NSM reserve change (first): removed(h) = reserve(h) − reserve(h − 1), reading the reserve balance directly from a node that reports it (CipherScan's ZakuraZakuraA Zcash full node that started as a fork of Zebra and is now developed by a separate team. CipherScan runs a Zakura node, which Burnwood can read blocks, fees and the NSM reserve balance from.More on /method → node, ≥ 1.5.0) at two consecutive blocks. At block A the previous reading is the seed, so the seed is left out automatically.
2. Pool delta (second, when a reserve reading is missing): removed(h) = block subsidy(h) − Σ change in every value pool at h, from our Zebra node. The subsidy and fees that didn't land in any pool went to the reserve. Valid until reissuance starts (the start block is under "What Burnwood measures"; ≈ 2031 on mainnet).
3. Fee share (the check): removed(h) = floor(fees(h) × 6 ÷ 10). Rounded down once per block, in the miner's favour (ZIP 235, applied as modified by ZIP 259). Example: fees of 1,002 zatoshi → 601 zatoshi removed. It checks the other two. It only produces the headline when neither the reserve nor our Zebra node is available, or to split a gap of several blocks between two reserve readings, and then only if the parts add up exactly to the reserve change.

From NU7 until the next halving, the block subsidy is 0.52083333 ZEC: 0.41666668 to the miner (plus 40% of fees), 0.04166666 to Zcash Community GrantsZCGZcash Community Grants, which receives 0.04166666 ZEC of every block reward from NU7 until the current funding streams end.More on /method → and 0.06249999 to the Lockbox. The ZCG and Lockbox shares apply from NU7 until the current funding streams end.

ZEC removed since NU7

which equals Σ removed(h) for every block from A up to the last checked block (throughHeight). Every time we read the reserve, we check that the two agree. If they don't, the headline stops at the last block where they did.

The seedSeedThe block subsidy and fees that miners left unclaimed before the NU6 upgrade, placed in the NSM reserve when NU7 activates. Burnwood reads the exact amount from the chain and doesn't count it as removed.More on /method → is never counted. The reserve starts with a one-off amount: the block rewards and fees that miners left unclaimed beforeNU6NU6A Zcash network upgrade that started the current funding streams and the Lockbox.More on /method →. It's placed in the reserve at NU7, so it isn't fee removal, and it's excluded. We don't hard-code it. ZIP 237 sets it as the reserve balance at block A−1, the block just before NU7, so we read it from the reserve at block A−1 and lock it once that block has 10 confirmationsConfirmationEach block added on top of a block is one confirmation. More confirmations mean the block is very unlikely to change.More on /method →. If we couldn't read block A−1 (for example, because a source was down), we work out an implied seed, reserve − Σ removed after activation. It's shown as provisional and serves only as a check until a seed is locked. The "Method in use right now" box below shows the seed's exact value once it has been measured.

Rates: last 24 h / 7 days / 30 days = the sum of removed(h) for the blocks in that time window (see "Time windows" above). Average per block (24 h) = last 24 h ÷ number of blocks in that window, rounded down.

Shielded actions per block = SaplingSaplingThe shielded pool introduced in 2018.More on /method → spends + Sapling outputs + OrchardOrchardThe shielded pool introduced in 2022. Since NU6.3 (block 3,428,143) it can only be spent from, not added to, so funds are moving from it to Ironwood.More on /method → actions + IronwoodIronwoodZcash's newest shielded pool, added in NU6.3. The Ironwood share is Ironwood's part of Orchard plus Ironwood, a gauge of the move away from Orchard.More on /method → actions + Sprout JoinSplits, counted over all the block's transactions, the coinbase included. Shown as "—" only when no source returned the transaction details for that block.

Fees (24 h) = sum of block fees in the window (shown as "—" if any block in it lacks a fee value). Median fee per transaction = the lower median of fees paid by non-coinbase transactions in the last 24 h whose fee is known exactly (see the Sprout note under "Fees per block").

Shielded share

Sprout still counts as shielded after NU7: NU7 disables spending from it, but its funds stay in the pool and remain shielded. The Lockbox and the NSM reserve are shown separately and are excluded: neither is part of the circulating supply.

Ironwood share

a gauge of the move from Orchard to Ironwood. Since NU6.3NU6.3The previous Zcash network upgrade, activated at block 3,428,143. The progress ring starts there.More on /method →, Orchard can only be spent from, not added to.

Progress ring: the share of the way from the previous upgrade's activation height (NU6.3, block 3,428,143) to A.

Activation: Burnwood only says "NU7 is live" when the tip is at or past A and the node reports that the chain tip follows NU7's consensus rules (branch id 77190ad9). The height alone is never enough.

What is sent

Only these four events, each marked with the network you're viewing (mainnet or testnet):

• pageview: when a page loads. It carries the page's address with no query except ?net=, and, if you followed a link here, only the domain of the page that linked.
• share-click: when you press Share. It carries the page's stage: A (NU7 not scheduled yet), B (countdown), C (activation) or D (counting since NU7).
• share-result: when a share finishes. It carries the outcome: shared with the image, shared as a link, card downloaded, link copied, or failed.
• card-download: when you download a card. It carries the card's kind, for example the countdown card or the activation card.

PostHog's code adds basic technical details to every event, such as browser and operating system, device type, screen and window size, language, time zone, and random identifiers that exist only in memory for that one page load. So every page load counts as a new, separate visit, and your visits aren't linked together.

PostHog looks up your country from your IP address as each event arrives, then discards the address. Only the country and continent are kept.

What isn't collected

• No cookies. The analytics store nothing in your browser. Burnwood itself keeps only its own display settings there: your theme, a note that the site's fonts are already downloaded (so your next visit can show them straight away) and, for the current tab only, details such as whether announcements are paused. None of them is used for analytics or sent anywhere.
• No stored IP addresses.
• No profiles. Events aren't tied to a person or to earlier visits.
• No session recording, no heatmaps and no automatic click tracking. Only the four events above are sent.
• No fingerprinting. We don't try to recognise returning visitors.

Your choices

If your browser sends Do Not Track or Global Privacy Control (privacy signals your browser can send for you), PostHog's code isn't loaded and nothing is sent.

The analytics code is part of Burnwood and comes from our own site. It starts only after the page has finished loading, so it doesn't hold up the page, and it sends events to PostHog's EU servers (eu.i.posthog.com). Many ad blockers block it. The site works the same either way, and our page-view counts are lower than the real number.