Subnet 94: BitSota
BitSota is Bittensor Subnet 94. Public BitSota materials describe an open machine-learning research competition where miners use automated search to evolve candidate algorithms and validators check the claimed results before weights are set.
What BitSota Rewards
The BitSota README frames the subnet as a decentralized research network for competitive algorithm optimization. Miners evolve machine-learning algorithms, validators independently evaluate submissions, and the reward signal is tied to whether the submitted work holds up under validation.
The research idea is related to automated algorithm discovery. The README cites AutoML-Zero as one inspiration: instead of only tuning a human-designed model, automated search can generate and test candidate learning procedures. BitSota applies a similar broad idea inside a Bittensor reward market, where many miners can explore candidates in parallel.
This makes the subnet different from an ordinary model leaderboard. The thing being rewarded is not only a trained model artifact, but the process of finding algorithms that perform better on the selected research problem. A useful submission must improve performance and remain reproducible enough for validators to verify.
Miner and Validator Roles
Miners run algorithm-search work and submit candidates for evaluation. The README describes direct mining, pool mining, and research-agent mining as different participation paths, but the subnet-level role is the same: miners search for stronger candidate algorithms and submit work that can be checked.
Validators are the independent check on those claims. They evaluate submitted work, verify reported performance, and set network weights according to the results that hold up. That role split keeps the competition from rewarding unverifiable claims: miners explore the search space, while validators decide which submissions can be trusted for subnet scoring.
Validation and Reward Channel Boundary
The BitSota README describes miners as evolving candidate machine-learning algorithms while validators independently evaluate submissions and set weights. That separation makes validation the boundary between a promising algorithm-search result and a rewardable subnet result. A miner’s work has to survive the independent check before it can matter for subnet weights.
The same source describes several participation modes, including direct mining, pool mining, and research-agent mining. Those modes are entry paths into the research process, not separate article topics with unrelated reward logic. The shared idea is that candidate algorithms or research work must be checked before it can influence the reward signal.
The BitSota rewards guide adds another useful boundary by distinguishing Bittensor subnet emissions from pool reputation rewards. Subnet emissions flow through validator-set weights, while pool rewards describe how pool participants are credited inside the pool’s reputation system. Those are related reward channels, but they should not be read as the same mechanism.
This distinction matters for interpreting BitSota results. A pool participant can contribute useful search or evaluation work inside the pool process, while validators still provide the subnet-level check that connects accepted results to Bittensor emissions. The pool can organize participation; the subnet still depends on validator-side scoring for network rewards.
BitSota’s AutoML-Zero inspiration also needs that evidence boundary. Automated algorithm discovery can produce candidate procedures, but the subnet’s public materials frame rewards around checked performance rather than novelty alone. The useful claim is not that every generated candidate is state of the art; it is that BitSota provides a market for searching, checking, and rewarding candidate algorithms that perform under the current task definition.
References: BitSota README, BitSota rewards guide
Research Context
BitSota’s sources describe the platform as problem-agnostic. A problem-agnostic research subnet can point the same competitive structure at different benchmarks or hidden evaluation criteria instead of locking the network to one fixed model forever. That flexibility is useful for automated research, where the target can change as stronger algorithms are discovered.
The README also describes both individual and pooled participation modes. At a high level, this means the subnet can accept work from miners with different compute profiles while still preserving validator-side verification. Direct miners can search locally, pool participants can contribute to shared search work, and validators remain the layer that tests whether submitted candidates deserve weight.
The key distinction is between algorithm discovery and algorithm deployment. BitSota’s subnet-level contribution is the search-and-verification loop: automated candidate generation, independent evaluation, and weights for candidates that hold up.
On-Chain Identity
Live SN94 subnet data is available on TaoStats. The source-backed research and validation details in this article come from public BitSota materials rather than from live identity fields.
Relationship to Yuma Consensus
Subnet 94 uses Yuma Consensus to convert the algorithm-evaluation weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The Yuma Consensus documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In BitSota’s context, validators independently evaluate submitted candidate algorithms, verifying reported search performance before translating those verified results 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 BitSota (SN94), that sequence changes how readers should interpret algorithm-search submission examples and validation-based scoring outcomes.
In localnet, BitSota-compatible miners and validators can be developed and tested in an isolated environment. Localnet algorithm-search results and emission outcomes do not represent production subnet performance.
On testnet, BitSota-compatible candidate algorithm submissions can be exercised in a shared, non-production network. Testnet evaluation results and validator weights are separate from mainnet subnet state.
On mainnet, BitSota (SN94) is the live production subnet where miners evolve machine-learning algorithms and validators independently verify those submissions to determine real Bittensor emissions. The BitSota repository describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. An algorithm evaluation result or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 94 BitSota should not be read as generic Bittensor subnet documentation, a guarantee that every evolved algorithm earns emissions, or a single pool leaderboard without validator replay. The BitSota README describes miners evolving candidate algorithms and validators independently checking submissions before weights are set.
Pool Reputation Rewards Differ From Subnet Emissions
The BitSota rewards guide describes pool miners earning through a reputation system converted to RAO at pool epoch boundaries, separate from Bittensor subnet emissions directed by validator weight setting. Pool epoch credits and on-chain subnet weights are related participation channels, not the same payout mechanism.
Production Weights Follow Backend Replay Validation
The same rewards guide states that current SN94 production weight direction comes from an autoresearch backend reward snapshot applied by validators through the backend weight setter. Subnet emissions therefore follow backend-validated replay results rather than unverified miner claims about algorithm performance alone.
Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).