Aleph Cloud (ALEPH) — the revision ledger

Generated 2026-09-02T19:03:14Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for Aleph Cloud: 9,064 observations · 51 distinct series · 4 upstream sources · first row 2026-08-09 17:15:20 · newest row 2026-09-02 18:49:30 · every one of the 9,064 rows carries a verify_url · 38 series refreshed in the last 24h (770 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where ALEPH's archive comes from

4 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 Aleph Cloud's own public telemetry (https://api2.aleph.im/metrics.json and the corechannel aggregate at https://api2.aleph.im/api/v0/aggregates/0xa1B3bb7d2332383D96b7796B908fB7f7F3c2Be10.json?keys=corechannel) — Core Channel Node and Resource Node populations, staking, message and storage counters from the network itself, with the CoinGecko market reference and aleph-im/pyaleph GitHub activity alongside.

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

The ledger query ran during generation and returned 0 rows for ALEPH — and for Aleph Cloud 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 ALEPH — 733 rows over 27 snapshots (2026-08-06 → 2026-09-01) — contains no series of that class. Every series held is a gauge: node populations, staking, node scores, file counts, market data. A gauge cannot produce a history-rewrite event; it can only move. Zero here is the live query result plus the structural reason, not a gap — the ledger itself is at /v1/revisions?symbol=ALEPH (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=ALEPH cross-check passed: the served API reports 0 row(s), matching the ledger count rendered on this page.

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

The detector diffs every daily snapshot of every cumulative-by-construction series. Below is the live intersection of the estate's cumulative watchlist with what the daily archive holds for ALEPH. It is empty: Aleph Cloud's public telemetry is node-population, staking and storage telemetry, not monotonic counters. Where a sibling network (AKT) shows a BLOCKS restatement, ALEPH structurally cannot produce one — its upstream publishes no cumulative counter this estate snapshots daily. That is the honest answer to "where are ALEPH's revisions": there is nothing for the detector to diff.

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

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 ALEPH case: CORE_NODES — the live Core Channel Node population from Aleph's own corechannel aggregate — steps down across the archive (82 → 81 → 80 → 78) as nodes leave the consensus set. A naive monotonicity detector would file every drop as a restatement; the detector correctly classifies it as a population gauge. The full trail below is the worked example.

The staking gauge: TOTAL_STAKED — total ALEPH staked to Core Channel Nodes from the same corechannel aggregate — moves in both directions across the archive as stake is delegated and withdrawn. Both directions are real; neither is a rewrite.

Same-timestamp conflicting values on record for ALEPH: 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 ALEPH 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 (node sets, staking, prices, capacity) legitimately move both ways and are deliberately excluded — a drop there is a real population change, not a rewrite; the CORE_NODES 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 and frozen daily at /revision-ledger/REVISIONS_20260902.json.

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

Served by /v1/network/ALEPH — 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); commands 3–4 hit Aleph Cloud's own first-party endpoints, the origins of the network-side series; 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 ALEPH — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=ALEPH" | 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) Aleph Cloud's own first-party metrics (node populations, storage, sync):
curl -s -H "User-Agent: kairos-check" "https://api2.aleph.im/metrics.json" | python3 -m json.tool | head -40
# 4) Aleph's corechannel aggregate (CCN populations and total staked):
curl -s -H "User-Agent: kairos-check" "https://api2.aleph.im/api/v0/aggregates/0xa1B3bb7d2332383D96b7796B908fB7f7F3c2Be10.json?keys=corechannel" | python3 -m json.tool | head -40
# 5) This estate's public API row for ALEPH (grades + provenance):
curl -s "https://kairossignal.com/v1/network/ALEPH" | 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_aleph.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The ALEPH revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='ALEPH'; the page refuses to ship if the served /v1/revisions?symbol=ALEPH 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 ALEPH is genuinely empty today — because the archive holds no cumulative-class series for Aleph Cloud at all, a structural fact measured live in the watchlist-intersection query above — 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: Aleph Cloud first-party metrics (api2.aleph.im/metrics.json) HTTP 200; Aleph corechannel aggregate (node populations, staked) HTTP 200; estate /v1/revisions?symbol=ALEPH HTTP 200; estate /v1/network/ALEPH HTTP 200; CoinGecko aleph page (browser-verified origin; 403 here is its bot wall) HTTP 403; GitHub aleph-im/pyaleph repo API (dev-velocity series origin) HTTP 200.