Skip to main content

Gradients (G.O.D Subnet 56)

Gradients (G.O.D Subnet 56) — 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).

Gradients (G.O.D) — an AI/Compute / AI/Other project on Bittensor (subnet), token (symbol: —).

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 runs “tournaments” for training LLM/diffusion models: the validator runs miners’ open‑source training repositories on standard infrastructure.
  • Who it’s for: for AI engineers/AutoML miners (tournament participants), subnet validators and Gradients users/clients who value reproducibility/transparency of training.
  • Why onchain/token: the Bittensor onchain layer is used for registration, weights/emissions and subnet incentives; a separate project token utility is not confirmed per Tier‑1.
  • What you can actually touch (Tier‑1): the tournament miner guide + the tournament results page gradients.io/app/research/tournament/{TOURNAMENT_ID}.

How it works (very briefly)

  1. The miner does: publishes a training repo (GitHub URL + commit) and brings up the endpoint /training_repo/{task_type}.
  2. The validator does: runs the miners’ code in Docker on standardized infrastructure according to the tournament schedule, evaluates quality and assigns weights.
  3. The user gets: rankings/results, as well as open “winning methodologies” after tournaments are completed (as claimed in the README).
  4. Where the blockchain is: participation/rewards and subnet mechanics — on Bittensor; execution of training/evaluation — offchain.
  5. Token role (if any): a separate project token and its role are not confirmed by Tier‑1.

Quick links: AI thesis fit

Project passport

Field Value
Project name Gradients (G.O.D Subnet 56)
Also known as (aliases) Gradients on Demand; G.O.D
Logo (logo) ../assets/450_gradients_logo.webp
Token symbol (ticker) —
Category AI/Compute | AI/Other
Primary chain (chain) Bittensor
Type Appchain
Network status mainnet
Consensus (consensus) PoS
Launch date (launch_date) —
Project status (status) active
Token (standard) —
Token contract —
Token model (token_type) —
Max supply —
Issuance —
Tokenomics (tokenomics, brief) Participation/rewards — within the Bittensor subnet; a separate project token is not confirmed per Tier‑1
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) distributed model training
Use‑case (use_case) AutoML training tournaments
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 3 / 2 / 0 / 0
Last verified 2026-02-11

General project overview

Gradients (G.O.D Subnet) describes “tournaments” as a competitive format of model training, where the validator executes miners’ open training repositories on standardized infrastructure. Unlike real‑time serving, tournaments focus on the quality of training methodologies and reproducibility.

The key product/artifact is the tournament results and the open “winning methodologies” (as claimed in the README), which is meant to increase transparency for users/clients and accelerate the adoption of new techniques.

Features/modules

  • Tournament orchestration: processes for scheduling tournaments and rounds, assigning tasks and nodes.
  • Docker execution: training runs in containers with resource limits and network isolation (per the docs).
  • Several tournament types: text/image/environment with different rules and GPU requirements (per the docs).
  • Evaluation and ranking: computing results and rendering tournament pages.

Typical scenarios

  • Scenario 1 (miner): implements a training repo → participates in a tournament → receives results/weights in the subnet.
  • Scenario 2 (validator): runs training/evaluation of the repositories → publishes rankings and submits weights.
  • Scenario 3 (observer): views tournament results on the gradients.io page and studies the winning methodologies (as claimed in the README).

Getting started (wallet/network)

  • What you need: a Bittensor wallet/hotkey registered in subnet 56; a running miner that serves the training repo endpoint.
  • Network/chain: Bittensor mainnet.
  • Fees: participation in tournaments involves a fee in TAO (the amount depends on the tournament type — per the docs); also standard Bittensor operations.

Architecture/tech (non‑AI)

  • Components: the Bittensor subnet (miners/validators), the tournament orchestrator, training runners, task evaluation, results pages.
  • Participant roles: miners (training repos), validators (execution/evaluation/weights), users/clients (viewing results/using methodologies).
  • Where logic runs: execution of training and evaluations — offchain; accounting of participants/weights/rewards — onchain on Bittensor.
  • Dependencies: Docker infrastructure, GPU pools (A100/H100, etc. per the docs), storage of datasets/artifacts.

Token/economics (expanded, no forecasts)

  • Token utility: a separate project token utility is not described by Tier‑1; the economy is built around the incentives of the Bittensor subnet.
  • Protocol necessity drivers: competition for weights/rewards; tournament fees (in TAO) are used as a filter/anti‑spam and are burned (per the docs).
  • Who pays fees: tournament participants pay a fee in TAO; also standard Bittensor network operations.
  • Where fees go: fees are collected and burned (per the docs); additional flows are not established per Tier‑1.
  • Issuance/burn of a separate project token: not established per Tier‑1.
  • Incentive mechanisms: subnet rewards + penalties/quality checks via executable training and evaluation.
  • Treasury: not established per Tier‑1.

Governance

  • Who makes decisions: not established per Tier‑1 (apart from the standard role of subnet validators).
  • How protocol parameters change: via updates to the code and the tournament constants/settings in the repository.

Security and incidents

  • Audits: not established per Tier‑1.
  • Bug bounty: not established per Tier‑1.
  • Incidents: not established per Tier‑1.
  • Threat model: malicious code in training repos → mitigations: a ban on obfuscation and network isolation of containers (per the docs), verbatim verification of LICENSE/NOTICE.

Project status and timeline

  • Current status: active Bittensor subnet (mainnet).
  • Key milestones: tournaments on a schedule (weekly/type‑specific) and the lifecycle are described in the docs.
  • Roadmap: published on the website (see links_*).

Ecosystem/integrations

  • Integrations: Bittensor; Docker/training frameworks and model/dataset hubs inside the training repositories.
  • Partners: not established per Tier‑1.
  • Where it’s actually used: competitions of training methodologies and publication of results/scripts.

AI component of the project

  • What is real AI here? The subnet organizes the training and evaluation of AI models (LLM/diffusion) via executable training repositories, tournaments and comparative scoring.
  • What is truly onchain? Participation/weights/rewards are implemented via the Bittensor subnet mechanics; execution of training/evaluation takes place offchain.
  • Why is a token needed? The utility of a separate project token is not established per Tier‑1; the documentation features fees/balances in TAO for participation.
  • Red flags (based on the information found): the risk of centralization/trust in the executor’s infrastructure (validators run the training); the security of executing miners’ code is a key risk area (mitigated by policies/container isolation).

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): A separate roadmap specifically about AI as a future feature is not recorded; there is a general project roadmap on the website.
  • Evidence: Tier‑1 — https://gradients.io/roadmap
  • Why sufficient / why not (one line): This is a product/subnet roadmap, not a separate “AI intent” in the sense of plans for an AI component.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): The system trains and evaluates models (LLM/diffusion) by running miners’ training scripts and tournament scoring.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/docs/tournament_overview.md; Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/README.md
  • Why sufficient / why not (one line): Tier‑1 directly describes model training and the competition of methodologies.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): There is a step‑by‑step miner guide and public tournament results pages on gradients.io.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/docs/tourn_miner.md; Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/docs/tournament_overview.md
  • Why sufficient / why not (one line): Tier‑1 contains a “Getting Started” and links to view tournament results.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 1
  • Metrics: tournament “quality scores”/scoring by task and round; boss‑round win rules by majority rule.
  • Context (version/date/how measured): evaluation is performed by the validator on standardized infrastructure and task sets (per the docs).
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/docs/tournament_overview.md
  • Why sufficient / why not (one line): There is a Tier‑1 description of the competition structure and the principles of comparing results.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): The tournament lifecycle, miner repository requirements, Dockerfile paths, CLI arguments and environment constraints are described.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/docs/tourn_miner.md; Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/docs/tournament_overview.md
  • Why sufficient / why not (one line): The documentation contains sufficiently detailed technical requirements and the process.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Bittensor
  • Addresses/identifiers: subnet netuid 56 (G.O.D)
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/docs/tourn_miner.md; Tier‑2 — https://taostats.io/subnets/56/chart
  • Why sufficient / why not (one line): Tier‑1 records netuid 56 (mainnet) and the participation rules.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: onchain accounting of subnet participants/weights/rewards (Bittensor), not only a “token”.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/docs/tourn_miner.md
  • Why sufficient / why not (one line): Participation and the assignment of weights are tied to the Bittensor subnet mechanics.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: without onchain, the mechanism of decentralized incentives/accounting is lost; but Tier‑1 does not prove that tournaments cannot be implemented offchain.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/README.md
  • Why sufficient / why not (one line): A replaceability test has not been performed in Tier‑1.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The existence/absence of a separate project token is not confirmed by Tier‑1.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/README.md
  • Why sufficient / why not (one line): Tier‑1 does not describe a separate token/utility; CoinGecko — a reference Tier‑2.
  • 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): Payment for the service with a project token is not confirmed by Tier‑1.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/README.md
  • Why sufficient / why not (one line): Tier‑1 describes fees in TAO and the participation mechanics, without a project token model.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): Incentives are described via subnet weights/rewards and tournaments, not via a separate project token.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/docs/tournament_overview.md
  • Why sufficient / why not (one line): Tier‑1 describes incentives/weights without a separate token.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): Governance via a project token is not described (Tier‑1).
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/README.md
  • Why sufficient / why not (one line): There are no Tier‑1 statements about a governance token.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): Without Tier‑1 utility of a project token, the replaceability assessment is invalid.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/gradients-ai/G.O.D/main/README.md
  • Why sufficient / why not (one line): It is not established what exactly is to be “replaced”.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://raw.githubusercontent.com/gradients-ai/G.O.D/main/README.md Overview of the subnet and tournaments (model training, open‑source training repos), links to the documents
Tier‑1 https://raw.githubusercontent.com/gradients-ai/G.O.D/main/docs/tournament_overview.md Definition of tournaments, lifecycle, tournament types, round structure and scoring/weights
Tier‑1 https://raw.githubusercontent.com/gradients-ai/G.O.D/main/docs/tourn_miner.md Miner/repository requirements, participation steps, fee/balance, transparency measures (license/notice, anti‑obfuscation, network sandbox)
Tier‑1 — No Tier‑1 source for claim “there is a separate project token and a clear utility/tokenomics” was found / not confirmed by Tier‑1.
Tier‑2 https://taostats.io/subnets/56/chart Context: metrics of subnet netuid 56
Tier‑2 https://www.coingecko.com/en/coins/gradients Context: reference listing
Tier‑2 https://coinmarketcap.com/currencies/gradients/ Context: reference listing

No comments to display

Back to top