Skip to main content

ComputeHorde

ComputeHorde (Bittensor Subnet 12) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

ComputeHorde — an AI/Compute | Infra project: a specialized Bittensor subnet (subnet 12) that provides “trusted GPU compute” for validation tasks of other subnets.

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a Bittensor subnet that turns miners’ GPUs into a more “verifiable” compute resource for validators.
  • Who it’s for: owners/validators of other Bittensor subnets who need scalable GPU compute for validation.
  • Why onchain/token: Bittensor onchain is used for accounting/weights/incentives; no separate ComputeHorde token is described (the ecosystem uses $TAO of the Bittensor network).

How it works (very briefly)

  1. The subnet validator does: sends tasks to ComputeHorde via the SDK/integration.
  2. ComputeHorde does: distributes tasks across miners/executors and collects the results.
  3. Verification does: the validator uses a “trusted miner” and additional mechanics (commit‑reveal, dancing) to reduce fraud.
  4. Where the blockchain is: onchain accounting/allowances/scoring and subnet incentives within Bittensor.
  5. Token role: no separate subnet token is described; incentives in the Bittensor ecosystem are tied to $TAO.

Quick links: AI thesis fit

Project passport

Field Value
Project name ComputeHorde
Also known as (aliases) Subnet 12 (Bittensor)
Logo (logo) ../assets/505_compute-horde_logo.png
Token symbol (ticker) —
Category AI/Compute | Infra
Primary chain (chain) Bittensor
Type Appchain
Network status mainnet
Consensus (consensus) —
Launch date (launch_date) —
Project status (status) active
Token (standard) none
Token contract —
Token model (token_type) —
Max supply —
Issuance —
Tokenomics (tokenomics, brief) Subnet economics are described via Bittensor incentives ($TAO); ComputeHorde provides a compute service within this model.
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) GPU compute for Bittensor subnet validation
Use‑case (use_case) scalable validation/compute for validators
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 2 / onchain_score 3 / token_score 2 / evidence_score 1
Last verified 2026-02-11

General project overview

ComputeHorde is described as a specialized Bittensor subnet whose goal is to give validators of other subnets access to scalable GPU compute for validation, reducing the ecosystem’s dependence on centralized clouds. The project describes mechanics for verifying miners’ work and distributing tasks via executors and the SDK.

Features/modules

  • ComputeHorde SDK: a Python SDK for sending jobs to the subnet.
  • Executors: a miner can run many executors (scaling without the UID limit).
  • Fair & verified work: measures against “weight copying” and hardware requirements (hardware classes) are described.
  • Collateral‑based trust (optional): a collateral mechanism for organic jobs (in the repository documentation).

Typical scenarios

  • Scenario 1: a subnet validator integrates the SDK → sends tasks to compute → receives results for validation.
  • Scenario 2: a miner runs executors → performs tasks on GPUs → receives incentives within the Bittensor subnet model.

Getting started (wallet/network)

  • What you need: access to Bittensor and installation of the validator/miner components (see the repository).
  • Network/chain: Bittensor (ComputeHorde subnet 12).
  • Fees: network/operational costs depend on the roles and infrastructure.

Architecture/tech (non‑AI)

  • Components: validator, miner, executor, facilitator (described in the README).
  • Participant roles: validators (order/evaluate tasks), miners/executors (perform them), trusted miner (for cross‑validation).
  • Where logic runs: job execution — offchain in the dockerized environment of executors; accounting/scoring/incentives — within the onchain model of the Bittensor subnet.
  • Dependencies: docker, GPU infrastructure and the Bittensor stack.

Token/economics (expanded, no forecasts)

  • Subnet token: no separate subnet token is described.
  • Incentives: the project describes the Bittensor context, where incentives are distributed in $TAO among subnet owners / miners / validators.
  • Collateral: validators can require collateral for organic jobs (described in the repository README).

Governance

  • Who makes decisions: subnet parameters/development are governed within Bittensor processes + via changes in the repository (details are not established per Tier‑1).

Security and incidents

  • Audits: —.
  • Bug bounty: —.
  • Incidents: —.
  • Threat model: fraud in compute (substitution of hardware/results), “weight copying”, DoS; the project describes a set of measures (commit‑reveal, dancing, collateral, shield).

Project status and timeline

  • Current status: mainnet (subnet 12) and testnet (netuid 174) are listed on the project website.
  • Roadmap: development goals are listed in the repository README.

Ecosystem/integrations

  • Integrations: an SDK for integrating validators of other subnets.
  • Partners: —.

AI component of the project

  • What is real AI here? the project is AI/Compute infrastructure: GPU compute for Bittensor tasks/subnets; not a “model” but a compute service.
  • What is truly onchain? the subnet operates within the Bittensor onchain model (accounting/scoring/incentives), while jobs are executed offchain.
  • Why is a token needed? a separate subnet token is not described; incentives and subnet economics are described via $TAO of the Bittensor network.
  • Red flags (based on the information found): dependence on the correctness of validation and the “trusted miner”; it is important to check that the protection mechanics are actually enabled for specific participants.

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 2
Onchain necessity high 3
Token necessity no token 2
Evidence Tier‑1 present 1
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): We do not separate the AI intent: the project is directly described as a compute subnet for Bittensor.
  • Evidence: Tier‑1 — https://github.com/backend-developers-ltd/ComputeHorde/
  • Why sufficient / why not (one line): Tier‑1 describes the operating function of the subnet, not just plans.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): The subnet provides GPU compute for validation tasks and job execution (including those related to Bittensor AI subnets).
  • Evidence: Tier‑1 — https://github.com/backend-developers-ltd/ComputeHorde/ ; https://computehorde.io/
  • Why sufficient / why not (one line): The README and the website describe the compute purpose of the subnet and the role of GPUs.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): No Tier‑1 demo surface (app/demo) to “touch” without deployment was found.
  • Evidence: Tier‑1 — https://github.com/backend-developers-ltd/ComputeHorde/
  • Why sufficient / why not (one line): There are instructions/an SDK, but no separate demo entry point.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://github.com/backend-developers-ltd/ComputeHorde/
  • Why sufficient / why not (one line): In Tier‑1 sources, no unified set of performance/quality metrics of the compute service was found.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 1
  • Claim (one line): The README describes the subnet architecture (validator/miner/executor/facilitator), scoring and protection mechanics.
  • Evidence: Tier‑1 — https://github.com/backend-developers-ltd/ComputeHorde/
  • Why sufficient / why not (one line): A technical description and the structure of components are present in the Tier‑1 repository.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Bittensor
  • Addresses/identifiers: Subnet 12 (mainnet netuid: 12; testnet netuid: 174)
  • Evidence: Tier‑1 — https://github.com/backend-developers-ltd/ComputeHorde/
  • Why sufficient / why not (one line): The official repository directly records the subnet/netuid.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: accounting of the “per block” allowance, scoring and distribution of incentives within the subnet.
  • Evidence: Tier‑1 — https://github.com/backend-developers-ltd/ComputeHorde/
  • Why sufficient / why not (one line): The README describes onchain‑related rules for allowance/blocks/scoring.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain accounting of allowance/scoring/incentives, the trustless distribution of the subnet’s tasks and rewards is lost.
  • Evidence: Tier‑1 — https://github.com/backend-developers-ltd/ComputeHorde/
  • Why sufficient / why not (one line): The subnet is defined as part of the Bittensor protocol; the key rules rely on the network’s onchain model.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 1
  • Claim (one line): No separate ComputeHorde token is described; the context of subnet incentives is given via Bittensor’s $TAO.
  • Evidence: Tier‑1 — https://github.com/backend-developers-ltd/ComputeHorde/
  • Why sufficient / why not (one line): The README describes the distribution of incentives via $TAO as the base economy of the ecosystem.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): No separate payment for services with a subnet token is described.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): TK_0=1 (there is no separate subnet token).
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 0
  • Claim (one line): There are no subnet‑specific token incentives (TK_0=1).
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Incentives are described at the Bittensor level ($TAO), not for a separate subnet token.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): There is no governance mechanic via a subnet token (TK_0=1).
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): TK_0=1.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): Not applicable: there is no separate subnet token.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): TK_0=1.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://github.com/backend-developers-ltd/ComputeHorde/ Description of the ComputeHorde subnet (Subnet 12), its architecture and fair/verified compute mechanics.
Tier‑1 https://computehorde.io/ Positioning of the subnet as a “trusted compute subnet” for validators; mainnet/testnet netuid are listed.
Tier‑2 https://taostats.io/subnets/12/chart Dashboard/context on subnet 12 (for reference).
Tier‑2 https://www.coingecko.com/en/coins/compute-horde Profile/metadata (for reference).
Tier‑2 https://coinmarketcap.com/currencies/compute-horde/ Profile/metadata (for reference).