SN99 — score multiplier by miner

Some miners' published score is their replayed q_lcb multiplied by a fixed per-miner constant. This is every miner the replay could verify.

7 steps

across 86 miners

miners with a verified step

operators involved

±0.000000

replay accuracy where verified

Table

uid	multiplier	segment	len	status	exact	epochs	repo

Detected by a replay-bias-free step detector: a one-epoch jump in published ÷ replayed of more than 1.5%, not adjacent to a missing epoch, with the ratio flat to <0.003 for four epochs on both sides. Across all 86 miners this fires 7 times on exactly 4 uids and nowhere else. Levels are stated relative to each miner's own baseline, so they do not depend on the replay being unbiased.

An earlier version of this page listed 14 miners. Nine of those were artefacts: their apparent segments began at epoch 87821, which is one past a missing snapshot, and an independent replay reproduces their published feed to 1 part in 10⁶ (uid 118 @87826: published 0.818144 vs replayed 0.8181441). They are corrected to no step here.

Multiplier by epoch

The three miners with Docker-graded ground truth, epoch by epoch. 1.00 means the replay matched the published feed exactly.

What this is

published_score = C × [ q_lcb − 0.02 · min(1, cost_per_task / 0.015) ] q_lcb = Σ_b weight_b · wilson_lcb(k_b, n_b) z = 1.645 EWMA λ = 0.5^(1/200) weights: mmlu 0 · math 0 · code 1

The factor multiplies the final score, after the cost tiebreak. Fitted on uid 28's clean plateau: C·(q_lcb − cost) gives max error 3.4×10⁻⁷ at exactly 1.030000, versus 3.4×10⁻⁶ for C·q_lcb − cost and 2.8×10⁻⁴ for an additive term.

Each miner's step ratios multiply back to 1. uid 24: 1.100079 × 0.981835 × 0.972234 × 0.952377 = 1.000098. The factor is switched on, stepped down, and switched off cleanly.

uid 117 needs no replay at all

Since q_lcb ≤ wilson(n,n) = 1/(1+z²/n) and n is deterministic (2 code tasks per epoch, EWMA λ), a published score has a hard ceiling given a miner's age. Anchoring every miner at its first appearance in scored ∪ dq across all 702 snapshots and assuming it was never absent and never wrong, exactly one miner exceeds its ceiling:

uid117 @87814 published 0.983714 ceiling 0.954742 (n_max 57.09) reaching 0.983714 honestly requires n = 163.5 = 95.9 consecutive flawless epochs uid117 had 30.

This is stronger than "a multiplier was applied": the number is outside the range of the documented scoring function for that miner, and it does not depend on any replay.

Where the factor sits

It is inside the validator's own output, not added at publication. Each snapshot's reign chain array records the score at which a seat was granted; uid 117 enters it at epoch 87828 with 0.968150 — bit-identical to its published 87827 value, whose unmultiplied replay is 0.84245. So the scaled value drives seat assignment and on-chain weight setting.

The public feed is a faithful copy: 9056 exact matches, 0 differences between the dashboard API and the standings snapshots. The dashboard is not the transform.

What was ruled out

The router scalar (headroom_lcb), re-confirmed harder: zero firings inside all four verified segments with diagnostics present on 161/161 covered epochs. Producing C would need a pooled gap ≥ 0.8696; the maximum published achievable_gap is 0.7838 across 534 samples (407 of them exactly 0), and recomputed from the 270 owner-signed references it is 0.4587. At epoch 87814 it is 0.000000.

Also eliminated, each with the measurement that killed it: cross-hotkey evidence pooling (best pair still 0.070 off, exact needs 1e-4); artifact re-commit (a reset lowers the ceiling, uid 117 went up through it); score copying from another miner (no match at 5×10⁻⁴); on-chain carriage (two coldkey-identical pairs carry different C; the owner governance commitment is byte-identical across 8 archive blocks and has no per-miner field; zero extrinsics at the 87827 step across 360 blocks).

Code audit: report.scored has three writers and one publisher; the only one reachable in production is validator.py:876; reign.py only compares scores; no hotkey literal appears anywhere in src/; no environment variable reaches a score.

What is not established

No mechanism survived. What survived is a bounded description of where the transform sits, not what performs it. The only remaining hypothesis space is that the process publishing the feed is not running the audited source — and there is one direct measurement pointing that way: 48 of 702 snapshots (epochs 75663–75715) carry no diagnostics key, which the current source emits unconditionally. The running emitter has differed from the audited source at least once.

This observes published output, not the code producing it. No claim is made about intent. Nothing in the repository can adjudicate it: the build-freshness check compares a commit hash to a repo inside the same container, and the attestation machinery attests miner runtimes, not the validator's.

What would settle it

One independent execution of one epoch. The replay consumes the owner's own published per-task grades, so re-running the audited code on published data can only ever reproduce the replay — the tie is breakable only by a second scorer.

On chain there are four weight-setters on netuid 99. uid 0 and uid 1 are identical and owner-side. uid 27 is live-updating, independently operated, and its weight set never contains uid 117. One number decides it — uid 27's computed score for uid 117 at epoch 87827: 0.8425 (audited code) or 0.96815 (published). Its raw scored dict is what is needed; its weight set alone is not a clean oracle, since it also carries uid 2 and uid 24.