NATIX Network (NATIX) — the revision ledger

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

Provenance — where NATIX Network's archive comes from

2 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. NATIX Network publishes a first-party coverage API — coverage.natix.network/coverage/v1/metrics/global — and the estate's first_party_api collector polls it hourly (countries, drivers, km_mapped, natix_burned). CoinGecko's market series sits alongside it. Token: SPL FRySi8LPkuByB7VPSCCggxpewFUeeJiwEGRKKuhwpKcX on Solana.

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

The ledger query ran during generation and returned 0 rows for NATIX — and NATIX's zero is a measured negative, on two independent measurements. (1) Structure: the daily archive this estate holds for NATIX — 481 rows over 27 snapshots (2026-08-06 → 2026-09-01) — contains zero series from the detector's cumulative watchlist: NATIX's first-party feed is population gauges (drivers, km_mapped, countries) and market gauges (CoinGecko), all of which legitimately move both ways and are excluded by construction. (2) Direct measurement: the one counter-class series the archive does hold — TOKENS_BURNED from NATIX's own coverage API, which is not on the watchlist (burn counters are not cumulative-by-construction; the detector deliberately does not watch them) — was diffed by hand for this page, live, across every snapshot pair of all 27 days, and every pair is monotonic non-decreasing. Real data was measured; none of it was rewritten. Where a sibling network (AR) shows a BLOCKS restatement (1,988,930 → 1,702,206, on the estate-wide ledger below), NATIX shows nothing of the kind. Zero here is the live query result plus the measured trails below, not a gap — the ledger itself is at /v1/revisions?symbol=NATIX (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=NATIX cross-check passed: the served API reports 0 row(s), matching the ledger count rendered on this page.

What the detector watches for NATIX Network — 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 NATIX.

Live query result: 0 watchlist series held for NATIX. 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 NATIX's daily archive. This is the structural zero behind the ledger count above, published as the query found it. NATIX's telemetry is gauge-shaped by nature: driver population, kilometres mapped, countries covered, market gauges. A rewrite of any of those is indistinguishable from a real population or market change, which is exactly why the detector refuses to call them revisions — and why the direct counter measurement below is the load-bearing proof for this network.

The trail behind the zero — TOKENS_BURNED, diffed by hand

TOKENS_BURNED is the one counter-class series in NATIX's archive (from NATIX's own first-party coverage API, source depin_first_party / first_party_api). The detector does not watch it — burn counters are not cumulative-by-construction, and a burn total can legitimately pause — so this page measured it directly rather than lean on the watchlist boundary. Live diff over every snapshot pair: 0 backward move(s) across 27 pairs. Monotonic end to end — which is what makes this trail the proof behind the zero, and the same trail where a restatement would appear if upstream ever rewrote it:

The gauge trails — first-party coverage API, every snapshot

These are NATIX's own network-side series from coverage.natix.network, rendered live from the archive. They are population gauges: constant here (NATIX's published totals have not moved inside the archive window), and excluded from revision detection by construction — a drop would be a real population change, not upstream rewriting history. They are published in full so the flatness is checkable, not asserted.

drivers — registered drivers reported by NATIX's coverage API:

km_mapped — cumulative kilometres mapped, per NATIX's coverage API:

countries — countries covered, per NATIX's coverage API:

Gauges that moved backward — deliberately NOT revisions

These series fall outside the detector's cumulative-by-construction class (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.

Same-timestamp conflicting values on record for NATIX: 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 NATIX 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 table 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 and frozen daily at /revision-ledger/REVISIONS_20260902.json.

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

Served by /v1/network/NATIX — 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 NATIX's own first-party coverage endpoint, the origin of the drivers / km_mapped / countries / TOKENS_BURNED rows; command 4 is the estate's graded network row; command 5 is the frozen daily snapshot of the ledger. One polite call per endpoint, no hammering.

# 1) The served revision feed for NATIX — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=NATIX" | 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) NATIX's own first-party coverage API (the first_party_api upstream):
curl -s -H "User-Agent: kairos-check" "https://coverage.natix.network/coverage/v1/metrics/global" | python3 -m json.tool | head -40
# 4) This estate's public API row for NATIX (grades + provenance):
curl -s "https://kairossignal.com/v1/network/NATIX" | 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"

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_natix.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The NATIX revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='NATIX'; the page refuses to ship if the served /v1/revisions?symbol=NATIX 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 NATIX is genuinely empty today — the archive holds zero watchlist series, and the one counter-class series it holds (TOKENS_BURNED, deliberately not on the watchlist) was diffed by hand on this page and proved monotonic across all 27 snapshots — a measured negative published as found, with the full trails rendered above. 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: CoinGecko NATIX Network page (browser-verified origin; 403 here is its bot wall) HTTP 403; coverage.natix.network /coverage/v1/metrics/global (NATIX's own first-party stats API — the first_party_api upstream) HTTP 200; estate /v1/revisions?symbol=NATIX HTTP 200; estate /v1/network/NATIX HTTP 200.