Subnet 107: Minos
Minos is Bittensor Subnet 107. Its on-chain description is “The Foundational Layer of Genomics,” and the project site is theminos.ai. The subnet applies Bittensor’s competitive incentives to genomic variant calling — the task of identifying where a DNA sample differs from a reference genome. The network repeatedly poses these as challenges with a known answer and rewards the miners whose methods recover the differences most accurately. The codebase for the subnet is minos-protocol/minos_subnet, and the Minos README source describes the subnet’s challenge, miner, validator, and scoring roles.
What Minos Rewards
On a regular cycle the platform generates a fresh challenge genome and injects hidden, synthetic mutations into it. Because the platform knows exactly which mutations it added, it has a ground truth to grade against, which makes the competition objective: a method either recovers the planted mutations or it does not.
Miners are rewarded for producing the configurations that find those mutations most accurately. In practice this means searching for the best settings for established, state-of-the-art variant-calling tools so they detect the planted variants as precisely as possible, and as the obvious settings get exhausted the competition is designed to move toward miners contributing their own custom approaches. The reward follows measured accuracy against the known answer rather than self-reported results.
Benchmark Context
Minos works because the challenge generator gives the subnet a known answer key. The platform can construct a genome challenge, insert synthetic mutations, and then ask miners to find those mutations without revealing where they are. This turns genomic variant calling into a benchmark that validators can score directly instead of relying on subjective review.
That known-answer design is important for a Bittensor subnet. Miners are competing on whether their method recovers the hidden variants, not on whether they can describe a plausible analysis. A miner that misses planted mutations or fails to generalize across fresh challenge data should score worse than one whose configuration continues to recover the hidden answer accurately.
Configuration Submission Context
Miners submit configurations rather than final variant-call outputs. That boundary helps keep the evaluation reproducible. Validators can run the submitted configuration against the same challenge data and compare the resulting calls with the known planted mutations, which keeps the scoring path independent of a miner’s self-reported result.
This makes Minos closer to a reproducible benchmarking subnet than a file-upload leaderboard. The miner contributes the method for making calls; the validator performs the run and measurement. That separation is what lets the network reward useful variant-calling behavior while still checking the work under validator control.
Miner and Validator Roles
A notable feature of Minos is that miners never upload their outputs. A miner downloads the challenge genome, runs a variant-calling pipeline on it, and submits only the configuration that produced their best result. A registered hotkey on netuid 107 is what ties that submission back to them.
Validators then reproduce the work trustlessly. They take each miner’s submitted configuration, run it themselves on the challenge data, and score the resulting calls against the known set of planted mutations using standard genomics benchmarking. From those scores they set weights on the network, which is how reward flows through Yuma Consensus. At the article level the split is straightforward: miners supply the variant-calling configuration, while validators execute it, measure its accuracy, and weight each miner accordingly.
Source and Live Data
The public project site is theminos.ai, and the codebase is maintained in the minos-protocol/minos_subnet repository. Live SN107 subnet data is available on TaoStats. The mechanism context in this article is tied to the project site and public README rather than to live identity fields alone.
Relationship to Yuma Consensus
Subnet 107 uses Yuma Consensus to convert the genomic-benchmark score weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The linked documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Minos’s context, validators take each miner’s submitted variant-calling configuration, run it themselves on the challenge genome data, score the resulting calls against the known set of planted mutations using standard genomics benchmarking, and translate those accuracy scores into weight vectors for the subnet. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Minos (SN107), that sequence changes how readers should interpret genomic variant-calling competition examples and benchmark scoring outcomes.
In localnet, Minos-compatible miners and validators can be developed and tested in an isolated environment. Localnet variant-calling benchmark results and emission outcomes do not represent production subnet performance.
On testnet, Minos-compatible genomics pipeline workflows can be exercised in a shared, non-production network. Testnet benchmark results and validator weights are separate from mainnet subnet state.
On mainnet, Minos (SN107) is the live production subnet where miners submit variant-calling configurations and validators score them against planted mutations to determine real Bittensor emissions. The Minos repository describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A benchmark result or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Netuid 107 Identifies the Subnet On-Chain
Bittensor assigns every subnet a unique numeric identifier called a netuid, and Subnet 107 is the subnet registered at netuid 107 (Glossary: Netuid). The Understanding Subnets reference explains that each subnet runs its own incentive mechanism while sharing the same underlying Subtensor chain, so the netuid is the stable handle that distinguishes Minos from every other subnet.
For a reader, this means “Subnet 107” and “netuid 107” refer to the same on-chain slot. A claim about Minos should be tied to that netuid rather than to the registered name alone, because the name field can be changed on-chain while the netuid stays fixed.
Reader Boundary
Subnet 107 Minos should not be read as generic Bittensor subnet documentation, a clinical or diagnostic genomics service, or proof that any pipeline performs on real patient data. It names one genomics subnet where miners tune variant-calling pipelines on synthetic genomes and validators run their configs to score accuracy on netuid 107 (Understanding Subnets, Glossary: Netuid).