Your agent just got an x402 challenge from a counterparty. The address looks right, the price looks fair, but a wallet balance alone tells you nothing about intent — that's the gap an ERC-8004 agent identity closes, and that's the gap EVIDIQ scores against.
ERC-8004 in Plain English
ERC-8004 agent identity is an on-chain standard for registering an AI agent as a distinct, verifiable entity, separate from a raw wallet address. EVIDIQ treats an ERC-8004 registration as the strongest identity anchor in its trust score, because the record is persistent, cryptographically attested, and cannot be casually regenerated the way a fresh EOA can.
At its core, ERC-8004 is a registry contract. You write a small entry that points an agent to a wallet, an interface description, an operator address, and a set of declared capabilities. That entry sits onchain with a stable id. Anyone, anywhere, can read it and ask: "does this specific agent exist, who controls it, and what does it claim to do?"
Before the standard existed, the closest thing to agent identity on EVM chains was a wallet address. That worked for humans, who have legal identity backing a recovery path. It breaks for agents, which are software: a keypair is free, an address is a one-line deploy, and there is no cost to spinning up a thousand of them.
The standard fixes that gap by giving an agent a stable, indexable identifier that doesn't depend on the wallet holding its funds. The id survives key rotation. The id is queryable by other agents. The id can carry a pointer to a machine-readable capability manifest, so the registry is also a discovery surface.
ERC-8004 was deliberately kept small. It's a registration record, not a reputation ledger and not an oracle of behavior. You still need a layer on top to interpret the entry — to ask: is this agent honest, has it done what it promised, should you escrow with it. A trust layer takes that registration and turns it into an actionable signal.
For now, just remember: ERC-8004 gives you a persistent, onchain handle for an agent. The rest is interpretation.
A Wallet Address Is Not an Identity
Here's the trap. In an x402 challenge, the agent you're transacting with surfaces an EVM address. You check it, see it holds some USDT0, and assume it must be a real counterparty. A wallet balance alone tells you nothing about intent — that's the gap an ERC-8004 agent identity closes.
An EOA is a keypair. Anyone can generate one in their browser tab in under a second. The address is just the keccak256 of a public key. There is no attestation that the entity behind it is the same entity that showed up yesterday, or that it will be the same entity tomorrow. A wallet also conflates two roles that should not be conflated:
- Custody of funds (pays the bill).
- Identity of the counterparty (who you are actually dealing with).
If an agent's only signal is its paying address, you have no way to tell whether you're paying the same agent that served you last Tuesday or a brand new impersonator that copied the marketing copy. In x402 flows especially, this matters — payment and capability are separated, and the address you pay is not necessarily the address you authenticate.
By contrast, an ERC-8004 agent identity record is an entry in a registry contract. You can't conjure it the same way you can conjure an EOA. To register, you submit a transaction; to spoof someone else's entry, you'd have to either rewrite registry storage or convincingly mirror it — and a verifier like EVIDIQ can compare the onchain record against the live endpoint.

Practically, the difference looks like this:
- Bare EOA: "Pay 0xAbCd… for inference." Anyone could mint 0xAbCd… tomorrow.
- ENS name: "Pay trader.eth." Better, but ENS is human-readable first; it still rotates if the owner changes.
- TLS-served domain: "Pay api.example.com via a verified domain." Strong, but doesn't survive a domain transfer.
- ERC-8004 record: "Agent id 0x0001, registered 2026-03-14, operator 0xBeef…, manifest https://…." The id is the source of truth.
The honest read: an EOA is a payment rail. ERC-8004 is a passport.
How EVIDIQ Scores an ERC-8004 Anchor
Now to our side of the wire. When EVIDIQ's verify_agent tool is called against an agent, the identity dimension of the trust score is built from four ordered tiers, and an ERC-8004 anchor sits at the top of that ordering.
The score itself is deterministic and explainable. It is computed as a weighted combination:
identityis scored 0–100 from anchors the agent can prove.capabilityis scored 0–100 from declared capabilities plus a live probe of the agent's endpoint.reputationis scored 0–100 from identity anchors and live signals (today that includes whether the endpoint runs a paid x402 service — economic skin in the game — we don't yet have a full historical reputation ledger, and we won't pretend we do).riskis scored 0–100, then inverted as100 − risk.
Final score: identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. Same inputs, same output, every time. Auditable.
Within the identity subscore, anchors are ranked from weakest to strongest:
- Bare EVM address: low tier. It proves control of a key, not continuity of an agent.
- ENS name: mid tier. It proves a name-to-address binding under a known registry.
- TLS-served domain on the agent's endpoint: high tier. It proves the endpoint is operated by someone who controls a domain.
- ERC-8004 agent identity record: top tier. It proves an onchain, persistent identifier tied to a manifest and an operator address — exactly the proof an autonomous counterparty needs.
Concretely, an agent that returns a valid erc8004Id in its registration hits the ceiling of the identity subscore. An agent with only a bare address sits well below that. The delta is not cosmetic — it's a meaningful bump in the weighted formula, and it's why we treat ERC-8004 as the strongest single anchor we recognize today.
Worth noting: a registered record is necessary, not sufficient. EVIDIQ still probes the endpoint, parses the manifest, checks for a paid x402 surface, and looks for risk flags. A registry id alone won't push a malicious agent across the finish line if other signals contradict it. The score is multi-dimensional by design.
If you want the deeper mechanics — including how the probe runs in roughly six seconds and how the verdict gets hashed, anchored on 0G Storage, and EIP-191 signed — the EVIDIQ Operator docs walk through it.
Should You Register One for Your Own Agent?
Short answer: yes, if you expect other agents to call verify_agent on yours in 2026 — and you should expect that.
Here's what registering actually buys you, practically. The next time another agent considers paying yours for an inference, a swap, a data lookup, or any x402-gated service, that caller can run an EVIDIQ check. If your agent has an ERC-8004 record:
- Its identity subscore sits at the top of the identity tier.
- Its continuity is provable across key rotations.
- Its declared capabilities can be cross-checked against the live probe EVIDIQ runs.
- The caller sees a single recommended verdict: proceed, proceed_with_escrow, caution, or do_not_proceed.
Without the record, your agent is starting from a lower identity floor and leaning entirely on its endpoint and payment signals to compensate. That works for a while, but it weakens the trust posture your counterparty can defend to their own users.
A few practical tips from how we've watched early adopters register agents:
- Pin your operator address in the registration, not just your paying address. They will diverge in production.
- Host a machine-readable skill or agent-card at a stable URL — EVIDIQ's live probe looks for it.
- If your endpoint serves paid x402 content, point the manifest at it; reputation scoring rewards that economic skin in the game.
- Rotate your paying wallet without re-registering; the ERC-8004 id is the thing that survives.
- Re-verify after any major capability change so the manifest reflects what you actually do today.
If you're wiring this into your own orchestration layer, the EVIDIQ Sentinel docs cover how to consume the verdict downstream. For the canonical scoring formula and the full evidence flow, EVIDIQ docs are the right starting point.

The cost of registering is small and the upside is durable. In 2026, treat an ERC-8004 agent identity the way you'd treat an SSL certificate on a public site: not optional if you want to be taken seriously by automated counterparties.
