# Into: Compute Horde Most subnets buy GPUs to validate their work. Compute Horde flips that around: it turns miners' untrusted GPUs into trusted compute that other subnets can rent. // Trustless GPU power for the whole network --- > New to Bittensor? Start here. Experienced users can skip to the full analysis. ### What is Compute Horde? Compute Horde is Subnet 12 on Bittensor, a decentralized network where independent operators ("miners") supply a service and "validators" score how well they do it. Compute Horde's service is raw GPU computing power. Its pitch, from the project's own repository, is to take GPUs offered by anonymous miners and make them reliable enough that other Bittensor subnets can run their own validation workloads on them. **The simple version:** It's like a decentralized RunPod or AWS for GPUs, except the renters are mostly other Bittensor subnets, and the network polices whether the rented hardware is actually doing the work it claims. **Centralized equivalent:** Cloud GPU providers like RunPod, Lambda Labs, or CoreWeave. The difference is that no single company owns the machines or sets the price. **How it works:** - **Miners** run GPUs and spawn multiple "executors" that each take on compute jobs. Per the repo, this executor model is how the subnet scales past Bittensor's usual per-subnet UID cap, since one miner can run many executors instead of one slot doing one job. - **Validators** send jobs, check that the returned work is authentic, and confirm the job ran on the hardware class the miner advertised (the repo gives the example of making sure an A6000-class task actually ran on an A6000). They also score miners and guard against shortcuts like weight-copying. --- ### Why This Matters - **The problem it solves:** Validating a Bittensor subnet often needs serious GPU power, and today that usually means renting from centralized clouds. Compute Horde's stated mission is to cut the ecosystem's dependence on those centralized services by sourcing that compute from within Bittensor itself. - **The opportunity:** If subnets can lean on a shared, trust-checked GPU pool instead of each one wiring up its own cloud account, the cost and friction of running a subnet drops. The repo frames this as helping Bittensor scale toward supporting far more subnets than it does now. - **The Bittensor advantage:** Renting compute from strangers normally means trusting them. Compute Horde's design replaces that trust with verification, including a collateral mechanism where miners can deposit a stake that validators can slash if the miner is dishonest on cross-subnet ("organic") jobs. - **Traction signals:** Development is ongoing. The public GitHub repository was last pushed on May 4, 2026, and carries contributions from 28 people. The project also publishes a Python SDK so subnet owners and validators can submit jobs from their own code, with a documented fallback to RunPod via SkyPilot if the network is briefly unavailable. --- ## Full Analysis **Category:** Inference and Compute | **Centralized Competitor:** RunPod, Lambda Labs, CoreWeave Compute power is the input every other subnet consumes, and most of it is bought from centralized clouds. Compute Horde, built by the backend-developers-ltd organization, is trying to make Bittensor's own miner GPUs into a supply that other subnets can draw on. That is a different bet from the many subnets that produce a model or a dataset: Compute Horde sells the shovels rather than the gold. **Mechanism:** The core challenge the repository describes is trust. A validator on some other subnet wants to run a job, but the miner offering the GPU is anonymous and could lie about the hardware, copy another miner's results, or skip the work. Compute Horde addresses this with a few moving parts, all sourced from its README. First, miners run executors. Each miner can spawn many of them, so the subnet's capacity scales with the number of GPUs available rather than the number of miner slots. The project organizes GPUs into hardware classes; the README lists A6000 as the currently supported class with A100 named as next. Second, validators verify rather than trust. They match jobs to the advertised hardware, score work globally (all validators score all miners' results, not just the ones they paid for), and use mechanisms meant to block weight-copying. Third, for "organic" jobs (real work coming from outside the subnet, such as another subnet's validator), Compute Horde layers on collateral. Miners can deposit a stake through a collateral contract, and validators that adopt the contract can slash that stake if the miner misbehaves. The README presents this as the way to make cross-subnet compute reliable enough to depend on. The scoring side ties usage to rewards. As the repo describes it, validators earn a compute allowance measured in executor-seconds, minted per miner-and-validator pair and scaled by stake, and they spend that allowance by running jobs. Paid runtime is then converted into the points that drive how miners are rewarded. The intent is to reward miners for doing genuine, externally useful work rather than idling. On the network side, the snapshot below tells a quieter story. As of June 9, 2026, Subnet 12's alpha token traded around 0.00581 TAO with roughly 13,960 TAO of depth in its pool, and its emission share sat at 0%. Under Bittensor's current "Taoflow" model (live since November 2025), a subnet's emissions track its net staking flows rather than its token price, and a subnet whose recent flows are net negative receives no emission share until that turns around. That is a market-demand reading, not a statement about the code, which continues to see commits. --- ### Risk Factors - **Emission share and deregistration:** Subnet 12 currently shows a 0% emission share, reflecting recently negative net staking flows under Taoflow. Bittensor automatically deregisters the non-immune subnet with the lowest moving-average price, and SN12 is long past its 4-month immunity window (it registered in January 2024). Sustained zero emissions and a low relative price are what put any subnet at deregistration risk. - **Demand depends on other subnets:** Compute Horde's value rests on other subnets actually routing their validation jobs to it. That is a harder adoption path than serving end users directly, and it is largely outside the team's control. - **Concentration:** On-chain stake in the subnet's alpha token appears concentrated, so a few large positions could move the pool. Thin pool depth means swaps can carry meaningful slippage. - **Verification is the whole game:** The entire model rests on validators reliably catching dishonest or mismatched hardware. Any gap in that verification, or in the collateral and slashing flow, weakens the trust guarantee the subnet sells. --- Into the next one.