Skip to main content

Bitcast (Subnet 93)

Bitcast (Subnet 93) — 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).

Bitcast — an AI/Other | Infra project on the Bittensor network (Subnet 93).

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 incentivizes content creators to fulfill “briefs” and distributes rewards based on engagement metrics.
  • Who it’s for: content creators (miners), validators, brands/brief requesters.
  • Why onchain/token: the Bittensor onchain layer is used for reward distribution and accounting of contributions; the subnet’s “alpha token” is used as the unit of reward.

How it works (very briefly)

  1. The brand publishes a brief: sets the requirements for the content.
  2. Miners create and publish content: for example, a YouTube video for the brief.
  3. Validators verify metrics: obtain analytics, check that the conditions are met and assign weights.
  4. Where the blockchain is: rewards and accounting of contributions go through the Bittensor subnet mechanics.
  5. Token role: the “Bitcast alpha token” is used as the unit of reward for subnet participants.

Quick links: AI thesis fit

Project passport

Field Value
Project name Bitcast (Subnet 93)
Also known as (aliases) Bitcast ALPHA, Subnet 93
Logo (logo) ../assets/457_bitcast_logo.ico
Token symbol (ticker) —
Category AI/Other | 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 to participants are paid out in the “Bitcast alpha token” at the subnet level.
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI-verified content performance scoring
Use‑case (use_case) creator briefs + on-chain rewards
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 1 / onchain_score 2 / token_score 1 / evidence_score 1
Last verified 2026-02-11

General project overview

Bitcast is described as a Bittensor subnet (Subnet 93) for the “creator economy”: brands formulate briefs, content creators release videos to the requirements, and validators confirm engagement metrics (via YouTube analytics) and distribute rewards. Tier‑1 sources also claim that the validation/verification of content and metrics relies on automated checks (described in the whitepaper as “validated by AI”, without model details).

Features/modules

  • Briefs: a public list of active tasks/campaigns.
  • Miners/creators: create content and claim rewards.
  • Validators: obtain analytics and assign weights/rewards.

Typical scenarios

  • Scenario 1: a brand publishes a brief → receives content that meets the requirements.
  • Scenario 2: a creator publishes a video for the brief → receives a reward upon passing verification.
  • Scenario 3: a validator verifies engagement metrics → participates in the distribution of incentives.

Getting started (wallet/network)

  • What you need: an environment for running a miner/validator; access to the briefs and the project documentation.
  • Network/chain: Bittensor (Subnet 93).
  • Fees: participation costs depend on the network/infrastructure; details — in Tier‑1 sources.

Architecture/tech (non‑AI)

  • Components: the subnet miner/validator, the briefs server, integrations for verifying YouTube analytics.
  • Participant roles: brands, creators/miners, validators.
  • Where logic runs: metric checks — offchain (via API/analytics), accounting of incentives — the Bittensor onchain layer.
  • Dependencies: external analytics (YouTube Analytics) and the subnet infrastructure.

Token/economics (expanded, no forecasts)

  • Token utility: rewarding creators and validators for their contribution to the subnet.
  • Protocol necessity drivers: an incentive structure is needed to distribute rewards based on measurable metrics.
  • Issuance/burn: — (not established per Tier‑1).
  • Security/incentive mechanisms: Tier‑1 sources describe verification via analytics and anti‑exploit restrictions.
  • 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 community 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 engagement metrics; Tier‑1 sources describe restrictions/lookback and anti‑exploit measures.

Project status and timeline

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

Ecosystem/integrations

  • Integrations: YouTube Analytics (for verifying metrics) and the briefs server (see links_*).
  • Partners: — (not established per Tier‑1).
  • Where it’s actually used: active briefs are available on the dashboard (see links_*).

AI component of the project

  • What is real AI here? the Tier‑1 whitepaper claims “AI‑verified” checks/validation of content/metrics, but no Tier‑1 tech description of the model/quality metrics for this part is identified.
  • What is truly onchain? accounting and incentivization of participants within Bittensor Subnet 93.
  • Why is a token needed? the subnet’s “alpha token” is used for rewards to creators and validators.
  • Red flags (based on the information found): “AI validation” without a tech description/metrics; dependence on external data (analytics) and possible manipulation of metrics.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 1
  • Claim (one line): The Tier‑1 whitepaper claims that content validation/verification is “validated by AI”.
  • Evidence: Tier‑1 — https://bitcast.network/whitepaper
  • Why sufficient / why not (one line): This is a Tier‑1 intent/claim about the AI part, but without technical details of the model/metrics (AI_1..AI_4 remain 0).
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): No Tier‑1 tech description of what exactly the AI component does and how its quality is measured was found.
  • Evidence: Tier‑1 — https://bitcast.network/whitepaper
  • Why sufficient / why not (one line): There is a declaration of “AI‑verified”, but without a description of the mechanics/metrics — we set 0.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): There is a briefs dashboard, but it is not a demonstration of the AI component as “AI reality”.
  • Evidence: Tier‑1 — https://www.dashboard.bitcast.network/briefs
  • Why sufficient / why not (one line): AI_2=1 requires a demo showing the AI part at work; not identified per Tier‑1.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://bitcast.network/whitepaper
  • Why sufficient / why not (one line): No set of quality metrics for the AI validation (as opposed to engagement metrics as such) was found per Tier‑1.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): A tech description of the AI part (model architecture/versions) is not identified per Tier‑1.
  • Evidence: Tier‑1 — https://bitcast.network/whitepaper
  • Why sufficient / why not (one line): AI_4 requires an explicit technical artifact; not found.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Bittensor (Subnet 93)
  • Addresses/identifiers: Subnet 93 (SN93)
  • Evidence: Tier‑1 — https://github.com/bitcast-network/bitcast
  • Why sufficient / why not (one line): The Tier‑1 README identifies the subnet and points to on-chain compensation.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: distribution of rewards and accounting of the weight of contributions in the subnet.
  • Evidence: Tier‑1 — https://github.com/bitcast-network/bitcast
  • Why sufficient / why not (one line): The Tier‑1 README states that Bittensor manages the on-chain compensation.
  • 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 turning into a centralized rewards program).
  • Evidence: Tier‑1 — https://github.com/bitcast-network/bitcast
  • Why sufficient / why not (one line): OC_3 requires an explicit argument; not identified per Tier‑1.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The Tier‑1 README describes the “Bitcast alpha token” as the subnet’s reward token.
  • Evidence: Tier‑1 — https://github.com/bitcast-network/bitcast
  • Why sufficient / why not (one line): The Tier‑1 source directly mentions the existence of the alpha token.
  • 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 as a mandatory mechanism for users was found.
  • Evidence: Tier‑1 — https://bitcast.network/whitepaper
  • Why sufficient / why not (one line): In Tier‑1 sources, the token is described as a reward mechanism, not as pay‑per‑use.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): The alpha token is used for incentives: rewards to miners/validators for contribution and engagement metrics.
  • Evidence: Tier‑1 — https://github.com/bitcast-network/bitcast ; https://bitcast.network/whitepaper
  • Why sufficient / why not (one line): Tier‑1 sources describe the subnet’s reward mechanism and its link to metrics.
  • 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/bitcast-network/bitcast
  • Why sufficient / why not (one line): There is no explicit description of voting/governance via the token.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The replaceability of the alpha token with another mechanism is not established per Tier‑1.
  • Evidence: Tier‑1 — https://bitcast.network/whitepaper
  • Why sufficient / why not (one line): TK_4 requires an explicit argument; not identified per Tier‑1.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://github.com/bitcast-network/bitcast Subnet 93, the roles of miners/validators/briefs and the fact of on-chain compensation; a mention of the “Bitcast alpha token”.
Tier‑1 https://bitcast.network/whitepaper Description of the briefs/metric verification model and the “validated by AI” claims.
Tier‑1 https://www.dashboard.bitcast.network/briefs Active briefs as the “surface” of the product.
Tier‑2 https://taostats.io/subnets/93/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