Skip to main content

Staking Alpha (Subnet 88)

Staking Alpha (Subnet 88) — 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).

Staking Alpha — an AI/Other / DeFi 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 in which “miners” publish investment strategies/portfolios, while “validators” evaluate them and distribute rewards.
  • Who it’s for: for quants/analysts (strategy miners), subnet validators and users who need “actionable” investment signals/strategies.
  • Why onchain/token: onchain is needed for the standard mechanisms of a Bittensor subnet (registration, weights/emissions and incentives); a separate utility of the project token is not confirmed per Tier‑1.

How it works (very briefly)

  1. The miner publishes: a strategy (an allocation table) and regularly rebalances the portfolio in a simulated environment.
  2. The validator computes: daily returns and scoring (taking into account risk/volatility factors) and sets reward weights.
  3. The system aggregates: the top strategies into an “ensemble/meta‑strategy” by asset class.
  4. Where the blockchain is: in the Bittensor layer (accounting of participants, weights/emissions and distribution of the subnet rewards).
  5. Token role (if any): a separate token/its utility for the product are not confirmed by Tier‑1; the subnet model uses the standard Bittensor rewards.

Quick links: AI thesis fit

Project passport

Field Value
Project name Staking Alpha (Subnet 88)
Also known as (aliases) Investing Subnet 88; Investing88
Logo (logo) ../assets/445_staking_logo.svg
Token symbol (ticker) —
Category AI/Other | DeFi
Primary chain (chain) Bittensor
Type Appchain
Network status mainnet
Consensus (consensus) PoS
Launch date (launch_date) —
Project status (status) active
Token (standard) none
Token contract —
Token model (token_type) —
Max supply —
Issuance —
Tokenomics (tokenomics, brief) Rewards/emissions — within the Bittensor subnet; a separate project token is not confirmed per Tier‑1
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) core contributors (Mobius Fund)
Funding (investors/funding) —
AI component (ai_component) ML/AI strategies + portfolio scoring
Use‑case (use_case) decentralized investment strategies
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 2 / 0 / 1
Last verified 2026-02-11

General project overview

Staking Alpha (Subnet 88) describes itself as a “decentralized hedge fund” in the form of a Bittensor subnet: a network of participants competes with investment strategies, and rewards are distributed by the quality of results.

The role of miners is played by quants/analysts who publish and update strategies (asset allocations) in a simulated trading environment. Validators collect the strategies, compute returns and other factors (risk/volatility), assign scoring and submit weights for the distribution of rewards. Separately, a stage of aggregating the best strategies into an “ensemble/meta‑strategy” is described as the final product (it can be applied to asset management and/or offered to third parties).

Features/modules

  • Strategy competition: miners publish portfolios and rebalance them at an arbitrary frequency.
  • Validator scoring: accounting for daily returns + risk/volatility factors.
  • Support for different asset classes/styles: from classical quant to ML/AI approaches and “human insights” (per the project’s claim).
  • Ensemble approach: combining the best strategies into meta‑strategies by asset class.

Typical scenarios

  • Scenario 1 (miner): publishes an allocation strategy → receives scoring/weights and (with good results) subnet rewards.
  • Scenario 2 (validator): collects strategies, computes metrics, submits weights → ensures a fair distribution of emissions and the quality of signals.
  • Scenario 3 (signal consumer): uses the ensemble/top strategies as an input for portfolio management or as a subscription product (as claimed in the Tier‑1 description).

Getting started (wallet/network)

  • What you need: a Bittensor wallet/hotkey and participation in the subnet as a miner or validator (specific launch commands are not given in the Tier‑1 document).
  • Network/chain: Bittensor mainnet.
  • Fees: standard for Bittensor (registration/transactions) + operating costs for infrastructure; the product’s fee model (AUM/subscriptions) is described only conceptually.

Architecture/tech (non‑AI)

  • Components: the Bittensor subnet, strategy miners, scoring validators, the logic of aggregating the top strategies into an ensemble.
  • Participant roles: miners (strategies/portfolios), validators (scoring/weights), signal consumers (internal asset management / 3rd parties — per the claim).
  • Where logic runs: computation of strategies/scoring — offchain; accounting of participants and distribution of rewards — onchain on Bittensor.
  • Dependencies: market data/backtesting/simulation infrastructure (specific providers are not specified in Tier‑1).

Token/economics (expanded, no forecasts)

  • Token utility: a separate utility of the project token is not described in Tier‑1; the subnet operation uses the standard Bittensor incentives.
  • Protocol necessity drivers: the economic necessity is described as rewarding strategies with higher scoring/results via the subnet mechanism.
  • Who pays fees: network participants pay the standard Bittensor onchain fees; monetization of the “product” is mentioned as an AUM fee and/or subscriptions for third parties (without parameters).
  • Where fees go: Tier‑1 does not record specific onchain fee flows/treasury; it is mentioned that part of the revenue may “return to the subnet” as bonus rewards.
  • Issuance/burn: the issuance/burn parameters of a separate project token are not specified (Tier‑1).
  • Security/incentive mechanisms: incentives via validator scoring and the distribution of rewards; the risk — manipulation in the simulation/data and the robustness of the scoring (details are not disclosed in Tier‑1).
  • Distribution and token issuance schedule: not specified (Tier‑1).
  • Treasury: not specified (Tier‑1).

Governance

  • Who makes decisions: not established per Tier‑1.
  • How protocol parameters change: the roadmap/development phases are described in the repository documents; a formal governance process (DAO/multisig) is not described.

Security and incidents

  • Audits: not established per Tier‑1.
  • Bug bounty: not established per Tier‑1.
  • Incidents: not established per Tier‑1.
  • Threat model: correctness of the simulation/data and robustness of the scoring; operational risks of the miner/validator infrastructure.

Project status and timeline

  • Current status: active Bittensor subnet (mainnet).
  • Key milestones: Tier‑1 describes development in phases (staking → expansion of asset classes, including US stocks and beyond).
  • Roadmap: claimed in the repository (see links_*).

Ecosystem/integrations

  • Integrations: Bittensor infrastructure; external brokers/tools are mentioned as plans (without verifiable Tier‑1 details).
  • Partners: Tier‑1 mentions a partnership link with TrustedStake (as context, without a formal agreement/terms).
  • Where it’s actually used: the use of strategies for asset management and as a product for 3rd parties is claimed; quantitative confirmations/cases are not given in Tier‑1.

AI component of the project

  • What is real AI here? The project allows/expects that part of the miners’ strategies will be built on ML/AI models; “heavy modeling” is also mentioned when building ensemble strategies (without verifiable quality metrics per Tier‑1).
  • What is truly onchain? Registration/accounting of participants, weights and the distribution of the subnet rewards take place in the Bittensor layer; computation of strategies and scoring is performed offchain.
  • Why is a token needed? The utility of a separate project token is not established per Tier‑1; a listing appears in public reference sources (Tier‑2), but this is not considered proof of token utility.
  • Red flags (based on the information found): the risk of inflated claims about an “AI‑edge” without metrics (AI‑washing); an unobvious/undescribed token model (token‑washing); what to double‑check: the existence/role of the token and the actual onchain flows (Tier‑1).

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 2
Onchain necessity medium 2
Token necessity low 0
Evidence Tier‑1 present (AI/OC) 1
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 mandatory component is not recorded.
  • Evidence: Tier‑1 — https://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md
  • Why sufficient / why not (one line): Tier‑1 describes the subnet and allows ML/AI strategies, but does not provide a separate AI roadmap.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): Strategies/portfolios can be built by miners on the basis of ML/AI models and are evaluated by returns/risk.
  • Evidence: Tier‑1 — https://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md
  • Why sufficient / why not (one line): Tier‑1 explicitly mentions “machine learning & AI models” as a supported strategy style.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): No public demo/guide of “what to touch” (Tier‑1) was found.
  • Evidence: Tier‑1 — https://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md
  • Why sufficient / why not (one line): The document describes the mechanics, but does not provide a ready public demo/step‑by‑step scenario.
  • 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/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md
  • Why sufficient / why not (one line): Tier‑1 describes scoring/returns as an idea, but does not publish verifiable quality metrics of the models/strategies.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): The miners/validators roles, strategy scoring and the assembly of ensemble strategies are described.
  • Evidence: Tier‑1 — https://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md
  • Why sufficient / why not (one line): There is a coherent tech description of the subnet mechanics and the evaluation/aggregation process.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Bittensor
  • Addresses/identifiers: subnet netuid 88 (Investing / Staking Alpha)
  • Evidence: Tier‑1 — https://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md; Tier‑2 — https://taostats.io/subnets/88/chart
  • Why sufficient / why not (one line): There is a Tier‑1 description of the subnet + a Tier‑2 metrics page linking it to a specific netuid.
  • 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 participants and distribution of the subnet rewards/weights (the standard logic of Bittensor subnets).
  • Evidence: Tier‑1 — https://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md; Tier‑2 — https://taostats.io/subnets/88/chart
  • Why sufficient / why not (one line): Tier‑1 describes the roles and incentives of the subnet; the onchain component is not reducible to “just a token”.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: without onchain, the verifiable mechanism of registration/weights/emissions is lost; but a formal replace‑the‑blockchain test was not performed in Tier‑1.
  • Evidence: Tier‑1 — https://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md
  • Why sufficient / why not (one line): The importance of onchain logically follows from the subnet model, but is not proven by a separate Tier‑1 “replaceability test”.
  • 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://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md
  • Why sufficient / why not (one line): Tier‑1 does not record a token; Tier‑2 listings are not considered proof.
  • 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): Tier‑1 does not describe payment for the service with the project token.
  • Evidence: Tier‑1 — https://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md
  • Why sufficient / why not (one line): Subscriptions/fees are mentioned conceptually, but without token mechanics.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): Incentives are described at the level of subnet rewards, but not via a separate project token.
  • Evidence: Tier‑1 — https://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md
  • Why sufficient / why not (one line): Tier‑1 speaks about emissions/rewards without defining 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://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md
  • Why sufficient / why not (one line): There is no Tier‑1 description of token governance.
  • 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://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.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://github.com/mobiusfund/investing/blob/main/Investing/doc/Subnet88.md Purpose of the subnet (a decentralized “investing subnet”), the miners/validators roles, strategy scoring, ensemble/meta‑strategy; mention of support for ML/AI strategies
Tier‑1 — No Tier‑1 source for claim “there is a separate project token and a clear utility/tokenomics” was found.
Tier‑2 https://taostats.io/subnets/88/chart Context: the metrics page of the Bittensor subnet linked to netuid 88
Tier‑2 https://www.coingecko.com/en/coins/staking-2 Context: a token listing appears in public reference sources (not considered proof of utility)

No comments to display

Back to top