Great search starts with finding the right pages. Ranking cannot fix a query that never reached the pages that matter.
Desearch 2.0 is the next stage of how Desearch builds and grows its search index with the Bittensor network. This article explains the pieces in plain language: an embedding model built for search, crawl and embed tasks for miners, sample checks by validators, and rewards tied to verified work.
Status: Desearch 2.0 released on the October 1 window (subnet-22 #378 merged). This post matches that shipping language. It still does not claim that every subnet program is already open; later task families are announced before they open.
Allowed sources for every claim below:
- Giga's Friday Discord announcement (Appendix A in the internal 2026-09-28 social plan)
- Architecture
- Desearch 2.0 vision README
Why search needs the right pages first
Desearch fine-tuned its own embedding model for search and web-scale retrieval. The point is retrieval before ranking: the right pages surface for a query before any ranking step runs.
Along the way, Desearch search got noticeably faster. That is the only speed wording this article uses. No latency numbers, no model-size callouts, no invented quality scores.
An embedding model can only find what the index holds. So Desearch is expanding the index and building it with the Bittensor network: miners crawl the web, pages are embedded with the Desearch model, and every verified page helps search reach further.
What miners do
Two kinds of tasks:
Crawling
Miners fetch a batch of web pages and upload their text. Validators check a sample of those pages against their own fetch.
Architecture docs describe the crawl path in more detail: a Desearch bot discovers URLs, the task API packs them into tasks, miners fetch and extract text, validators re-check a sample, and verified pages are published into the collection the search index is built from.
Embedding
Miners turn crawled pages into embeddings with the Desearch model on their own GPUs. Validators recompute a sample to confirm them.
Architecture docs describe embedding tasks as built for the network program, with crawling as the first task family on SN22 and later programs announced before each opens. Desearch 2.0 is released on the October 1 window; this article explains the crawl-and-embed loop without inventing open dates for every later program.
How validators check a sample
Validators do not take miner uploads on trust.
For crawl work, validators check a sample of pages against their own fetch and report pass or fail. For embedding work, validators check that vectors are present and well formed, and they recompute a random sample with the same model so every sample must match.
The public announcement summarizes the same idea: validators check a sample (crawl) or recompute a sample (embed). Architecture docs add the operational detail that finalized, verified pages are what reach the index.
Rewards by verified work
Crawling and embedding are rewarded the same way: by the verified work each miner delivers, compared with every other miner. More work done accurately earns more. Work that does not hold up under checking earns nothing.
This article does not discuss network payment schedules or weight math. Those details are out of scope for a public product explainer.
What comes next
Fine-tuning competitions are the next step for making web search better. The network will compete to train retrieval and ranking models that find the right pages more accurately, and models that beat the current one on quality, speed, and cost become part of Desearch search.
Treat competitions as a next step, not as a live program with a dated start in this post.
Where to read more
- Architecture (how crawl / embed / validate fit together):
docs/architecture.md on the desearch-2.0 branch - Vision and reading order:
docs/desearch-2.0/README.md - Try search in product today: Desearch Console
How the pieces fit (high level)
At a high level the loop is:
- Discover URLs worth keeping (Desearch bot / feeder into the task API).
- Miners crawl those URLs and upload extracted text.
- Validators check a sample; finalized verified pages are published.
- When embedding is open for the network, miners embed texts with the Desearch model; validators recompute a sample.
- The engine builds search from published pages and vectors.
That is how "right pages first" connects to a growing index. The embedding model improves retrieval; the crawl-and-embed loop grows what retrieval can see.
What this is not
- Not a mining drama post. No closing narrative about SN22.
- Not a benchmark sheet. No invented metrics.
- Not a competitor comparison.
- Not a claim that every 2.0 program is already open on day one; release does not equal every task family live at once.
FAQ
Has Desearch 2.0 shipped yet?
Yes. Desearch 2.0 released on the October 1 window. Later programs (including fine-tuning competitions) are still announced before they open.
Does this replace Desearch search APIs?
No. This article explains how the index grows. Builders still use Console and the documented APIs / MCP paths for calling search.
Are there speed or model-size numbers?
No. The only allowed speed phrase here is "noticeably faster" from the announcement. No model sizes, percentages, or benchmarks.
What should miners expect?
Crawl tasks and embed tasks, with rewards based on verified work. Read the architecture and vision docs before you change hardware or ops plans. Later programs are announced before they open.