Our aim is to distinguish what is announced from what is demonstrated, and what is known from what remains uncertain.

We use primary sources wherever possible, separate reporting from opinion, and avoid treating token price movements as evidence of a project’s progress.

Bittensor.zone is being developed gradually. Our focus is on publishing useful, well-sourced material rather than filling pages for the sake of volume.

For companies exploring Bittensor, product–market fit is only part of the assessment. We also examine protocol fit: whether a business problem can be translated into useful tasks, credible evaluation and incentives that reward meaningful results.

Miners contribute work, models or services. Validators assess their performance under each subnet’s rules. The business opportunity depends on how closely those rules align with what customers actually need.

Cybersecurity offers a practical example. A security company could use subnet-developed agents to support recurring reviews of authorised codebases, with contributors competing to improve vulnerability detection. Bitsec already documents a model in which miners submit security agents and validators evaluate their findings against benchmark vulnerabilities.

The potential is an ongoing source of competing approaches to a defined problem. Its value still depends on reliable findings, confidentiality, integration and sustainable economics. Strong protocol fit should support a useful product and a viable business.

An editorial selection, not a ranking. We choose projects to illustrate different services, use cases and incentive designs. Placement does not indicate quality, investment potential or preference.

We look for a clearly described service, documentation we can examine, and a useful connection to a business or developer task. We distinguish individual subnets from organisations working across the ecosystem.

The selection is a starting point for research, not a complete directory or a technical audit. Inclusion does not establish customer adoption, commercial performance or security.

We start with official project websites and documentation, then official repositories and announcements. We use TAOStats to check subnet identity and network information.

We link to the sources behind factual descriptions. A project’s own claims are not independent proof: where performance, adoption or partnerships have not been substantiated, we avoid presenting them as established facts.

We separate announced features from confirmed availability and label interpretation and hypothetical examples. Review dates describe when information was checked; they do not imply continuous monitoring. Uncertain information remains qualified.

When a material factual error is identified, we correct the affected content and add a dated note explaining the change. Routine wording and typographical fixes may be made without a separate correction note.

If you spot an error or outdated information, send us the relevant URL, identify the statement in question and include a primary source where possible.

Submit a correction →