ERC-8004 is an Ethereum standard for on-chain AI agent identity. Each agent is minted as an NFT in an IdentityRegistry contract; the tokenURI points at metadata that describes the agent's name, capabilities, service endpoint, and payment options. A companion ReputationRegistry lets clients emit signed feedback events after a job. The standard is deployed on Ethereum mainnet, Base, and BNB Chain (BSC), with a fork-compatible BRC-8004 registry on BNB.

How do I check an ERC-8004 agent's on-chain identity?

Look up the agent's agentId in the IdentityRegistry on its home chain, read tokenURI to fetch the metadata document, then resolve the owner. A named owner (ENS, Basename, Farcaster) or a block-explorer-verified deployer contract is a stronger signal than a bare externally-owned wallet — most registered agents currently do not resolve to a human-readable identity.

What does the ERC-8004 ReputationRegistry actually tell me?

The ReputationRegistry stores feedback events emitted by clients after paid interactions. Each event references a job and a rating. Raw counts are easy to game with self-issued reviews, so any usable reputation score must Sybil-adjust by unique client wallets and by how concentrated the feedback is — a single client posting hundreds of five-star ratings for its own agent should not dominate. Adoption is currently uneven: feedback on Base is dense, on Ethereum and BNB much thinner.

Is x402 payment support enough to trust an agent?

No. Advertising x402 in a 402 discovery response is table stakes; the agent still has to be reachable, quote current pricing, and actually settle a payment on-chain. Many agents advertise x402 without ever having received an on-chain payment. Cross-check the payment discovery response against an inbound-transfer index on the same chain before wiring real money to it.

Do I need to check every chain, or just one?

Check every chain the agent operates on. ERC-8004 agents can register on Ethereum mainnet, Base, and BNB Chain (via the BRC-8004 fork). Some agents are single-chain by design; others advertise the same endpoint from multiple registrations. A directory that only covers Base or Ethereum misses the majority of the population — BNB Chain currently holds the largest share of registered agents by a wide margin.

How to Verify an ERC-8004 Agent Before You Trust It

A practical checklist for developers and integrators: the on-chain identity, reputation-registry, payment, and liveness signals that tell you whether an ERC-8004 AI agent is safe to integrate with — and pay.

Headline counts on this page are pulled live from our public index and update continuously — the methodology below applies to the entire ERC-8004 agent population as it exists right now, not a frozen snapshot.

ERC-8004 turned AI agents into first-class on-chain citizens: each agent is an NFT in an IdentityRegistry, with metadata describing its capabilities, its service endpoint, and how to pay for it. That is a huge gain for machine-to-machine discovery. It is not a trust signal on its own — anyone can mint an agent, point it at any endpoint, and claim any capability. The registry says the agent exists. It does not say it works, that the endpoint is live, that the owner is who they claim to be, or that you should route a paying job to it.

This guide is the checklist we run — on every one of the 93,495 ERC-8004 agents currently in our index across Base, Ethereum mainnet, and BNB Chain — to separate real, usable agents from paper registrations. It is deliberately vendor-neutral: the same six checks work whether you use our API, roll your own indexer, or do it by hand off a block explorer. At the bottom we point at where we make each of these checks cheap to run.

1. Confirm on-chain identity in the IdentityRegistry

Start at the IdentityRegistry contract on the agent's home chain. Look up the agentId, read tokenURI(agentId), and fetch the metadata document (a data: URI, IPFS CID, or HTTPS URL). Verify that:

The agentId actually resolves — a Transfer event from the zero address at mint is enough to prove the registration exists.
The metadata document is well-formed JSON with a serviceEndpoint (or equivalent) and the capabilities it advertises.
The owner returned by ownerOf(agentId) is one you can meaningfully evaluate — see check 2.

The registry addresses are the same across every EVM chain that supports the standard: 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 for the IdentityRegistry, and 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63 for the ReputationRegistry. BNB Chain also runs a fork-compatible BRC-8004 registry at 0xfA09B3397fAC75424422C4D28b1729E3D4f659D7.

2. Resolve the owner — named, contract, or bare wallet

Not all owners are equal. Of the 53,145 distinct owner wallets across the index, only 1,169 resolve to a human-readable identity through ENS, Basenames, or Farcaster. That is a small minority — pseudonymity is the default in this ecosystem, so treat a named owner as a bonus signal, not a required one.

More important: is the owner an externally-owned wallet or a contract? We currently see 129 agents owned by plain externally-owned accounts, and 12,597 owners that are explorer-verified deployer contracts. A verified deployer contract means the source is public on the block explorer — you can read it, and so can anyone else. An unverified contract, or a bare wallet with no ENS record and no on-chain history, is a much weaker story. Neither is disqualifying on its own, but treat opaque ownership as one signal to weigh against the rest of the checklist.

3. Read the ReputationRegistry — with a Sybil-adjustment

The ERC-8004 ReputationRegistry stores signed feedback events emitted by clients after paid interactions. It is the first on-chain data point that distinguishes an agent that is used from an agent that is merely registered. Our index has ingested 277,710 feedback events across 29,128 agents so far.

Raw counts are trivially gamed with self-issued reviews. A usable reputation signal has to Sybil-adjust for:

Unique-client concentration. Ten five-star reviews from ten different wallets are far stronger than a hundred from one wallet — feedback density matters much less than client diversity.
Job-value plausibility. Feedback attached to jobs that never actually settled a payment is essentially unsigned; treat it as noise.
Chain skew. The ReputationRegistry was deployed on Base first and adoption on Ethereum mainnet and BNB has been slower. The absence of feedback on a BNB-only agent is not the same signal as the absence of feedback on a Base agent — one is expected, the other is a red flag.

A single Sybil-adjusted score, on a normalized 0–100 scale with a confidence label (low / medium / high), is the shape we've found most useful. Below that composite the raw feedback_count and unique_clients counts should still be visible — a buyer should be able to sanity-check the score.

4. Verify payment support — x402 plus settlement history

ERC-8004 doesn't mandate a payment protocol, but the ecosystem has largely settled on x402: the agent returns an HTTP 402 with a discovery body describing accepted assets, prices, and settlement wallets. Two independent checks:

Does the endpoint speak x402? Hit it with an unauthenticated request. A 402 with a well-formed discovery response is the entry cost. No 402, no auto-integration.
Has the settlement wallet ever received a payment? Index inbound transfers to the settlement wallet on the agent's home chain. An agent that advertises x402 but has zero inbound settlement history is unproven — it might be new, or it might be non-functional. An agent that has received on-chain payments is one that someone, somewhere, has already trusted with real money.

Both signals should be checked; either alone is a partial picture.

5. Cross-chain presence and coverage

ERC-8004 agents live on 19,137 agents on Base, 1,825 on Ethereum mainnet, and 72,533 on BNB Chain (via the BRC-8004 fork). BNB Chain currently holds the largest share of registered agents by a wide margin, so any directory that only covers Base or Ethereum is seeing a small slice of the actual population.

For verification purposes: check every chain the agent claims to operate on. Some agents are single-chain by design; others advertise the same off-chain endpoint from multiple on-chain registrations. When the same endpoint appears on multiple chains, the on-chain identity with the strongest signals (verified owner, reputation feedback, payment history) is the one to lean on.

6. Probe for liveness — reachability, TLS, and freshness

The registry is on-chain. The agent isn't. Every check above is upstream of a much simpler failure mode: the endpoint is dead. Endpoint churn in this ecosystem is real — a top-N list from a month ago will already contain agents whose service URLs no longer respond. Before you route a paying job to an agent, confirm:

Reachable. The advertised serviceEndpoint returns a real HTTP status (not a connection refused, not a DNS failure), within a reasonable response time.
TLS valid. The certificate hasn't expired and matches the hostname. Expired TLS on an agent that also claims to take payment is not a signal you want to overlook.
Freshly probed. The verdict you're reading is from within the last few hours, not from an index that was refreshed once at launch and never re-checked. Reachability moves.
Capability manifest present. An MCP tools list, an OpenAPI schema, or a /.well-known/agent.json tells you what the agent will actually accept as a job — not just what its on-chain metadata claims.

Putting it together: the readiness composite

Any single check above is defeasible. A named owner without payment history is just a bio. Payment history without live reachability is a graveyard. Reputation feedback on an unreachable endpoint is history. The verdict a buyer actually wants is a composite: identity and reputation and payment and liveness, weighted by confidence and freshness, expressed as one score they can act on.

That composite is what our AI Verdict block computes on every paid /v1/intel/agent response — you can read the exact factor weights and the Sybil-adjustment methodology in the API docs. But the same shape works if you build it yourself: emit each of the six signals with a confidence label, roll them into a bucketed verdict (Transact-ready, Promising, Not ready), and expose the raw signals so your consumers can second-guess the composite when they need to.

The short version

Identity in the IdentityRegistry — proves the agent exists.
Owner resolution — named / verified contract / bare wallet.
ReputationRegistry feedback — Sybil-adjusted, not raw.
x402 plus on-chain settlement history — both, not either.
Cross-chain: check every chain the agent claims (Base, Ethereum, BNB).
Liveness: reachable, TLS-valid, freshly probed, manifest present.

If all six clear, integrate. If any fail, either fix the gap with the agent's operator or don't route paying jobs through it. The gap between "registered on-chain" and "safe to pay today" is enormous — closing it is what verification actually means in this ecosystem.