Skip to main content

Chutes

Chutes — 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).

Chutes — an AI/Inference | Infra 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 platform/subnet for running serverless inference (and other AI code) on distributed GPU resources; the docs state that it is Bittensor Subnet 64.
  • Who it’s for: developers/teams who want to deploy models/“chutes” (applications), and operators of Bittensor miners/validators.
  • Why onchain/token: the onchain part is the subnet mechanics (incentives/weights/participation) via the Bittensor network; in the Dynamic TAO model the subnet has a subnet‑specific “alpha” token and TAO reserves (see Evidence).

How it works (very briefly)

  1. The user does: registers (via a Bittensor hotkey), creates an API key and deploys a “chute” (application).
  2. The system does: routes execution to miners with suitable GPUs; the SDK/CLI describes the process of building images and deploying.
  3. The user gets: an endpoint/API for inference/running AI code and scaling with load (within the platform).
  4. Where the blockchain is: Subnet 64 on Bittensor records network parameters/participants and the incentive economy.
  5. Token role (if any): an external project token (ERC‑20 etc.) is not recorded per Tier‑1; at the same time, the subnet on Bittensor has a subnet‑specific “alpha” token (Dynamic TAO) and an onchain incentive economy.

Quick links: AI thesis fit

Project passport

Field Value
Project name Chutes
Also known as (aliases) chutes.ai, Subnet 64
Logo (logo) ../assets/436_chutes_logo.svg
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) native
Token contract Subnet netuid 64 (Bittensor)
Token model (token_type) —
Max supply —
Issuance —
Tokenomics (tokenomics, brief) subnet “alpha” token + TAO reserves/emissions (Dynamic TAO)
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) serverless inference engine
Use‑case (use_case) GPU inference for AI apps
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 3 / 1 / 3
Last verified 2026-02-11

General project overview

Chutes is positioned as a platform for deploying and running AI inference and other serverless AI code on distributed GPU resources. The docs explicitly state that the project is “powered by Bittensor” and operates as Subnet 64, and the public repository describes the terms (chute/cord/image), the registration process and working via the CLI/SDK.

Features/modules

  • A CLI/SDK for building and deploying “chutes” (applications).
  • The “image → chute → cord” model (docker images, applications and functions/endpoints).
  • Registration via Bittensor hotkey signatures and API key management.

Typical scenarios

  • Scenario 1: a developer creates a chute (a FastAPI application) → deploys it to the platform → gets an endpoint for requests.
  • Scenario 2: an operator launches a subnet miner/validator → participates in the network and receives incentives per the Bittensor rules.

Getting started (wallet/network)

  • What you need: a Bittensor wallet/hotkey (for registration) + following “Get Started” in the official docs/README.
  • Network/chain: Bittensor Subnet 64.
  • Fees: depend on the platform model and the Bittensor network; not recorded within this card.

Architecture/tech (non‑AI)

  • Components: a client SDK/CLI + the platform (API) + the network of miners/validators (Bittensor subnet).
  • Where logic runs: computation/inference runs offchain on GPUs; onchain provides identity/participation and the subnet incentive economy.

Token/economics (expanded, no forecasts)

  • Subnet economics: within Bittensor, incentives depend on quality/validation and network parameters.
  • Subnet token (Dynamic TAO): the subnet has a subnet‑specific “alpha” token and TAO reserves (see Evidence); an external project token (ERC‑20 etc.) is not recorded per Tier‑1.

Governance

  • Not established per Tier‑1 as of the verification date.

Security and incidents

  • Audits / bug bounty / incidents: not established per Tier‑1.
  • Threat model: typical risks of distributed offchain infrastructure (dependence on the validator/routing, abuse by GPU providers, API key security) and risks of the Bittensor subnet economics (attacks on scoring/incentives).

Project status and timeline

  • Current status: active; subnet on Bittensor mainnet.
  • Roadmap: published (the link is in links_*).

Ecosystem/integrations

  • Ecosystem: participation is observable via the subnet’s onchain metrics (taostats); other integrations/partners are not recorded per Tier‑1.

AI component of the project

  • What is real AI here? Tier‑1 sources describe a platform for inference/running AI code (including deployment templates for models) and an infrastructure SDK.
  • What is truly onchain? the subnet exists as Bittensor Subnet 64 (netuid 64), where onchain participates in the incentive/weight mechanics.
  • Why is a token needed? on Bittensor, subnet economics use TAO and the subnet‑specific “alpha” token (Dynamic TAO) for incentives/emission distribution.
  • Red flags (based on the information found): without a Tier‑1 record of a “project token”, do not use Tier‑2 aggregators as evidence; for security, real security pages/audits matter (if they appear).

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): AI is described as a working use‑case of the platform (inference engine), not only an intent.
  • Evidence: Tier‑1 — https://docs.chutes.ai/
  • Why sufficient / why not (one line): intent adds no signal when a Tier‑1 description of the product is available.

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): running AI inference/AI code as a service (serverless inference) via the platform.
  • Evidence: Tier‑1 — https://docs.chutes.ai/
  • Why sufficient / why not (one line): the docs explicitly describe the product as an inference engine.

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): a public app/demo “what you can touch” is not recorded per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): without an explicit link to an app/demo in Tier‑1 — we set 0.

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): reproducible quality/performance metrics of the platform are not recorded in Tier‑1.

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

  • AI_4 (decision): 1
  • Claim (one line): the docs/README describe the key entities (image/chute/cord), registration, API keys and the deployment process.
  • Evidence: Tier‑1 — https://github.com/rayonlabs/chutes ; https://docs.chutes.ai/
  • Why sufficient / why not (one line): there is a tech description of the interaction and of the developer tools.

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Bittensor
  • Addresses/identifiers: subnet netuid 64
  • Evidence: Tier‑1 — https://taostats.io/subnets/64/chart
  • Why sufficient / why not (one line): taostats records the existence of the subnet on the Bittensor network.

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

  • OC_2 (decision): 1
  • What useful logic is onchain: the onchain layer participates in subnet accounting and the incentive economy (via the Bittensor network).
  • Evidence: Tier‑1 — https://taostats.io/subnets/64/chart
  • Why sufficient / why not (one line): a subnet as part of the onchain network is not reducible to a “project token”.

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain the trustless mechanics of distributing incentives/weights among subnet participants break down.
  • Evidence: Tier‑1 — https://docs.learnbittensor.org/subnets/understanding-subnets ; https://taostats.io/subnets/64/chart
  • Why sufficient / why not (one line): the subnet’s incentive network relies on onchain state/incentives.

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): on Bittensor the subnet has a subnet‑specific “alpha” token (Dynamic TAO); an external project token (ERC‑20 etc.) is not recorded per Tier‑1.
  • Evidence: Tier‑1 — https://docs.learnbittensor.org/subnets/understanding-subnets
  • Why sufficient / why not (one line): “no token” is incorrect for a subnet; at the same time, a separate external project token is not established.

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 the project token is not established per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): there are no Tier‑1 artifacts of pay‑per‑call on the project token.

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

  • TK_2 (decision): 1
  • Claim (one line): subnet economics distribute emissions/incentives among miners/validators and rely on the onchain mechanics of Bittensor (Dynamic TAO).
  • Evidence: Tier‑1 — https://docs.learnbittensor.org/subnets/understanding-subnets ; https://taostats.io/subnets/64/chart
  • Why sufficient / why not (one line): Tier‑1 docs describe incentives/emissions in subnets; taostats confirms the specific netuid.

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): the governance role of the project token is not established per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): there is no Tier‑1 description of governance via the project token.

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the replaceability of the token/subnet economics with an alternative model is not established per Tier‑1.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): for subnets, the role of the token/TAO is built into the Bittensor economy; a conclusion about replaceability requires separate analysis.

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.chutes.ai/ Tier‑1 description of the product as an inference engine and the statement “Powered by Bittensor (Subnet 64)”.
Tier‑1 https://github.com/rayonlabs/chutes Tier‑1 SDK/CLI artifact: registration, API keys, deployment of chutes and a tech description of the entities.
Tier‑1 https://docs.learnbittensor.org/subnets/understanding-subnets Tier‑1 description of Bittensor subnets: onchain consensus/emissions/incentives; subnet‑specific “alpha” tokens (Dynamic TAO).
Tier‑1 https://taostats.io/subnets/64/chart Onchain fact of the existence of Bittensor subnet netuid 64.
Tier‑2 https://www.coingecko.com/en/coins/chutes Reference profile and link navigation.
Tier‑2 https://coinmarketcap.com/currencies/chutes/ Reference profile and link navigation.

No comments to display

Back to top