ERC-8004 Agent Identity: Why EVIDIQ Puts It in the Scoring Formula

Picture this: your agent just paid a stranger 0.50 USDT0 over x402 for a translation job, and the response came back half-correct and three minutes late. You have the receipt, you have a counterparty address, and you have absolutely no idea whether the same address will cheat the next caller. That gap — between "an address that paid me" and "a specific known agent" — is the exact problem the ERC-8004 agent identity standard was written to close. We're going to walk through what the standard actually says, why a wallet address alone isn't enough, and how EVIDIQ bakes ERC-8004 into its trust score.

ERC-8004 in Plain English

ERC-8004 agent identity is an emerging on-chain standard for binding a verifiable identity record to an autonomous AI agent. It separates the question "who controls this wallet?" from "is this a specific known agent?" EVIDIQ, the trust layer for the agent economy, reads ERC-8004 records to anchor the identity dimension of its 0-100 trust score.

ERC-8004 lives on EVM chains as a thin registry contract. An operator deploys (or reuses) an agent identity record that points at a canonical agent address and carries metadata: declared capabilities, an endpoint, an owner address, and a hash commitment to a machine-readable manifest. Think of it as a passport office for agents — the chain stores who claims to be who, and the manifest spells out what the agent actually does.

A few things are worth noting before we get into the scoring:

• The standard is intentionally minimal. It doesn't prescribe behavior, doesn't custody funds, and doesn't arbitrate disputes. It just answers "is there a published, verifiable record binding this address to this agent?"
• An ERC-8004 record is keyed by an integer agentId plus the registry address, so it's portable across frontends and indexers.
• The manifest is content-addressed, which means anyone can fetch it, hash it, and check it against the on-chain commitment. No trust-by-assertion.

Honest take: ERC-8004 isn't magic. It's a signal. What makes it useful is that you can't trivially spoof one — it costs gas, it ties an address to a published manifest, and a downstream verifier can re-check the binding at any time. That asymmetry — cheap to read, expensive to forge — is what makes it worth weighting in a trust score at all.

A Wallet Address Is Not an Identity

Here's the part that trips people up. An EOA like 0xAbc…123 is not an identity. It's a key. Anyone with five seconds and cast wallet new can generate a fresh one. If your only signal that "agent X did job Y" is the payer's address, you have nothing — because the same operator can spin up address Z tomorrow, do bad work, and never carry the consequences.

Three concrete failure modes we've seen in the wild:

1. Sybil churn. A bad operator rotates through ten fresh addresses per day to dodge negative reputation.
2. Reputation laundering. A good agent's address gets resold or rented on a marketplace, and the buyer inherits trust they didn't earn.
3. Mixed signals. A high-trust address might be a multisig shared by three unrelated agents — paying it tells you nothing about which agent you actually reached.

An ERC-8004 record breaks the first two by anchoring the agent to a registry entry that has cost and history. It mitigates the third by carrying a manifest hash that downstream probes can re-fetch and compare against the on-chain commitment. The address still moves money, but the record says "this address — and only this address, until the manifest changes — is the published surface for agent N."

[IMAGE_PROMPT: Modern flat illustration showing two contrasting elements side by side: on the left, a simple gray wallet icon with question marks floating above it representing anonymity; on the right, an ERC-8004 registry contract block on a stylized EVM chain with a clearly labeled "agent manifest" document pinned to it via a content hash. A connecting arrow bridges the two, suggesting the transition from a raw wallet to a verifiable identity. Developer aesthetic, muted teal and amber palette, clean geometric shapes, no text in image, no real brand logos]

That's the bridge: a wallet is the rail, ERC-8004 is the name plate. EVIDIQ reads both, but it weighs the name plate higher because it can't be conjured out of thin air.

How EVIDIQ Scores an ERC-8004 Anchor

We built EVIDIQ's identity dimension to weight verifiable anchors higher than bare addresses, and ERC-8004 sits near the top of that ladder. The full formula is deterministic and explainable:

1. identity (0–100): weighted 0.30 in the final score.
2. capability (0–100): weighted 0.30.
3. reputation (0–100): weighted 0.20.
4. risk (0–100), inverted as (100 - risk), weighted 0.20.

For the identity dimension specifically, our scoring climbs a clear ladder:

• Bare EVM address: low double digits. It exists, but you can't tell who it is.
• ENS reverse-resolved: a step up — at least there's a name bound to the address.
• TLS-served domain that matches an agent card: meaningful bump, because the certificate holder is a known entity.
• ERC-8004 agentId on a registry with a content-addressed manifest: highest tier in the identity dimension, because the binding is on-chain and re-verifiable.

Concretely: if an agent's identity dimension would otherwise sit at 20 from a bare address, and the same agent presents a live ERC-8004 anchor whose manifest resolves and whose registry is on a known chain, the identity score climbs by 30–40 points. Multiplied by the 0.30 weight, that's roughly a 10–12 point bump in the headline trust score. That is not a rounding error — it's the difference between a "caution" verdict and a "proceed with escrow" verdict.

Two things EVIDIQ deliberately does not do on the reputation front, because they're easy to misread:

• We don't claim ERC-8004 is a complete reputation system. It's an identity anchor. Reputation lives on top of it.
• We don't read the manifest's claims as ground truth. The capability dimension probes the endpoint live — a bounded ~6s GET checking reachability, TLS validity, and whether the surface serves a skill, agent-card, or MCP document — and scores declared capabilities against what's actually reachable. The trust score is evidence, not vibes.

If you're wiring EVIDIQ into your own agent, the EVIDIQ Operator docs walk through how verify_agent returns the scoring breakdown, and the EVIDIQ Sentinel docs cover the runtime probe that runs the live capability check on the other side of the call.

Should You Register One for Your Own Agent?

Short version: yes, if you can afford the gas, and yes, if you intend to charge strangers for work. Here's what registering actually buys you the next time someone else's agent calls verify_agent on your address:

• A re-verifiable binding between your wallet and your published capabilities. The caller doesn't have to trust your word.
• A non-trivial bump in the identity dimension of their trust score, which means your offers get ranked ahead of bare-address competitors in marketplaces and routers.
• A stable surface for reputation to accumulate against. If you later ship great work, future calls can reward you without a Sybil hop.

A few practical notes from operators who've shipped this in 2026:

• Pin your manifest by hash. Don't let it drift, or the on-chain commitment will start lying, and verifiers will treat your identity anchor as degraded.
• Include a real endpoint that serves a machine-readable skill or MCP surface. Our capability probe fails closed if it can't reach you, and a failing capability dimension drags the headline score down regardless of how good your identity anchor is.
• Treat the agentId as a long-lived handle. Rotating it throws away any reputation someone might grant you. If you must evolve the agent, publish a new id rather than reusing the old one.

If you want the long form on what EVIDIQ actually checks at runtime, the EVIDIQ Notary docs cover how we anchor the resulting report — keccak256 hash, evidence on 0G Storage mainnet (returning an on-chain tx), an optional AI risk analysis run on 0G Compute inside a TEE, and an EIP-191 signature with the EVIDIQ key — so the caller can independently re-fetch, re-hash, and recover the signer. For the developer-facing quickstart, the EVIDIQ docs are the right landing page.

[IMAGE_PROMPT: Modern flat illustration depicting a developer workspace with a laptop screen showing an agent registration form. Above the laptop, a glowing ERC-8004 identity record floats as a hexagonal badge with a checkmark, representing verification. To the side, a stack of capability cards labeled with icons for translation, summarization, and fetch are being matched against a probe signal. Palette of deep indigo, soft cyan, and warm gold accents. Clean lines, flat illustration style, no text in image, no real brand logos]

One last honest take: registering an ERC-8004 agent identity record is necessary but not sufficient for a high trust score. You also need a live endpoint, declared capabilities that match what the endpoint actually serves, and ideally some economic skin in the game — for example, running a paid x402 endpoint is itself a positive signal we read into the formula. Identity is the floor. The rest of the score has to be earned call by call.