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 committed 0656 four-chain
freeze 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.
Every headline number below derives from a named key in
summary.json;
the parenthetical citations point at the key path. Full method is in
METHOD.md.
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
(identity_registrations.distinct_agent_ids).
Decoding the to-address of each
mint yields 1,000 distinct owners
(identity_registrations.distinct_owners).
The ratio — 1.604 mints per distinct owner — is lower
than Base (3.02×) and far lower than BNB’s historical mass-
mint regimes. Arbitrum’s cohort is wider at the 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 — and
unlike BNB’s historical top-1 shares (which pulled 10,000+
mints into one address through batch-mint factories), the top
Arbitrum owner holds 273 mints, not 20,000. 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
(reputation_feedback.feedback_events)
from 36 distinct client addresses
(distinct_feedback_clients) to
108 distinct feedback-receiving agents
(distinct_feedback_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. For reference, the paid-API chain-
stats surface reports agents_with_reputation
= 29,128 on Base and 0 on Ethereum (ETH indexer paused per the
project memory); these are different cohorts and no ratio claim
is made.
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
(task 0656, 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
(prior_measurement_delta.registrations_delta_pct).
Deploy block matches (428,895,443). The ~7× jump in
distinct-sender vs. distinct-owner between the two reads is a
definition change (0656 published distinct tx.from;
0772 publishes distinct Transfer to),
not a cohort change.
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 Report 12); 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.
The source envelope’s verdict — ADD_ARBITRUM(live=108)
— is an input to a future indexer-wiring decision, not a
statement that /v1/intel/* now
covers Arbitrum. Any future expansion is gated on a separate
propose-first decision (new RPC provisioning, scanner wiring,
reconciliation against this measurement). The two chains the
paid API does cover are Base and Ethereum, and that has not
changed in this task.
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 measurement script is at scripts/analysis/0772_arbitrum_public_rpc_census.py
in the repo. One command:
python3 scripts/analysis/0772_arbitrum_public_rpc_census.py
No API key is needed. No on-chain state is modified. Expected
wall-clock: ~40 seconds. The script uses the public RPC
https://arb1.arbitrum.io/rpc
with arbitrum.gateway.tenderly.co
as a documented fallback.
Limitations
-
Deploy block was seeded, not derived. The
public node is non-archive and
eth_getCodeat the deploy block is pruned; the deploy block was taken from the committed 0656 freeze. The deploy-block match against the 0656 freeze is true, but a reader who does not trust the 0656 freeze will need an archive RPC to verify the deploy-block seed independently. -
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 the four-chain census carries on its
BNB rows 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.