Skip to main content

404—GEN (Subnet 17)

404—GEN (Subnet 17) — 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).

404—GEN — an AI/Inference | Infra project on the Bittensor network (Subnet 17).

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 for generating 3D assets from text prompts (3D generator).
  • Who it’s for: content creators and subnet participants (miners/validators).
  • Why onchain/token: the Bittensor onchain layer is used for incentives/accounting of contributions and emission distribution.
  • What you can actually touch (Tier‑1): the public subnet code + a user guide and a dashboard.

How it works (very briefly)

  1. The user sets a prompt: describes an object/scene.
  2. The subnet generates a 3D result: miners perform the generation, validators evaluate quality/compliance.
  3. The user gets: a 3D asset/generation result.
  4. Where the blockchain is: incentives and accounting of participants’ contributions go through the Bittensor subnet mechanics.
  5. Token role: incentivizing the work of subnet participants (token parameters/ticker not established per Tier‑1).

Quick links: AI thesis fit

Project passport

Field Value
Project name 404—GEN (Subnet 17)
Also known as (aliases) 404 GEN, SUBNET 17
Logo (logo) ../assets/452_404-gen_logo.jpg
Token symbol (ticker) —
Category AI/Inference | Infra
Primary chain (chain) Bittensor
Type Appchain
Network status mainnet
Consensus (consensus) —
Launch date (launch_date) —
Project status (status) active
Token (standard) —
Token contract —
Token model (token_type) —
Max supply —
Issuance —
Tokenomics (tokenomics, brief) Rewards/emissions are distributed to subnet participants via the Bittensor mechanics.
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) 3D asset generation from text prompts
Use‑case (use_case) generate 3D assets for creators
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 3 / onchain_score 2 / token_score 0 / evidence_score 1
Last verified 2026-02-11

General project overview

404—GEN positions itself as a Bittensor subnet focused on generating 3D content/assets. The Tier‑1 sources (the subnet repository and the user guide) describe a “prompts → generation → evaluation/validation” structure and the operational scenario of running a validator.

Features/modules

  • Subnet (SN17) on Bittensor: an incentive structure for participants.
  • User guide: instructions for using the generator and for the basic concepts.
  • Dashboard: monitoring of subnet activity and metrics.

Typical scenarios

  • Scenario 1: a user sets a text prompt → receives a 3D generation result.
  • Scenario 2: an operator runs a subnet validator → validates the work and participates in the incentive structure.
  • Scenario 3: a developer/participant explores the code → improves the generation/validation pipeline.

Getting started (wallet/network)

  • What you need: an environment for running a validator/miner and access to the user guide/repository.
  • Network/chain: Bittensor (Subnet 17).
  • Fees: participation costs depend on the network/infrastructure; details — in the subnet’s Tier‑1 documentation.

Architecture/tech (non‑AI)

  • Components: the subnet code (miner/validator), generation/validation services, the dashboard.
  • Participant roles: users, miners, validators.
  • Where logic runs: generation/evaluation — offchain; incentives/accounting — the Bittensor onchain layer.
  • Dependencies: the subnet infrastructure and the generation models/pipelines (see the repository).

Token/economics (expanded, no forecasts)

  • Token utility: incentives/rewards for subnet participants.
  • Protocol necessity drivers: the incentive structure is needed for permissionless participation and for distributing compute/validation.
  • Issuance/burn: — (not established per Tier‑1).
  • Security/incentive mechanisms: validation/quality evaluation within the subnet structure.
  • Limitation: the exact ticker/standard/contracts of the subnet token are not established per Tier‑1.

Governance

  • Who makes decisions: — (not established per Tier‑1).
  • How protocol parameters change: —.
  • Where decisions are discussed/made: GitHub (issues/PR) and the official channels (see links_*).
  • Keys/multisig: —.

Security and incidents

  • Audits: — (not established per Tier‑1).
  • Bug bounty: — (not established per Tier‑1).
  • Incidents: — (not established per Tier‑1).
  • Threat model: risks of manipulating the quality of generation/evaluation; they require transparent validation rules.

Project status and timeline

  • Current status: active.
  • Key releases/milestones: — (not established per Tier‑1).
  • Roadmap: —.

Ecosystem/integrations

  • Integrations: —.
  • Partners: — (not established per Tier‑1).
  • Where it’s actually used: the subnet’s user guide and dashboard (see links_*).

AI component of the project

  • What is real AI here? Tier‑1 sources describe the generation of 3D assets and (inside the subnet) prompt generation services/pipeline.
  • What is truly onchain? accounting and incentivization of participants within Bittensor Subnet 17.
  • Why is a token needed? incentives/distribution of rewards to miners and validators.
  • Red flags (based on the information found): the absence of quality metrics/benchmarks as Tier‑1; unclear tokenomics parameters; mixing marketing with verifiable artifacts.

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 1
Details

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): Tier‑1 sources describe a product (3D generation) and artifacts, not just “intentions”.
  • Evidence: Tier‑1 — https://github.com/404-Repo/three-gen-subnet
  • Why sufficient / why not (one line): AI_0 is used when there is only intent; here there is code/a guide/a dashboard.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): The subnet generates 3D assets (3D generator) from a text description.
  • Evidence: Tier‑1 — https://guide.404.xyz/ ; https://404.xyz/
  • Why sufficient / why not (one line): The Tier‑1 user guide and the website describe the purpose and the format of the result.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): There is a subnet dashboard for monitoring activity/metrics.
  • Evidence: Tier‑1 — https://dashboard.404.xyz/d/main/404-gen/
  • Why sufficient / why not (one line): The dashboard is a reproducible “surface” for observing the operation.
  • 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/404-Repo/three-gen-subnet
  • Why sufficient / why not (one line): No Tier‑1 set of generation quality metrics/benchmarks was found.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): The Tier‑1 README describes the prompt generation module and the specific LLM models used for prompt generation (for example, Qwen2.5‑7B‑Instruct‑1M, phi‑4, glm‑4‑9b‑chat‑1m).
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/404-Repo/three-gen-subnet/main/README.md
  • Why sufficient / why not (one line): There are technical details (module + model versions/names) as part of the subnet pipeline.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Bittensor (Subnet 17)
  • Addresses/identifiers: Subnet 17 (SN17)
  • Evidence: Tier‑1 — https://github.com/404-Repo/three-gen-subnet
  • Why sufficient / why not (one line): The Tier‑1 README directly identifies the subnet.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: accounting of contributions and distribution of incentives within the Bittensor subnet.
  • Evidence: Tier‑1 — https://github.com/404-Repo/three-gen-subnet ; https://guide.404.xyz/
  • Why sufficient / why not (one line): Tier‑1 sources describe the operation of the subnet as part of the Bittensor incentive network.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: no Tier‑1 justification was found that without onchain the product “breaks down” (rather than becoming a centralized generation service).
  • Evidence: Tier‑1 — https://guide.404.xyz/
  • Why sufficient / why not (one line): OC_3 requires an explicit argument “which key property is lost”; not found per Tier‑1.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): Token incentives of the subnet are implied by the Bittensor logic, but the exact ticker/standard is not established per Tier‑1.
  • Evidence: Tier‑1 — https://github.com/404-Repo/three-gen-subnet
  • Why sufficient / why not (one line): One cannot assert “no token”; but there is also no exact Tier‑1 ticker/standard.
  • 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 Tier‑1 description of “payment for the service” with the token by users as a mandatory mechanism was found.
  • Evidence: Tier‑1 — https://guide.404.xyz/
  • Why sufficient / why not (one line): A pay‑per‑use model is not recorded per Tier‑1.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): The specific conditions of incentives/collateral/penalties are not established per Tier‑1.
  • Evidence: Tier‑1 — https://github.com/404-Repo/three-gen-subnet
  • Why sufficient / why not (one line): TK_2=1 requires explicit staking/slashing parameters.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): Governance use of the token is not established per Tier‑1.
  • Evidence: Tier‑1 — https://github.com/404-Repo/three-gen-subnet
  • Why sufficient / why not (one line): There is no explicit description of governance mechanics.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The replaceability of the token/incentives with another mechanism is not established per Tier‑1.
  • Evidence: Tier‑1 — https://github.com/404-Repo/three-gen-subnet
  • Why sufficient / why not (one line): TK_4 requires an explicit argument; not found per Tier‑1.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://github.com/404-Repo/three-gen-subnet Subnet 17, the purpose of the subnet and links to the dashboard/docs.
Tier‑1 https://raw.githubusercontent.com/404-Repo/three-gen-subnet/main/README.md The prompt generation module and examples of the LLM models used (technical details of the pipeline).
Tier‑1 https://guide.404.xyz/ The generator’s user guide and the “decentralized AI” context (statement/description).
Tier‑1 https://dashboard.404.xyz/d/main/404-gen/ The subnet dashboard (what can be observed/verified).
Tier‑1 https://404.xyz/ Description of the 3D generator (product positioning).
Tier‑2 https://taostats.io/subnets/17/chart Subnet metrics/visualization (context).
Tier‑1 — No Tier‑1 source for claim “exact ticker/standard of the project token” was found / not confirmed by Tier‑1.

No comments to display

Back to top