Onocoy Token (ONO) — the revision ledger

Generated 2026-09-02T19:14:37Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for Onocoy Token: 8,692 observations · 29 distinct series · 3 upstream sources · first row 2026-08-09 17:15:20 · newest row 2026-09-02 18:49:30 · every one of the 8,692 rows carries a verify_url · 28 series refreshed in the last 24h (768 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where Onocoy Token'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. ONO is one of this estate's first-party-telemetry networks: onocoy publishes its own public explorer API (https://api.onocoy.com/api/v1/explorer), which feeds the station population series (station_count, stations_online, stations_validated, stations_offline) and the STATION_LIVENESS_PCT series directly from the network's own infrastructure, with CoinGecko's market series alongside. ONO's token lives on Solana (onoyC1ZjHNtT2tShqvVSg5WEcQDbu5zht6sdU9Nwjrc).

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

The ledger query ran during generation and returned 0 rows for ONO — and ONO's zero is a measured negative with a structural reason: the daily archive this estate holds for ONO — 398 rows over 27 snapshots (2026-08-06 → 2026-09-01) — contains zero cumulative-by-construction series. Every series onocoy publishes is gauge-class: station population counts, a liveness percentage, and market data — the classes a drop in means a real population or market change, not upstream rewriting history. The detector diffed what exists and correctly found nothing diffable of the restatement class; the measured gauge behaviour below is the proof the archive itself is alive and moving. Where a sibling network (AR) shows a BLOCKS restatement (1,988,930 → 1,702,206, on the estate-wide ledger below), ONO publishes nothing of that counter class. Zero here is the live query result plus the measured trails below, not a gap — the ledger itself is at /v1/revisions?symbol=ONO (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=ONO cross-check passed: the served API reports 0 row(s), matching the ledger count rendered on this page.

What the detector watches for Onocoy Token — 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 (75 declared names, so this page can never drift from the detector) — with what the daily archive holds for ONO. Live query result: 0 watchlist series held for ONO. The intersection query ran during generation and returned an empty set: none of the 75 cumulative-by-construction metric families the detector watches appear in ONO's daily archive. ONO's telemetry is entirely gauge-class — station population counts, liveness percentage, market data. This is the structural zero behind the ledger count above, published as the query found it. Honest boundary: if onocoy ever publishes a cumulative counter (total checks, stations onboarded lifetime, rewards paid out cumulative), the detector watches it automatically and this page gains the trail.

The trails behind the zero — ONO's gauges, end to end

These are actual series from ONO's daily archive, rendered live. Each is a gauge: it legitimately decreases when a station goes dark or the market reprices, which is exactly why the detector excludes these classes from revision detection — publishing their drops as "revisions" would be the fake-metric behaviour this product exists to eliminate. The backward steps are visible in the trails, measured, not smoothed away. These same trails are also where a restatement would surface if onocoy upstream rewrote any of these values for an already-archived date — the archive keeps every write, so a replacement is detectable.

stations_online — stations online — the first-party population gauge; every drop is a station going dark, not a rewrite:

STATIONS_TOTAL — STATIONS_TOTAL — the catalog-wide station population series:

station_count — station_count — the first-party station count series:

price_usd — price_usd — the CoinGecko market gauge; drops are revaluation:

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 population or market change, not upstream rewriting history. Publishing them as "revisions" would be exactly the fake-metric behaviour this product exists to eliminate. For ONO this is the whole archive: 22 of its daily series showed at least one backward move across the 27 snapshots — measured, not assumed.

Same-timestamp conflicting values on record for ONO: 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 ONO 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 (18 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 deleted; 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 deleted. Population gauges (provider 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 gauge tables on this page are the worked example, and for ONO the exclusion class covers every series it publishes. 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.

Estate grades for ONO (graded 2026-08-20 13:54:15.000)

Served by /v1/network/ONO — the same grades a paying agent receives. Scores are the engines' own 0–100 outputs, published exactly as the engines emitted them, unflattering parts included.

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 the network's own first-party stats API, the origin of the station series; command 4 is the estate's graded network row; command 5 is the frozen daily snapshot of the ledger; command 6 is the market-data origin. One polite call per endpoint, no hammering.

# 1) The served revision feed for ONO — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=ONO" | 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) onocoy's own public explorer API (the first_party_api / onocoy_explorer origin):
curl -s -H "User-Agent: kairos-check" "https://api.onocoy.com/api/v1/explorer" | python3 -m json.tool | head -60
# 4) This estate's public API row for ONO (grades + provenance):
curl -s "https://kairossignal.com/v1/network/ONO" | python3 -m json.tool | head -60
# 5) 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"
# 6) CoinGecko's ONO page in a browser (the market-series origin; a plain
#    curl here meets its bot wall and returns 403 — stated, not hidden):
curl -s -o /dev/null -w "%{http_code}\n" -H "User-Agent: kairos-check" "https://www.coingecko.com/en/coins/onocoy-token"

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_ono.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The ONO revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='ONO'; the page refuses to ship if the served /v1/revisions?symbol=ONO disagrees with it. The 18 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 ONO is genuinely empty today — because ONO's archive holds no cumulative-by-construction series at all (its telemetry is station population, liveness, and market gauges — the exclusion class), a structural fact measured live above and published as found — and this page says so instead of inventing restatements. The same-stamp conflict check is likewise the honest live answer: 0 groups in depin_onchain and 0 in depin_daily. Upstream probes ran serially by this generator immediately before rendering: api.onocoy.com /api/v1/explorer (the first_party_api and onocoy_explorer upstream — ONO's own public stats API) HTTP 200; CoinGecko ONO page (browser-verified origin; 403 here is its bot wall) HTTP 403; estate /v1/revisions?symbol=ONO HTTP 200; estate /v1/network/ONO HTTP 200.