ThreeFold (TFT) — the revision history

Generated 2026-09-02T18:29:56Z from live ClickHouse queries against this estate's ledger. Held inventory: 16,226 observations · 55 distinct series · 4 upstream sources · first row 2026-08-09 17:15:20 · newest row 2026-09-02 17:53:04 · 16,226/16,226 rows carry a verify_url. 44 series refreshed in the last 24h (1,136 fresh rows). Nothing on this page is cached, estimated, or remembered.

Revision ledger — 0 backward revisions recorded for TFT — stated as measured

The detector's scope is cumulative counters only; TFT holds none. Absence is published, never zero-filled into a fake event.

The ledger query ran during generation and returned 0 rows for TFT. Zero here is the live query result, not a gap. Structural reason (verified in propintel/revision_ledger.py at generation): the detector scans only series DECLARED cumulative by construction — counters that cannot decrease unless upstream rewrote them. Every TFT series in the archive is a population gauge (nodes, farms, contracts, twins — populations legitimately move both ways, so a drop is a real population change, not upstream rewriting history) or a market-reference value. Gauges are deliberately out of revision scope; recording a gauge drop as a "revision" would be fabrication. The ledger itself is live at /v1/revisions.

The estate-wide ledger this product sells — 32 events, 9 networks on the ledger (live)

Every backward revision the estate has recorded, each with both timestamps and both values, exactly as held. This is the point-in-time moat: when a network's own API rewrote an already-published number, the before-value survived here and nowhere else. Detection is mechanical, zero human review.

Provenance — where every number 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.

30-day history — headline series (daily last-value, live)

One row per series: latest value, a 30-day sparkline of daily last-known values (scaled to the series' own min→max), day count, and window change. Series absent from the 30-day window are omitted from this table, not zero-filled.

Grid telemetry — the project's own GridProxy API, as held

ThreeFold operates a public stats API for its own grid (catalog has_public_stats_api = 1): farm, node, gateway, contract, country and capacity gauges read from gridproxy.grid.tf. These are the project's own numbers about its own network — first-party telemetry. Where the upstream publishes an exact zero, it ships as a zero with its cross-check (see caveats); where a gauge moved down because the population moved, that is the gauge, not a revision, and the detector correctly records none.

Market reference — CoinGecko coin page, as held

Market-data reference rows for the TFT token (id threefold-token): price, supply, capitalisation, diluted valuation, and the published change columns including ATH/ATL. These are the coin-page reference's own numbers — the estate does not model, smooth, or forward-fill them. The all-zero circulating-supply and market-cap series ship with their same-response cross-checks below, never silently. NOT probed live this generation run (run-level command gate); the verify_url on every held row is the origin, stated as held.

Dev velocity — GitHub platform API, as held

Repository and org counters for threefoldtech/zos (Zero-OS, the grid's node operating system) and the threefoldtech org — an aggregator-tier platform API, not first-party grid telemetry.

Full metric inventory — 55 measured series, each with provenance

Every series held for TFT with rows in the last 30 days: latest value, when it was observed, which source observed it, how many rows we hold, how many of the last 30 days it reported, its comparability grade, and the origin link. "days/30" counts distinct dates with at least one row in the window. The all-zero series are included with their caveats — the inventory shows what is held, at the depth it is held.

Verify any cell yourself — the exact commands

No account, no key, no trust required. Commands 1–3 hit the same upstream endpoints our collectors do; they were NOT probed during this generation run (run-level command gate — stated, not hidden), so run them and check us. Command 4 hits this estate's public API, where every row carries the same source / as_of / verify_url fields.

# 1) GridProxy nodes (ThreeFold's own API — given for the buyer to probe):
curl -s -H "User-Agent: kairos-check" "https://gridproxy.grid.tf/nodes" | python3 -m json.tool | head -40
# 2) GridProxy stats (the first-party stats endpoint on every stats row):
curl -s -H "User-Agent: kairos-check" "https://gridproxy.grid.tf/stats" | python3 -m json.tool
# 3) Market reference (CoinGecko public API, collector id threefold-token):
# CoinGecko public markets API — id "threefold-token", the exact id
# our market collector reads. The verify_urls on the held rows point
# at the browser coin page; this is the programmatic endpoint of the
# same reference (NOT probed this run — run it yourself):
curl -s "https://api.coingecko.com/api/v3/coins/markets?vs_currency=usd&ids=threefold-token" | python3 -m json.tool | head -30
# 4) This estate's public API row for TFT:
curl -s "https://kairossignal.com/v1/network/TFT" | python3 -m json.tool | head -60

Method & honesty notes. All counts are queries against the live ledger at generation time, not restamped copy — this page is regenerated by gen_tft_revision_history.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. Comparability grades come from the served canonical-metric system via its own resolver: total_supply maps to token_supply_total (question-verified), nodes to nodes_total (unit-verified), CRU_TOTAL to compute_cores_total (question-verified), countries to countries_covered (question-verified), gateways to gateways_total (unit-verified), gpus to gpus_total (question-verified). The remaining series are TFT-native grid metrics with no cross-network concept; grading them would be fabrication, so they are labelled "tft-native (unmapped)". The revision count of zero is the detector's live answer with its structural reason stated beside it; the estate-wide ledger above is the same table the /v1/revisions feed serves. Where a section has no data, it is absent — we do not publish zeros for gaps.