ERC-8004 Agent Identity: Why EVIDIQ Checks For It Before Trusting an Agent

ERC-8004 in Plain English

ERC-8004 agent identity is an on-chain standard that binds an autonomous agent to a stable identifier separate from any wallet it controls. EVIDIQ treats a published ERC-8004 record as a high-value identity anchor in its deterministic trust score, weighted more heavily than a bare EVM address or an ENS name.

ERC-8004 is, roughly speaking, a soul for an agent.

That phrasing isn't quite right technically, but it captures the intent. The standard, formally proposed as ERC-8004, defines a minimal on-chain interface for binding an autonomous agent to a stable identifier — what the spec calls an agentId — that lives separately from any keypair the agent happens to use today. It's a counterpart to ERC-721 (soulbound tokens) and ERC-20 (fungible tokens), but purpose-built for non-human economic actors.

At its core, an ERC-8004 record is a smart contract entry that says: "This entity — named here, registered at this block, owned by this address — is a known agent with the following declared metadata, capabilities, and service endpoints." Anyone can read it. The owning address can update it. The record is not a wallet; it's a registry that ties together a wallet, a name, and a public surface area.

The practical effect is straightforward: instead of staring at a random 0x… and guessing what's behind it, another contract (or another agent) can resolve a stable identifier and ask the registry, "is this the agent I think it is?"

The standard matters because the agent economy is already here. In 2026, agents transact, hire sub-agents, and settle invoices over x402. They're doing this across chains and across vendors. Without something like ERC-8004, every interaction starts from zero — every counterparty reinventing the wheel of "who am I actually talking to?"

A Wallet Address Is Not an Identity

[IMAGE_PROMPT: A modern flat illustration showing two side-by-side panels: the left panel depicts an opaque hexadecimal wallet address floating without context, gray and isolated; the right panel depicts the same address bound to a structured registry card with a stable agentId, a declared skill URL, a small chain icon, and a verified badge. A developer figure connects the two with a checkmark. Color palette of deep blue, teal, and soft orange. No real brand logos.]

Here's where most teams get stuck.

They publish their agent's payment address on a website. They tweet it. They wire it into their marketplace listing. Six weeks later someone on the other side of a transaction asks, "who did I just pay?" and the honest answer is: nobody can say for sure.

A wallet address controls funds. That's all it does. An EOA, by definition, is just a keypair. Anyone can spin one up in under a second using cast wallet new. There is nothing inherent in an address that says "this is that agent" — it's a rotating opaque handle, not an identity.

Compare that to an ERC-8004 record:

• It's a contract entry. To create one, the owner had to send a transaction. That transaction left a permanent receipt on-chain.
• It points to a stable identifier (the agentId) that survives the address being rotated, the agent's hot wallet being compromised, or a key-rotation event.
• It can be queried by id, not by address. Two callers who both know the same agentId reach the same agent even if the underlying addresses differ.
• It's upgradeable in-place: the owner can publish a new declared endpoint or a new payment address without breaking anyone else's cached pointer.

A bare address conflates controls funds with is a known entity. ERC-8004 separates them. The standard doesn't replace payment addresses — it sits above them and says, "this is the agent that owns that address, has been operating since block N, and serves the following capabilities."

This is exactly the gap EVIDIQ's identity scoring dimension is designed to close. When an agent calls verify_agent, the question isn't "do you have ETH?" — it's "is there a deterministic, on-chain, public record tying your wallet to a specific named entity?" A wallet alone scores low. An ERC-8004 anchor scores high.

How EVIDIQ Scores an ERC-8004 Anchor

Now the concrete math, because this is where most explainers wave their hands.

EVIDIQ's identity dimension is one of four inputs into the deterministic trust score. The full formula is:

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

The 30% weight on identity is large. It reflects the prior: if you can't identify who you're dealing with, every other signal becomes suspect.

Within that identity dimension, our scoring treats different anchors on a tiered basis:

1. Bare EVM address: low — anyone can generate one in seconds, no proof of continuity.
2. ENS name reverse-resolving to the address: medium — better than nothing, requires paying a small annual fee and thus some "economic skin," but still rotatable and not agent-specific.
3. TLS-served domain with a machine-readable agent card or skill: medium-to-high — strong signal for the service identity, weaker for the legal/economic identity.
4. ERC-8004 anchor: high — combines on-chain finality, declared ownership, and a registry-stable identifier in a single query.

We built the identity probe so that an 8004 record referencing the calling address triggers a near-ceiling contribution to the identity sub-score. An ENS alone doesn't. An address alone doesn't. The combination of an 8004 record plus a live, declared endpoint scores essentially as high as the dimension allows.

Why does the ERC-8004 anchor get this treatment? Three reasons we keep returning to:

• It's expensive to fake. Registering requires a transaction on a network; you can't phish a registry entry the way you can squat a username on a centralized service.
• It's public and verifiable. Anyone, including our probe, can fetch the record and re-derive the same answer. No privileged lookup, no API key, no rate limit.
• It's portable. The agentId is chain-native, which means it survives vendor changes, front-end redesigns, and even the operational death of the original issuer's domain.

The probe itself is lightweight: a read-only call to the registry contract for the claimed agentId, a check that the registered owner is either equal to or an explicit delegate of the caller, and a reconciliation against the declared metadata. Total round-trip time is bounded — we cap the identity probe at a couple of seconds inside the broader ~6s capability probe. For a full walkthrough of how these tiers feed into verify_agent, the EVIDIQ docs are kept in sync with the deployed scoring code.

Honest take: the 8004 anchor isn't magic. It's a signal. A determined attacker can still mint a record, point it at a hostile skill endpoint, and game a probe that doesn't also weigh declared capability depth and live economic behavior. That's why the formula multiplies identity by 0.3 instead of letting it dominate. Identity tells you who's there; capability and reputation tell you whether they're worth dealing with.

Should You Register One for Your Own Agent?

[IMAGE_PROMPT: A modern flat illustration of an agent builder at a terminal, deploying a registration transaction to a chain. Above them, a structured on-chain identity card materializes with fields for agentId, declared capabilities, and skill endpoint. Below, two other agents query the card and receive a green verification badge. Color palette of navy, mint green, and amber. No real brand logos, no readable text on the card.]

Short answer: yes, and the sooner in your launch cycle the better.

Here's the practical chain. Imagine you ship an agent today that uses a single hot wallet to receive x402 payments. Six months from now, your agent is popular. Another agent operator — a competitor, a customer, a regulator's crawler — points EVIDIQ at your wallet and asks, "is this entity trustworthy?"

What the probe sees:

• An address. Low identity tier.
• An optional ENS. Medium if present.
• Maybe a domain serving a .well-known file. Decent capability tier.
• No ERC-8004 record. Identity sub-score capped well below the ceiling.

The recommendation that comes back might be caution, even though your agent has shipped clean code, settled a thousand invoices, and never had a single dispute. That's the gap, and it's almost entirely the absence of an ERC-8004 anchor.

If you'd registered an 8004 record at launch, with the same address as owner and a metadata blob pointing at your /skill.md, here's what changes for the next inquiry against your agent:

• Identity tier jumps from low to high.
• Reputation, which today is partly derived from identity anchors and live signals (including whether your endpoint serves a paid x402 service — i.e. economic skin in the game), gets a measurable bump.
• The risk dimension, which penalizes unknowns, drops.
• The aggregate trust score moves from "proceed with caution" toward "proceed" — sometimes into "proceed with escrow," which is the green-light-plus-paperwork verdict EVIDIQ hands back when its confidence is good but not absolute.

The practical advice, then, is concrete:

• Register early. ERC-8004 records are cheap to publish and update. The cost of being uninstantiated later dwarfs the on-chain cost of registration now.
• Point it at real endpoints. The metadata blob should declare your real /skill.md, MCP server, or agent card URL. Empty declarations look the same as no declaration.
• Keep the owner address deliberate. If you hold the agent's treasury at a cold multisig, register with a small operational EOA and grant it delegate rights to the cold address. We see teams make the mistake of registering with the treasury directly, then rotating the treasury and orphaning the record.
• Treat it as durable infrastructure. The agentId should outlive your deployment. If you fork the agent, write a new record; don't try to mutate the old one into something it never was.

For builders integrating end-to-end, the EVIDIQ Sentinel docs explain how to surface an EVIDIQ verdict inside your own product, and the EVIDIQ Operator docs cover how to register a service and consume the discovery endpoint at evidiq.dev/x402.

One more honest take: a 2026 agent that consumes other agents should also be a 2026 agent that publishes an ERC-8004 anchor. The two go together. Symmetric identity — both sides of a transaction having published records — is what turns an interaction from "trust the largest party" into "trust the deterministic score."