Chirp (CHIRP) — the revision ledger

Generated 2026-10-17T05:14:47Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for Chirp: 33,347 observations · 40 distinct series · 3 upstream sources · first row 2026-08-09 17:15:20 · newest row 2026-10-17 04:50:53 · every one of the 33,347 rows carries a verify_url · 35 series refreshed in the last 24h (640 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where Chirp's archive comes from

3 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. Chirp (the catalog name here is Chirp Token, category wireless, chain sui) publishes its own public stats endpoint (first_party_api — app.chirpwireless.io — the devices, nodes, cities, countries, users, packets and pings series) and this estate polls it directly; the market series come from CoinGecko's /coins/markets feed. Chirp's token is a Sui move object, not an EVM contract, so the estate's Blockscout chain-read family does not apply to this network — the absence of chain-counter sources below is structural, not a gap in collection.

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

The ledger query ran during generation and returned 0 rows for CHIRP. Zero here is the live query result, not a gap — the ledger itself is at /v1/revisions?symbol=CHIRP (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=CHIRP cross-check passed: the served API reports 0 row(s), matching the ledger count rendered on this page.

Why zero is the interesting answer here. The detector watches every cumulative-by-construction series — counters that cannot decrease unless upstream rewrote them (block heights, transfer counters, lifetime fees). The live intersection of that watchlist with what the daily archive holds for CHIRP is empty, measured below: nothing Chirp publishes through its stats endpoint is a monotone counter. Its event series (pings, packets) oscillate; its population series (devices, nodes, cities, users) are gauges by construction; its supply and market series are price-driven classes the detector excludes by name. The structural zero is therefore: the archive is fully exposed, and no held series is of the class that can expose a rewrite. Publishing an empty ledger as a live query result — instead of padding it with gauge noise — is the same retention discipline the ledger exists to sell.

What the detector watches for Chirp — the intersection, measured

The detector diffs every daily snapshot of every cumulative-by-construction series. Below is the live intersection of the estate detector's cumulative watchlist — imported directly from propintel/revision_ledger.py (11 declared names, so this page can never drift from the detector) — with what the daily archive holds for CHIRP.

Live query result: 0 watchlist series held for CHIRP. The intersection query ran during generation and returned an empty set — none of the 11 cumulative-by-construction metric families the detector watches appear in CHIRP's daily archive. This is the structural zero behind the ledger count above, published as the query found it. The full series inventory CHIRP's archive does hold follows, so the disjoint is checkable row by row.

Everything the daily archive holds for Chirp — the other side of the disjoint

36 series held for CHIRP in depin_daily, all of them gauge- or price-class: none appears in the detector watchlist above. This inventory is live — it is the query result, not a curated list.

The trails behind the structural zero — oscillating event gauges, end to end

CHIRP's endpoint publishes PINGS and PACKETS as running totals, but the trails this estate holds for them oscillate — they fall as often as they rise. That is the defining behaviour of a gauge (a windowed or resampled event count), not a monotone counter, and it is why neither series can enter the detector's cumulative class: diffing them would manufacture a "revision" out of every ordinary daily fluctuation. Rendered raw from the archive — both directions visible; the reader does not have to trust the classification.

PINGS — as published by app.chirpwireless.io, captured by the estate's first-party collector across all 72 snapshot days:

PACKETS — same origin, same window — 72 snapshot days:

Level vs increment — Chirp's own numbers, reconciled

For PACKETS, PINGS the network's own stats endpoint publishes BOTH a level and a same-named *_INCREMENT series. If the endpoint is internally consistent, day-over-day level change should equal the increment. Measured live across every snapshot day where both exist: 2 of 2 do not reconcile. This estate records what upstream published, including upstream disagreeing with itself; both trails are in the archive, both are rendered here, and nothing is smoothed over. The per-day deltas follow the summary so every claim on this page can be re-derived by hand. Withheld: CITIES, COUNTRIES, DEVICES, NODES, USERS. Chirp's device and node counters and the increment series for these held one value on every hourly read since 2026-08-06 (quality incident chirp_frozen_device_node_counters_20260927), so reconciling them would reconcile an artifact.

Per-day deltas — level, implied change, and the increment the source published for the same day:

Gauges that moved backward — deliberately NOT revisions

These series fall outside the detector's cumulative-by-construction class (NOT_TRULY_CUMULATIVE and plain gauges in propintel/revision_ledger.py): a drop there is a real fleet, event-count or market change, not upstream rewriting history. For CHIRP this table is the whole archive's behaviour — every moving series is in it, from the PINGS event gauge (which fell on more than half its day-pairs) to the CoinGecko price and market-cap classes (a price fall revalues every derived series; that is a market move, not a rewrite) to the city and user populations themselves. Publishing them as "revisions" would be exactly the fake-metric behaviour this product exists to eliminate.

Same-timestamp conflicting values on record for CHIRP: 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 CHIRP 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 level-vs-increment disagreement above is a cross-series discrepancy between two different metric families — not a same-stamp conflict — which is why it lives in its own section.)

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.

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 (provider sets, node counts, prices, capacity, rolling windows) legitimately move both ways and are deliberately excluded — a drop there is a real change, not a rewrite; the gauge table on this page is the worked example, and for CHIRP it is the entire held inventory. 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 and frozen daily at /revision-ledger/REVISIONS_20260902.json.

The snapshot archive the detection runs over

CHIRP's slice of depin_daily: 2,005 rows over 72 snapshot days (2026-08-06 → 2026-10-16), from 3 source families. Each snapshot is a same-day capture of every series the collectors touched; the detector diffs consecutive snapshots of cumulative series across this window. This is the substrate the zero above is measured over — not an assumption, a measured archive.

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 is Chirp's own stats endpoint, the origin of every first-party series on this page; command 4 is the CoinGecko origin page; 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 CHIRP — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=CHIRP" | 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) Chirp's own public stats endpoint (the first_party_api origin):
curl -s -H "User-Agent: kairos-check" "https://app.chirpwireless.io/api/public/stats/total" | python3 -m json.tool
# 4) CoinGecko CHIRP page (the market-series origin; browser-verified, bot-walled to curl):
curl -s -o /dev/null -w "%{http_code}\n" "https://www.coingecko.com/en/coins/chirp-token"
# 5) This estate's public API row for CHIRP (grades + provenance):
curl -s "https://kairossignal.com/v1/network/CHIRP" | 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_20260902.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_chirp.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The CHIRP revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='CHIRP'; the page refuses to ship if the served /v1/revisions?symbol=CHIRP is reachable and disagrees with it (at generation the estate API was reachable and the cross-check passed). 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 same-stamp conflict check is the honest live answer: 0 groups in depin_onchain and 0 in depin_daily. The level-vs-increment tables are re-diffed from the raw trails on every regeneration — if upstream fixes its endpoint so the two reconcile, this page will say so. Upstream probes ran serially by this generator immediately before rendering: CoinGecko CHIRP page (the market-series origin; 403 here is its bot wall) HTTP 403; Chirp's own public stats endpoint (the first_party_api origin) HTTP 200; estate /v1/revisions?symbol=CHIRP HTTP 200; estate /v1/network/CHIRP HTTP 200.