Subnet 22: Desearch
Desearch is Bittensor Subnet 22, a search-focused subnet connected to Desearch’s public API and console. The project site is desearch.ai, and the GitHub repository listed for the subnet is datura-ai/desearch.
What Desearch Provides
The Desearch repository describes SN22 as coordinating miners and validators that serve live web, X/Twitter, and multi-source search data. In Bittensor terms, the subnet makes search retrieval a rewarded service: miners provide search responses, validators evaluate miner outputs, and validator weights feed into Yuma Consensus.
This places Desearch in the data-access part of the subnet ecosystem. Its value proposition is not model training by itself, but access to current search and social data that can be used by products, agents, and other applications that need fresher context than static model training data provides.
Live Retrieval Context
The Desearch README source describes SN22 as the subnet behind Desearch’s decentralized real-time intelligence layer. It says the subnet coordinates miners and validators that serve live web, X/Twitter, and multi-source search data for Desearch API and console products.
The public Desearch website describes the product as search, crawl, citation, and monitoring for fresh web plus social context through one API for AI agent workflows. Read with the README, that makes Subnet 22 a retrieval-oriented subnet: the work is about getting current external context into products and agents, not about producing a trained model as the direct output.
That distinction matters because live retrieval has different failure modes from offline model training. A useful miner response needs to be timely, relevant, and checkable against external sources. The README’s architecture table reflects that by describing validators that send synthetic and organic queries to miners and verify results with independent providers.
Scoring and Service Context
The Desearch README separates the subnet runtime into miner, validator, validator API, and shared package components. Miners run a Bittensor axon, declare search capacity, answer health checks, and serve AI, X/Twitter, and web search synapses. Validators send queries to miners, store scoring windows, and write weights on-chain.
This split is useful for understanding the subnet as a service chain. Miners provide search capability, validators compare returned results and convert that measurement into weights for the subnet, and the validator API described in the README lets trusted Desearch services request organic search and inspect public miner state.
References: Desearch README source, Desearch website
Miner and Validator Roles
The repository separates miner operators from validator operators. Miners run a Bittensor axon that answers health checks and search synapses. Validators run the scoring service that queries miners and writes weights, plus a protected API used by trusted Desearch services.
At the article level, the important distinction is simple: miners supply search capability, while validators decide how that capability should be weighted.
On-Chain Identity
Live SN22 subnet data is available on TaoStats. The source-backed retrieval and validation details in this article come from Desearch’s public website and README source rather than from live identity fields.
Relationship to Yuma Consensus
Subnet 22 uses Yuma Consensus to convert the search-quality weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The linked documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Desearch’s context, validators send synthetic and organic search queries to miners, verify returned results against independent providers, and translate those quality scores into weight vectors for the subnet. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Desearch (SN22), that sequence changes how readers should interpret search retrieval examples and scoring outcomes.
In localnet, Desearch-compatible miners and validators can be developed and tested in an isolated environment. Localnet search results and scoring outcomes do not represent production subnet performance.
On testnet, Desearch-compatible components can be exercised in a shared, non-production network. Testnet retrieval results and validator scores are separate from mainnet subnet state.
On mainnet, Desearch (SN22) is the live production subnet where miners serve real-time search results and validators evaluate those results to determine actual Bittensor emissions. The Desearch README describes the retrieval and scoring mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A search retrieval example or scoring result from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 22 Desearch should not be read as generic Bittensor subnet documentation, a finished search engine product, or proof that one retrieval response defines model-training quality. It names one subnet’s decentralized real-time search layer on netuid 22 (Understanding Subnets, Glossary: Netuid).
Synthetic and Organic Queries Exercise Miners
The Desearch README describes validators sending both synthetic and organic queries to miners and recording scoring windows from the responses (Desearch README).
The subnet therefore measures live retrieval service rather than offline model output.
Independent Providers Verify Returned Results
The README’s architecture table describes validators checking miner results against independent providers rather than accepting self-reported answers alone (Desearch README).
That verification step is what turns search responses into on-chain weights.
Validator Weights Still Flow Through Yuma Consensus
Subnet 22 uses Yuma Consensus to convert validator weight submissions into emission shares each tempo (Yuma Consensus, Emission).