Jackal Protocol (JKL) — the revision ledger

Generated 2026-09-02T18:38:13Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for Jackal Protocol: 12,864 observations · 43 distinct series · 3 upstream sources · first row 2026-08-09 17:15:20 · newest row 2026-09-02 17:49:30 · every one of the 12,864 rows carries a verify_url · 42 series refreshed in the last 24h (1,127 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where JKL's archive comes from

3 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. The largest family is the Jackal chain's own LCD REST endpoints (https://rest.cosmos.directory/jackal/cosmos/base/tendermint/v1beta1/blocks/latest and siblings) — first-party telemetry from the network's own public API, with the CoinGecko market reference alongside.

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

The ledger query ran during generation and returned 0 rows for JKL: every cumulative-by-construction series held for the Jackal ledger has been monotonic across all 24 daily snapshots in the archive (2026-08-09 → 2026-09-01; measured live below, not asserted). Zero here is the live query result, not a gap — the ledger itself is at /v1/revisions?symbol=JKL (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=JKL cross-check passed: the served API reports 0 row(s), matching the ledger count rendered on this page.

The cumulative-by-construction series the detector watches for JKL — measured, live

Straight from default.depin_daily at generation, using the detector's own lagInFrame diff: counters that cannot decrease unless upstream rewrote them. A backward move in any of these would be a revision event; the zero above is this measurement, not an assertion.

Gauges that moved backward — deliberately NOT revisions

These series fall outside the detector's cumulative-by-construction class (NOT_TRULY_CUMULATIVE 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.

The sharpest JKL case: bonded_validators moved 30 → 29 twice (snapshots 2026-08-10 and 2026-08-15, both spellings the estate holds measured identically). A naive monotonicity detector would file two restatements; the detector correctly classifies it as a population gauge — validators unbond and bond, the counter describes the live validator set, and the 30-value days either side prove the series was live, not stale. That classification is the difference between a revision feed and noise.

Same-timestamp conflicting values on record for JKL

The task-level conflict check, run live: any (metric, timestamp) family where this estate recorded two or more different values. JKL holds 21 such groups, all from the same upstream family (CoinGecko market series re-polled within the same stamp — the estate kept every copy, which is the point-in-time moat; the served API resolves to the latest). Zero of them involve cumulative-by-construction metrics, and the daily snapshot archive holds 0 — the detector's input is clean.

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 (validator sets, node counts, prices) legitimately move both ways and are deliberately excluded — a drop there is a real population change, not a rewrite; the bonded_validators case 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 JKL (graded 2026-08-20 13:54:15.000)

Served by /v1/network/JKL — 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); command 3 hits the Jackal chain's own LCD endpoint, the first-party source most chain-side rows came from; command 4 is the estate's graded network row; command 5 is the frozen daily snapshot of the ledger. One polite call per endpoint, no hammering.

# 1) The served revision feed for JKL — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=JKL" | 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) Jackal's own LCD endpoint (the first-party family most chain rows came from):
curl -s -H "User-Agent: kairos-check" "https://rest.cosmos.directory/jackal/cosmos/base/tendermint/v1beta1/blocks/latest" | python3 -m json.tool | head -40
# 4) This estate's public API row for JKL (grades + provenance):
curl -s "https://kairossignal.com/v1/network/JKL" | python3 -m json.tool | head -60
# 5) 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_jkl.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The JKL revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='JKL'; the page refuses to ship if the served /v1/revisions?symbol=JKL 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 JKL is genuinely empty today, and this page says so instead of inventing restatements; the same-stamp conflict table above is the honest answer to the "value changed at same timestamp family" check — 21 retained CoinGecko groups, zero cumulative-class. Upstream probes ran serially by this generator immediately before rendering: Jackal LCD latest-block endpoint (upstream of the chain family) HTTP 200; estate /v1/revisions?symbol=JKL HTTP 200; estate /v1/network/JKL HTTP 200; CoinGecko jackal-protocol page (browser-verified origin; 403 here is its bot wall) HTTP 403.