{"slug": "claimed-vs-verified-what-erc-8004-agent-identity-evidence-actually-proves-before", "title": "Claimed vs Verified: What ERC-8004 Agent Identity Evidence Actually Proves Before an x402 Payment", "summary": "ContextIQ's Policy Check and ERC-8004 Inspector tools label every agent identity signal as either \"verified\" or \"claimed,\" separating on-chain evidence from self-declared metadata before an agent signs an x402 payment. The agent wallet is read authoritatively from the ERC-8004 Identity Registry's getAgentWallet(agentId) call, which returns one of four statuses — verified, zero_address, missing, or unknown — while ENS, DID, email and web entries in registration files are reported as claimed linkage with weak weight. ContextIQ warns that minting an agent ID costs only gas and registration files are self-authored, so an identity check that only confirms a registration, wallet and filled-in metadata file mostly measures effort to look legitimate.", "body_md": "# Claimed vs Verified: What ERC-8004 Agent Identity Evidence Actually Proves Before an x402 Payment\n\nWhat ERC-8004 agent identity evidence proves: on-chain getAgentWallet, ENS/DID/email linkage claimed vs verified, and .well-known ownership, before an x402 payment.\n\nAn ERC-8004 registration answers one question: *did someone mint an agent identity?* It doesn't answer the question an agent about to sign an x402 payment actually has: *is the party behind this endpoint who they say they are?* Those are different claims with different evidence, and a scoring system that blurs them hands out trust it hasn't earned.\n\nThis post describes how ContextIQ's [Policy Check](https://contextiq.trango-compute.com/policy-check) and [ERC-8004 Inspector](https://contextiq.trango-compute.com/erc8004-inspector) keep them apart. Every identity signal is labelled **verified** or **claimed**, and endpoint ownership is checked against the domain itself. If you're new to the standard, start with [What Is ERC-8004?](https://contextiq.trango-compute.com/blog/what-is-erc-8004-ethereum-trustless-ai-agent-identity).\n\n## The Problem: Registration Is Cheap\n\nMinting an agent ID on the ERC-8004 Identity Registry costs gas and nothing else. The registration file the token points to is self-authored: the registrant chooses the `name`, the `services`, and whether to list an ENS name, a DID, or an email address. Anyone can list `research-agent.eth` without owning it.\n\nSo an identity check that only asks \"is there a registration, a wallet and a filled-in metadata file?\" mostly measures *effort to look legitimate*. It rewards all of it whether or not any of it was independently checked.\n\nThe fix isn't to distrust everything. It's to record, for each signal, *who vouches for it*.\n\n## Three Kinds of Evidence\n\n### 1. Agent wallet: authoritative, read from the chain\n\nThe payment wallet comes from the Identity Registry's `getAgentWallet(agentId)`, not from the registration file. The EIP states that `agentWallet` is reserved, can't be set through `setMetadata()`, and is automatically cleared when the agent NFT is transferred, so the new owner must re-verify it.\n\nThat last property matters: a wallet that was valid for the previous owner can't silently carry over. The Inspector reports exactly what the call returned:\n\n| `agentWalletEvidence.status` | Meaning | \n|---|---|\n| `verified` | `getAgentWallet` returned a non-zero address (`isAuthoritative: true` ) | \n| `zero_address` | The call succeeded and returned `0x000…` — no wallet set, or cleared by a transfer | \n| `missing` | The call reverted | \n| `unknown` | The RPC request itself failed, so the chain was never actually asked ( `isAuthoritative: false` ) | \n\nThe `unknown` case is the one that's easy to get wrong. Treating a failed RPC call as \"no wallet\" would penalize an agent for an infrastructure hiccup.\n\nPolicy Check also uses the wallet as a cross-check. The `agentId` you supply identifies the agent being *paid*, the seller behind the endpoint, so the wallet is compared with the address the 402 challenge actually asks you to pay. An endpoint could otherwise present a legitimate agent's identity while requesting payment to an unrelated address. A mismatch is surfaced as a warning rather than a block, since a treasury address or a payment splitter is a legitimate reason for it.\n\n### 2. Human linkage: declared is not verified\n\nRegistration files commonly declare `ENS`, `DID`, `email` and `web` entries under `services` (older files used `endpoints`; both are read). ContextIQ parses these and reports them as:\n\n```\n{\n  \"humanLinkage\": {\n    \"status\": \"claimed\",\n    \"confidence\": \"medium\",\n    \"sources\": [\n      { \"type\": \"ENS\", \"value\": \"research-agent.eth\", \"verification\": \"declared\", \"weight\": \"weak\" },\n      { \"type\": \"DID\", \"value\": \"did:web:research-agent.example\", \"verification\": \"declared\", \"weight\": \"weak\" }\n    ],\n    \"summary\": \"Agent declares ENS and DID, but no external proof-of-human signal was verified.\"\n  }\n}\n```\n\nThe rules are deliberately strict:\n\n- ENS, DID, email and web values are **claimed** linkage. We don't resolve the ENS name or the DID document, so they stay`declared` .\n- Confidence is `low` for one declared type and`medium` for two or more. It never reaches`high` from self-declared data.\n- `externally_verified` is reserved for evidence that is actually checked: a World ID or Self proof, an Icebreaker credential, or an EAS attestation.**No verifier exists yet, so nothing emits that status today.** The type is in the response so the shape won't change when one ships.\n- Malformed values (an \"ENS\" entry that isn't a `.eth` name, a \"DID\" without a`did:` prefix) are ignored rather than counted.\n\n### 3. Endpoint ownership: the domain vouches for the agent\n\nThe ERC-8004 spec defines an endpoint domain verification file. A domain that serves an agent's endpoint publishes `https://{endpoint-domain}/.well-known/agent-registration.json`:\n\n```\n{\n  \"registrations\": [\n    {\n      \"agentId\": 22,\n      \"agentRegistry\": \"eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432\"\n    }\n  ]\n}\n```\n\nOnly whoever controls the domain can serve that file, so a matching entry ties the on-chain agent to the party operating the endpoint. Policy Check fetches it from the endpoint's own origin (SSRF-guarded) and returns one of four results:\n\n| `endpointOwnershipEvidence.status` | When | \n|---|---|\n| `verified` | The file lists this `agentId` on this registry | \n| `mismatch` | The file lists *other* agents on this registry but not this one | \n| `unverified` | No file, unreadable file, redirect to another domain, or the agent appears only on a different chain | \n| `not_checked` | No endpoint to check | \n\nTwo details are worth stating. A missing or unreachable file is `unverified`, never `mismatch`: a domain that doesn't publish the file isn't contradicting anything. And a redirect to a different domain is ignored, since otherwise a third party could vouch for the endpoint. A `tokenURI` hosted on the same domain is noted as corroboration but doesn't count as verification, because the registrant can point the URI anywhere.\n\n## How the Evidence Feeds the Decision\n\nPolicy Check combines two kinds of input into one pre-payment decision: checks on the x402 endpoint's 402 challenge, and, when you supply an `agentId`, the evidence about the agent behind it. Each check is reported by name in the `reasons` list, so a decision can be traced to what produced it.\n\nA few properties are worth stating:\n\n- **Verified evidence counts for more than claimed evidence.** A self-declared ENS name or email is credited far less than an on-chain read or a domain-published registration, and unverified proof-of-human signals earn nothing.\n- **Hard failures still block.** A malformed challenge, an unreachable endpoint, or an agent ID that isn't registered blocks the payment regardless of how strong the identity evidence is.\n- **Weak identity behind a valid payment is a warning, not a block.** Whether an unproven agent is acceptable is the caller's judgment, so Policy Check says \"look closer\" rather than deciding for them.\n- **Mismatches are surfaced as warnings.** If the endpoint's domain vouches for a different agent than the one you supplied, or the challenge pays an address that isn't the agent's own wallet, the agent and the endpoint may not belong together. That is a strong signal rather than proof of fraud.\n- **No `agentId` means identity isn't evaluated.** The response says`not_evaluated` instead of substituting a default agent, and only the payment checks run.\n\nThe weighting behind these checks is not published and may change between releases. Treat the decision and the per-check reasons as the interface, and apply your own policy on top.\n\n## What Changes in the API Response\n\nThe request is untouched: `{ \"endpoint\", \"agentId\"?, \"network\"? }`. The response gains fields, and `reasons` keeps its shape.\n\n```\n{\n  \"decision\": \"allow\",\n  \"rubricVersion\": 2,\n  \"trustEvidence\": {\n    \"agentWallet\":       { \"status\": \"verified\" },\n    \"humanLinkage\":      { \"status\": \"claimed\", \"confidence\": \"medium\" },\n    \"endpointOwnership\": { \"status\": \"unverified\" },\n    \"payTo\":             { \"status\": \"matches\" }\n  }\n}\n```\n\n- `trustEvidence` summarizes each dimension, and reads`not_evaluated` when no`agentId` was supplied.\n- `reasons` gains checks for human linkage, endpoint ownership and the payment address, and`agent_wallet_set` is now`agent_wallet_verified` .\n- `rubricVersion` records which scoring version produced a result, so a stored decision can be read against the right one.\n- The ERC-8004 Inspector response adds `agentWalletEvidence` ,`humanLinkage` ,`endpointOwnershipEvidence` and`trustEvidenceSummary` .\n\nIn the UI, each signal carries one of these labels: **Verified**, **Claimed**, **Unverified**, **Missing** or **Mismatch**, plus **Not evaluated** when nothing was checked. \"Claimed\" is a different color from \"Verified\" on purpose.\n\n## What This Doesn't Prove\n\n- **Ownership isn't personhood.** A verified`.well-known` file shows the endpoint's operator registered the agent. It says nothing about whether that operator is a person, a company, or a bot.\n- **ENS and DID aren't resolved.** Claimed means claimed. Resolving and verifying them, and checking EAS, Icebreaker, World ID or Self proofs, is where`externally_verified` would come from.\n- **DNS races remain.** The runtime resolves DNS itself, so a record could change between the safety check and the fetch. Checks and redirect re-validation reduce this but can't pin the IP.\n- **It's a signal, not a verdict.** ERC-8004 is a draft standard, and strong evidence means the identity is better supported, not that a payment is safe.\n\nTo see these fields for a real agent, look one up in the [ERC-8004 Inspector](https://contextiq.trango-compute.com/erc8004-inspector), or run the combined check with an agent ID and an x402 endpoint in [Policy Check](https://contextiq.trango-compute.com/policy-check). For what to verify on the payment side of the decision, see the [x402 payment checklist](https://contextiq.trango-compute.com/blog/x402-payment-checklist-what-ai-agents-verify-before-signing).\n\nFollow Trango Compute on LinkedIn\n\nWe post updates on new tools, context engineering patterns, and LLM cost research.\n\n[Follow on LinkedIn](https://www.linkedin.com/company/trango-compute)", "url": "https://wpnews.pro/news/claimed-vs-verified-what-erc-8004-agent-identity-evidence-actually-proves-before", "canonical_source": "https://contextiq.trango-compute.com/blog/erc8004-claimed-vs-verified-agent-identity-policy-check-scoring", "published_at": "2026-10-02 00:00:00+00:00", "updated_at": "2026-10-17 16:05:22.283153+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-safety"], "entities": ["ContextIQ", "ERC-8004 Identity Registry", "x402", "ENS", "DID", "Policy Check", "ERC-8004 Inspector"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/claimed-vs-verified-what-erc-8004-agent-identity-evidence-actually-proves-before", "markdown": "https://wpnews.pro/news/claimed-vs-verified-what-erc-8004-agent-identity-evidence-actually-proves-before.md", "text": "https://wpnews.pro/news/claimed-vs-verified-what-erc-8004-agent-identity-evidence-actually-proves-before.txt", "jsonld": "https://wpnews.pro/news/claimed-vs-verified-what-erc-8004-agent-identity-evidence-actually-proves-before.jsonld"}}