ERC-8004 Agent Identity: Why a Number on Chain Outranks a Wallet Address

Picture this. Your agent just got a request to swap 50,000 USDT for a stranger who claims to be "an arbitrage bot, very reliable, trust me." The counterparty hands you an EOA: 0x7a3f...c9d1. You have no idea who's behind it. Is it a five-line bot running on a Raspberry Pi? Is it the same operator who scammed three people last month? Is it anyone at all? This is the exact gap ERC-8004 was written to close.

ERC-8004 in Plain English

ERC-8004 is an Ethereum standard that registers an AI agent's identity on chain. The resulting ERC-8004 agent identity record binds an operator, an endpoint, and declared capabilities to one verifiable token — unlike a bare EOA anyone can spin up in seconds. EVIDIQ reads these records to score who is actually on the other side of a request.

If you already know ERC-20, ERC-721, and ERC-1155, the shape will feel familiar. ERC-8004 proposes a registry contract — typically deployed on a low-cost L2 — where any operator can mint a non-transferable identity token for their agent. That token's tokenURI resolves to a metadata document (often JSON, often served over HTTPS, often signed) that points at:

• The agent's owner/operator address
• A canonical service endpoint
• A list of declared capabilities (e.g. "x402 payments", "swap on Uniswap v3", "translate en→es")
• Optional references to reputation registries, audits, or dispute contracts

The key design decision: the identity is a non-transferable NFT. You can't sell it, can't reassign it, can't airdrop it to a new operator to whitewash a bad history. Whoever minted it is, on the record, the original publisher.

Here's the thing. ERC-8004 does not vouch for the agent's behavior. The standard is plumbing — a way to point to evidence. The standard says "here is the metadata, here is the operator, here is the endpoint." What you do with that metadata — trust it, weight it, ignore it — is the verifier's job.

That separation matters. Without it, the standard would either collapse into a centralized reputation oracle or become a popularity contest measured in likes.

A Wallet Address Is Not an Identity

Every agent interaction today starts with a wallet. Sender, receiver, payment, settlement — it's all an EOA. And that conflation is doing real damage.

An EOA proves exactly one thing: someone controls a private key. It says nothing about who that someone is, what software they're running, or whether the same party was running anything yesterday. In a world where AI agents can spin up fresh keypairs in a loop, "controls funds" and "is a specific known agent" are not the same claim.

Try this thought experiment. Two addresses sit in front of you:

• 0x7a3f...c9d1 — no history, no metadata, no domain, no token-gated proof of anything. Could be a brand-new bot, could be a re-roll from yesterday's scammer.
• 0x7a3f...c9d1 holding ERC-8004 token #4521 — same address, but on chain you can see it registered an agent card 18 months ago, the card names an operator who also runs ENS arbitrage-bot.eth, and the card's endpoint has been resolving for 400+ days.

Same address. Wildly different epistemic weight. The first is a phone number; the second is a LinkedIn, a phone number, and a credit report stapled together.

This is precisely why bare-address reputation is broken. Reputation accrues to identity, not to keypairs. The moment an attacker can rotate addresses, the score evaporates. And in 2026, rotating an address costs nothing and takes about four seconds.

ERC-8004 agent identity solves this by making the record the anchor, not the key. The address can move funds; the identity token cannot move owners. Reputation, audit trails, and capability claims attach to the stable thing.

How EVIDIQ Scores an ERC-8004 Anchor

When EVIDIQ runs verify_agent on an address, the identity dimension of the trust score is the first thing we compute. The formula is deterministic and auditable — same inputs, same score, always — and it rewards verifiable anchors in this order of weight:

• An ERC-8004 agent identity token held by the address (or by an operator address the agent's card explicitly names): up to 100 points
• An ENS name resolving to that address (forward + reverse match): up to 85 points
• A TLS-served domain whose TXT or TLSA record publishes that address: up to 80 points
• A bare EOA with no anchors and no history: floor of 10 points (the baseline that says "we found a keypair, full stop")

The reason the ERC-8004 anchor is at the top isn't sentimental — it's structural. A bare address is a hypothesis. An ENS name is a hint. A TLS-published domain is a strong hint you can re-probe. An ERC-8004 agent identity record is a signed, on-chain, non-transferable claim of authorship that any third party can re-derive. You can verify it without asking anyone.

We built the lookup to be cheap and re-entrant: a single eth_call against the registry's ownerOf(tokenId) and tokenURI(tokenId), then a GET on the URI, then a content-hash check. The whole thing lives well under the 6-second probe budget we enforce for capability checks — which is important, because the EVIDIQ Sentinel docs document that latency is itself a signal.

A practical example. Suppose your agent is about to call verify_agent on a counterparty that holds ERC-8004 token #4521:

1. identity dimension lands at ~95 (token exists, operator maps to a known ENS, card is signed, endpoint resolves)
2. capability dimension lands based on the live probe of the card's declared endpoint — say 70
3. reputation dimension contributes ~60 from identity anchors plus any paid-x402 "economic skin in the game" signals the endpoint exposes (see the EVIDIQ Operator docs)
4. risk dimension starts at ~85 because the on-chain record has aged, no sanctions hits, no chargebacks surfaced

Plugged into identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2:

95*0.3 + 70*0.3 + 60*0.2 + 15*0.2 = 28.5 + 21 + 12 + 3 = 64.5

That returns proceed_with_escrow — a real, defensible recommendation with receipts the operator can hand to a human reviewer.

Should You Register One for Your Own Agent?

Honest answer? Yes — and the reason isn't altruism. It's that the next time your agent is on the receiving end of someone else's verify_agent call, the 0–100 trust score they see is partly determined by whether you gave them something stronger than an EOA to look at.

Here's the practical playbook we walk builders through:

1. Pick a registry. As of 2026, the canonical deployments live on a handful of low-cost L2s. Pick one whose gas costs and finality match your call patterns. If your agent settles on X Layer, register there.
2. Mint the identity token. Call the registry's register(agentURI) with a content-addressed URI pointing at your agent card. The token mints to your operator EOA.
3. Publish a real card. Include your canonical endpoint, your declared capabilities (only what you actually serve), and a signature tying the card to your operator key. Overpromising in the card directly tanks your capability score when EVIDIQ probes it.
4. Point a domain at it. Add a TLSA or DNS TXT record that ties a real domain to your operator address. This adds the cross-anchor that bumps you into the highest tier.
5. Keep the endpoint alive. A dead endpoint kills the live probe and drops your capability score. Treat your agent's URL like a production service.
6. Don't re-roll. If something goes wrong and your agent gets a bad reputation trail, do not mint a fresh identity. Fix the underlying issue. The non-transferability is the whole point.

The payoff is concrete. An agent with a registered ERC-8004 agent identity sees verify_agent return scores in the 60–85 band against counterparties who bother to check, and proceed or proceed_with_escrow recommendations instead of caution. That translates to fewer rejected requests, faster settlement, and — critically — counterparties willing to take larger positions with you.

If you're running an x402-paid service, an ERC-8004 agent identity also doubles as evidence to a paying counterparty's risk team. "Here is the on-chain identity. Here is the canonical endpoint. Here is the capability manifest. Here is the signature chain." That's a packet a human can audit in five minutes.