Helium (HNT) — the revision ledger

Generated 2026-10-17T05:25:20Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for Helium: 36,079 observations · 46 distinct series · 5 upstream sources · first row 2026-08-09 17:15:20 · newest row 2026-10-17 04:51:55 · every one of the 36,079 rows carries a verify_url · 46 series refreshed in the last 24h (677 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where HNT's archive comes from

5 source families feed this network's ledger. Every row they wrote carries its own source, as_of and verify_url; this table is the live rollup of that. The first-party family is Helium's own entities service (https://entities.nft.helium.io/v2/hotspots/pagination-metadata?subnetwork=iot and the MOBILE sibling) — telemetry from the network itself — with the DefiLlama fees family (its 24h/7d/30d/1y/all-time fee and 24h/30d revenue windows are withdrawn from 2026-08-09T17:17:15Z on — quality incident defillama_hnt_buyback_as_fees_20260925), the Solana SPL-mint chain state, the CoinGecko market reference and the helium GitHub activity series alongside.

Revision ledger — 0 backward revision(s) recorded for HNT

The ledger query ran during generation and returned 0 rows for HNT — and for Helium the structural reason is on this page, measured live: the detector only files cumulative-by-construction series (counters that cannot decrease unless upstream rewrote them), and the daily archive this estate holds for HNT — 2170 rows over 72 snapshots (2026-08-06 → 2026-10-16) — contains 0 series of that class once withdrawn rows are excluded. DefiLlama's fees_alltime_usd, which earlier versions of this page named as the one watched series, is withdrawn (2026-09-25, quality incident defillama_hnt_buyback_as_fees_20260925): it is not Helium fees: api.llama.fi/summary/fees/helium-network measures only Helium Mobile's open-market HNT buyback, its adapter returns 0 by code for every day after 2026-01-02 without querying anything, and the same response's methodology and warning banner say Data Credit burns for network usage are deliberately excluded, so its all-time total no longer changes. With no watched series held, there is nothing for the detector to diff. Zero here is the live query result plus the structural reason, not a gap — the ledger itself is at /v1/revisions?symbol=HNT (the same query this page ran, served live), and a restatement would appear on this page the day the detector records one. /v1/revisions?symbol=HNT cross-check passed: the served API reports 0 row(s), matching the ledger count rendered on this page.

Why the ledger is empty for HNT — the detector class, measured

The detector diffs every daily snapshot of every cumulative-by-construction series. The live watchlist below is imported at generation from the detector itself (propintel/revision_ledger.py (live import)). Its intersection with what the daily archive holds for HNT is the table, measured after the quality-incident filter. DefiLlama's fees_alltime_usd, the one watched series earlier versions of this page showed here, is withdrawn (quality incident defillama_hnt_buyback_as_fees_20260925, see below), so its flatness is no longer offered as the reason for the zero.

Live query result: 0 watchlist series held for HNT. The intersection query ran during generation and returned an empty set — none of the 11 declared-cumulative metric families the detector watches appear in HNT's daily archive. This is the structural zero behind the ledger count above, published as the query found it.

The watched fee series — withdrawn (2026-09-25)

Gauges that moved backward — deliberately NOT revisions

These series fall outside the detector's cumulative-by-construction class (NOT_TRULY_CUMULATIVE in propintel/revision_ledger.py): a drop there is a real population or market change, not upstream rewriting history. Publishing them as "revisions" would be exactly the fake-metric behaviour this product exists to eliminate.

The sharpest HNT case: IOT_HOTSPOTS — the LoRaWAN hotspot population from Helium's own entities API. Note what the trail shows: in this 27-day window it only ever grew. A detector that classified by measured monotonicity would admit it as cumulative; this estate's detector classifies by construction — hotspots can go offline, so a drop would be a real population change, not a rewrite. Trending gauges are exactly the case that fools naive monotonicity checks, which is why the exclusion list is explicit.

The 5G-side sibling, MOBILE_HOTSPOTS, from the same first-party service — same classification, same reasoning.

Same-timestamp conflicting values on record for HNT: none

The task-level conflict check, run live: any (metric, timestamp) family where this estate recorded two or more different values. The query ran at generation and returned 0 groups in both depin_onchain and depin_daily — every (metric, timestamp) pair the estate holds for HNT carries exactly one value. Zero here is the live query result, not a gap; the archive kept every write it made, and none of them disagree.

The ledger, live — every restatement recorded estate-wide (39 deduped events)

Deduped on revision identity exactly as /v1/revisions dedupes it. This is the same feed a subscriber polls; it is rendered live from ClickHouse at generation, not copied from a snapshot. Each row is an upstream source replacing the value of a (network, metric, date) it had already published — after this estate recorded the original. The superseded value is retained, never overwritten; that retention is the only reason a rewrite is detectable, and it is the part every overwriting vendor discards. HNT is absent from this table because its own ledger is empty — the estate-wide rows are the proof the detector fires when a rewrite actually happens.

How detection works — and what it cannot see

The detector (propintel/revision_ledger.py) diffs every daily snapshot this estate holds of every cumulative-by-construction series — counters that cannot decrease unless upstream rewrote them (block heights, transaction and transfer counters, lifetime fees). A row enters default.depin_revision_ledger iff two snapshots disagree for an already-observed date; zero human judgement. Resolution rule: latest observation wins for current-state reads, the superseded value is retained, never overwritten. Population gauges (hotspot sets, node counts, prices, capacity) legitimately move both ways and are deliberately excluded — a drop there is a real population change, not a rewrite; the IOT_HOTSPOTS case on this page is the worked example. Honest boundary: this catches value-history rewrites ex-post; identical-schema semantic drift with plausible values is what the hash-pinned derivation_replay layer is for. The detector's full classification is inspectable at /v1/revisions; a frozen daily copy serves at /revision-ledger/REVISIONS_20261017.json.

Verify any cell yourself — the exact commands

No account, no key, no trust required. Commands 1–2 hit this estate's public API (the same rows this page queried — every row carries source / as_of / verify_url); command 3 hits Helium's own entities service, the first-party source for the hotspot families; command 4 is the DefiLlama endpoint behind the withdrawn fees_alltime_usd, so the reason can be checked at origin; command 5 is the estate's graded network row; command 6 is the frozen daily snapshot of the ledger. One polite call per endpoint, no hammering.

# 1) The served revision feed for HNT — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=HNT" | python3 -m json.tool
# 2) The estate-wide feed (every network, both sides of every diff):
curl -s "https://kairossignal.com/v1/revisions" | python3 -m json.tool | head -80
# 3) Helium's own entities API (the first-party family for hotspot telemetry):
curl -s -H "User-Agent: kairos-check" "https://entities.nft.helium.io/v2/hotspots/pagination-metadata?subnetwork=iot" | python3 -m json.tool
# 4) DefiLlama's fees series for Helium (behind the withdrawn fees_alltime_usd — quality incident defillama_hnt_buyback_as_fees_20260925):
curl -s -H "User-Agent: kairos-check" "https://api.llama.fi/summary/fees/helium-network" | python3 -m json.tool | head -40
# 5) This estate's public API row for HNT (grades + provenance):
curl -s "https://kairossignal.com/v1/network/HNT" | python3 -m json.tool | head -60
# 6) The public daily snapshot of the ledger (frozen copy):
curl -s -o /dev/null -w "%{http_code}\n" "https://kairossignal.com/revision-ledger/REVISIONS_20261017.json"

Method & honesty notes. All counts are queries against the live ledger at generation time, not restamped copy — this page is regenerated by gen_revision_page_hnt.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The HNT revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='HNT'; the page refuses to ship if the served /v1/revisions?symbol=HNT disagrees with it. The 39 estate-wide events shown are deduped on revision identity (deterministic hash of network, metric, current_date, prior_date) exactly as the API dedupes them; detected_at is the first detection and never moves. Series absent from a section are absent, not zero: the daily-snapshot ledger for HNT is genuinely empty today — the watchlist queries above measure what the archive holds of the cumulative class, with DefiLlama's withdrawn fees_alltime_usd excluded (quality incident defillama_hnt_buyback_as_fees_20260925) — and this page says so instead of inventing restatements. The same-stamp conflict check is likewise the honest live answer: 0 groups in both tables. Upstream probes ran serially by this generator immediately before rendering: Helium entities API, IOT subnetwork (first-party upstream) HTTP 200; Helium entities API, MOBILE subnetwork (first-party upstream) HTTP 200; DefiLlama /summary/fees/helium-network (alltime-fees source) HTTP 200; estate /v1/revisions?symbol=HNT HTTP 200; estate /v1/network/HNT HTTP 200; CoinGecko helium page (browser-verified origin; 403 here is its bot wall) HTTP 403; frozen daily ledger snapshot HTTP 200.