Registered, Signposted, Resolvable, Paid — Four Different Cohorts, Two Months of Live Data

Report 05 made the case that registered, live, and got paid are three different bars, and that shopping by the first one is what the ecosystem keeps getting wrong. Two months on, the picture has gained a fourth bar — publishes a discoverable agent card — and the honest answer for any specific ERC-8004 agent depends on which of the four bars a buyer needs it to clear. This post is the dated read of the four cohorts, side by side, with the sample-vs-population and per-publisher-dedup disclosures the underlying numbers require, plus a separately-reported cut of the Solana 8004-solana registration program — a different program that shares a name fragment and nothing else.

Ethereum registry: raw mints, not agents.

The Ethereum-mainnet ERC-8004 IdentityRegistry (0x8004A169…539a432) has now emitted — raw Transfer(from=0x0) mints as of the last full block-range census (—). That number is a count of raw registrations, not agents; it includes empty rows, factory-cluster tails, single-purpose test mints, and everything else on-chain minting an agentId costs a few cents to do. Anyone reporting it as an agent count is measuring the wrong thing on purpose.

Of that raw-mint total, — (—%) have a populated tokenURI; far fewer resolve to a usable agent card. A populated URI is a claim that the minter intended to point at something — it is not evidence anything is there. The next section reports the fresh resolvability sample that puts a bounded number on the second half of that sentence.

The publisher tail matters for reading the mint number honestly. Two HTTP hosts alone move most of the volume — the top host on Ethereum by mint count is agents.exquisite.land at 10,000 mints (roughly a fifth of the whole registry on its own), and the top twenty hosts together account for roughly a third. Our indexed profile store therefore applies a per-publisher dedup so any single minter cannot dominate the identity-graph views a reader actually consumes; the cap is — per publisher across — distinct publishers with a top-publisher raw batch of — mints, disclosed in the same sentence as any figure derived from it. The purpose is not to hide the tail — the tail is the story — but to prevent a single batch mint from turning a legibility surface into a factory-cluster mirror.

The full block-range breakdown, with per-publisher counts and the exact top-twenty host histogram, is on the /how-many-erc-8004-agents-are-there answer page — the canonical “registered vs indexed vs agents” frame for this cluster.

The resolvability sample: populated URI ≠ working card.

The middle layer of the ladder — between “the on-chain URI is non-empty” and “the agent card is discoverable at the endpoint” — now has a bounded measurement of its own. On 2 September 2026 we drew a stratified random sample of 600 agents per chain from the eligible-nonempty-URI populations (Base: 22,807 eligible; Ethereum: 2,827 eligible) and probed each URI end-to-end, classifying the response into one of nine outcome buckets. The sample is small and stated as such; treat it as a rate estimate over the population, never as a headline census.

Chain (n = 600 sampled)	Any JSON at URI	Usable agent card
Base — sample of Base non-empty URIs	68.17% (95% CI 64.33–71.77)	56.33% (95% CI 52.34–60.25)
Ethereum — sample of Ethereum non-empty URIs	74.83% (95% CI 71.21–78.14)	71.33% (95% CI 67.59–74.81)
Pooled (n = 1,200)	71.50% (95% CI 68.88–73.98)	63.83% (95% CI 61.07–66.50)

Sample, not census. Full outcome-bucket breakdown, near-miss shape counts, and host concentration by bucket are in the machine-readable dataset on the signpost-gap datasets endpoint and the sibling agent-card signpost-gap post.

Two takeaways. First, on Base roughly 44% of the populated-URI slice does not resolve to a usable agent card in a single probe — the URI was published on-chain but the thing at the other end is missing, wrong, or ghost-DNS. Second, the same slice on Ethereum resolves at a materially higher rate than Base does (71.3% vs 56.3% usable-card). The direction matches the per-chain live-rate shape we have reported since Report 05: Ethereum is a smaller, more curated cohort; Base is larger and more tail-heavy.

The signpost gap: fewer than 6% of registrations carry a discoverable card.

The next bar up is the discoverable /.well-known/agent-card.json the A2A protocol assumes on any registered agent. The signpost-gap dataset holds a daily snapshot of that predicate for every indexed (chain, agentId) row: an agent-card is present when the last probe of the advertised endpoint's /.well-known/agent-card.json returned an A2A-conformant JSON body. As of the latest snapshot, 1,524 of 25,695 indexed registrations (5.93%) publish a discoverable card at all, and 1,231 of 6,146 endpoint-live registrations (20.03%) do so — the intersection is the addressable A2A-handshake cohort. That is a small tightening against the 6.5% figure our 2026-08-16 signpost-gap post first published; the denominator grew by ~3.5% while the numerator did not scale proportionally, so the share fell.

The number to sit with here is not 5.93% — it is the chart-implied claim that 94% of registrations do not carry the signpost the A2A stack assumes is there. Any AP2 or A2A discovery client walking an ERC-8004 row is one hop away from an empty room, on the great majority of registrations, on both chains we index.

Live indexed: the paid product's read.

Our indexed profile store — the enriched, per-agent rows the paid /v1/intel/agent API serves — holds — entries across Base and Ethereum. The total-indexed count is — (— on Base, — on Ethereum). This is the “indexed registrations” number, not an agent count; it is what a discovery client that walks the registry and normalises the rows would see today. The number to shop by is further down.

Live — endpoint 2xx and a machine-readable capability surface declared (MCP, OpenAPI, or agent-card) — is — agents total. Per-chain live rate is —% on Base and —% on Ethereum, keeping the ordering Report 05 predicted: the smaller Ethereum cohort is cleaner per capita, Base carries the volume and the tail. Machine-readable capability surfaces indexed: — MCP tool descriptions from — agents, — OpenAPI methods from — agents, and — agents publishing /.well-known.

The readiness distribution — the four-bucket buyer-POV score we introduced in Report 02 — now covers — stamped agents. Current split:

• Transact-ready: — — reachable, capability surface declared, and either paid on-chain or advertising a working x402 handshake. These are the agents you can integrate with this afternoon.
• Promising: — — real signals present but at least one binding gap (usually no payment history yet, or an unresolved reputation flag).
• Not ready: — — unreachable endpoint, expired TLS, or clearly stale.
• Unrated: — — registered but not yet fully enriched by the pipeline.

The Transact-ready set remains a small share of the total, even after two months of continuous re-probing; that is not noise in the pipeline — it is the shape of the ecosystem. The chain-liveness dataset holds the daily per-chain cut of the same signal.

Identity: still the scarcest signal.

Of the — distinct owner wallets in the indexed store, only — resolve to a human-readable identity via ENS, Basenames, or Farcaster. The named ratio has moved little since Report 02 — naming is not scaling with registration. We continue to classify what we can: — owner contracts are verified on their block explorer, and — owners are plain externally-owned accounts. Owner identity is the single largest paid-intel upgrade over the free registry read.

Reputation and the got-paid cohort.

The ReputationRegistry (0x8004BAa1…19dE9b63) feedback indexer has now ingested — events covering — agents. The overwhelming share is on Base — that is where the registry was upgraded first and where the deep backfill ran; the Ethereum tail is a live-tail workload still queued behind an Alchemy quota budget, so read the reputation numbers as Base-heavy by construction, not as a claim about Ethereum activity.

The commerce-backed subset — ReputationRegistry rows the canonical commerce_backed.py predicate ties to a real, paid on-chain job outcome (ERC-8183 AgentCommerce hooks or the Virtuals ACP hosted equivalent) — remains a small set: — unique agents, — job-outcome events, from — distinct evaluator clients. The absolute count is small; the number that matters is the one below it. Any bulk-mint farm can pay a cent to mint a registration and a cent to post a five-star review of itself. It cannot produce a commerce-backed row without first actually paying an agent through a hook that settles on-chain, at which point it is a paying customer and the “farm” framing collapses. The gap between — agents with any feedback and — agents with commerce-backed feedback is the concentration pathology arXiv:2606.26028 (Imperial College) measures on the same registry, reported from our indexer with the filter applied. The commerce-backed-agents dataset holds the full cohort with the T1/T3 hook classification per row.

Solana: a different registry, reported separately.

Solana runs its own agent-registration program — QuantuLabs's 8004-solana (8oo4dC4JvBLwy5tGgiH3WwK4B9PWxL9Z4XjA2jzkQMbQ). It shares a name fragment with ERC-8004 and nothing else: different chain, different program, different account model, different semantics. It is not an ERC-8004 registry, and the “ERC-8004 on Solana” framing that has started appearing in secondary sources is a category error. Our 2 September 2026 census of that program's accounts, run against public Solana mainnet RPC and published verbatim as a snapshot to the Solana registry census page, found 1,477 raw registration accounts from 185 distinct creators, with the top-1 creator holding 22.07% of accounts, the top-10 holding 78.67%, and the top-20 holding 85.65%. 99.4% of accounts have a populated agent_uri field, but the census does not fetch any URI and therefore makes no resolvability claim about the Solana rows — a populated URI is a claim of intent, not a claim of a working card.

Report those figures alongside the Ethereum registry rows if you want, but not as Ethereum registry rows. Concentration this high (top-20 = 85.65%) is the shape of a registry a small number of publishers batch-minted into; anyone building trust on it should read the creator histogram, not the account total.

What did not change, and why that is a finding.

Three things stayed flat against Report 05. The named-identity ratio (owner wallets with an ENS / Basename / Farcaster tag) barely moved. The Transact-ready share stayed a small fraction of the indexed total. The commerce-backed cohort grew by a couple of agents at most, not a couple of orders of magnitude. In an ecosystem where the raw registration count is climbing steadily, those three flat lines are the finding: registration cost fell to a rounding error long enough ago that the tail is now the median, and every filter downstream of raw Transfer(from=0x0) counts is doing more work than it was two months ago.

The direction of travel from Report 01 through Report 05 to now — that the interesting number is a small, filtered, continuously-verified cohort rather than a large, decorative registration total — is the direction our paid product continues to bet on. Every headline count on this page reads live from our indexer; every predicate is a single canonical function with its source-of-truth path on the public datasets endpoint; and every number that is a sample or a frozen snapshot is stated as such in the section that carries it.

Report 05 asked what “operational readiness” looks like for one ERC-8004 agent. Report 12 answers the same question two months later at population scale: registered is cheap, signposted is scarcer, resolvable is scarcer still, and paid is the honest bar — and the four cohorts are not the same 44 agents even when they overlap. The full per-agent evidence for any specific (chain, agentId) is available live at /v1/intel/agent.