ERC-8004 Agent Identity: What It Is and Why EVIDIQ Checks For It

ERC-8004 in Plain English

ERC-8004 agent identity is an on-chain standard that gives an autonomous AI agent a verifiable, persistent identifier on EVM chains — separate from the wallet that holds its funds. It binds a public address to declared capabilities, an owner, and a registry entry that anyone can read. EVIDIQ checks for it because the kind of agent trust scoring that powers real x402 payments depends on an identity anchor that can't be conjured in two seconds.

ERC-8004 is, at its core, an attempt to answer a very boring but very expensive question: who is this agent, really? Not "which wallet paid me" — that's just a payment rail. Not "what string did it sign with" — keys are cheap. The standard proposes that an agent gets registered into a smart contract as a record. That record carries an identifier, a reference to a controller, and a set of declared capabilities. The point isn't to make the agent trustworthy by fiat of registration. The point is to give the rest of the world a stable, queryable handle so that reputation, audit trails, and capability claims can be tied to something that doesn't evaporate when a fresh private key shows up.

If you've been building agents in 2026, you've probably run into the same weirdness we have. A counterparty shows up at your endpoint, claims to be "TheArbitrageBot v3," presents a wallet, and asks for 50 USDC of work. You check the wallet. It has 12,000 USDC in it. So… is that enough? Honestly, no. A funded wallet is a payment instrument, not an identity. The wallet might belong to a careful, six-month-old agent with a clean track record — or it might be a brand-new address generated an hour ago by a script that just airdropped itself some stablecoins.

ERC-8004 is the standard that says: register once, get a stable id, declare your capabilities, and let the world look you up. The chain becomes your public, append-only identity layer.

The way the standard is meant to be used is straightforward:

1. An owner calls a registry contract to mint an id for their agent.
2. The owner attaches metadata — name, declared capabilities, an endpoint, a controller address.
3. Anyone — a verifier, a counterparty, a settlement system — reads the id and sees the same record.

Step three is the one that matters. Without a shared, on-chain lookup, every verifier would have to maintain its own database. With ERC-8004, a single source of truth replaces a thousand custom integrations.

A Wallet Address Is Not an Identity

Here's the failure mode we keep seeing. An agent integrator builds a service. Their service does something useful — say, scraping market depth across three CEXs and returning a normalized order book. They publish an endpoint. Agents start calling it. Some of those callers are real. Some are trying to game the rate limit. Some are probing for prompt injection. The integrator's question, every single time, is: "Can I trust this caller?"

A wallet balance tells you almost nothing. The same wallet that paid you $0.50 yesterday can be reused by a totally different operator tomorrow — private keys are sold, leaked, or rotated. And a brand-new address with $50,000 of stablecoin funding tells you even less. Where did the funds come from? Is this the agent it claims to be? Will the agent be the same entity tomorrow?

A bare EOA conflates two facts that should be separate:

• "I control funds at this address."
• "I am this specific known agent, with this specific declared purpose, operated by this specific party."

ERC-8004 splits those facts apart. The wallet handles payments. The registry handles identity. A caller can show you both. If they only show you the wallet, you know they have money. You do not know who they are.

Here's how the three common signals stack up against each other:

• Wallet (EOA): one private key, no history requirement, no controller field, no declared capabilities, free to spin up infinitely.
• ENS: better than nothing (one name, one address) but doesn't bind to declared capabilities and has no native "this is an agent" flag.
• ERC-8004 record: a registry entry that costs gas to create, references a controller, lists capabilities, and persists on a public chain.

We designed our EVIDIQ scoring formula to treat those three very differently. An EOA alone gives you almost no identity signal. An ENS name gives you a small bump. A registered ERC-8004 id gives you a substantial one — and that's a deliberate choice, because registering costs real effort and is harder to fake at scale.

How EVIDIQ Scores an ERC-8004 Anchor

The scoring math is documented in our EVIDIQ docs and the EVIDIQ Notary docs, but the short version is: identity contributes 30% of the overall trust score, and within identity, an ERC-8004 id is the strongest single signal we accept.

A concrete breakdown of the identity dimension (0-100):

• EVM address verified and reachable at a declared endpoint: 40 points.
• ENS name reverse-resolving to that address: +15 points.
• ERC-8004 registry id pointing at that address as controller, with on-chain metadata: +30 points.
• TLS-valid domain used as the agent's identifier: +20 points (alternative path; can stack with EVM signals).
• Cross-anchor agreement (e.g. ENS and ERC-8004 id both resolve to the same address): +10 points, capped at 100.

Notice the math: an ERC-8004 id alone gets you 70 out of 100 on identity. That's not a tiebreaker — it's the dominant signal. And because the score is deterministic (identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2), a strong identity reading pulls the overall trust score up materially. Same inputs, same score, every time. You can re-run it and audit the result.

The reason we weight it so heavily is operational, not philosophical. A registered ERC-8004 id is observable on chain, it costs gas to create at scale, and it forces the registrant to commit a controller address. That's friction, and friction is what kills the cheap Sybil attacks that make agent marketplaces unusable. It also gives reputation systems something to attach to — once a full historical reputation ledger exists, ERC-8004 ids are the natural keys.

Worth noting: the identity dimension is auditable in the EVIDIQ Notary. Each verify_agent response is hashed, anchored on 0G Storage, optionally run through GLM-5.2 on 0G Compute inside a TEE, and signed with the EVIDIQ key. The hash and signature travel with the report so any third party can re-derive the score and confirm the signer. That's how we've built the system to be defensible when an integrator gets asked by their compliance team, "Why did you accept this caller?"

Should You Register One for Your Own Agent?

Yes, and here's the practical reason that matters more than the philosophical one.

When you register an ERC-8004 id for your agent today, you are not buying yourself anything directly. You can't yet spend it at most merchants. But the next time your agent is on the receiving end of someone else's verify_agent call — which, if you sell x402 services, will happen constantly — the difference between "yes, this id is on chain" and "no, this is just a wallet" is the difference between a clean proceed and a caution verdict.

We see this asymmetry all the time. The first wave of agent builders in 2026 are mostly buyers — they call other agents, they pay them, they move on. The second wave is starting to be sellers. Sellers get verified. And the ones who registered early don't have to retrofit their identity layer when a counterparty starts asking, "Show me your ERC-8004 id or I'm routing through escrow."

A few practical pointers for the actual registration:

1. Pick a controller address that you're willing to be permanently associated with. Don't use a hot wallet that you'll burn and replace.
2. Declare capabilities conservatively. A future reputation system will be able to penalize you for overpromising.
3. Pin your metadata to a stable URI (IPFS, 0G Storage, or a domain you control). The registry entry references a JSON document; if that document rots, your id becomes a husk.
4. Keep your endpoint live. EVIDIQ's live probe does a bounded ~6-second GET to check reachability, TLS, and a machine-readable skill/agent-card/MCP surface. A dead endpoint knocks capability points off your score.

If you're already serving an x402 endpoint, registering is a one-shot upgrade that compounds. Every verify_agent call another integrator makes against you starts from a higher floor. And once historical reputation ledgers land, your id becomes the seed for a long, auditable track record. Think of it the way you thought of HTTPS in 2014 — cheap to add, expensive to be the last holdout.