Documentation · How-to

How do I verify an ERC-8004 agent before I pay it?

Five checks, in order: confirm the agent’s registration on the IdentityRegistry, probe its endpoint, read the x402 402 challenge and its payTo address, look at on-chain payment activity, and read reputation feedback with caution. The first four need no wallet and no funds. None of them guarantees an agent will deliver; they reduce the chance of paying something that does not work. Current ecosystem figures are on the stats page.

The checklist

  1. Registry. The agentId exists on the IdentityRegistry and its registration document names a service endpoint and an owner you expect.
  2. Endpoint. The listed host resolves, has a valid TLS certificate and answers HTTP.
  3. 402 and payTo. The paid route answers 402 with a well-formed challenge, and the payTo address is one you can tie to the seller.
  4. Payments. The payTo address shows incoming transfers consistent with an agent that has been used.
  5. Reputation. Any feedback recorded for the agentId is read for who left it and how much there is.

A failure at any step is a reason to stop or to start with a very small payment, not a verdict on its own. This page is the buyer’s sequence; the two detail pages reachable and payable and x402 endpoint checklist go deeper on steps 1–3.

1. Look up the agentId on the IdentityRegistry

Find the agent’s numeric agentId and chain, then call tokenURI(agentId) on the IdentityRegistry for that chain (addresses are in ERC-8004 explained) and fetch the registration document it points to. Check that:

  • the document is valid JSON and lists at least one service endpoint;
  • the endpoint host matches the project you think you are paying;
  • the registry’s ownerOf(agentId) is an address you can connect to that project (ENS name, a verified contract, the project’s own site linking back).

Registration is self-asserted. It shows an identity was minted, not that the operator is who the document says.

2. Probe the endpoint

Request each listed endpoint with no payment header:

curl -i https://example.com/the/listed/endpoint

You want the host to resolve, TLS to validate, and any HTTP response to come back. A 401, 402 or 403 still means a live server. Timeouts, certificate errors and DNS failures mean you cannot reach the agent at all. Details and failure signs: reachable and payable.

3. Read the x402 402 challenge and the payTo address

Call the paid route as documented, still without paying. A working x402 endpoint answers 402 with an accepts array. For each entry, check:

  • payTo is a well-formed address. Compare it with the owner from step 1 and with any address the project publishes; a payTo that matches nothing public is a question to ask before paying.
  • asset and network are what you intend to spend (for example USDC on Base) and the amount is a plausible per-call price.
  • The body parses with the x402 client you plan to use. v1 and v2 bodies differ; see the x402 endpoint checklist.

A 402 shows the seller can describe a price. It does not show that settlement or delivery will work.

4. Check on-chain payment activity

Open the payTo address on a block explorer for the relevant chain and look at incoming USDC and ETH transfers. Useful questions: are there incoming payments from many unrelated wallets, or only a handful from the same few? Is the history recent? Does an address that has never received anything claim to be a busy seller? Activity is a weak positive signal, because payments can be self-funded; absence is not proof of a problem for a new agent.

5. Read reputation feedback, with caution

The ReputationRegistry records feedback that other addresses submit about an agentId. Read what is there and by whom: a few entries from addresses with no other history, or all from related wallets, is weak evidence either way, since feedback can be created cheaply. No feedback at all is common for new agents and is not itself a red flag. See ERC-8004 explained for the registry’s role.

Worked example with our free endpoints

Our free public lookup returns the observable signals for an indexed agent in one call, covering parts of steps 2 to 4: host reachability and HTTP status, TLS validity, advertised x402 support, and whether any on-chain payment has been received. Example, for any indexed agent (here agentId 19353 on Base): 

curl https://api.onchainagentintel.io/v1/public/agent/base/19353

Read status_label (our one-line summary) and the objective_signals block (reachability, TLS, x402 support, payments seen), and check last_indexed_at: the response reflects our most recent probe, not the present moment. If it is more than a few days old, treat the signals as dated. Then repeat steps 1 and 3 yourself against the chain. The same data is available to MCP clients through our free read-only server at https://api.onchainagentintel.io/mcp (for example the get_agent_summary tool, with chain and agent_id arguments); see MCP explained. Our response is a second opinion to compare with your own checks, not a substitute for them.

What our free lookup includes

  • Free, no payment or login: the public agent summary above, the public stats, the leaderboard, and the published datasets. Payment status is a yes/no flag.
  • Paid: the full profile (owner identity, endpoint data, exact payment amounts, the readiness score with its reasons) and search, trend and graph endpoints. The catalog, with current prices and payment options, is in agent.json and the docs; the scoring rules are published at readiness methodology.

You do not need anything paid to run the five checks above.

What this doesn’t prove

Passing all five checks shows an agent is registered, reachable, quotes a coherent price and has some history. It does not show that it is safe, that a payment will settle, that the response will be correct, or that the operator will behave the same tomorrow. Pay a small amount from a dedicated wallet first and read every offer before you sign it.