PKT (PKT) — the revision ledger

Generated 2026-09-02T19:06:01Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for PKT: 9,163 observations · 48 distinct series · 4 upstream sources · first row 2026-08-08 23:21:30 · newest row 2026-09-02 18:49:30 · every one of the 9,163 rows carries a verify_url · 42 series refreshed in the last 24h (862 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where PKT'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. PKT publishes no first-party stats API of its own — the network-side family here is the pkt.cash explorer stats endpoint (12 pkt_* supply / airdrop / yield series, hourly, under source deep_stats_pkt_explorer) plus public chain infrastructure (Base Blockscout address and token counters for 0x917f39bb33b2483dd19546b1e8d2f09ce481ee44), with CoinGecko's market series and pkt-cash GitHub activity alongside.

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

The ledger query ran during generation and returned 0 rows for PKT — and PKT's zero is a measured negative: the daily archive this estate holds for PKT — 380 rows over 24 snapshots (2026-08-08 → 2026-09-01) — contains three cumulative-class series the detector watches, every snapshot pair of all three was diffed, and every pair is monotonic. Real counters were watched; none was rewritten. Where a sibling network (AR) shows a BLOCKS restatement (1,988,930 → 1,702,206, on the estate-wide ledger below), PKT's watched counters show nothing of the kind. Zero here is the live query result plus the measured trail below, not a gap — the ledger itself is at /v1/revisions?symbol=PKT (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=PKT cross-check passed: the served API reports 0 row(s), matching the ledger count rendered on this page.

What the detector watches for PKT — 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 PKT. Three watched series are held and were fully diffed; none produced a backward pair. That is the structural content of the zero above: watchable counters exist, and they are clean.

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

These are the actual counter trails the detector diffed for PKT, rendered live from the archive. Each is a series that cannot decrease unless upstream rewrote history — which is exactly what makes their smooth monotonicity the proof behind the zero, and the same trails where a GRT/OVPP/EIGEN-style restatement would appear if it ever happened. All three come from Base Blockscout for the PKT token contract.

contract_gas_used_total — the lifetime gas-spent counter for the PKT token contract:

contract_transactions_total — the lifetime transaction counter for the PKT token contract, the series class that produced real restatements for OVPP, AUKI, R1 and SOGNI elsewhere in the estate:

token_transfers_total — the lifetime transfer counter for the PKT token contract, the series class that produced real restatements for OVPP, AUKI, R1 and SOGNI elsewhere in the estate:

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 population or market change, not upstream rewriting history. Publishing them as "revisions" would be exactly the fake-metric behaviour this product exists to eliminate.

Same-timestamp conflicting values on record for PKT

The task-level conflict check, run live: any (metric, timestamp) family where this estate recorded two or more different values. Showing the first 30 groups of 72 in depin_onchain — and 0 in depin_daily.

What these are, stated plainly. All of the conflicting groups are CoinGecko market gauges: rolling-window price-change and market-cap-change series re-queried at slightly different moments inside the same timestamp family, so the 24h/7d/30d windows straddle different minutes. They are gauges — legitimately non-monotonic, excluded from revision detection by construction — and this estate kept every write rather than overwriting, which is why the disagreement is visible and publishable instead of silently destroyed.

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 (provider sets, node counts, prices, capacity) legitimately move both ways and are deliberately excluded — a drop there is a real population 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.

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

Served by /v1/network/PKT — 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 the upstream families the network-side rows came from; 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. Note: the explorer.pkt.cash endpoint behind the pkt_* supply series currently serves a TLS certificate whose subject does not match its hostname — a plain curl fails the handshake until they fix it; the stored rows remain what the collector received, with that defect published here rather than hidden.

# 1) The served revision feed for PKT — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=PKT" | 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) Base Blockscout counters for the PKT token contract (counter trails' origin):
curl -s -H "User-Agent: kairos-check" "https://base.blockscout.com/api/v2/addresses/0x917f39bb33b2483dd19546b1e8d2f09ce481ee44/counters" | python3 -m json.tool
# 4) GitHub API for pkt-cash/pktd (the dev-velocity upstream family):
curl -s -H "User-Agent: kairos-check" "https://api.github.com/repos/pkt-cash/pktd" | python3 -m json.tool | head -30
# 5) This estate's public API row for PKT (grades + provenance):
curl -s "https://kairossignal.com/v1/network/PKT" | 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_pkt.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The PKT revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='PKT'; the page refuses to ship if the served /v1/revisions?symbol=PKT 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 PKT is genuinely empty today — because every watched counter the archive holds proved monotonic under the detector's diff, a measured negative published as found, with the full trails rendered above — and this page says so instead of inventing restatements. The same-stamp conflict check is likewise the honest live answer: 72 groups in depin_onchain (all CoinGecko market gauges, provenance attached) and 0 in depin_daily. Upstream probes ran serially by this generator immediately before rendering: CoinGecko PKT page (browser-verified origin; 403 here is its bot wall) HTTP 403; explorer.pkt.cash /api/v1/stats (the pkt_* supply/airdrop upstream; ERR here is its TLS certificate hostname mismatch, stated not hidden) HTTP 000; Base Blockscout address counters for the PKT token contract (the blockscout upstream family) HTTP 200; GitHub API pkt-cash/pktd (the github upstream family) HTTP 200; estate /v1/revisions?symbol=PKT HTTP 200; estate /v1/network/PKT HTTP 200.