Subnet 12: Compute Horde
Compute Horde is Bittensor Subnet 12 (SN12), developed by backend-developers-ltd. The subnet addresses a core infrastructure challenge for the Bittensor network: as the number of subnets grows, validators on those subnets need access to reliable GPU compute. Compute Horde decentralizes that compute layer by coordinating miners who provide GPU hardware with validators who need to run AI workloads, and by verifying the results so that both sides can trust the output.
How the Mechanism Works
The ComputeHorde repository distinguishes between two types of jobs: synthetic and organic. Synthetic jobs are generated by validators specifically to test miners — they are standardized tasks with known outputs, used to measure reliability and correctness. Organic jobs are real workloads submitted by other Bittensor validators who need compute for their own subnets.
When a miner completes an organic job, the validator verifies the result by comparing it against a trusted ground-truth baseline established independently. Miners that complete jobs correctly and reliably earn higher scores; miners that fail or return incorrect results earn less.
Resource allocation across the miner set is governed by a stake-weighted system: validators with larger stakes have access to proportionally more miner compute, and that access is distributed fairly across the active miner set. Scores from both synthetic and organic job completion feed into weight vectors submitted to Yuma Consensus, which converts them into emission shares distributed to subnet participants through Dynamic TAO.
Participating as a Miner
Miners on Compute Horde provide GPU hardware that validators across Bittensor can use to run AI workloads. Their economic role is to maintain reliable, high-performance GPU capacity and complete the jobs assigned to them correctly. Miners who consistently complete both synthetic test jobs and real organic jobs earn emissions proportional to their verified job output.
The ComputeHorde repository describes miners operating multiple GPU instances under their registered identity, with scores reflecting the aggregate performance of those instances. The subnet incentivizes resource diversity: miners that distribute their hardware across multiple registrations earn a score multiplier that rewards decentralization and reduces the risk of concentrated compute failures.
Organic jobs are higher-value work than synthetic tests. Miners who want access to organic jobs must maintain a record of reliable synthetic performance first, establishing the trust needed for validators to route real workloads to them.
Participating as a Validator
Validators on Compute Horde have two responsibilities. First, they continuously send synthetic jobs to the miner set, measuring each miner’s uptime, execution speed, and output correctness. Second, they accept organic job requests from other Bittensor validators and route those jobs to miners, verifying the results before returning them to the requester.
For organic job verification, the ComputeHorde repository describes validators maintaining an independent compute resource that pre-executes the job to establish a correct baseline. Miner output is compared against this baseline rather than taken at face value. This design means that dishonest or underperforming miners cannot game the scoring by guessing outputs. Validators who consistently score miners accurately and submit timely weights receive emissions through Yuma Consensus.
On-Chain Identity
Compute Horde is registered at netuid 12 on Bittensor with 256 neurons, verifiable via
taostats.io/subnets/12. The subnet owner coldkey is
5ELzhHvgUqmnAYs74vFWjMMehXNeHkRtkreAa3g8QQS96PCp. The codebase is maintained at
backend-developers-ltd/ComputeHorde.
Relationship to Yuma Consensus
Subnet 12 uses Yuma Consensus to convert the 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 Compute Horde’s context, validators derive weights from two sources: continuous synthetic job scoring that measures each miner’s reliability and output correctness, and organic job verification where validators run an independent baseline execution before accepting miner results. Validators who submit accurate, timely weight sets earn emissions alongside miners. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
Bittensor’s subnet-development path moves from localnet to testnet and then mainnet (Introduction to Bittensor). For Compute Horde (SN12), that sequence changes how readers should interpret examples of GPU job routing, synthetic tests, organic workloads, and verifier baselines.
In localnet, miners and validators can develop and test Compute Horde-compatible job handling in an isolated environment. Localnet examples can explain synthetic-job scoring and result verification, but they do not represent production GPU capacity or organic workload demand.
On testnet, Compute Horde-compatible implementations can be exercised in a shared, non-production network. Testnet examples can show realistic coordination between job assignment, miner execution, and validator checking, but they remain separate from mainnet compute outcomes.
On mainnet, Compute Horde (SN12) is the production subnet where miners provide GPU resources and validators verify synthetic and organic job results (ComputeHorde repository). That makes the production context important for interpreting whether a job score, reliability result, or organic-workload example reflects the subnet’s active compute market.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A job-routing example, verifier baseline, or miner score from one environment should not be read as representing production subnet performance in another environment.
That distinction matters for Compute Horde because scoring depends on the requested workload, miner hardware, verifier baseline, and timing of the job. A local or test example can explain the scoring model, while a production example depends on the actual GPU resources and verification context that produced it.
Miner and Validator Roles
Subnet 12 operates under the standard Bittensor two-role structure. Miners supply the subnet’s capability and validators evaluate those contributions and set weights. Reward distribution follows Yuma Consensus.
Reader Boundary
Subnet 12 Compute Horde should not be read as generic Bittensor subnet documentation, a guaranteed GPU rental contract, or proof that any validator can access unlimited hardware on demand. It names one subnet’s decentralized GPU compute marketplace on netuid 12 (Understanding Subnets, Glossary: Netuid).
Synthetic Reliability Unlocks Organic Workloads
The ComputeHorde repository describes organic jobs as higher-value work that miners reach only after establishing reliable synthetic performance (ComputeHorde repository).
That gate separates continuous uptime testing from real workloads routed by other validators.
Validators Establish Independent Baselines
For organic jobs, validators pre-execute workloads on separate compute to set a trusted baseline before accepting miner output (ComputeHorde repository).
Miner results are compared to that baseline instead of being credited on self-reported completion alone.
Validator Weights Still Flow Through Yuma Consensus
Subnet 12 uses Yuma Consensus to convert validator weight submissions into emission shares each tempo (Yuma Consensus, Emission).