MVL (MVL) — the revision ledger

Generated 2026-09-02T20:35:24Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for MVL: 7,405 observations · 32 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,405 rows carries a verify_url · 32 series refreshed in the last 24h (702 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where MVL'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. MVL (the catalog name here is MVL — Mass Vehicle Ledger, category sensor, chains binance-smart-chain,ethereum,the-open-network) does not publish a public stats API this estate polls — the network-side series come from this estate's own Ethereum reads of the MVL token contract 0xa849eaae994fb86afa73382e9bd88c2b6b18dc71 (the catalog's own token_address field) via evm_blockscout (total supply, holders, token transfers, contract transaction and gas counters, top-holder balance), with CoinGecko's market series (coin id mass-vehicle-ledger) and DefiLlama's TVL/staking buckets (protocol mvl-staking) alongside. The catalog lists three chains, but the estate's chain-side family reads the ETHEREUM contract only — the catalog's token_address; no BSC or TON chain-side rows are held, so none are published or implied.

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

The ledger query ran during generation and returned 0 rows for MVL. Zero here is the live query result, not a gap — the ledger itself is at /v1/revisions?symbol=MVL (the same query this page ran, served live), and a restatement would appear on this page the day the detector records one. /v1/revisions cross-check: the estate API's free-tier daily quota answered HTTP 429 at generation time (resets 00:00 UTC); the ledger count on this page is the live ClickHouse result, and the served endpoint was probed and found quota-gated, not missing.

Why zero is the interesting answer. The detector does not skip MVL — below, the live intersection shows the 3 cumulative-by-construction series the archive holds for this network, each fully diffed across its whole snapshot window, and each rendered here end to end so the monotone runs are visible raw. Not one backward move exists anywhere in the watched trails, measured live. 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 MVL — 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 MVL. The watched series here are the Blockscout lifetime counters for the MVL token contract on Ethereum mainnet: token transfers, contract transactions, and contract gas used. The holder population and the top-holder balance are deliberately NOT in the detector's class — holders join and leave, balances move — and their backward moves are printed below as the exclusion proof. The chain-side supply read is a fixed-cap constant (30,000,000,000) — a single value with no differing counterpart to diff, and the moving counters beside it prove the read path is alive.

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

These are the actual counter trails the detector diffed for MVL, rendered live from the archive. Each is a series that cannot decrease unless upstream rewrote history — and the raw runs are the evidence; the reader does not have to trust the summary.

contract_transactions_total — the transaction counter for the MVL token-contract address, from Blockscout's address-counters endpoint — 10 snapshot days (2026-08-23 → 2026-09-01), measured never backward across all 10 snapshot days:

contract_gas_used_total — the cumulative gas used by the MVL token-contract address, from the same Blockscout counters endpoint — 10 snapshot days (2026-08-23 → 2026-09-01), measured never backward across all 10 snapshot days:

token_transfers_total — the token transfer counter for the MVL contract on Ethereum mainnet, from the estate's Blockscout collector — 11 snapshot days (2026-08-22 → 2026-09-01), measured never backward across all 11 snapshot days:

Every backward move in the watched trails, measured live: none. All three monotone-class checks ran over the full snapshot windows and found zero backward steps — the monotonicity verdicts above are the measured result, checkable against the raw trails above.

Gauges that moved backward — deliberately NOT revisions

The detector's cumulative-by-construction class (CUMULATIVE and NOT_TRULY_CUMULATIVE in propintel/revision_ledger.py) deliberately excludes population gauges: a drop there is a real change, not upstream rewriting history. For MVL the worked example is the holder population itself: across the 23 held snapshot days (2026-08-09 → 2026-09-01) the archive records 7 days where the holder count FELL — holders left. Measured live, the largest dip: 2026-08-09 → 2026-08-10 (11,839 → 11,838, Δ -1, -0.008%). The daily archive's market series (price, market cap, fully-diluted valuation, TVL, staking TVL, rolling change windows) oscillate as the market revalues and windows roll off. Publishing any of these as "revisions" would be exactly the fake-metric behaviour this product exists to eliminate.

Same-timestamp conflicting values on record for MVL: 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 MVL 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. The Arweave rows (BLOCKS −14.4%) are the canonical example of what this product catches; MVL's own ledger slice is the zero above.

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 by more than the 0.01% float-noise floor; zero human judgement. Resolution rule: latest observation wins for current-state reads, the superseded value is retained, never deleted. Population gauges (holder sets, prices, capacity, rolling windows) legitimately move both ways and are deliberately excluded — a drop there is a real change, not a rewrite; the holder-population 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.

The snapshot archive the detection runs over

MVL's slice of depin_daily: 432 rows over 24 snapshot days (2026-08-09 → 2026-09-01), from 4 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 MVL: omitted at generation. the estate API answered its free-tier daily-quota 429 at generation time (quota resets 00:00 UTC) — the grades section is omitted rather than filled with remembered numbers. The live grades remain one call away at /v1/network/MVL.

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 Blockscout upstream family the watched counter rows came from (the same eth.blockscout.com instance the verify_urls point at, for the catalog's own token contract); command 6 is the DefiLlama protocol response the TVL rows read; command 7 is the CoinGecko programmatic endpoint the market rows read; command 8 is the estate's graded network row; command 9 is the frozen daily snapshot of the ledger. One polite call per endpoint, no hammering.

# 1) The served revision feed for MVL — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=MVL" | 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 MVL token contract (the counter-trails origin):
curl -s -H "User-Agent: kairos-check" "https://eth.blockscout.com/api/v2/tokens/0xa849eaae994fb86afa73382e9bd88c2b6b18dc71/counters" | python3 -m json.tool | head -30
# 4) Blockscout address counters for the MVL contract address (transactions + gas):
curl -s -H "User-Agent: kairos-check" "https://eth.blockscout.com/api/v2/addresses/0xa849eaae994fb86afa73382e9bd88c2b6b18dc71/counters" | python3 -m json.tool | head -30
# 5) Blockscout token endpoint (the supply/holders origin):
curl -s -H "User-Agent: kairos-check" "https://eth.blockscout.com/api/v2/tokens/0xa849eaae994fb86afa73382e9bd88c2b6b18dc71" | python3 -m json.tool | head -30
# 6) DefiLlama protocol API (the tvl_usd / staking origin):
curl -s -H "User-Agent: kairos-check" "https://api.llama.fi/protocol/mvl-staking" | python3 -c "import json,sys; d=json.load(sys.stdin); t=(d.get('tvl') or [{}]); print('tvl_usd', (t[-1] if t else {}).get('totalLiquidityUSD')); print('staking', (d.get('currentChainTvls') or {}).get('staking'))"
# 7) CoinGecko public markets API (the market-series origin; the coingecko.com
#    browser coin page 403s plain curl, so the programmatic endpoint is given):
curl -s "https://api.coingecko.com/api/v3/coins/markets?vs_currency=usd&ids=mass-vehicle-ledger" | python3 -m json.tool | head -40
# 8) This estate's public API row for MVL (grades + provenance):
curl -s "https://kairossignal.com/v1/network/MVL" | python3 -m json.tool | head -60
# 9) 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_mvl.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The MVL revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='MVL'; the page refuses to ship if the served /v1/revisions?symbol=MVL is reachable and disagrees with it (at generation the estate API was answering its free-tier daily-quota 429, so the cross-check ran against ClickHouse as the authority and the endpoint was verified quota-gated, not missing). 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 chain-side supply read (onchain_total_supply) is constant 30,000,000,000 across every held row because the ERC-20 contract's totalSupply() is a fixed cap — the chain's true answer, not staleness; the counters beside it move, proving the read path is alive. The same-stamp conflict check is the honest live answer: 0 groups in depin_onchain and 0 in depin_daily. Upstream probes ran serially by this generator immediately before rendering: Blockscout token endpoint for the MVL contract (the supply/holders origin) HTTP 200; Blockscout counters for the MVL contract (the counter-trails origin) HTTP 200; Blockscout holders endpoint for the MVL contract (the top-holder origin) HTTP 200; Blockscout address-counters for the MVL contract (the tx/gas origin) HTTP 200; DefiLlama protocol API for mvl-staking (the tvl_usd / staking origin) HTTP 200; CoinGecko markets API for mass-vehicle-ledger (the market-series origin) HTTP 200; estate /v1/revisions?symbol=MVL HTTP 429; estate /v1/network/MVL HTTP 429.