Every chart carries the version of the metric that produced it. This is what those versions mean — what each one measures, how it is defined, what changed at every bump and whether values that had already been published moved. It is generated from the source of each module on every build, so it cannot describe a definition the site is not using.
Retuning a metric silently rewrites every historical chart drawn with it. Change the diminishing factor in the risk model and every value the site has ever shown is a different number, with nothing on the page to say so. That is the failure this catalogue exists to make impossible, and it is why each entry below states not just what changed but whether the change reached backwards.
3 of the 19 metrics have restated a published value at least once — flags, resrisk, tech. A chart drawn before one of those bumps does not match the same chart drawn after it, which is a fact about the numbers rather than about the code, and belongs where a reader can find it.
| Metric | Version | Versions | Charts | Historical values | What it measures |
|---|---|---|---|---|---|
| align | align-v2 | 2 | 2 | Never moved | Putting two sources on the same calendar day. |
| alt | alt-v1 | 1 | 1 | Never moved | Alt season index — share of large alts outperforming BTC over a rolling window. |
| breadth | breadth-v2 | 2 | 4 | Never moved | Market breadth and cross-asset correlation. |
| cycle | cycle-v5 | 5 | 115 | Never moved | Cycle and ROI comparison. |
| dom | dom-v1 | 1 | 3 | Never moved | Dominance — share of a defined basket, not of "the total crypto market cap". |
| implied | implied-v1 | 1 | 2 | Never moved | Market-implied probabilities from Kalshi candles. |
| logreg | logreg-v2 | 2 | 44 | Never moved | Logarithmic regression — fit log(price) against log(days since genesis). |
| risk | risk-v1 | 2 | 46 | Never moved | Risk metric — reconstruction, not a clone. |
| riskstat | riskstat-v1 | 1 | 15 | Never moved | Statistics about the risk metric. |
| tech | tech-v4 | 4 | 137 | Restated | Technical indicators. |
| val | val-v1 | 1 | 44 | Never moved | Valuation multiples and the asymmetric regression fan. |
| Metric | Version | Versions | Charts | Historical values | What it measures |
|---|---|---|---|---|---|
| cat | cat-v1 | 1 | 3 | Never moved | Market categories — the denominator for "dispute rate by category". |
| flags | flags-v2 | 2 | 3 | Restated | Phase 4 — the flag taxonomy. This is the product, not the plumbing. |
| latency | latency-v1 | 1 | — | Never moved | Settlement latency — how long a venue takes to pay out after the question is answered. |
| match | match-v3 | 3 | — | Not stated | Phase 4 step 3 — candidate generation for cross-venue matching. |
| resdb | resdb-v2 | 2 | 3 | Not stated | Phase 4 — the resolution database. Four tables, one per RESOLUTION_DB's design. |
| resrisk | resrisk-v2 | 2 | 3 | Restated | Resolution risk as a metric module — the locked contract, plus the evidence. |
| uma | uma-v1 | 1 | — | Never moved | UMA's DVM: who settles disputes, with what stake, which way, and when slashed. |
| verify | verify-v1 | 1 | — | Never moved | Phase 4 step 3, stage two — LLM verification of candidate links. |
These versions changed something, and their modules do not say whether values already published moved with it. The catalogue is generated, so it can either report that or invent an answer. It reports it. Until the module says, treat a chart stamped with one of these as possibly not matching the same chart drawn before the bump.
settlement_time added — when a contract ACTUALLY settled, which on Kalshi is not expiry_time. See below.The same data, generated in the same pass, with no login and no key: catalog.json and llms.txt. Both carry every version, every verdict above and the sentence from the source that produced it.