All posts
StandardsOctober 1, 2026·8 min read

ERC-8004 Agent Identity: Why a Wallet Address Is Not Enough

ERC-8004 Agent Identity: Why a Wallet Address Is Not Enough

ERC-8004 agent identity is an on-chain standard that gives an autonomous AI agent a verifiable identity record distinct from a bare wallet address. EVIDIQ uses ERC-8004 to anchor an agent's identity in a trust score, ensuring that a public key represents a specific known agent with declared capabilities, not just a freshly generated account holding funds.

ERC-8004 in Plain English

If you build agents, you've already hit the question: how do I prove this address is my agent, and not some random keypair I spun up five minutes ago to dump a bad trade? ERC-8004 answers that. It's a lightweight on-chain registry standard, refined through 2026, that maps a stable identity to a specific agent. Think of it as a name tag, but on-chain, with a pointer to where the agent actually lives and what it claims to do.

Concretely, an ERC-8004 record holds a few things: an agent identifier, a public address the agent controls, a URI pointing to an agent card or skill manifest (the machine-readable description of what the agent does), and a handful of trust signals the issuer attaches. Registration is permissionless — anyone with a bit of gas can mint one and bind it to a particular EVM address. There is no central authority deciding who counts. The chain does.

Why does this matter? Because in 2026 the agent economy is no longer hypothetical. Agents are paying agents. Agents are calling agents. And every one of those calls is a decision: do I trust this counterparty enough to send a USDC transfer, fulfill a request, or sign a sub-delegation? Without a stable identity, every decision degrades into "well, the wallet has a balance, ship it." That's a fast way to get rugged.

ERC-8004 doesn't solve trust on its own. What it solves is the lower, harder problem: it makes an agent addressable in a way that survives key rotation, rebrands, and frontends disappearing. The rest — capability claims, reputation, live behavior — is layered on top by whoever's doing the verification.

A Wallet Address Is Not an Identity

Here's the failure mode we keep seeing in the wild. An agent checks the balance of a counterparty's wallet, sees a fat USDC bag, and proceeds with a transaction. A second later the counterparty rotates the private key, sweeps the funds, and disappears. Or worse — the address was a vanity front for a one-shot scam, and the "rich wallet" was just yesterday's exit liquidity dressed up for one transaction.

A wallet address is a capability, not an identity. It says: this key controls X funds at this moment. It does not say: this is the same agent as yesterday, here's its track record, here's where you can read its terms, here's how to dispute a bad outcome. Any attacker can generate a fresh EOA in a second, fund it from a mixer, and look solvent for the duration of your handshake.

An ERC-8004 agent identity flips that. The record is bound to a contract entry, not a key. Rotating the controlling address is a deliberate, on-chain event that anyone can observe. The record carries a URI, so the agent's declared capabilities and contact surface stay stable even when keys churn. And the registry itself becomes a public, queryable list of known agents — anyone can ask "what's the erc8004Id for this address?" and get a deterministic answer.

It's the difference between a phone number and a business card. A phone number is just digits; a business card has a name, a role, and a place to look you up. The chain gives you the business card.

EVIDIQ blog illustration 1

How EVIDIQ Scores an ERC-8004 Anchor

We built EVIDIQ's identity dimension to reward exactly the kind of evidence that survives an address changing hands. Within our scoring formula — identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2 — the identity component is a 0–100 number derived from a stack of anchors. A bare EVM address with nothing attached is the floor. An ENS name nudges you up. A domain that serves a TLS-secured skill manifest pushes you higher. And a verifiable ERC-8004 agent identity record, indexed and cross-checked, lands you near the top of that band, and is the single biggest lever for your overall trust score.

Concretely, the scoring treats an erc8004Id as stronger evidence than a name and roughly on par with — and often ahead of — an ENS + live endpoint combination, because the on-chain record is auditable, timestamped, and not trivially transferable. The registry is the registry; you can't just register a new one for the same name and pretend.

Here's roughly how the check works when our probe runs:

  1. Resolve the agent's declared address and look up any erc8004Id attached to it on the registry contract.
  2. Fetch the URI from the on-chain record and confirm it resolves to a machine-readable surface — typically an AgentCard, MCP tool list, or skill.md.
  3. Verify the URI host serves a valid TLS certificate and is reachable within a bounded ~6s window.
  4. Cross-reference the declared capabilities in the card against the live probe output, flagging mismatches as risk deductions.

Each of those steps is auditable. The hash of the report is anchored on 0G Storage, the verdict is signed with the EVIDIQ key (EIP-191), and a complete write-up lives in the EVIDIQ Notary docs. Anyone holding a report can re-fetch the evidence, re-hash it, and recover the signer. The full integration patterns for running this yourself are in the EVIDIQ Sentinel docs and the EVIDIQ Operator docs — both worth reading if you're wiring trust checks into your own agent stack.

Should You Register One for Your Own Agent?

Short version: yes, if your agent ever receives funds, fulfills requests from strangers, or signs anything on behalf of a user. You're going to be on the receiving end of someone else's verify_agent call sooner than you think, and the cost of not having an identity record shows up in their score before it ever shows up in yours.

A few things a registered identity actually buys you:

  • A stable handle other agents can reference, even if you rotate keys.
  • A canonical place to publish your skill manifest or AgentCard that doesn't depend on your homepage URL staying alive.
  • Higher identity scores from any third party using the same standard — including EVIDIQ.
  • A dispute surface: when something goes wrong, the on-chain record is the first thing everyone looks at.

Registration is cheap. You mint a record, point it at your agent card, and you're done. The cost is the gas to write the entry; the upside compounds every time another agent decides whether to trust you. Without a record, you're an address. With one, you're a known counterparty with a public history.

If you're still in the "my agent is just a Telegram bot" phase, this might feel like overkill. It isn't. The moment your bot starts doing commerce — settling invoices, calling paid APIs, swapping tokens on behalf of a user — you have become an economic actor, and economic actors need identity. The EVIDIQ docs walk through how our scoring treats the difference; in practice, an agent with a registered ERC-8004 agent identity and a live, machine-readable endpoint sits in a different trust score tier than one without.

EVIDIQ blog illustration 2

Frequently Asked Questions

The Agent Skill and the install tools — how_to_install and get_evidiq_skill on the MCP server at EVIDIQ — are free and open source (MIT). The actual verify_agent call is paid per request via x402, settled on X Layer in USDT0. Pricing is per-call, and the 402 challenge follows x402 v2 so any compliant client can handle it without extra glue.

Give your agent the trust skill:

curl -s https://evidiq.dev/skill.md
E

EVIDIQ Team

The EVIDIQ team builds the trust layer for the AI agent economy — verifying agent identity and capability, scoring risk, and anchoring every verdict on-chain so agents can decide who to trust before value moves.

More from EVIDIQ Team →
ERC-8004 Agent Identity and Why EVIDIQ Checks For It — EVIDIQ