Subnet 66: ninja
ninja is Bittensor Subnet 66. The registered tau repository and tau README source describe a staged software-engineering workflow for generating tasks, running solver agents, comparing saved solutions, and validating a live king-of-the-hill loop.
The same source also identifies a separate public miner-editable agent harness while tau owns task generation, execution, validation, scoring, and managed inference.
What ninja Provides
ninja provides a competitive workflow for improving software agents. The public materials describe tasks based on software-engineering commits, candidate agents that produce patches for those tasks, and validator scoring that compares challenger patches against the current leading agent.
The subnet’s name and live description frame this as software-agent distillation: miners improve an agent, validators test those improvements, and successful challenger behavior can become the new public base agent for later challengers.
Miner and Validator Roles
Miners submit agent logic that follows the public harness contract described by the tau README. At a high level, a miner’s work is to produce an agent that can inspect a software task and return a useful patch with supporting run metadata.
Validators operate the task and duel workflow. The README describes validators generating or maintaining task pools, running the current leader and challenger on the same tasks, comparing their patches with a language-model diff judge, and promoting a challenger when it wins the required duels. The resulting validator weights fit the usual Mining and Validating pattern and are processed through Yuma Consensus.
Agent Distillation Context
ninja’s core contribution model is software-agent distillation. The tau README describes a workflow where tasks are generated from software-engineering commits, solvers produce patches for those tasks, and validators compare saved solutions before updating the current leader.
That makes the subnet different from a generic coding benchmark. A miner is not only trying to solve a single issue once; the public materials frame the subnet as a repeated challenger process where better agent behavior can displace the current leading agent and become the next base for future comparisons.
The same registered source separates miner-editable agent behavior from validator systems, task generators, scoring, wallets, and infrastructure. That separation helps explain why the subnet’s public name is about distilling software agents rather than publishing a general development toolchain.
Evaluation Boundary
The tau README identifies task generation, Docker execution, validation, scoring, and managed inference as tau-owned responsibilities. That boundary is important because Subnet 66 measures agent behavior under a validator-controlled evaluation process rather than accepting self-reported miner results.
The evaluation signal is patch quality in a controlled software task setting. Validators can compare the current leader and a challenger on the same tasks, use judge-based comparison of their patches, and promote a challenger only when it performs better under the subnet’s duel process.
The miner-facing boundary narrows what miners are expected to improve: reasoning, repository inspection, editing behavior, and returning a usable patch. The subnet therefore rewards agent improvements that survive shared task evaluation, not changes to scoring infrastructure or validator-owned controls.
On-Chain Identity
Live SN66 subnet data is available on TaoStats. The source-backed agent-distillation and evaluation-boundary details in this article come from the registered tau repository materials rather than from live identity fields.
Relationship to Yuma Consensus
Subnet 66 uses Yuma Consensus to convert the duel-performance 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 ninja’s context, validators generate task pools from software-engineering commits, run the current leader and each challenger on the same tasks, compare their patches using a language-model diff judge, and promote a challenger only when it wins the required duels. The resulting weight vectors reflect each miner’s agent performance across those duel evaluations. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Reader Boundary
Subnet 66 ninja should not be read as generic Bittensor subnet documentation, a general software development tool, or a place where miners control the evaluation pipeline. The tau materials separate miner-editable agent behavior from tau-owned task generation, execution, validation, and scoring (tau README source).
It is also not a static benchmark result. The subnet is framed as a king-of-the-hill loop where validators run the current leader and challengers on shared tasks and promote a challenger only when it wins the required duels. Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Subnet 66, that sequence applies to the standard Bittensor lifecycle: localnet for isolated development, testnet for shared non-production testing, and mainnet for live operation with real emissions.
On mainnet, Subnet 66 is registered as the live production subnet at netuid 66. The Bittensor Networks reference separates mainnet, testnet, and localnet. Participation examples or emission outcomes from one environment should not be read as representing production subnet performance in another environment.