How to Look Up an AI Agent's On-Chain Identity and Reputation (ERC-8004 Walkthrough)

Knowing that ERC-8004 defines an Identity Registry and a Reputation Registry is one thing. Actually reading them — for a real agent, on a real network — is another. This is a hands-on walkthrough using agents that are genuinely registered on-chain right now, so every example here is real data, not a hypothetical schema.

What You Need

Nothing, really. Every call below is a read-only eth_call against a public RPC endpoint — no wallet, no gas, no signup. The Identity and Reputation registries deploy at the same address on every EVM chain the standard supports (Ethereum, Base, Arbitrum, Polygon, Avalanche, BNB Chain, plus Base Sepolia for testing), so the contract address doesn't change — only which network's RPC you point at.

Step 1: Get an Agent ID

Unlike a domain name or a username, there's no public directory to browse ERC-8004 agents by name — the Identity Registry isn't ERC-721-Enumerable, so there's no on-chain way to list "all agents" or "all agents owned by address X" without an indexer. In practice this means: you need an agent ID handed to you (by the agent's operator, in its documentation, or from a service that publishes one), not discovered by browsing.

For this walkthrough, agent ID 1 is registered on every network above, so it works as a fallback if you don't have a specific ID in hand.

Step 2: Read the Identity Registry

The Identity Registry is an ERC-721 contract, so its interesting reads are all standard NFT calls: ownerOf(agentId), plus the ERC-8004-specific getAgentWallet(agentId) and tokenURI(agentId).

Looking up agent 1 on Ethereum mainnet:

{
  "owner": "0x9ce7082814bda389f3ba548bdf2626006279569c",
  "agentWallet": "0x9ce7082814bda389f3ba548bdf2626006279569c"
}

owner is who controls the NFT (can transfer it, update its URI). agentWallet is a separate, optional field an owner can set — in principle these can differ, letting an operator hold custody of the identity while a different wallet handles the agent's actual transactions. A revert on ownerOf for a given ID just means that agent isn't registered on the network you asked — not an error, just a "not found."

Step 3: Decode tokenURI — It's Not Always a URL

This is the step most walkthroughs gloss over, and it's where a naive implementation breaks. tokenURI can point to:

• An http(s) URL you fetch normally.
• An ipfs:// URI requiring a gateway.
• A data: URI — the metadata JSON embedded directly in the string, base64-encoded, no network request needed at all.

Agent ID 13 on Base Sepolia is a good example of the third case. Its raw tokenURI looks like an unreadable wall of base64:

data:application/json;base64,ewogICJ0eXBlIjogImh0dHBzOi8vZWlwcy5ldGhlcmV1bS5vcmcv...

Decode the base64 and it's a complete, human-readable registration document:

{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "Corgent - Cortensor Agent",
  "description": "Corgent is an ERC-8004-native trust and execution agent that acts as a shared oracle for AI agents in the 8004 ecosystem. Instead of blindly trusting a single model run, ERC-8004 agents send Corgent their task + context (and optionally a claimed result). Corgent re-runs or cross-checks the work on the Cortensor decentralized AI network, then returns simple machine-readable signals: VALID / INVALID / RETRY / NEEDS_SPEC.",
  "image": "https://blob.8004scan.app/...",
  "active": true,
  "x402support": true
}

That's a real, purpose-built agent: an independent verification oracle other ERC-8004 agents can send work to for cross-checking, rather than trusting a single model's output blindly — and it advertises x402support, meaning it expects to be paid for that verification work via the payment protocol covered elsewhere on this blog.

The practical lesson: treat data: URIs as free — no request, no SSRF surface, just a base64 decode — and don't assume tokenURI is always a link you need to fetch.

Step 4: Read the Reputation Registry

Two calls cover most of what you need: getClients(agentId) returns the addresses that have given feedback, and getSummary(agentId, clients, tag1, tag2) returns an aggregate (count, value, valueDecimals) across them.

Agent 1 on Ethereum has 2 clients and an aggregate summary of count: 6, value: 51, valueDecimals: 0 — 6 feedback entries totaling a score of 51 on whatever scale the feedback-givers used (the standard doesn't mandate a fixed scale; valueDecimals just tells you how to interpret the raw integer). A full per-entry feedback list (readAllFeedback) exists too, but its return shape — seven parallel arrays, two of them arrays of strings — is genuinely awkward to decode by hand; the aggregate summary plus client list covers the "does this agent have real feedback, and roughly how much" question most lookups actually need.

What This Data Doesn't Tell You

Worth being explicit about the limits, since it's easy to over-read a reputation number:

• Reputation is self-reported by whoever gave it — it's a signal, not a certification. A small number of feedback entries from related parties isn't the same as broad, independent trust.
• active: true in metadata is a claim, not a guarantee — nothing on-chain enforces that a registered agent is actually running or reachable right now.
• No ValidationRegistry data is covered here — the standard defines a third registry for independent validator attestations, but no canonical contract address for it is published anywhere in the reference implementation as of this writing, so it's not something you can reliably read yet.

Try It Without Writing the eth_calls Yourself

Every step above — resolving the network, calling ownerOf/getAgentWallet/tokenURI, decoding data: URIs, reading getClients/getSummary — is exactly what the ERC-8004 Inspector does when you paste in an agent ID. It's free, live (not indexed or cached), and covers Ethereum, Base, Base Sepolia, Arbitrum, Polygon, Avalanche, and BNB Chain. Agent 1 works as a live example on every one of those networks, and agent 13 on Base Sepolia is the Corgent example from this post — a good one to try if you want to see what a fully-populated identity looks like rather than a bare registration.