HashAI (HASHAI) — the revision ledger

Generated 2026-10-18T05:25:32Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for HashAI: 34,143 observations · 39 distinct series · 4 upstream sources · first row 2026-08-09 17:15:20 · newest row 2026-10-18 04:58:01 · every one of the 34,143 rows carries a verify_url · 39 series refreshed in the last 24h (634 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where HashAI'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. HashAI (the catalog name here is HashAI, category ai, chain ethereum) does not publish a public stats API this estate polls — the network-side series come from this estate's own Ethereum reads of the HASHAI token contract 0x292fcdd1b104de5a00250febba9bc6a5092a0076 via evm_blockscout (total supply, holders, token transfers, contract transaction and gas counters, top-holder balance), with CoinGecko's market series and DefiLlama's TVL/staking series alongside; the daily archive also holds this estate's own depin_first_party holders capture.

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

The ledger query ran during generation and returned 0 rows for HASHAI. Zero here is the live query result, not a gap — the ledger itself is at /v1/revisions?symbol=HASHAI (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=HASHAI 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 does not skip HASHAI — below, the live intersection shows the 0 cumulative-by-construction series the archive holds for this network, each fully diffed across its whole snapshot window (where it has more than one observation), and each rendered here end to end so the monotone runs are visible raw. Every backward move anywhere in the watched trails is measured and printed below, and each sits inside the detector's 0.01% float-noise floor. Nothing above the floor moved backward. That is the structural zero: the detector was watching, the counters were fully exposed to it, and upstream did not rewrite history for this network in the window this estate holds. 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 HashAI — 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 HASHAI. The three watched series here are the Blockscout counters for the HASHAI token contract on Ethereum mainnet: token transfers, contract transactions, and contract gas used.

Live query result: 0 watchlist series held for HASHAI. 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 HASHAI's daily archive. This is the structural zero behind the ledger count above, published as the query found it.

The trails behind the ledger — watched counters, end to end

These are the actual counter trails the detector diffed for HASHAI, rendered live from the archive. Each is a series that cannot decrease unless upstream rewrote history — and the raw runs are the evidence; the reader does not have to trust the summary.

token_transfers_total — the token transfer counter for the HASHAI contract on Ethereum mainnet, from the estate's Blockscout collector — 55 snapshot days:

contract_transactions_total — the transaction counter for the HASHAI contract, from the same Blockscout counters endpoint — 54 snapshot days:

contract_gas_used_total — the cumulative gas used by the HASHAI contract, from the same Blockscout counters endpoint — 54 snapshot days:

Every backward move in the watched trails, measured live: the largest is token_transfers_total from 2026-10-07 to 2026-10-08 (613,687 → 613,684, Δ -3.00, -0.0005%). The detector's noise floor is 0.01% (NOISE_PCT = 0.0001 in propintel/revision_ledger.py): fractional-cent jitter in an aggregator's USD rollup is reporting noise, not a restatement, and is deliberately not ledgered — the classification is checkable against the raw rows above.

Cross-source supply — the HASHAI total supply, two pipelines

The HASHAI total supply is captured from two independent directions: CoinGecko's market API (total_supply) and this estate's own chain read of the token contract (onchain_total_supply). On the 59 snapshot days both hold a value, they are checked live. Supply is deterministic on-chain, so the verdict band is float-representation exactness (relative 1e-6) — anything beyond that is published as a disagreement, never smoothed. Every delta is shown, nothing hidden: 0 exact days, 59 divergent.

The two pipelines disagree, and the disagreement is published, not fixed. The estate's chain read returns the contract's raw totalSupply() — the full minted token record on Ethereum; the aggregator's market-API figure is its own editorial supply definition (minted supply net of its own burn/lockup accounting). Both raw numbers are shown below with their origins; the reader decides which definition they need. Silently picking one and discarding the other is exactly the overwrite behaviour this product exists to detect.

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 market or window change, not upstream rewriting history. For HASHAI the market series dominate this table — price, market cap, fully-diluted valuation, TVL and the rolling 24h/7d/30d windows oscillate as the market revalues and windows roll off, and the holder population genuinely shrinks and grows (the archive records 29,440 holders on 2026-08-18 and 29,334 on 2026-08-19 — holders left; that is a population change, not a rewrite). Publishing them as "revisions" would be exactly the fake-metric behaviour this product exists to eliminate.

Same-timestamp conflicting values on record for HASHAI: 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 HASHAI 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 (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 by more than the 0.01% float-noise floor; 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. 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

HASHAI's slice of depin_daily: 2,026 rows over 70 snapshot days (2026-08-09 → 2026-10-17), from 4 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.

Estate grades for HASHAI: omitted at generation. — the grades section is omitted rather than filled with remembered numbers. The live grades remain one call away at /v1/network/HASHAI.

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–5 hit the Blockscout upstream family the watched counter rows came from; commands 6–8 are the Etherscan, DefiLlama and CoinGecko origin pages; command 9 is the estate's graded network row; command 10 is the frozen daily snapshot of the ledger. One polite call per endpoint, no hammering.

# 1) The served revision feed for HASHAI — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=HASHAI" | 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) Blockscout counters for the HASHAI token contract (the counter-trails origin):
curl -s -H "User-Agent: kairos-check" "https://eth.blockscout.com/api/v2/tokens/0x292fcdd1b104de5a00250febba9bc6a5092a0076/counters" | python3 -m json.tool | head -30
# 4) Blockscout token endpoint (the holders/supply origin):
curl -s -H "User-Agent: kairos-check" "https://eth.blockscout.com/api/v2/tokens/0x292fcdd1b104de5a00250febba9bc6a5092a0076" | python3 -m json.tool | head -30
# 5) Blockscout holders endpoint (the holders origin):
curl -s -H "User-Agent: kairos-check" "https://eth.blockscout.com/api/v2/tokens/0x292fcdd1b104de5a00250febba9bc6a5092a0076/holders" | python3 -m json.tool | head -30
# 6) Etherscan token page for the HASHAI contract (the ethereum-side origin):
curl -s -o /dev/null -w "%{http_code}\n" -H "User-Agent: kairos-check" "https://etherscan.io/token/0x292fcdd1b104de5a00250febba9bc6a5092a0076"
# 7) DefiLlama protocol page (the tvl_usd / staking origin):
curl -s -o /dev/null -w "%{http_code}\n" -H "User-Agent: kairos-check" "https://defillama.com/protocol/hashai"
# 8) CoinGecko HashAI 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/hashai"
# 9) This estate's public API row for HASHAI (grades + provenance):
curl -s "https://kairossignal.com/v1/network/HASHAI" | python3 -m json.tool | head -60
# 10) 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_hashai.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The HASHAI revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='HASHAI'; the page refuses to ship if the served /v1/revisions?symbol=HASHAI 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. Upstream probes ran serially by this generator immediately before rendering: CoinGecko HashAI page (browser-verified origin; 403 here is its bot wall) HTTP 403; DefiLlama protocol page for hashai (the tvl_usd / staking_tvl_usd origin) HTTP 403; Etherscan token page for the HASHAI contract (the ethereum-side origin) HTTP 403; Blockscout token endpoint for the HASHAI contract (the holders/supply origin) HTTP 200; Blockscout counters for the HASHAI contract (the counter-trails origin) HTTP 200; Blockscout holders endpoint for the HASHAI contract (the holders origin) HTTP 200; estate /v1/revisions?symbol=HASHAI HTTP 200; estate /v1/network/HASHAI HTTP 200.