AR.IO Network (ARIO) — the revision ledger

Generated 2026-10-17T05:10:55Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for AR.IO Network (ARIO): 33,635 observations · 38 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,635 rows carries a verify_url · 37 series refreshed in the last 24h (681 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where AR.IO Network (ARIO)'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. AR.IO Network (the catalog name here is AR.IO Network, symbol ARIO, category storage, chains base + solana) DOES publish a first-party public stats API — https://ar-io.dev/ar-io/peers — and it is the network's own gateway-registry read: the count of gateway peers, the count of arweave nodes across the tracked set, and per-gateway data/chunk weights. This estate reads it through TWO independent capture pipelines (cross-checked below): the depin_first_party Go firehose (hourly) and the first_party_api Python collector — alongside CoinGecko's market series and GitHub dev-activity series for ar-io/ar-io-node. The ARIO token contract address in the catalog (DcNnMuFxwhgV4WY1HVSaSEgr92bv2b1vUvEKiNxWqHdF, Base chain) is an Arweave-style address, not an EVM contract — no chain-RPC token counter family exists for this network in the archive.

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

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

Why zero is the interesting answer. The detector was watching ARIO across the entire snapshot window — and the live intersection below shows the archive holds zero cumulative-by-construction series for this network. Every series the estate holds for ARIO is either a population gauge (gateway peers, arweave nodes), a revalued market gauge (price, market cap, supply), a mean-weight gauge, or a dev-activity counter (stars and forks — revisable both ways legitimately). With no cumulative counter in the archive, there is structurally nothing the detector could see a rewrite in: publishing that empty intersection as a live query result — instead of padding the page with gauge noise — is the same retention discipline the ledger exists to sell.

What the detector watches for AR.IO Network (ARIO) — 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 ARIO.

Live query result: 0 watchlist series held for ARIO. 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 ARIO's daily archive. This is the structural zero behind the ledger count above, published as the query found it. ARIO's supply-side series (gateway peers, arweave nodes, mean data/chunk weights) are fleet gauges by construction: gateways join and leave, weights re-measure. They are excluded from the detector's revision class for exactly the same reason price is — not by omission.

The trails behind the zero — every gauge held, end to end

These are the actual series the estate holds for ARIO, rendered live from the archive. Each is a gauge that may legitimately move both ways — gateways join and leave, weights re-measure, the market revalues — which is why the detector excludes them by construction, and exactly why the ledger above is empty. The raw runs are the evidence; the reader does not have to trust the summary.

PEER_GATEWAYS — the count of AR.IO gateway peers returned by the network's own stats API (https://ar-io.dev/ar-io/peers), captured hourly by this estate's depin_first_party Go firehose, across all 72 snapshot days:

ARWEAVE_NODES — the count of arweave nodes across the tracked gateway set, same firehose capture of the same endpoint, across all 72 snapshot days:

MEAN_DATA_WEIGHT — the mean dataWeight across the gateway set, same firehose capture of the same endpoint, across all 72 snapshot days:

MEAN_CHUNK_WEIGHT — the mean chunkWeight across the gateway set, same firehose capture of the same endpoint, across all 72 snapshot days:

market_cap_usd — the CoinGecko /coins/markets daily market-cap row (revalued daily at spot — a gauge by construction), across all 61 snapshot days:

The same two pipelines also both capture the arweave-node count (firehose ARWEAVE_NODES vs collector arweave_nodes_count). Overlapping days held: 1. Note the firehose series itself wobbles (127 → 157 → 124 across the window) — that is the network changing, and it is why this gauge class is excluded from revision detection.

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 or market change, not upstream rewriting history. For ARIO the backward movers are the gateway-fleet weights and the market/price classes. Publishing them as "revisions" would be exactly the fake-metric behaviour this product exists to eliminate.

Same-timestamp conflicting values on record for ARIO

The task-level conflict check, run live: any (metric, timestamp) family where this estate recorded two or more different values. Showing the first 30 groups of 11 in depin_onchain — and 0 in depin_daily.

What these are, stated plainly. The conflicting groups above are examined per row with their provenance; the estate keeps every write rather than overwriting, which is why any disagreement would be visible and publishable instead of silently destroyed.

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 tables on this page are 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.

The snapshot archive the detection runs over

ARIO's slice of depin_daily: 1,805 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 hits the network's own stats API that the gateway/node/weight rows were captured from; command 4 is the GitHub origin of the dev-activity series; command 5 is the estate's graded network row; command 6 is the frozen daily snapshot of the ledger. The CoinGecko market-series origin page is linked per-source in the provenance table above. One polite call per endpoint, no hammering.

# 1) The served revision feed for ARIO — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=ARIO" | 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) AR.IO Network's own public stats API — the first-party origin of every gateway/node/weight series on this page:
curl -s -H "User-Agent: kairos-check" "https://ar-io.dev/ar-io/peers" | python3 -c "import json,sys; d=json.load(sys.stdin); print('gateway peers:', len(d['gateways']))"
# 4) GitHub API for ar-io/ar-io-node (the dev_* origin family):
curl -s "https://api.github.com/repos/ar-io/ar-io-node" | python3 -m json.tool | head -30
# 5) This estate's public API row for ARIO (grades + provenance):
curl -s "https://kairossignal.com/v1/network/ARIO" | 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_ario.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The ARIO revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='ARIO'; the page refuses to ship if the served /v1/revisions?symbol=ARIO disagrees with it, and states the fact plainly if that endpoint is unavailable at generation. 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: 11 groups in depin_onchain and 0 in depin_daily. Upstream probes ran serially by this generator immediately before rendering: ar-io.dev/ar-io/peers — AR.IO Network's own public stats API, the first-party origin of every gateway/node/weight series on this page HTTP 200; CoinGecko AR.IO Network page (browser-verified origin; 403 here is its bot wall) HTTP 403; GitHub API for ar-io/ar-io-node (the dev_* origin family) HTTP 200; estate /v1/revisions?symbol=ARIO HTTP 200; estate /v1/network/ARIO HTTP 200.