Minos: how the mechanism works
Minos turns a genomics benchmark into a repeated contest, and it is unusually specific about exactly how a narrow win becomes an outsized reward — and about exactly which numbers are not fixed in its own code.
Minos runs a genomic variant-calling benchmark. Roughly every 72 minutes, its own platform generates a fresh challenge genome containing hidden synthetic mutations, injected at the level of individual sequencing reads by a tool it calls HelixForge. A miner is rewarded for hyperparameter search: finding settings for an established variant-calling tool that catch more of those hidden mutations. The subnet's own materials say plainly what comes after that: once the hyperparameter space is "saturated," miners will compete with their own custom algorithms instead — and a miner is, in the subnet's own words, "never... asked to upload outputs," only the configuration a validator then runs itself. [source]
At this course's snapshot, Minos carries a market capitalisation of 94796917372184 @ 8878789 rao against a measured emission share of 2.5% @ 8878789 (rank 7 @ 8878789). 2720 @ 8878789 wallets hold its alpha token, and 35.0% @ 8878789 of the stake behind its judging committee traces to the root network rather than to stake placed directly in Minos itself.
How the mechanism works
A miner downloads the round's challenge genome, runs one of three established tools — GATK, DeepVariant, or BCFtools — locally with settings of its own choosing, and submits only that configuration, not any output. [source] [source] A validator then re-runs that exact configuration itself and grades the result with hap.py, an industry-standard genomics comparison tool, against the true mutations. [source] [source] Nothing a miner reports is taken on trust — the validator's own re-run of the same settings is what actually gets scored. [source]
The score itself blends four components: the core F1 match rate is worth 60% of it, completeness 15%, false-positive rate 15%, and a biological-consistency check the remaining 10%. [source] [source] SNP and indel calls are weighted against each other in proportion to how many of each the truth set actually contains. [source]
Turning that score into pay is deliberately winner-heavy. A miner needs at least five valid scored rounds inside the last twenty before it is eligible for anything; once eligible, the single top-ranked miner in the current round currently takes roughly 90% of the reward, and the next nineteen split what is left on a decaying scale. [source] But "currently" is doing real work in that sentence: the subnet's own documentation says outright that these are "dynamic protocol values — read the current numbers from get_network_config rather than assuming them." [source] [source]
Why they built it this way
The subnet's own stated reason for re-running a miner's configuration rather than grading a self-reported result is direct: results are evaluated "using industry standard tools and approaches such as hap.py," and the validator "executes trustlessly" rather than accepting an upload. [source] That closes off an entire category of dishonest reporting for free — a miner cannot claim a result it did not actually produce.
The reward policy's own code is just as direct about a second design choice: rather than hold the winner-heavy split as a constant, the validator fetches it live and refuses to set weights at all if that fetch fails. Its own comment reads: "Network reward params are authoritative. If the platform cannot provide a complete policy, fail closed instead of silently using stale local defaults." [source] That is a stated reason for *failing closed on a missing policy* — this course did not find a stated reason, anywhere in this source, for why the reward curve is fetched from a live service in the first place rather than fixed in the open-source validator code, so it says that plainly rather than guessing one.
What a miner is actually optimising
The stated goal is accurate variant calling. What the reward structure actually pays for is narrower: being the single best configuration on that specific round's synthetic genome, since the gap between first place and the rest of the field is worth roughly nine times as much as the entire remaining field combined. [source]
Unverified With only three underlying tools available and a configuration limited to their published parameters, a miner's real edge may come down to how thoroughly it has searched that tool's parameter space against this platform's own mutation-generation habits, rather than to any deeper advance in variant calling. The subnet's own materials gesture at this directly, describing today's contest as hyperparameter search with custom algorithms deferred until "the hyperparameter space has been saturated" — but this lesson cannot confirm from its pinned source how much headroom is actually left in that search today, or how close to saturated it already is. [source]
Do validators do anything besides validate?
Not a second business of their own: nothing in this source shows a validator serving an external API, selling capacity, or holding funds beyond its own stake. But the work of judging here is split, not duplicated. Each validator fetches a scoring assignment from the platform — a primary range of miners sized by that validator's own stake — personally re-runs only that primary range, then backfills the miners it did not personally cover by taking scores other validators already reported. [source] [source] The re-run-to-verify guarantee described above is real, but it applies to the miners a given validator was personally assigned — a score it backfills from a peer for its own submission is exactly as trustworthy as that peer's own re-run was.
The genomic ground truth every score is checked against, and the reward-policy numbers that turn a score into pay, both come from one service the subnet's own team runs — https://api.theminos.ai — which validators and miners "connect automatically" to, "no self-hosting required." [source] [source] That same platform prepares the challenge genomes, injects the synthetic mutations, coordinates rounds, and serves reference genomic data through its own indirected URL. [source] [source] A validator genuinely re-runs a miner's work locally — that part is real and checkable — but it is grading against truth data it did not generate, on a scoring curve it does not set, both supplied by the same subnet-owned service.
Why it earns
Cross-subnet emission share is set by one formula, identical for every subnet: each one's share is its own moving-average alpha price, discounted by a miner-burn penalty, against every other subnet's. [source] [source] Minos' scoring design is unusually specific and checkable — a published four-component formula, a re-run rather than a self-report, an industry-standard grading tool — but that specificity has no separate route into the emission formula above; it can only matter by first moving alpha price. Minos' alpha traded at 0.066956377 @ 8878789 TAO at this snapshot, up 10.82802915716152 @ 8878789% over the trailing week and up 46.4984633566973 @ 8878789% over the trailing month — a real, measured move that this course's evidence can trace toward Minos' 2.5% @ 8878789 share, but a checkable mechanism is not the same claim as a mechanism that is *driving* that price, and this lesson does not have evidence to join those two.
What to copy, what to avoid
Copying: a validator that re-executes a miner's own declared method against fresh data, rather than grading a self-reported result, closes off an entire category of dishonest reporting for free. [source] Refusing to set weights at all when the live reward policy cannot be fetched — rather than quietly falling back to a stale default — is a real, checkable safeguard against acting on a policy nobody currently confirmed. [source]
Avoiding: concentrating close to the entire round's reward on a single winner makes the difference between a genuinely better method and a slightly luckier hyperparameter search look identical from the outside. [source] And publishing a reward curve as "dynamic — read it from get_network_config" rather than as a fixed, auditable constant means the actual economics a miner is competing under can change between rounds without any change to the open-source code itself. [source]
How it actually works
The repository lays out where each piece lives: neurons/miner.py and neurons/validator.py are the two chain-facing loops; scoring runs hap.py and computes the four-component AdvancedScorer result; utils/weight_tracking.py turns a round's scores into the weights actually submitted on chain. [source] [source]
ScoreTracker tracks only the current round's scores — nothing from earlier rounds carries into it — and gates eligibility on a rolling window: [source]
PARTICIPATION_WINDOW = int(os.getenv("PARTICIPATION_WINDOW", "20"))
MIN_PARTICIPATION_ROUNDS = int(os.getenv("MIN_PARTICIPATION_ROUNDS", "5"))
[source] Its module defaults for the reward curve itself are named constants, used only as a local fallback:
DEFAULT_BURN_RATE = 0.0
DEFAULT_WINNER_WEIGHT = 0.9
DEFAULT_DUST_TOP_N = 20
DEFAULT_DUST_DECAY = 0.80
[source] get_winner_heavy_pruning_dust_weights takes those same four parameters as arguments rather than reading the module constants directly, assigns the top-ranked eligible miner winner_weight, and splits miner_budget - winner_weight across the next dust_top_n - 1 ranks by geometric decay. [source] [source] [source]
The caller that actually decides what those four parameters *are* is where the live dependency lives. Before setting weights, the validator calls self.platform_client.get_network_config() — an HTTP GET /scoring/network-config against the platform, returning None on any error — and validates every field it gets back: [source] [source]
network_cfg = await self.platform_client.get_network_config()
if not network_cfg:
bt.logging.error("Network reward config unavailable — skipping weight submission ...")
return False
[source] [source] [source] burn_rate, burn_uid, winner_weight, dust_top_n, and dust_decay are each range-checked — an out-of-range or missing field skips weight submission entirely for that round rather than falling back to the module defaults above. [source]
Grading work itself is sharded, not duplicated: a validator fetches "a scoring assignment from platform (primary miner range based on validator stake)," scores that primary range by locally re-running each miner's submitted configuration, then fetches peer-reported scores to backfill any miner it did not personally cover before finalising the round and setting weights. [source] [source] A validator's own operational notes are explicit that this is heavier than ordinary miner work, and that the truth data it grades against is private and never shared publicly. [source] [source]