Bittensor (TAO) — the revision ledger

Generated 2026-09-02T20:04:40Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for TAO: 7,812 observations · 29 distinct series · 5 upstream sources · first row 2026-08-09 23:24:26 · newest row 2026-09-02 19:49:20 · every one of the 7,812 rows carries a verify_url · 29 series refreshed in the last 24h (740 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where TAO's archive comes from

5 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. TAO is the native token of the Bittensor Substrate chain — it has no ERC-20 token contract (the catalog's token_address field is empty for it, and nothing here invents one). The catalog records no first-party stats API for Bittensor: the network-side series held for TAO come from the Bittensor chain itself via its finney entrypoint (https://entrypoint-finney.opentensor.ai — the substrate_rpc / subtensor_rpc / first_party_api families: block heights, peer health, total issuance, subnet count), with CoinGecko's market series and DefiLlama's chain TVL alongside.

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

The ledger query ran during generation and returned 0 rows for TAO. Zero here is the live query result, not a gap — the ledger itself is at /v1/revisions?symbol=TAO (the same query this page ran, served live), and a restatement would appear on this page the day the detector records one. /v1/revisions cross-check unavailable at generation (HTTP Error 429: Too Many Requests); counts re-derived live from ClickHouse.

Why zero is the interesting answer. The detector does not skip TAO — below, the live intersection shows the 3 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. Nothing 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 Bittensor — 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 TAO. All three series held are counters from the Bittensor chain itself: head block height, finalized block height, and total TAO issuance — quantities that cannot decrease unless upstream rewrote history.

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

These are the actual counter trails the detector diffed for TAO, rendered live from the archive. Each is a series that cannot decrease unless upstream rewrote history — and each is monotonic across its entire held window, which is exactly why the ledger above is empty. The raw runs are the evidence; the reader does not have to trust the summary.

BLOCK_HEIGHT — the head block height of the Bittensor Substrate chain, captured daily by this estate's own first-party collector against the finney entrypoint (https://entrypoint-finney.opentensor.ai), across all 24 snapshot days:

finalized_block_height — the finalized block height of the same chain, read via the Bittensor Substrate RPC at the finney entrypoint, across all 24 snapshot days:

TOTAL_ISSUANCE — the total TAO issuance, read from the Bittensor subtensor RPC at the finney entrypoint (chain-side issuance, not CoinGecko's circulating measure), across all 10 snapshot days:

What the archive itself measures — the chain's block cadence

Derived live from the BLOCK_HEIGHT trail above, not quoted from documentation: between the first and last snapshot day the head advanced 165,561 blocks over 23 day-gaps — about 7,198.3 blocks/day, i.e. 12.00 seconds per block as this estate measured it. The same arithmetic is what the detector runs over: any day where the head height failed to advance by a fresh block count would be a backward revision, and none was recorded.

Cross-source agreement — two independent pipelines, one quantity

This estate's first-party PRICE spot capture and CoinGecko's price_usd market series are two independent pipelines measuring the same quantity: the TAO/USD price. On the snapshot days where both hold a value, the captures agree exactly on 0 of 11 overlapping days, and on the 11 divergent days the two captures differ by at most 2.13 USD (≈0.9453% of the day's value) — the signature of two collectors sampling the market at different moments, not of a history rewrite. A live-computed check, not an assertion — every overlapping day, both values, and the delta:

Two collectors, one chain — the finalized-height pair

The estate's own first-party collector and the substrate_rpc family both captured the finalized block height of the Bittensor chain, 781 seconds apart. Both captures are kept with their exact timestamps — and the spacing between them is itself informative: the finalized head advanced 67 blocks over 781 s — 11.66 s/block, matching the cadence the archive measures above (a chain moving forward, not a value being rewritten). Both values, both timestamps, retained:

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 change, not upstream rewriting history. Price, velocity, market-cap and 24h-range classes dominate this table for TAO — a token that trades moves these every snapshot. Publishing them as "revisions" would be exactly the fake-metric behaviour this product exists to eliminate.

Same-timestamp conflicting values on record for TAO: 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 TAO 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, chain issuance). 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 (prices, market caps, volumes, peer counts, 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

TAO's slice of depin_daily: 417 rows over 27 snapshot days (2026-08-06 → 2026-09-01), from 7 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 is the Bittensor entrypoint the block-height and issuance rows came from; command 4 is the CoinGecko origin of the market series; command 5 is DefiLlama's chain feed; the next is the estate's graded network row; the last is the frozen daily snapshot of the ledger. One polite call per endpoint, no hammering.

# 1) The served revision feed for TAO — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=TAO" | 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) The Bittensor chain itself — the finney entrypoint (the BLOCK_HEIGHT / finalized_block_height / TOTAL_ISSUANCE origin):
curl -s -o /dev/null -w "%{http_code}\n" -H "User-Agent: kairos-check" "https://entrypoint-finney.opentensor.ai"
# 4) CoinGecko's Bittensor market page (the *_usd market-series origin):
curl -s -o /dev/null -w "%{http_code}\n" -H "User-Agent: kairos-check" "https://www.coingecko.com/en/coins/bittensor"
# 5) DefiLlama /v2/chains (the chain_tvl_usd origin):
curl -s -H "User-Agent: kairos-check" "https://api.llama.fi/v2/chains" | python3 -m json.tool | grep -m1 Bittensor
# 5) This estate's public API row for TAO (grades + provenance):
curl -s "https://kairossignal.com/v1/network/TAO" | 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_tao.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The TAO revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='TAO'; the page refuses to ship if the served /v1/revisions?symbol=TAO disagrees with it, and states the fact plainly if that endpoint is unavailable at generation. 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 same-stamp conflict check is the honest live answer: 0 groups in depin_onchain and 0 in depin_daily. The block cadence and the finalized-height pair are computed from rows this estate holds, not from documentation. Upstream probes ran serially by this generator immediately before rendering: CoinGecko Bittensor page (browser-verified origin; 403 here is its bot wall) HTTP 403; Bittensor finney entrypoint (the substrate_rpc / subtensor_rpc origin family) HTTP 405; DefiLlama /v2/chains (the chain_tvl_usd origin) HTTP 200; estate /v1/revisions?symbol=TAO HTTP 429; estate /v1/network/TAO HTTP 429.