An On-Chain Agent Registration Is Not a Liveness Check

When a builder looks for an integration target and finds a service with an on-chain agent identity, the registration answers one question: someone created this entry. It does not answer whether the service is currently running, whether it has paying customers, or whether the declared capabilities match the actual implementation.

The gap between registered and operational in the on-chain agent registry is large. There are currently 105,852 on-chain agent identities registered. Of those, 21,948 carry anything substantive behind them by our classification: an entry is substantive when it has a non-auto-generated name and an agentUri that resolves to a live service, not back to the spec page. That is our methodology, not the registry's; the registry reports the raw total and makes no such distinction. Separately, 52,050 entries fit our placeholder definition: auto-generated names pointing at the spec page rather than a running service.

The remaining entries fall outside both categories. They may have real names but unresolvable URIs, or partially configured entries the operator never finished. The classification is conservative in both directions.

Why the gap exists

The on-chain registration spec defines a minimal record: an agent name, a URI pointing at the service, and an operator wallet. Creating this record is cheap. Gas costs are low enough that an operator building a suite of experimental services can register entries in an afternoon at negligible cost. An entry that never receives a caller costs the operator nothing extra to leave in the registry.

The spec-page placeholder pattern is a specific artifact of how many SDK scaffolds work. When a developer initializes a new agent project from a template, the agentUri defaults to the spec page until the developer fills it in. Operators who create registrations before their service is built, or who abandon projects partway through, leave the default in place. The registry has no mechanism to expire or remove these entries, and operators have no financial incentive to clean them up.

This is not a registry design flaw in isolation. Any sufficiently cheap registration system accumulates stale entries over time. The relevant fact for a builder is that the raw registration count is not a signal of ecosystem health. The substantive count is closer to that signal, and even it does not tell you whether those services are currently accepting calls.

What matters before an integration

A single on-chain registration cannot be the start and end of due diligence. The signals that matter come from outside the registration itself. Whether the endpoint responds to a live handshake is a check you run directly, as covered [today](/news/agent-registry-liveness-oct2026): more than half of probed registry MCP servers did not answer. Whether other buyers have paid for calls is a check the index exposes through commerce data. Neither is available from the registration alone, and neither is retrievable without querying beyond the registry entry.

The practical sequence

First: is the agentUri responding? If the endpoint does not answer a tools/list call, the registration is a record of intent, not a record of operation. This check costs one HTTP request.

Second: does the service have buyers beyond its own operator? A service with one payer is a service calling itself. The multi-buyer count is the check that separates a listing from a market. An entry with a registration but no independent buyer in the commerce data tells you the registration happened before anyone else decided the service was worth paying for.

Third: is there on-chain settlement? USDC transfers to the service's payment address are the only check of the three that cannot be faked by submitting data to a registry. On-chain transfers are settled ledger entries. A service with real settlement history and a valid liveness check has cleared two independent thresholds that registration alone cannot clear on its behalf.

An on-chain registration is a starting point for discovery, not a quality signal. A high count across a suite of services tells you only that the operator is active. None of the checks above can be skipped based on registration count alone.