Onchain Agent Registry: 500K Records, Which Work?
On June 16, 2026, The Spawn production analytics page reported 516,375 registrations in the onchain agent registry across 28 chains.
That scale changes the operating problem. Small registries can be scanned by hand. However, past half a million entries, discovery turns into routing work. A useful directory has to resolve the URI, probe the advertised surface, classify the protocol, and ignore dead inventory.
In brief: 500K registered onchain agents does not mean 500K working agents. It means the ERC-8004 surface is large enough that discovery needs ranking, URI resolution, endpoint probes, and payment checks before a person or another agent spends effort on a listing.
TL;DR:
- June 16 production showed 516,375 registrations across 28 chains.
- Metadata, service, and x402 signals narrow the pool before any live call.
- Only 1,793 entries sat in S/A/B tiers, the group worth inspecting first.
Answer-first summary: The June 16 snapshot is useful because it separates registration supply from caller readiness for real product and search decisions. The onchain agent registry held 516,375 indexed ERC-8004 records, but only 259,298 had parsed metadata, 44,782 declared services, 191,456 carried an x402 signal, and 1,793 landed in S/A/B quality tiers. Therefore, the right reading is not "there are 500K working agents." A better reading is "there are 500K published records, and every useful directory now needs resolver, schema, endpoint, protocol, payment, and liveness checks." This matters for search visitors, coding agents, and paid-agent workflows because a registry event alone cannot tell a caller whether a URL still resolves, whether MCP or A2A answers correctly, or whether an x402 payment can complete.
Use this route through the piece. First, read the dated snapshot before quoting the 500K number. Next, check the method before comparing this count with another index. Then use the builder checklist before publishing a new ERC-8004 record, and use the search path before calling or paying an agent from any directory.
What the onchain agent registry snapshot counted
We would not call this "516,375 working agents." The production snapshot breaks the counter into narrower cuts:
| Production field | Count |
|---|---|
| Total agent registrations | 516,375 |
| Indexed chains | 28 |
| Agents with parsed metadata | 259,298 |
| Agents declaring services | 44,782 |
| Agents with an x402 signal in indexed data | 191,456 |
| Agents in S/A/B quality tiers | 1,793 |
Counts move because indexers sync at different times, offchain files change, and probes rerun. However, the pattern is clear enough to act on: registration volume is real, while the inspection-worthy subset is much smaller.
Read the table in two layers. Specifically, the first two rows show registry reach. The last four rows show how much work remains before search can route a user to a useful agent.
What should a caller do with this count? Treat it as supply first. Readiness comes after independent checks. In practice, an onchain agent can be registered, indexed, partially decoded, payment-adjacent, and still not ready for a caller. Metadata, service declarations, payment signals, and endpoint behavior fail independently, so one registration counter hides operational risk.
How the ERC-8004 agent snapshot was collected
We measured this original production snapshot from production-rendered /analytics SSR props and Dataset JSON-LD at 2026-06-16T07:42:41Z UTC. The snapshot ID is 500k-onchain-agents-2026-06-16.
The June 16 JSON record stores the fields used in this article. The moving aggregate remains on The Spawn analytics dashboard, so treat these numbers as a dated production read; the registry will continue to change.
Method note: we analyzed a rendered production page rather than a local database dump because the public page is the source search visitors can verify. In addition, the saved JSON snapshot keeps the exact counts beside the capture timestamp, source URL, and field definitions used in this article. The live analytics page can move after new blocks, retries, gateway results, or metadata refreshes. As a result, this article treats the June 16 figures as a reproducible dated sample and treats the analytics dashboard as the changing aggregate. If a later crawl changes the totals, the comparison should use the same field boundaries: total registrations, parsed metadata, service declarations, x402 signal, S/A/B quality tier, capture time, crawler scope, and public source URL.
What the snapshot definitions mean
The record keeps five denominators separate. Total registrations are indexed ERC-8004 records, not live agents. Parsed metadata is decoded offchain content stored by The Spawn after the URI can be fetched and read. Service declarations are records with a non-empty services field, while x402 signal means metadata or indexed fields mention x402 rather than proving that payment works. In particular, quality tiers are The Spawn inspection buckets for entries that have stronger liveness and protocol evidence than the average row.
| Denominator | Definition |
|---|---|
| Total registrations | Indexed ERC-8004 records |
| Parsed metadata | Decoded offchain content stored by The Spawn |
| Service declarations | Records with a non-empty services field |
| x402 signal | Metadata or indexed fields mention x402 |
| Quality tiers | Entries in S, A, or B after The Spawn liveness and inspection checks |
Why registry counts can move between crawler runs
Useful crawlers keep failure reasons named instead of collapsing them into "dead." For example, common buckets include NXDOMAIN, timeout, TLS alert, CORS denial, MIME mismatch, JSON parse error, method mismatch, empty catalog, bad challenge, unsupported network, stale cache, gateway miss, oversized payload, malformed URI, and silent 200.
Therefore, chain reorgs, RPC lag, gateway caching, schema drift, retry windows, and crawler timeouts can shift totals between runs. For that reason, this article keeps inventory, chain coverage, parsed JSON, service declarations, payment hints, and quality tiers separate instead of blending them into one vanity metric.
Why the ERC-8004 agent registry is doing its job
ERC-8004 gives builders a shared identity model. A caller can start with chain ID plus token ID, resolve the agentURI, and fetch the registration file. Runtime inspection happens after that file is available.
Compared with a README, a Discord post, or an MCP URL pasted into a chat, onchain identity gives every directory, wallet, marketplace, coding agent, and evaluator the same record to resolve.
For the longer registry mechanics, read ERC-8004 Explained. In other words, ERC-8004 records identity and trust context; it does not run the agent for you.
In this article, ERC-8004 names the shared identity standard. The agentURI field is the pointer an indexer resolves before deeper inspection. x402 support is only a hint that the listing may speak HTTP 402 payment. Quality tiers group entries with stronger liveness and protocol proof than the average row.
How indexers separate registered onchain agents from usable ones
Once a record exists, an indexer has to do the dull work a chain cannot do.
Indexing starts by fetching the URI and parsing the JSON. The entry stays useful only when the file still has a complete profile and callable surfaces. Reachability is separate: call the public URL and confirm it answers as advertised. Plain web-server responses are not enough. For example, MCP should return tools from tools/list, A2A should accept a task shape, and paid APIs should return x402 requirements a buyer could retry with.
Together, those checks separate "a token exists" from "another system can route work here."
Useful registry rows leave a trail. Specifically, resolver freshness, gateway durability, schema completeness, endpoint semantics, protocol handshake, facilitator readiness, retry behavior, cache age, finality lag, adapter coverage, queue backlog, probe timestamp, and error class all help decide whether a catalog entry can become a route.
For example, failed records usually fail in ordinary ways: expired temporary hosts, unpinned files that public gateways stop fetching, tutorial defaults left in production metadata, HTTP 200 responses that do not speak the advertised protocol, or x402 claims that do not return a usable 402 response.
The agent directory, world map, and quality checker start with the raw count, then add file and endpoint evidence.
Useful onchain agents are a smaller subset
In fact, raw registration count proves supply, while search and routing need the smaller set: 1,793 S/A/B entries out of 516,375 total registrations.
The S, A, and B labels are not official ERC-8004 statuses. Those labels put cleaner JSON, reachable URLs, protocol proof, and fewer dead-end signals ahead of weaker rows.
Dead endpoints waste human clicks; autonomous agents also lose context and tool budget, and paid calls can waste money too. Before an assistant installs an MCP server, calls a paid tool, or hands work to another agent, the registry event is only the first piece of evidence.
Protocol choice changes the inspection path. Use ERC-8004 vs MCP to compare identity with runtime access, MCP vs A2A when tool calls turn into delegation, and Claude Skills vs MCP when a local procedure competes with live external access.
Routing note: the smaller S/A/B set exists because failures compound across metadata, service, protocol, payment, and liveness checks. A record can resolve while its service list is empty. Another record can advertise MCP while its URL returns a generic web page. A paid listing can mention x402 while the endpoint fails to return payment requirements. In practice, each failed check removes a record from the pool a search visitor should inspect first. This is why The Spawn starts with the registry event, then adds metadata parsing, endpoint probing, protocol checks, payment-readiness checks, and quality scoring. That sequence matters: stale metadata hides the service, a bad service blocks the protocol check, and a failed 402 prevents payment. The result is a ranked path where a published record can become a human click, an agent call, or a paid retry only after passing more evidence.
Why x402 agents are promising, not payment proof
In particular, the production snapshot counted 191,456 agents with an x402 signal in indexed data. The count is large enough to justify product work on paid calls, but a declaration alone does not prove checkout.
x402 works when a server returns HTTP 402 requirements, accepts a signed payload, and delivers the protected resource on retry. HTTP 402 mechanics are documented in the official x402 docs. For this site, the flow is in x402 for APIs and Agents, and registration details are in registering an x402 service.
Can a listing mention x402 and still fail checkout? It can, which is why x402 support should be treated as a lead. The next check is whether the service actually negotiates payment.
What a builder should do before registering
Therefore, registration should wait until the service works. Otherwise, early records are cheap to publish and stale records are expensive for every crawler or agent that touches them later.
Useful agentURI values point at durable JSON, and the hosting choice changes how much cleanup the indexer has to do. For instance, pin the IPFS file, operate the HTTPS domain, or use an immutable data URI when no future edits are needed. If nobody can fetch the file, the onchain identity remains visible but hard to classify.
Service lists should be specific enough for another agent to act on. Specifically, "MCP" is incomplete unless the URL answers as MCP. "Paid tool" is incomplete unless the x402 path returns real payment details. "Research agent" is incomplete unless the profile names accepted input and returned output.
Before announcing the record, run The Spawn quality checker with the chain and token ID; the report catches missing images, empty descriptions, unresolved URIs, weak surface declarations, and dead endpoints. The longer launch checklist is in registering onchain AI agents.
What a search visitor should do
Search should start with the job instead of the total count. However, the largest registry can still send a visitor to a dead end when ranking ignores liveness and protocol proof.
MCP searches should begin with the task and high-tier entries. Similarly, paid-service searches should look for x402 proof before sending value. Standards comparisons deserve a separate pass before installing anything into Claude, Codex, Cursor, OpenClaw, or another host.
Raw inventory is useful only after the directory can filter it. Good search paths end in an action: inspect a profile, run a check, install an MCP server, compare registration details, or call a paid endpoint with clear terms.
Registry entries record supply; quality checks decide what deserves a try.
Method and authorship
This field note was written by Roman Krutovoy, maintainer of The Spawn. I maintain the directory that produced this snapshot. For this update, we analyzed the live analytics payload, measured the published aggregate fields, and tested the article render against the public snapshot file. It is not an official ERC-8004 registry status report; it is original production data from one directory that indexes ERC-8004 records, resolves metadata, runs service checks, and exposes the aggregate on a public analytics page.
Corrections should be made against public evidence: the snapshot JSON above, the live analytics dashboard, the about page, the site manifesto, and the public privacy and terms pages. For editorial corrections, contact Roman through the public links on krutovoy.me. We tested the local article route, hero image route, snapshot JSON route, and JSON-LD output before treating this article as a release candidate. The page was cleaned on July 12, 2026 so public Article, FAQ, and Dataset schema comes from The Spawn renderer rather than duplicated inline helper markup.
FAQ
Does 500K mean 500K working agents?
It does not mean every record is callable. The production snapshot counted 516,375 registered agent records on June 16, 2026. The live subset is smaller and should be judged by metadata, endpoint behavior, protocol evidence, and quality tier.
Why are many registrations low quality?
Open registration makes it cheap to publish records before the service is reliable. Some records are demos, some are abandoned, and some have metadata that no longer resolves. Quality scoring exists because the registry alone cannot test those conditions.
Should I trust x402 support in metadata?
Use it as a signal to inspect before trusting the service. A payment-ready service needs a real 402 response, payment requirements, and a successful retry after payment.
Where should a search visitor start with this registry?
Browse The Spawn agent directory, then run the quality checker on any agent you plan to call or integrate.
Further reading
Read ERC-8004 Explained when the decision is how registry identity is supposed to work. Read ERC-8004 vs MCP when the decision is identity versus runtime access. Read x402 for APIs and Agents when the decision is whether a paid endpoint can complete a payment handshake.