ERC-8004 Agent Identity: The On-Chain Anchor EVIDIQ Actually Trusts

Picture this: your trading agent just received an offer from another agent on the wire. The offer looks legitimate — a clean ENS name, a polished manifest, even a glowing review in a Discord. You sign the deal. Three hours later the counterparty address is empty, the ENS is parked, and the "agent" was a fresh keypair minted an hour before the conversation started.

We see this pattern every week on the EVIDIQ team. The plumbing is fine; what's missing is a trust score rooted in something the counterparty cannot regenerate in five seconds. That something is what this article is about.

ERC-8004 in Plain English

ERC-8004 agent identity is an on-chain standard for registering a specific AI agent against a verifiable identity record — distinct from the bare wallet it happens to transact from. EVIDIQ reads this record as one of its strongest identity anchors when computing a trust score.

ERC-8004 started life as a community proposal for "Trustless Agents" and was shaped through 2026 alongside x402 payment flows and the broader push toward autonomous agent commerce. The basic idea is small on purpose: a contract, deployable on any EVM chain, that maps a numeric agentId to a controller address, a metadata URI, and a set of declared capability tags. Anyone can resolve that agentId and read back who is supposed to be running the agent, where the agent card lives, and what the agent claims to be able to do.

Three properties make this useful in practice. First, the agentId is bound to a controller rather than to a balance — moving funds away does not move the identity, and a new owner has to explicitly update the record. Second, the metadata URI is meant to serve a machine-readable agentCard.json, the same shape OpenAI's agent cards, MCP servers, and a growing list of agent frameworks already emit. Third, the record is on-chain, public, and deterministic — anyone, including EVIDIQ, can re-fetch and re-verify it without asking the agent permission.

If you've worked with ENS, this will feel familiar but narrower. ENS answers "what human-readable name points to this address?" ERC-8004 answers "what specific agent is bound to this controller, what can it do, and where do I read its card?" Different question, different standard — and a different role inside any modern trust score.

A Wallet Address Is Not an Identity

Here's the math that keeps biting builders. An Externally Owned Address on any EVM chain can be generated offline in under a second. There is no proof of work, no proof of stake, no proof of humanity — just a fresh keypair and a sprinkle of entropy. That makes a wallet address the worst possible thing to use as an identity anchor for an autonomous agent.

We treat identity as a property the counterparty can't conjure on demand. An EOA can. An ENS name costs a yearly fee and at least an hour of patience, so it's somewhat sticky — a fresh address can't claim your ENS without a transfer event. But ENS still only tells me that some entity that once paid for a name controls this address today. It doesn't tell me the agent is the same one I talked to yesterday.

ERC-8004 closes that gap by tying the controller to a published identity record. The record has a creation timestamp, a history of controller updates, and a metadata URI that the agent is expected to keep serving. Swap the controller, and the on-chain log shows it. Move the funds, and the record still points at the same agentId. From EVIDIQ's perspective, that is a fundamentally different signal than "address has balance > 0" or "address resolves an ENS."

In our live probe, an ERC-8004 record is the identity anchor we trust most after a TLS-served domain under the agent's own control. A bare EOA with funds scores in the identity dimension; an ERC-8004 agent identity record with a reachable metadata endpoint scores higher still — and the gap is not cosmetic.

How EVIDIQ Scores an ERC-8004 Anchor

Identity is one of four dimensions we fold into the final 0–100 trust score. The full formula is:

score = identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2

For the identity dimension specifically, the rough weighting inside EVIDIQ's scorer looks like this:

1. No anchor at all — only a wallet address, no ENS, no erc8004Id, no domain: identity score lands between 20 and 40, weighted by balance age and transaction count. It's a starting number, not a verdict.
2. ENS name resolving the agent's controller: identity score lifts into the 50–65 range, depending on how long the name has been held and whether the reverse record agrees.
3. An erc8004Id registered against the agent's controller with a reachable metadata URI: identity score lands 70–85. The metadata has to actually serve a parseable agent card, otherwise we cap the bump.
4. A TLS-served domain under the agent's control, with a published agent card or MCP surface: identity score can reach 90+. This is the ceiling today.

The reason an erc8004Id earns more than an ENS isn't sentimental — it's structural. ENS proves a name purchase; an ERC-8004 agent identity proves that someone chose to publish a binding record for this specific agent, and that the controller address and the metadata URI agree. The on-chain log of that registration is something an attacker would have to either replay (visible forever) or buy (publicly visible). Either way, it raises the cost of forgery by an order of magnitude.

Our scorer is deterministic: same inputs, same score, every time. The full breakdown lives in the EVIDIQ docs, and the live probe used to verify the metadata URI is described in the EVIDIQ Operator docs. If you're running a service that needs to surface signed verdicts to end users, the EVIDIQ Sentinel docs cover the integration pattern.

Should You Register One for Your Own Agent?

If you're shipping an agent that will ever receive a verify_agent call, you want to be on the right side of this. Here's what registering an erc8004Id actually buys you the next time someone runs EVIDIQ against your endpoint:

• A non-replayable identity anchor that survives key rotation, wallet migration, and rebrands.
• A free boost in the identity dimension of any trust score a counterparty computes against you.
• A single source of truth for your agent card — the metadata URI becomes the canonical place to publish capabilities, contact info, and policy URLs.
• A signer story for future on-chain reputation: when EVIDIQ's roadmap lands a reputation registry, your existing ERC-8004 agent identity record is the natural anchor for it.
• An auditable trail that doesn't depend on EVIDIQ or any single vendor — anyone can resolve your agentId and confirm the controller history.

Registration itself is cheap and doesn't require running a validator or staking anything. You deploy (or reuse) an ERC-8004 registry on your chain of choice, point it at a static JSON or IPFS URI, and bind it to your controller address. We typically recommend pairing the registration with a hosted MCP endpoint and an x402 payment surface — both flip additional positive signals in the capability and reputation dimensions, and they pay for the hosting.

One honest caveat: an erc8004Id without a reachable metadata URI is worse than no record at all, because it advertises a promise the agent then breaks. If you register, serve the card. The probe is bounded — about six seconds, a single GET, TLS check included — so a small static host is enough. The full report, once generated, gets hashed, anchored to 0G Storage, and signed by EVIDIQ — details for the integrity pipeline live in the EVIDIQ Notary docs.