ERC-8004 Agent Identity and Why EVIDIQ Checks For It

ERC-8004 in Plain English

An ERC-8004 agent identity is a stable, on-chain id for an AI agent. It is a proposed Ethereum standard that gives that agent an identifier separate from any wallet it uses for payments. It is what systems like EVIDIQ check first when verifying an agent, turning "this address paid me" into "this specific agent paid me." In plain terms, ERC-8004 is a thin registry entry — a signed declaration binding a human-meaningful agent description to an on-chain id, which any counterparty can read for free.

The standard emerged from a real gap that the agent economy hit in 2026 and 2026: as more autonomous software started transacting on-chain, the only identity signal a counterparty had was the paying EOA. That's not enough. A wallet address tells you nothing about who or what is behind it — only that it controls some ether or stablecoins right now. ERC-8004 fixes this by letting an agent (or its operator) publish a registry entry containing the agent's declared capabilities, an endpoint URL, and a verifiable binding to a signing key. The id is a uint256, the entry is stored in a contract, and anyone can query it.

Three pieces make the standard tick:

1. The registry contract. Holds a mapping from agentId to a struct describing the agent.
2. The agent's declared metadata. Things like a name, description, capability tags, and a service endpoint — often an HTTP URL pointing at an MCP server, an Agent Card, or a skill file.
3. A signature binding. The metadata is signed by a key, and that signature can be checked against the on-chain id — which means the metadata can't be quietly swapped out without the swap being detectable.

Why does this matter? Because once a counterparty has the on-chain id, they can re-derive everything: the declared capabilities, the endpoint to probe, the public key, and a cryptographic chain back to whoever first registered the agent. None of that is possible from a wallet address alone.

A Wallet Address Is Not an Identity

This is the part we keep coming back to internally, and it's worth stating bluntly: a wallet address is not an identity. It is a control point over funds. Conflating the two is the single most expensive mistake you can make when verifying an agent.

Here's the math. Anyone can generate a fresh EVM address in under a second. No KYC, no history, no reputation, no nothing. If "agent identity" reduces to "the address that signed the transaction," then any attacker who wants to spoof a known agent just generates a new address, imitates the agent's behavior for one transaction, and disappears. The counterparty has no way to distinguish a long-lived agent from a fly-by-night impersonator.

An ERC-8004 record can't be conjured the same way. To mint a new id, you have to:

• Submit a transaction to the registry contract (paying gas, leaving a public trace).
• Sign the agent's metadata with a key that becomes part of the on-chain record.
• Bind the metadata to an endpoint, which is now a permanent finger of accusation if it serves malicious content.

That last point is the one attackers hate. An ERC-8004 id points at an endpoint. The endpoint can be probed, fingerprinted, and cross-referenced. Spoofing the on-chain record without owning the endpoint is impossible — and owning the endpoint means you're now a known operator on the internet, not an anonymous fresh address.

There's a subtler version of this problem we run into constantly: an agent and its operator are not the same thing, but on a bare wallet they look identical. With ERC-8004, the operator can rotate the paying address, rotate the signing key, and even migrate the endpoint — without losing the identity. The id stays stable; the keys are disposable. That is exactly the property a long-lived agent needs and exactly the property a raw wallet lacks.

How EVIDIQ Scores an ERC-8004 Anchor

When EVIDIQ runs a verify_agent call, the first thing we check is whether the agent has an ERC-8004 agent identity record on-chain — EVIDIQ reads it back live from the ERC-8004 IdentityRegistry deployed on 0G (the same chain we already use for 0G Storage and Compute). If yes, the identity dimension of the trust score gets a substantial boost — and that boost is structured, not vibes-based.

Our scoring formula is:

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

Within identity, an erc8004Id is the strongest single signal we recognize, ahead of a bare EVM address, an ENS name, or a TLS-served domain. The reason is simple: ERC-8004 is the only signal that ties the agent to both a cryptographic key and a publicly resolvable metadata record. A bare address only proves you control the funds right now. An ENS name only proves you own a name. A domain only proves you control DNS. ERC-8004 proves you made a public, signed, on-chain declaration about what the agent is — and that declaration is now part of a global, queryable registry.

The practical bump in our current scoring: an agent that presents only an EVM address lands around 40/100 on the identity dimension. Adding an ENS pushes that toward 60. Presenting an ERC-8004 id that EVIDIQ resolves live against the IdentityRegistry on 0G — the id exists, and the supplied address matches its on-chain owner or verified agent wallet — pushes identity into the 80s. That's a swing from "caution" to "proceed" in the final recommendation, with no other change to inputs.

Worth noting: we weight a resolvable, owner-matched ERC-8004 agent identity much higher than a self-declared one. Anyone can paste an id into free-text. The signal only counts if EVIDIQ reads the id back off the on-chain IdentityRegistry and the address the caller supplied matches the id's on-chain owner — or its verified agent wallet, the one set via an EIP-712 / ERC-1271 signature. Claim an id you don't control and the read catches it immediately: zero identity credit, plus a flagged impersonation warning.

Capability scoring rewards a live probe of the declared endpoint — a bounded ~6s GET that checks reachability, TLS, and whether the endpoint serves a machine-readable surface like an MCP server, agent card, or the EVIDIQ skill format. The reputation dimension today is scored from identity anchors and live signals (does the endpoint run a paid x402 service — economic skin in the game). We're explicit that we don't have a full historical on-chain reputation registry yet. When that lands, ERC-8004 ids will be the natural join key.

The score itself is deterministic. Same inputs, same score, every time. Anyone with the same inputs can re-run the math and reproduce our verdict. That's the auditable property we think the agent economy needs — not a black-box ML confidence number that nobody can challenge.

For the implementation details, EVIDIQ docs walks through the exact endpoint shapes, the x402 payment flow, and the 402 challenge format. The short version: you POST to the MCP server's verify_agent tool, pay via x402 (HTTP 402, scheme "exact", EIP-3009 transferWithAuthorization, settled on X Layer in USDT0), and get back a signed report. The report is canonical, hashed with keccak256, and the evidence is anchored on 0G Storage with an on-chain transaction you can look up yourself.

Should You Register One for Your Own Agent?

If you've built an agent that does anything with money — even small amounts — register an ERC-8004 agent identity for it. Here's why, from a builder's perspective on the receiving side:

In 2026, the agent economy is bidirectional. Yesterday you worried about your agent being tricked by a malicious counterparty. Today, every other agent in the ecosystem is going to run a verify_agent call against you before sending funds, signing agreements, or sharing sensitive state. The question isn't whether you'll be verified; it's what the verification will say.

Without an ERC-8004 id, no ENS, and no declared endpoint, the identity dimension of the score comes back low. The counterparty's recommendation lands on "caution" or "do_not_proceed." You don't get the job. You don't get the trade. Your agent is invisible.

With an ERC-8004 agent identity, a signed metadata record, and a live endpoint, the identity dimension pops. The recommendation lands on "proceed" or "proceed_with_escrow." You become a known quantity.

Concretely, registering buys you:

• A stable identifier that survives wallet rotation, key rotation, and infrastructure migration.
• A public declaration of what your agent does, signed by you, anchored on-chain.
• An endpoint slot that verifiers can probe to confirm you actually serve what you claim.
• A reputation join key for every future reputation system that wants to score agents — including ours, once the historical registry lands.

The cost is a single registry transaction and the discipline to keep your endpoint honest. The upside is being on the right side of every verification check that runs against you for the rest of your agent's life.

If you're building today, the practical steps are:

1. Deploy or find the ERC-8004 registry contract on your chain of choice (mainnet, X Layer, Base — pick where your agent settles).
2. Prepare a metadata document — name, description, capability tags, endpoint URL.
3. Sign the metadata with the key you want bound to the agent.
4. Submit the registration transaction. Pay gas. Save the id.
5. Stand up the endpoint and make sure it serves a machine-readable surface (MCP, Agent Card, or the EVIDIQ skill).
6. Re-verify after any key rotation by re-signing and updating the record.

That's it. Six steps, mostly one-time. After that, your agent carries a verifiable ERC-8004 agent identity into every interaction it has, and every counterparty that runs EVIDIQ against you gets a clean, deterministic score.