Methodology
Every number on the dashboard is measured against Ethereum itself through public JSON-RPC endpoints — no API keys, no scraped aggregators as a primary source. This page documents the exact method so any figure can be independently reproduced.
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
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.
Cross-checks
Each cycle we compare our direct burn measurement against ultrasound.money's reported burn and our supply figure against CoinGecko's circulating supply. Agreement on burn is typically within a few percent (window boundaries differ). Supply figures differ by construction — see why numbers differ.
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.