Methodology

This page documents the exact method behind every figure on the dashboard so each one can be independently reproduced. It also states which figures this site measures itself and which it quotes — those are different claims and are worth separating.

Measured here vs quoted

Figure	Origin	How
Burn — base fee and blob	Measured here	Block headers across a 7,200-block window
Median base fee, gas used	Measured here	Per-block header fields from the same window
L2 bridge escrow balances	Measured here	`eth_getBalance` on each canonical escrow
Total supply, staked ETH	Quoted	Aggregated consensus-layer feed. Summing every account balance is not something a public JSON-RPC endpoint can do, and the beacon-side sum needs full consensus state
Net issuance, annual rate	Derived	Combines the measured burn with the quoted supply and stake

The measured figures need no API key and no third party: a public RPC endpoint is sufficient. The quoted figures are the reason this page does not claim that everything here is self-measured.

Base-fee burn

EIP-1559 burns the base fee of every transaction. We fetch 7,200 consecutive block headers (≈24 hours at 12-second slots) and sum baseFeePerGas × gasUsed per block. The window is scaled to exactly 24h using the real timestamp span of the first and last block, so short-term slot variance does not distort the daily rate.

If a few blocks inside the window fail to fetch (up to 5%), the sum would understate the daily rate by exactly the missing fraction — so we apply a density correction that imputes missing blocks at the window average, and the dashboard displays the window coverage whenever it is below 100%. Beyond 5% missing, the whole window is withheld instead (see data-quality rules below).

Blob burn (EIP-4844)

Blob-carrying transactions additionally burn baseFeePerBlobGas × blobGasUsed. We take the per-block blob base fee from eth_feeHistory — the client computes it — rather than deriving it by hand from excessBlobGas, because the update fraction changes across forks and blob-parameter-only upgrades. Hand-derivation silently breaks at every such fork; the client value does not.

Supply and staking

These two figures are quoted, not measured here — see the table above for why. Total supply is assembled from consensus-layer sums: execution balances + beacon balances − processed deposits (execution side in wei, beacon side in gwei — a classic unit trap). The staked amount is the beacon balance sum. Note that the deposit-contract balance alone only ever grows: withdrawals are credited at the system level elsewhere, so reading the contract balance as "current stake" overstates it.

Issuance estimate

Annual consensus issuance is bounded by approximately 166.32 × √(staked ETH). Actual issuance runs slightly below the bound (it depends on participation and sync-committee duty), so the net-issuance figure on the dashboard is a conservative upper estimate of inflation pressure. When the verdict flips near zero, treat it as "approximately balanced" rather than a hard sign change.

L2 bridge escrows

We read the native ETH balance of each canonical bridge escrow contract directly. Two rules: locked ETH is not subtracted from supply (it is still ETH on L1), and a 0.0 balance on a known escrow is treated as "address migrated" — bridge contracts move during upgrades, and counting a stale address as zero would silently understate the total.

Data-quality rules

No shrunken samples. If more than 5% of a window's blocks fail to fetch, the whole window is marked missing and withheld. A burn average over a partial window looks plausible and is quietly wrong — we would rather show the previous verified value with its timestamp.
No silent zeros. Failed fetches and migrated escrows are labeled as such, never folded into totals as 0.
Visible staleness. Every page states the measurement timestamp. If the freshest window was withheld, the dashboard says so explicitly.

Divergence checks

Every cycle the collector compares its own burn measurement against an independent reference and records the difference. Agreement is typically within a few percent — window boundaries never line up exactly — and a larger gap raises a data-quality warning rather than being published silently. These comparisons are an internal check on our own arithmetic; they are not the source of any figure shown on the dashboard.

Update cadence & reproduction

The collector runs every 6 hours. To reproduce any number you need nothing but a public Ethereum RPC: fetch the block range shown on the dashboard, apply the formulas above, and compare. If you find a discrepancy beyond RPC-lag noise, something is wrong — tell us on the blog.