Skip to main content

Dippy

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

Dippy — an AI/Training project on the Bittensor network (subnet 11), subnet token (symbol: DIPPY).

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: Bittensor subnet 11 about evaluation/incentives around roleplay LLMs (models for conversation/companions).
  • Who it’s for: miners (model submissions), validators (evaluation), users/integrators of the results.
  • Why onchain/token: the subnet’s onchain mechanics distribute emissions/weights; the subnet token is used in the demand/access mechanics (see Evidence).
  • What you can actually touch (Tier‑1): the Dippy website/app and the subnet repository (a guide for the miner/validator).

How it works (very briefly)

  1. The user does: interacts with the project’s product/subnet.
  2. The system does: miners submit models, validators evaluate quality and compute weights/rankings.
  3. The user gets: access to the best models/results (at the product/ecosystem level).
  4. Where the blockchain is: Bittensor subnet 11 (emissions/weights/subnet parameters).
  5. Token role (if any): the subnet token is tied to access/demand (for example, gated access to the dataset for miners) and to supply management (see Evidence).

Quick links: AI thesis fit

Project passport

Field Value
Project name Dippy
Also known as (aliases) DIPPY
Logo (logo) ../assets/491_dippy_logo.png
Token symbol (ticker) DIPPY
Category AI/Training
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) —
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) roleplay LLM evaluation + dataset + scoring
Use‑case (use_case) evaluation + incentives for roleplay LLMs in a subnet
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 3 / onchain_score 2 / token_score 1 / evidence_score 3
Last verified 2026-02-11

General project overview

Dippy (subnet 11) is a subnet in the Bittensor ecosystem focused on the development and evaluation of roleplay LLMs (“companion” models) through an incentive economy: miners submit models, validators evaluate quality against the set criteria and compute weights.

Features/modules

  • Model submissions by miners (training/fine‑tuning/merging).
  • Quality evaluation by validators per the protocol and scoring criteria.
  • Documentation on running a miner/validator and on the repository structure.

Typical scenarios

  • Scenario 1: a miner trains/prepares a model → submits it to the subnet → receives rewards when quality is competitive.
  • Scenario 2: a validator evaluates submissions via the scoring mechanism → publishes weights/rankings, affecting emissions.

Getting started (wallet/network)

  • What you need: a wallet/account (if required by the product) and access to the Bittensor ecosystem.
  • Network/chain: Bittensor.
  • Fees: — (depend on operations/infrastructure).

Architecture/tech (non‑AI)

  • Components: the subnet (miners/validators), the repository with the miner.py/validator.py code, the scoring module and documentation.
  • Participant roles: miners, validators, users/integrators of the results.
  • Where logic runs: model evaluation/preparation — offchain at the participants; distribution of weights/rewards — via the Bittensor onchain mechanics.
  • Dependencies: —.

Token/economics (expanded, no forecasts)

  • Token utility: the subnet token is used as an element of incentives/access (for example, gated access to the dataset for miners; buyback from the app’s revenue).
  • Protocol necessity drivers: described in the subnet’s Tier‑1 documentation (see Evidence).
  • Who pays fees: —.
  • Where fees go: —.
  • Issuance/burn: —.
  • Security/incentive mechanisms: —.
  • Distribution and token issuance schedule: —.
  • Treasury: —.

Governance

  • Who makes decisions: —.
  • How protocol parameters change: —.
  • Where decisions are discussed/made: —.
  • Keys/multisig: —.

Security and incidents

  • Audits: —.
  • Bug bounty: —.
  • Incidents: —.
  • Threat model: —.

Project status and timeline

  • Current status: active.
  • Key releases/milestones: —.
  • Roadmap: see links_* (as navigation).

Ecosystem/integrations

  • Integrations: —.
  • Partners: —.
  • Where it’s actually used: subnet statistics/state are available via taostats (see links_* / Evidence).

AI component of the project

  • What is real AI here? Development/evaluation of roleplay LLMs: evaluation criteria, dataset, comparison protocol, model submission processes (see Evidence).
  • What is truly onchain? Bittensor subnet 11: emissions/weights and incentives within the network (see Evidence).
  • Why is a token needed? The token is used in the demand/access mechanics (for example, gated access to the dataset) and in supply management (burn emissions), as well as a buyback mechanism from the app’s revenue (see Evidence).
  • Red flags (based on the information found): if the scoring/dataset/evaluation procedures change without versioning and without public artifacts; reliance on an external “judge” requires transparency of the criteria and protection against manipulation.

DecAI Fit component summary

  • DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality high 3
Onchain necessity medium 2
Token necessity medium 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): Per Tier‑1 sources, AI is described as the operating goal/mechanics of the subnet, not only an “intent”.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/impel-intelligence/dippy-bittensor-subnet/main/README.md
  • Why sufficient / why not (one line): This flag applies when there is only intent without a confirmed AI component; here the AI component is described.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): The subnet incentivizes the development of roleplay LLMs: miners submit models, validators evaluate their quality.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/impel-intelligence/dippy-bittensor-subnet/main/README.md
  • Why sufficient / why not (one line): There is a Tier‑1 description of the subnet’s purpose and of the roles of miners/validators.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): There is a “surface” for verification: the Dippy website/app and instructions for running a miner/validator.
  • Evidence: Tier‑1 — https://www.dippy.ai/ ; https://raw.githubusercontent.com/impel-intelligence/dippy-bittensor-subnet/main/README.md
  • Why sufficient / why not (one line): Tier‑1 sources provide reproducible launch steps and the official product endpoint.
  • Conflict note (if any): —

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): There are scoring criteria, but this card does not record a public “quality benchmark”/metrics with numerical results by model version.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): The repository describes the roles of miners/validators, the scoring mechanism and the system components.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/impel-intelligence/dippy-bittensor-subnet/main/README.md ; https://raw.githubusercontent.com/impel-intelligence/dippy-bittensor-subnet/main/docs/llm_scoring.md
  • Why sufficient / why not (one line): There is a tech description of the evaluation mechanics and the component structure.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Bittensor
  • Addresses/identifiers: subnet id 11
  • Evidence: Tier‑1 — https://learnbittensor.org/subnets/11
  • Why sufficient / why not (one line): The Tier‑1 source records subnet id 11 and the identity of the subnet.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: the weights/emissions mechanism and the subnet’s incentive design (not only “token issuance”).
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/impel-intelligence/dippy-bittensor-subnet/main/README.md
  • Why sufficient / why not (one line): Tier‑1 describes the incentive mechanics and the calculation of weights/rewards.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: not established (no Tier‑1 justification of criticality).
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Without a Tier‑1 argument “why without onchain the rationale breaks down” we set 0.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The subnet has a subnet token (access/demand/burning of emissions are described in Tier‑1).
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/impel-intelligence/dippy-bittensor-subnet/main/docs/subnet_token.md
  • Why sufficient / why not (one line): The Tier‑1 document describes the use of the subnet token and the demand/supply mechanisms.
  • 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 confirmation that the token is used to pay for the service was found.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Without tech docs/terms of use per Tier‑1 we set 0.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): Access to the extended dataset for miners may be gated by a stake in the subnet token; part of the emissions may be burned.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/impel-intelligence/dippy-bittensor-subnet/main/docs/subnet_token.md
  • Why sufficient / why not (one line): Tier‑1 describes stake‑gating and burn emissions as elements of the mechanics.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): No Tier‑1 confirmation of governance via the token was found.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Without a described governance process per Tier‑1 we set 0.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): Tier‑1 does not provide a strict comparison with alternatives (for example, “USDC instead of the subnet token”) for assessing replaceability.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Tier‑1 materials on the utility/mechanics are needed to assess replaceability.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://raw.githubusercontent.com/impel-intelligence/dippy-bittensor-subnet/main/README.md The subnet’s purpose, the roles of miners/validators, incentive mechanics, roadmap, launch artifacts.
Tier‑1 https://raw.githubusercontent.com/impel-intelligence/dippy-bittensor-subnet/main/docs/llm_scoring.md Scoring criteria/evaluation mechanics (judge score, comparison criteria).
Tier‑1 https://raw.githubusercontent.com/impel-intelligence/dippy-bittensor-subnet/main/docs/subnet_token.md Use of the subnet token: demand/access (stake gating), burn emissions, buyback intent.
Tier‑1 https://learnbittensor.org/subnets/11 Identity and parameters of subnet 11 (Dippy Studio) in the Bittensor ecosystem.
Tier‑1 https://www.dippy.ai/ Available product “surface” (website/app).
Tier‑1 — No Tier‑1 source for claim “public quality metrics/benchmarks by model version” was found.
Tier‑2 https://taostats.io/subnets/11/chart Dashboard of the subnet’s state/statistics (context).
Tier‑2 https://www.coingecko.com/en/coins/dippy Token profile (for reference; navigation).

No comments to display

Back to top