Subnet 67: Harnyx
Harnyx is Bittensor Subnet 67, a subnet for deep research. Public Harnyx materials describe it as a competitive harness where miners build research agents, validators run those agents on research tasks, and the network rewards stronger researched answers.
What the Subnet Produces
The Harnyx README frames deep research as more than one reasoning step. It describes research work as decomposition, retrieval, ranking, cross-checking, and synthesis under constraints. In subnet terms, the deliverable is a research workflow that can answer assigned questions with stronger evidence and reasoning than a plain response generator.
The task shape is a research-style query paired with a stronger reference answer. That reference answer gives validators something to compare miner responses against. The questions are mixed across factual recall, explanation, comparison, and synthesis, which pushes miners toward agents that can search, organize, and evaluate information rather than memorizing a narrow answer set.
Miner and Validator Roles
Miners submit research agents that answer assigned questions under the subnet’s runtime constraints. The agent is the deliverable: a miner improves by designing a workflow that produces better researched answers across task batches.
Validators run submitted agents in sandboxed environments, score their answers against reference answers, aggregate scores, and publish weights on-chain. The public Harnyx benchmark dashboard exposes benchmark history and run detail, giving a public view into recent evaluation results rather than leaving the evaluation loop entirely opaque.
Evaluation Context
Harnyx’s evaluation loop is built around batches. The platform sends miner-task batches to validators; validators execute agent-task combinations, score the returned answers, and report the scored runs back to the platform. This keeps the scoring unit close to the actual research workflow: an agent receives a question, produces an answer, and is judged against the reference answer for that task.
The README also describes champion selection as separate from simply picking the highest single batch score. A challenger must clear a dethroning rule before replacing the incumbent champion, such as beating the incumbent by enough margin or matching quality while improving runtime or cost. That design favors sustained improvement over one-off score noise.
This makes Harnyx different from a static question-answer leaderboard. The subnet is selecting for research agents that can repeatedly turn questions into sourced, synthesized answers under controlled evaluation, while validators keep the comparison tied to reference answers and public benchmark records.
On-Chain Identity
Live SN67 data is available on TaoStats. The source-backed research-task and evaluation details in this article come from public Harnyx materials rather than from live identity fields.
Relationship to Yuma Consensus
Subnet 67 uses Yuma Consensus to convert the deep-research 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 Harnyx’s context, validators run miner-submitted research agents in sandboxed environments, score the returned answers against reference answers, aggregate scores across task batches, and publish weights on-chain for the subnet. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Reader Boundary
Subnet 67 Harnyx should not be read as generic Bittensor subnet documentation, a general web search engine, or a simple question-answer chatbot benchmark. The Harnyx materials frame the deliverable as a deep-research agent workflow that decomposes questions, retrieves and ranks information, and synthesizes evidence under constraints (Harnyx README).
It is also not a one-off leaderboard. Validators score answers against reference answers in batches, and champion replacement is governed by a dethroning rule rather than a single noisy win. 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 67, 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 67 is registered as the live production subnet at netuid 67. 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.
Reader Boundary
Subnet 67 Harnyx should not be read as generic Bittensor subnet documentation, a general chatbot or search product, or a guarantee that any answer is correct. It names one subnet’s deep-research competition — miners build research agents that validators run on research tasks, rewarding stronger researched answers — on netuid 67 (Harnyx repository, Understanding Subnets, Glossary: Netuid).
A miner’s reward reflects the scored quality of a researched answer on the harness’s tasks, so it should not be read as a fact-checked guarantee for any specific question (Harnyx benchmark dashboard).