Skip to main content

Merit (Subnet 73)

Merit (Subnet 73) — 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).

Merit — an 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 Bittensor subnet that rewards miners for active participation in other Bittensor subnets.
  • Who it’s for: for Bittensor miners (who operate in several subnets) and Merit validators.
  • Why onchain/token: onchain is needed for the standard Bittensor mechanisms (hotkey registration, metagraph collection, set_weights()); a separate project token utility is not confirmed per Tier‑1.

How it works (very briefly)

  1. The miner does: registers a hotkey in Merit (netuid 73) and operates in other active subnets.
  2. The validator does: once per epoch pulls data on all subnets, looks for the hotkey’s participation in each subnet and collects incentives.
  3. The system computes: the average “participation” (BMPS) across all active subnets (except root and Merit) + a penalty for unavailability (ping).
  4. Where the blockchain is: metagraph collection, registration and submission of weights (set_weights()) are performed in the Bittensor layer.
  5. Token role (if any): a separate token/its role in the Merit mechanics are not described by Tier‑1.

Quick links: AI thesis fit

Project passport

Field Value
Project name Merit (Subnet 73)
Also known as (aliases) Merit SN73; netuid 73
Logo (logo) ../assets/447_merit-sn73_logo.svg
Token symbol (ticker) —
Category Infra
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 are distributed at the level of the Bittensor weights mechanics; a separate project token is not confirmed per Tier‑1
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) fx-integral (core contributors)
Funding (investors/funding) —
AI component (ai_component) —
Use‑case (use_case) incentives for subnet participation
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary 0 / 2 / 0 / 2
Last verified 2026-02-11

General project overview

Merit (Subnet 73) is a Bittensor subnet that offers a simple incentive: to reward miners who actually work in different subnets of the ecosystem, rather than merely “being present” in one place.

Merit validators calculate a participation score (BMPS) for each registered hotkey by looking at the incentives of that same hotkey in all other active subnets and averaging them. Additionally, an availability check (ping) with cryptographic verification (a TOTP‑like scheme in the description) is applied in order to penalize “dead” nodes.

Features/modules

  • Cross‑subnet evaluation: search for the same hotkey across all active subnets.
  • BMPS formula: average incentive × a scale constant.
  • Liveness‑checks: pings and a penalty for unavailability.
  • Anti‑gaming measures: public IPv4, TOTP verification, typed responses (as claimed in the whitepaper).

Typical scenarios

  • Scenario 1 (miner): participates in several subnets → gets a higher BMPS and, as a consequence, higher weight/rewards in Merit.
  • Scenario 2 (validator): once per epoch collects network information and publishes weights → ensures correct BMPS calculation and resistance to “ghosts”.

Getting started (wallet/network)

  • What you need: a Bittensor wallet/hotkey registered in netuid 73; a Python environment for running a miner/validator.
  • Network/chain: Bittensor mainnet (in the examples — finney).
  • Fees: standard Bittensor (registration/transactions) + server infrastructure.

Architecture/tech (non‑AI)

  • Components: the Merit Bittensor subnet (netuid 73), miners (hotkeys), validators (BMPS calculation, pings), Bittensor RPC/metagraph.
  • Participant roles: miners (participation in subnets), validators (evaluation/weights), the Bittensor network (registration and finalization of weights).
  • Where logic runs: metagraph collection, BMPS calculation and pings — offchain; publication of weights — onchain on Bittensor.
  • Dependencies: access to Bittensor metagraphs (get_all_metagraphs_info()), network access for ping.

Token/economics (expanded, no forecasts)

  • Token utility: Tier‑1 does not describe a separate Merit token; the economy is built around the weights/rewards of the Bittensor subnet.
  • Protocol necessity drivers: the incentive is to reward broad participation across all active subnets.
  • Who pays fees: participants pay standard Bittensor fees (registration/transactions).
  • Where fees go / treasury: not established per Tier‑1.

Governance

  • Who makes decisions: not established per Tier‑1 (apart from the standard role of subnet validators).
  • How protocol parameters change: via updates to the validator/miner code; a roadmap is in the repository (see links_*).

Security and incidents

  • Audits: not established per Tier‑1.
  • Bug bounty: not established per Tier‑1.
  • Incidents: not established per Tier‑1.
  • Threat model: gaming via “fictitious participation”, node unavailability, forged responses — mitigations are described in the whitepaper.

Project status and timeline

  • Current status: active Bittensor subnet (mainnet).
  • Key parameters: netuid 73; tempo/ping timeouts, etc. are listed in the whitepaper.
  • Roadmap: in the repository (see links_*).

Ecosystem/integrations

  • Integrations: the Bittensor metagraph and subnet infrastructure.
  • Partners: not established per Tier‑1.
  • Where it’s actually used: as a “meta‑subnet” for participation incentives, on top of the other Bittensor subnets.

AI component of the project

  • What is real AI here? Per Tier‑1, this is not an AI product: the subnet evaluates hotkey participation by incentives/uptime, not the quality of AI models.
  • What is truly onchain? Registration in netuid 73, access to metagraphs and publication of weights via set_weights() on the Bittensor network.
  • Why is a token needed? The role of a separate project token is not established per Tier‑1.
  • Red flags (based on the information found): AI‑washing (if marketing positions it as AI without facts); token‑washing (Tier‑2 listings without Tier‑1 utility); what to double‑check: the existence/role of a token per Tier‑1.

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality low 0
Onchain necessity medium 2
Token necessity low 0
Evidence Tier‑1 present (OC) 2
Details

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): Tier‑1 does not claim an AI roadmap; this is a subnet about participation/incentives.
  • Evidence: Tier‑1 — https://github.com/fx-integral/merit/blob/main/whitepaper.md
  • Why sufficient / why not (one line): The whitepaper contains no AI intentions — the focus is on the BMPS mechanics.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): Per Tier‑1 there are no AI features: the metric is built on incentives/uptime.
  • Evidence: Tier‑1 — https://github.com/fx-integral/merit/blob/main/whitepaper.md
  • Why sufficient / why not (one line): The whitepaper describes the algorithm for searching hotkeys and averaging incentives without AI.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): An AI demo is not applicable (no AI features are claimed per Tier‑1).
  • Evidence: Tier‑1 — https://github.com/fx-integral/merit/blob/main/README.md
  • Why sufficient / why not (one line): The README provides launch guides, but this is not an AI demo.
  • 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/fx-integral/merit/blob/main/whitepaper.md
  • Why sufficient / why not (one line): The metrics in the project are about participation (BMPS), not AI quality.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): An AI tech description is absent; there is a description of the BMPS protocol logic.
  • Evidence: Tier‑1 — https://github.com/fx-integral/merit/blob/main/whitepaper.md
  • Why sufficient / why not (one line): A description exists, but it is not about an AI architecture.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Bittensor
  • Addresses/identifiers: subnet netuid 73 (Merit)
  • Evidence: Tier‑1 — https://github.com/fx-integral/merit/blob/main/whitepaper.md; Tier‑2 — https://taostats.io/subnets/73/chart
  • Why sufficient / why not (one line): The whitepaper records netuid 73 and onchain registration per Bittensor standards.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: onchain registration of hotkeys and publication of weights by validators (set_weights()), as well as retrieval of metagraphs by subnet.
  • Evidence: Tier‑1 — https://github.com/fx-integral/merit/blob/main/whitepaper.md; Tier‑1 — https://github.com/fx-integral/merit/blob/main/README.md
  • Why sufficient / why not (one line): The Merit mechanics are directly tied to Bittensor network data and onchain weights.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: without the Bittensor onchain, registration and publication of weights break down; but a formal replaceability test has not been performed in Tier‑1.
  • Evidence: Tier‑1 — https://github.com/fx-integral/merit/blob/main/whitepaper.md
  • Why sufficient / why not (one line): Criticality follows from the design, but is not proven by a separate 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/fx-integral/merit/blob/main/whitepaper.md
  • Why sufficient / why not (one line): Tier‑1 does not describe a token; CMC — a reference Tier‑2.
  • 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): Payment for the service with a project token is not described by Tier‑1.
  • Evidence: Tier‑1 — https://github.com/fx-integral/merit/blob/main/whitepaper.md
  • Why sufficient / why not (one line): The mechanics are about weights/participation incentives, without a payment token.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): Incentives are implemented via subnet weights; the “penalty” is zeroing the BMPS on a failed ping (not token mechanics).
  • Evidence: Tier‑1 — https://github.com/fx-integral/merit/blob/main/whitepaper.md
  • Why sufficient / why not (one line): In the whitepaper, incentives/penalties are described without a separate token.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): Token governance is not described (Tier‑1).
  • Evidence: Tier‑1 — https://github.com/fx-integral/merit/blob/main/whitepaper.md
  • Why sufficient / why not (one line): There are no Tier‑1 statements about governance via a project token.
  • 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/fx-integral/merit/blob/main/whitepaper.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/fx-integral/merit/blob/main/whitepaper.md Purpose of the subnet (reward for cross‑subnet participation), the BMPS formula and the validation process (metagraphs, hotkey search across subnets, set_weights()), anti‑gaming measures
Tier‑1 https://github.com/fx-integral/merit/blob/main/README.md Practical instructions for running the miner/validator and confirmation of netuid 73
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/73/chart Context: metrics page of Bittensor subnet netuid 73
Tier‑2 https://coinmarketcap.com/currencies/merit-sn73/ Context: reference listing (not counted as proof of utility)

No comments to display

Back to top