Mysterium (MYST) — the revision ledger

Generated 2026-09-02T20:07:51Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for Mysterium: 7,961 observations · 39 distinct series · 3 upstream sources · first row 2026-08-09 17:15:20 · newest row 2026-09-02 19:49:20 · every one of the 7,961 rows carries a verify_url · 31 series refreshed in the last 24h (698 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where Mysterium'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. MYST (the catalog name here is Mysterium, category other, chains binance-smart-chain / ethereum / polygon-pos) publishes a first-party stats API — discovery.mysterium.network — which this estate collects directly (first_party_api: countries covered, total nodes, proposal counts by service type), alongside this estate's own depin_first_party collectors (ACTIVE_PROVIDERS, COUNTRIES, per-country node counts), CoinGecko's market series, and the GitHub dev-velocity family (mysteriumnetwork/node and the org).

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

The ledger query ran during generation and returned 0 rows for MYST. Zero here is the live query result, not a gap — the ledger itself is at /v1/revisions?symbol=MYST (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=MYST 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 MYST — the archive it watches is fully enumerated below. The live intersection of the detector's cumulative-by-construction watchlist with MYST's daily archive is empty: every series this estate holds for Mysterium is a population gauge or a market-revaluation class (active provider counts, country counts, node counts per country, market cap, price, supply), which the detector excludes by construction — a drop there is a real network or market change, not upstream rewriting history. The exclusion is not an assumption: every MYST series with backward movement in the archive is rendered raw further down this page, exactly as measured. 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 Mysterium — 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 MYST.

Live query result: 0 watchlist series held for MYST. The intersection query ran during generation and returned an empty set — none of the 75 cumulative-by-construction metric families the detector watches appear in MYST's daily archive. Mysterium's telemetry in this estate is population and market classes, not lifetime counters. This is the structural zero behind the ledger count above, published as the query found it.

The trails behind the ledger — two independent collectors, rendered raw

These are the actual trails the detector's construction excludes from revision semantics for MYST, rendered live from the archive so the two-way movement is visible raw. Each is a population series: providers go on- and off-line, countries enter and leave the measured set. Neither collector is a lifetime counter, so neither can witness an upstream history rewrite — which is exactly why the ledger above is empty. The raw runs are the evidence; the reader does not have to trust the summary.

COUNTRIES — countries with active Mysterium presence, captured by this estate's depin_first_party collector across all 27 snapshot days:

countries_covered — the same quantity, independently captured from Mysterium's own discovery API (first_party_api) — 24 snapshot days, and on every day the two families overlap the two measurements are rendered side by side below:

ACTIVE_PROVIDERS — active provider nodes, depin_first_party collector, 27 snapshot days:

nodes_total — the same quantity, independently captured from Mysterium's discovery API (first_party_api) — 24 snapshot days:

Per-country node counts held by the depin_first_party collector (21 snapshot days each, 2026-08-10 → 2026-09-01):

Cross-source agreement — two independent pipelines, one quantity

Check 1 — countries. On the snapshot days where both the depin_first_party COUNTRIES collector and the first_party_api countries_covered series (Mysterium's own discovery API) hold a value, the two independent captures are compared live: 13 agreeing days, 11 divergent (max observed gap 2 countries). A divergence is a sampling-window difference between two collectors hitting the same upstream at different moments — a real measured fact, published as measured, never reconciled away.

Check 2 — active providers / nodes. The same construction over ACTIVE_PROVIDERS (depin_first_party) vs nodes_total (discovery API) on their overlap days: 0 agreeing days, 24 divergent (max observed gap 940 nodes).

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 network, market or window change, not upstream rewriting history. For MYST the table is dominated by exactly what the network is: provider populations that churn (a provider going offline is a smaller count, not a rewrite), country coverage that shifts, and market-cap / price / supply classes that revalue. Publishing them as "revisions" would be exactly the fake-metric behaviour this product exists to eliminate.

Same-timestamp conflicting values on record for MYST: 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 MYST 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). 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, 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 for MYST's all-gauge profile. 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

MYST's slice of depin_daily: 477 rows over 27 snapshot days (2026-08-06 → 2026-09-01), 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.

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

Served by /v1/network/MYST — 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 — this network's node-quality and revenue grades are F, and the page says so rather than burying 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); commands 3–5 hit the Mysterium discovery API and GitHub origins the first-party rows came from; command 6 is the CoinGecko origin page; command 7 is the estate's graded network row; command 8 is the frozen daily snapshot of the ledger. One polite call per endpoint, no hammering.

# 1) The served revision feed for MYST — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=MYST" | 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) Mysterium's own discovery API, countries (the countries_covered origin):
curl -s -H "User-Agent: kairos-check" "https://discovery.mysterium.network/api/v4/countries" | python3 -m json.tool | head -30
# 4) Mysterium's discovery API, proposals (the proposal-count series origin):
curl -s -H "User-Agent: kairos-check" "https://discovery.mysterium.network/api/v4/proposals?limit=3" | python3 -m json.tool | head -40
# 5) GitHub API, the dev-velocity origin for mysteriumnetwork/node:
curl -s -H "User-Agent: kairos-check" "https://api.github.com/repos/mysteriumnetwork/node" | python3 -m json.tool | head -30
# 6) CoinGecko MYST 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/mysterium"
# 7) This estate's public API row for MYST (grades + provenance):
curl -s "https://kairossignal.com/v1/network/MYST" | python3 -m json.tool | head -60
# 8) 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_myst.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The MYST revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='MYST'; the page refuses to ship if the served /v1/revisions?symbol=MYST 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 same-stamp conflict check is the honest live answer: 0 groups in depin_onchain and 0 in depin_daily. The two cross-source agreement checks are computed in-generation from the raw trails shown above, not asserted. Upstream probes ran serially by this generator immediately before rendering: Mysterium discovery /v4/countries (the countries_covered + COUNTRIES origin) HTTP 200; Mysterium discovery /v4/proposals (the proposal-count series origin) HTTP 200; GitHub API mysteriumnetwork/node (the dev-velocity series origin) HTTP 200; GitHub API mysteriumnetwork org (dev_public_repos origin) HTTP 200; CoinGecko MYST page (browser-verified origin; 403 here is its bot wall) HTTP 403; estate /v1/revisions?symbol=MYST (keyed) HTTP 200; estate /v1/network/MYST (keyed) HTTP 200.