How we counted
One request per batch, 10,000,000-block windows, iterated against
https://arb1.arbitrum.io/rpc
(fallback arbitrum.gateway.tenderly.co)
from the ERC-8004 deploy block (428,895,443) to
head at run (512,646,051) — 83,750,609
blocks, 9 windows, 100% coverage. 228 RPC calls total; 0 errors;
0 backoffs. Deploy block was seeded from the 2026-09-17 four-chain
census because the public node is non-archive — but
eth_getLogs is index-based (not
state-based) and works globally, so the full-history scan is
complete. The input envelope is pinned at
SHA-256 2ce26378ad36a7ded274f9f60ccd6b360b0239e574f5bceac39961260ba1554b.
The method is described below, and every figure matches a field in
summary.json.
Finding 1 — 1,604 agent IDs from 1,000 distinct owners.
The ERC-8004 IdentityRegistry on Arbitrum One has emitted
1,604 Transfer(from=0x0)
events across its full history.
Decoding the to-address of each
mint yields 1,000 distinct owners.
That is 1.604 mints per distinct owner, a lower concentration
than Base (3.02 per owner). The Arbitrum cohort has a broader
operator base than its raw size suggests.
Finding 2 — Top-1 owner holds 17.02% of mints; top-10 hold 31.61%.
0xad7d4d39…ee721 accounts
for 273 of the 1,604 mints — 17.02%
on its own
(identity_registrations.top1_share_pct).
The top ten owners together hold 31.61%
(top10_share_pct). This is real concentration, but not single-vendor: the top Arbitrum owner holds 273 mints. The long tail
(~990 owners sharing ~68.4% of mints) is a wider operator
population than Arbitrum’s prior public measurements had
on record.
Finding 3 — 108 agents received on-chain reputation feedback from 36 clients across 973 events.
A full-history scan of the Arbitrum One ReputationRegistry
(0x8004BAa17C55a88189AE136b182e5fdA19dE9b63)
pulls 973 NewFeedback events
from 36 distinct client addresses to
108 distinct feedback-receiving agents.
This is a full-cohort full-history count — not a
sample and not an extrapolation. 108 of 1,604 registered
agents (6.73%) carry at least one on-chain reputation signal
attached to their agent id.
Finding 4 — The HTTP-live rate on a 200-sample is 0%. That is not an agent-dead signal.
We drew a 200-of-1,604 evenly-spaced-by-agent-id sample
(tokenuri_sample.sample_strategy
= evenly_spaced_by_agent_id,
sample_cap = 200). 198 of 200
agents (99.0%) return a tokenURI();
44 (22.0%) resolve to parseable JSON metadata;
40 (20.0%) carry service, capability,
x402Support, or
payment signal. A single-GET
5-second probe on the first HTTP(S) endpoint in resolved metadata
returned a 2xx/3xx/4xx on 0 of 200 agents.
The 0% is a HTTP-reachability measurement on the first
endpoint of a sampled agent — it is NOT an agent-liveness
rate. Many Arbitrum agents publish ENS, .eth,
.arb, or .agent
names in their endpoint field (clawnews.io,
vitalik.arb, z.agent,
web3smart53.agent, sparkmind31.agent
all show up in the sample clusters) rather than resolvable
HTTP(S) URLs, and the probe does not resolve those name-service
references. On Arbitrum, the stronger live signal is the 108
agents receiving on-chain feedback (above), not an HTTP probe.
A proper liveness rate for the Arbitrum cohort would require
full endpoint enumeration and name-service resolution; that is
a separate measurement we have not yet published.
Finding 5 — +6.79% over the 2026-09-17 freeze.
The prior four-chain 2026-09-17 census (Alchemy archive) recorded 1,502 registrations at head block 505,982,474. Twenty days later, on a public (non-archive) RPC and over 83,750,609 blocks of coverage, this measurement records 1,604 — a +6.79% cohort growth over the window. Deploy block matches (428,895,443). The two reads also count “distinct addresses” differently: the earlier one counted the addresses that sent registration transactions, this one counts the addresses that own the minted agent IDs, so those two address counts are not comparable. The change in registrations (1,502 to 1,604) is the like-for-like comparison.
What this means — and what it doesn’t.
Registration is not liveness. 1,604 agent IDs exist on the Arbitrum One IdentityRegistry; 44 of a 200-sample resolve to parseable agent metadata, 0 of 200 answer a single HTTP GET on their first endpoint, and 108 of the whole cohort have on-chain reputation feedback. A buyer-side agent on Arbitrum evaluating these services has to answer three separate questions — is it registered, does the agent card resolve, has anyone ever written feedback for it — and the registry mint only addresses the first. Base and Ethereum have the same three-layer structure (see our State of ERC-8004 report); Arbitrum’s version of it skews heavier on reputation-but-not-HTTP-probable than Base’s does, because of the name-service endpoint pattern Finding 4 names.
Arbitrum is measured here, not indexed by the paid API.
This is a measurement, not a statement that
/v1/intel/* now
covers Arbitrum. The two chains the
paid API does cover are Base and Ethereum, and that has not changed.
Reproducing this report
Every number above is a named key in
summary.json.
The headline aggregates are also exported to
dataset.csv
and the schema.org Dataset metadata is at
dataset.jsonld.
The method and the input envelope hash are published in
METHOD.md.
No API key is needed and no on-chain state is modified. The
measurement uses the public RPC
https://arb1.arbitrum.io/rpc
with arbitrum.gateway.tenderly.co
as a documented fallback.
Limitations
- Starting block was taken from an earlier census, not derived on-chain. Verifying it independently needs an archive node.
-
HTTP liveness probe is first-endpoint only.
Agents publishing multiple endpoints with the first one being
an ENS/
.agentname are counted as 0 in the HTTP-live cut even if a later endpoint would have answered. - Distinct-owner is a lower bound on operator identity. Owners who transferred an agent-id post-mint would show up as two separate addresses; this cut does not deduplicate.
-
No confidence intervals on the sample. The
200-of-1,604 tokenURI sample is published as point estimates;
Wilson CI95 bounds like those on the earlier census are not published here. Readers extrapolating from
the sample rates to the whole cohort should treat the
extrapolated_fields as point reads with sample noise.