Methods
How the evidence is captured
This is a principles-level summary of how the live data on this site is produced and how far each figure can be trusted. It is intentionally short. The full methods notes ship alongside the data downloads at launch, so the record can be checked independently of any dashboard.
Capture and provenance
The public read path is kept strictly separate from private ingest. Capture happens continuously from multiple vantages (for example a Core vantage and a Knots RDTS vantage), and raw observations are written into sealed, append-only capture segments. Nothing on the public site writes back into capture: the pages you see are downstream consumers of that record, never its source.
Every live panel on the dashboard maps to exactly one read model, and each read model is a rebuildable projection of the sealed segments. Because the segments are the source of truth, a read model can be recomputed from scratch and should produce the same numbers. That is what lets the underlying datasets be published as CC0 flat files with manifests: the dashboard is a convenience, and the flat files are the durable artefact.
The segment and read-model contract
Observations carry their provenance. Around any consensus boundary, state is recorded by both block hash and height, because deployment state is branch-relative and a reorganization can otherwise make a record ambiguous. A read model never infers a consensus verdict it did not observe. In particular, a transaction missing from a mempool is recorded as absent, not as rejected.
How freshness is computed
Freshness is per source, following the merge-mining-monitor pattern: each panel carries its own live, caution, or stale bead rather than one page-wide status. The thresholds are chosen to match how fast each source actually changes, so a bead flags a genuinely old reading rather than routine variance. Read the bead before the number: a stale bead means the value next to it is materially old.
| Source class | Refresh | Warn after | Stale after |
|---|---|---|---|
| Mempool divergence (Core vs Knots) | ~10s | over 60s | over 5 min |
| Chain tips (tip families) | ~10s | over 60s | over 5 min |
| Signalling state (per block) | per block (~10 min avg) | over 45 min | over 2 h |
| Enforcement census (service-bit-27 crawl) | hourly | over 3 h | over 12 h |
| Pool / Stratum intent | ~30s | over 5 min | over 30 min |
The developments ledger on the Timeline page is different: it updates on the newsroom cadence of a few hours rather than as a live feed, so it carries a "last updated" stamp rather than a freshness bead.
What the instruments do not claim
Each instrument measures one thing, and the guardrails printed on the panels say what it does not measure. Header signalling is a claim, not enforcement. A service-bit crawl is a reachability sample, not hash power or economic weight. Pool intent is work advertised by an endpoint, not attached hashrate. The monitoring explainer sets out each guardrail in full.
This page is a short summary. The complete methods notes, including the exact read-model definitions and the capture manifest format, are published with the CC0 data downloads at launch.