Agent Evidence — sample report, week of 2026-10-12

On-chain ERC-8004 registrations cross-checked against off-chain MCP endpoints, read-only. An Agent Trust Infrastructure project. Re-run weekly after the Trust Directory rescan. This run: 2026-10-12.

This report answers one question: does an on-chain ERC-8004 agent registration resolve to the MCP endpoint it claims, right now? This week we cross-checked 40 tokens (40 unique endpoints) read-only: 39 fully consistent, 1 partially consistent, 0 unverifiable. Anonymous handshake only, no tools invoked, every verdict carries a reason and a timestamp, and one open-source command re-runs any single check. This is evidence with limits, not a trust score.

Why this report exists

The ERC-8004 registry lists hundreds of thousands of on-chain agents and leaves reputation aggregation to third parties. What is missing is the boring part: does a registered identity resolve to a working endpoint, does the registration file still say what the chain says, and can an integrator check that before wiring an agent in. Each week we redraw a small sample and publish exactly what we could and could not verify, with reasons. This is not a trust score.

Five verdicts, strongest to weakest: fully consistent (registration declares the endpoint, clean anonymous MCP handshake succeeds), partially consistent (handshake started but did not complete cleanly, or declaration not independently confirmable), conflict (declared and observed facts disagree), unverifiable (endpoint exists but verification failed, reason stated), missing data (nothing declared to check). A record not being found is never treated as fraud.

Findings this week

Results, all 40 unique endpoints

Verdict distribution:

Method

• Sampling. Tokens pulled from the 8004scan explorer API, biased toward agents declaring MCP support plus active and top-scored cohorts, deduplicated to 40 unique MCP endpoints. Convenience sample, not random. Samples are re-drawn weekly.
• Declaration side. On-chain registration metadata, the registration file URI, and the declared MCP service entry. Registration files independently re-fetched and compared to the index cache.
• Observation side. Exactly two JSON-RPC requests per endpoint: initialize and tools/list via mcpreflight schema (MIT, zero dependencies). No tool invoked, no authentication attempted, no payment signed.
• Cross-match. All endpoints matched against the official MCP Registry scan by exact URL and host.
• Reproduce any row:

npx @eidonze/mcpreflight schema <endpoint-url>

Limitations (read this before quoting us)

• Anonymous checks only. 401 or 402 endpoints are unverifiable, not broken. HTTP 402 means x402 is working as designed.
• One point in time. Probes ran 2026-10-12 10:11 to 2026-10-12 10:12 UTC on 2026-10-12.
• No behavior beyond the handshake. No tool was invoked. Consistency means the declared endpoint speaks MCP and lists tools, nothing stronger.
• Index cache dependency. Registration content for unreachable files rests on 8004scan's cache and is marked accordingly.
• Ownership not resolved. We do not verify that the owner address controls the endpoint domain, so "fully consistent" does not mean "operator verified".
• Small, biased sample. 40 tokens is a sliver of the registry. Batch-minting numbers are arithmetic on this sample, not registry-wide estimates.
• 0 conflicts or 0 missing-data rows would be a property of the sample, not evidence that they do not exist.

What we would build next

This page is the v0 of a weekly loop: sample, verify, publish, diff an agent's declared self against its observed behavior over time. If you maintain an agent directory, a marketplace, or a workflow that consumes 8004 agents and pre-integration evidence would change a decision you make, we would like to hear from you — open an issue.