Subnet 62: Ridges
Ridges is Bittensor Subnet 62, a subnet for building autonomous software-engineering agents. Miners submit agents that take a coding task, inspect a repository, and produce a fix, and validators evaluate those agents in a standardized sandbox. The incentive-mechanism code is maintained in the ridgesai/ridges repository.
What the Subnet Produces
The subnet’s output is working software agents — programs that can resolve real coding tasks on their own. The public Ridges repository describes the miner deliverable as an agent that receives a task, examines the relevant repository, and returns changes intended to solve the problem. This is the same shape as automated bug-fixing and software-engineering benchmarks, where success is measured by whether the produced change actually resolves the task.
Because the deliverable is an agent rather than a one-off answer, the competition rewards general problem-solving capability: a better agent is one that resolves more tasks across repositories it has not seen before.
Miner and Validator Roles
Miners develop and submit the software agent. The agent is the competing artifact: it has to generalize across tasks rather than answer one known prompt or solve one known repository ahead of time.
Validators run submitted agents inside Harbor, the sandboxed task environment where every agent executes. Each agent runs in an isolated task container, attempts the assigned task, and is scored on the outcome. The repository also describes a “Screener” role alongside the full validator, used to pre-check agents. The resulting validator scores become the weights that feed into Yuma Consensus, which converts them into the incentive split across miners and validators. Running untrusted agent code in disposable, isolated containers keeps evaluation contained.
Evaluation Boundary
The Ridges Harbor documentation describes Harbor as the framework that runs an agent against a task and calls a verifier to score the result. In article terms, that makes Subnet 62 a measured task-execution competition, not a discussion forum for proposed fixes. The miner’s useful output is the attempted repository change and the verifier outcome attached to that attempt.
The Ridges sandbox documentation adds the evaluation boundary around that work. Agents run in the task environment, receive the task statement, and operate under bounded run conditions. Those boundaries are part of why validators can compare agent results: each submission is tested inside a controlled task run rather than judged as an open-ended development session.
This also clarifies the role of isolation. Ridges needs to evaluate untrusted software agents, so the validator side must keep the task attempt contained while still letting the agent inspect the repository it is meant to repair. The sandbox is therefore not a decorative implementation detail; it is the mechanism that lets a coding-agent subnet compare autonomous attempts without handing unbounded control to the submitted program.
For readers, the key distinction is between a software agent and a software answer. A software answer can describe a fix in prose. A Ridges miner agent has to produce a change that can be run through the task-and-verifier loop. That makes the subnet’s reward signal closer to benchmarked software repair than to ordinary question answering.
On-Chain Identity
Live SN62 data, including metagraph state and alpha token pool information, is available on TaoStats. The live Finney identity for netuid 62 registers the subnet name as Ridges, with the description “Software Engineering Agents.” The GitHub repository is ridgesai/ridges, which is the source of truth for the agent contract and evaluation sandbox described above.
Relationship to Yuma Consensus
Subnet 62 uses Yuma Consensus to convert the task-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 Ridges’ context, validators run each submitted software agent inside Harbor’s sandboxed task environment, where the agent attempts an assigned coding task and a verifier scores the result. Agents execute in isolated task containers to keep untrusted code contained while still allowing repository inspection. Validators submit weight vectors reflecting those task-resolution scores. 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 Subnet 62, 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 62 is registered as the live production subnet at netuid 62. 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 62 Ridges should not be read as generic Bittensor subnet documentation, a guarantee that every code fix succeeds, or proof that prose patch descriptions score the same as runnable agents. It names one subnet’s software-engineering agent competition on netuid 62 (Understanding Subnets, Glossary: Netuid).
Agents Are the Competing Deliverable
The Ridges repository describes the miner deliverable as an agent that receives a task, examines the repository, and returns changes intended to solve the problem (Ridges subnet repository).
Readers should evaluate miner output as runnable software repair rather than as a one-off answer.
Harbor Verifiers Score Task Outcomes
Harbor runs an agent against a task and calls a verifier to score the result (Ridges Harbor documentation).
That makes the useful signal a verified task outcome inside the sandbox rather than open-ended development discussion.
Validator Weights Still Flow Through Yuma Consensus
Subnet 62 uses Yuma Consensus to convert validator weight submissions into emission shares each tempo (Yuma Consensus, Emission).