# ERC-8004 gives an agent a name and a place to post reviews. It cannot tell you the agent is honest.

A team is wiring an agent marketplace, and ERC-8004 looks like the piece that makes it safe. The pitch is right there in the name — "Trustless Agents" — and the structure is reassuring: three on-chain registries, Identity, Reputation, and Validation, deployed as smart contracts any counterparty can read without asking a central directory for permission. An agent gets a permanent handle. Other agents post feedback against that handle. And a Validation Registry sits alongside the other two, named for exactly the thing a marketplace fears most: how do you know the agent will actually do what it says. Three registries, one of them called Validation. The trust problem looks solved by construction.

It is not, and the standard says so in its own text. The same EIP that defines the three registries concedes — in a sentence the spec puts there deliberately — that while it cryptographically ties an agent's registration file to its on-chain handle, it "cannot cryptographically guarantee that advertised capabilities are functional and non-malicious." The Identity Registry tells you who the agent is. The Reputation Registry tells you what others said about it. The Validation Registry, despite the name, does not run a check or verify one — it records that some external validator returned a response, and stores the hash. The half a marketplace actually needs — is this agent honest and competent — is in none of the three registries. It is deferred to "pluggable" external trust models the standard explicitly scopes out, and that are themselves unstandardized and mostly unbuilt.

"On-chain agent identity" standardizes the easy half — who the agent is, and what others claim about it — and punts the half that matters to an empty socket.

This post is about that socket: what each registry actually asserts, why the Validation Registry records rather than validates, what the EIP's own text scopes out and why that exclusion is the whole story, and what a team has to add before "ERC-8004 verified" means anything load-bearing.

## What each registry asserts, stated exactly

Start with what the three registries claim, because the word "trustless" in the title is doing more work than the contracts behind it.

ENS, in its own write-up of the standard, describes ERC-8004 as "a standardized, onchain trust framework made of three registries: Identity, Reputation, and Validation." That is the structure every explainer agrees on. The question is what each registry's output actually proves.

The Identity Registry resolves a handle to a registration file: a minimal, ERC-721-style mapping from an on-chain agent ID to an off-chain record of capabilities, endpoints, and keys, with the record hashed on-chain so it cannot be silently edited. This is the part that works as advertised, and the cryptography is real — the registration file provably corresponds to the on-chain agent. But notice what that proves. It proves this handle published this manifest. It does not prove a single claim _inside_ the manifest. Composable Security, a smart-contract-audit firm, puts the boundary plainly: "Registration connects identity to endpoints; it does not by itself prove that an agent fulfills its advertised capabilities." A manifest can advertise anything. The registry binds the manifest to the handle, not the claims to reality.

The Reputation Registry is an interface for posting and fetching feedback. Allium, an on-chain-data firm, frames its output precisely: "the Reputation Registry records what others say about" an agent. That is the exact shape of the guarantee — third-party assertions, not a correctness proof. "Alice's agent gave Bob's agent four stars" is a fact about what Alice's agent said, not about whether Bob's agent is any good, and the registry claims only the former. Worse, it is gameable by default: BuildBear, a developer-tooling firm, notes that "Sybil attacks remain possible," and that the fix — "specialized reputation aggregators" applying "sophisticated spam detection and reviewer scoring" — is anticipated off-chain work, not part of the standard. So the reputation half ships "what others said," with the de-Sybiling that would make it trustworthy left to systems nobody has standardized.

That leaves the Validation Registry, which is named for the guarantee the other two cannot make. It is the one that has to carry the weight. It does not.

## The Validation Registry records a check; it does not run one

Read what the Validation Registry actually does, because its name promises a verb it does not perform.

The EIP describes it as "generic hooks for requesting and recording independent validators checks (e.g. stakers re-running the job, zkML verifiers, TEE oracles, trusted judges)." Parse that slowly. The registry's job is _requesting and recording_. The checking is done by "independent validators" — entities outside the registry. The registry is the message board on which a request goes up and a response comes back; the validator is whoever, off-stage, allegedly did the work.

The contract makes this concrete. Its two operations are a validation request and a validation response, and what it persists is metadata: the EIP specifies that "the contract stores `requestHash`, `validatorAddress`, `agentId`, `response`, `responseHash`, `lastUpdate`, and `tag` for on-chain querying and composability." It stores _who_ the validator claims to be, _which_ agent was checked, and a _response_ with its hash. It does not store, because it cannot, any guarantee that the validator ran the check, ran it correctly, or ran it at all. The on-chain record is a receipt that a response was posted — not evidence that the response is true. BuildBear states the design intent without flinching: the registry is "validator-agnostic, supporting diverse verification approaches." Validator-agnostic means it enforces none of them.

Backpack Learn's guide lands on the same reading, describing the registry as "generic hooks for requesting and recording independent validator checks through crypto-economic staking mechanisms, zkML proofs, or Trusted Execution Environment (TEE) oracles." The grammar is identical across every independent explainer: the registry _routes to_ validators; it is not itself a validator. It is a socket. The thing that validates is the plug — and the plug is not in the box.

## The exclusion is the whole story

Here is the sentence that turns "the registry doesn't validate" from a quibble into the thesis. The EIP does not merely omit the validating mechanism. It explicitly excludes the part that would make any validating mechanism _mean_ something.

A validator's response is only worth checking against if the validator has something to lose by lying. That something — the stake, the slashing, the economic skin in the game — is precisely what the standard scopes out. In the EIP's own words: "Incentives and slashing related to validation are managed by the specific validation protocol and are outside the scope of this registry." That is the empty socket, verbatim. The registry standardizes the _shape_ of a request and a response and hands the economic security — the only thing that makes a validator's "looks good to me" credible — to "the specific validation protocol," which is to say, to software someone else has to write.

This is not one source's hostile interpretation. It is the consensus reading across every independent reviewer. Composable Security: "Multiple validation models can coexist. Incentives, staking, and slashing logic are outside the standard." BuildBear: "The Validation Registry doesn't define validator economics, incentives and slashing are managed by specific validation protocols built on top of the registry." Allium: "ERC-8004 does not mandate a single validation technique; it defines a common interface so multiple validation mechanisms can coexist." Three firms — an auditor, a tooling vendor, a data vendor — independently describe the same hole, in nearly the same words.

The standard's _own framing_ confirms the half it ships is not the half that matters where stakes are real. The EIP says trust models are "pluggable and tiered, with security proportional to value at risk, from low-stake tasks like ordering pizza to high-stake tasks like medical diagnosis," and that "developers can choose from different trust models: reputation systems using client feedback, validation via stake-secured re-execution, zero-knowledge machine learning (zkML) proofs, or trusted execution environment (TEE) oracles." Read that as a menu: the cheap option, reputation, is the one the standard ships. The three that would secure a high-stakes interaction — stake-secured re-execution, zkML, TEE oracles — are the ones it defers. Allium says the consequence out loud: "For higher-stakes interactions, reputation alone is insufficient." So the standardized half is adequate for ordering pizza, and the medical-diagnosis half is the empty socket. The tiering is honest; the upper tiers are just interfaces waiting for implementations.

Composable Security closes the loop: "Any verification approach — re-execution, proofs, or attestations — can plug in." _Can_ plug in. The verb is permissive, not present-tense. The standard makes the plug _possible_; it does not make it _exist_.

## The plug is hard, and not because nobody has tried

It would be easy to read this as "the standard is half-finished, give it a year." That underrates the problem. The deferred half is not deferred because it is tedious. It is deferred because the three candidate plugs are each genuinely hard, and one of them runs into a wall no amount of cryptography moves.

The three families the EIP names map to three mature-but-costly techniques. Stake-secured re-execution means a staker re-runs the agent's job and is slashed if its result disagrees — which works only for deterministic, cheaply-reproducible work, and an LLM agent's output is neither. zkML means producing a zero-knowledge proof that a specific model produced a specific output: real research, but expensive and limited in model size. TEE oracles mean trusting that hardware ran the model in a tamper-resistant enclave — which moves the trust to the chip vendor and the enclave's security, and says nothing about whether the model's _answer_ was any good.

That last gap should worry anyone treating a future Validation Registry plug as a solution. Even a perfect tamper-resistant substrate does not buy a reliable agent. Peer research on self-sovereign decentralized AI agents — built on exactly the blockchain-and-TEE primitives ERC-8004's validators would lean on — finds the substrate and the agent's reliability are different axes. It observes that these "tamper-resistant trustless substrates allow agents to achieve self-sovereignty through ownership of cryptowallet private keys and control of digital assets and social media accounts" — they deliver _control and ownership_. But it identifies a structural tension underneath: "given ongoing challenges in LLM reliability such as hallucinations, this creates paradoxical tension between trustlessness and unreliable autonomy." (The paper does not name ERC-8004; it is adjacent evidence for the general point.) A TEE can prove the model ran untampered and still hand you a confident hallucination. The cryptography certifies the _execution_, not the _answer_. So even the strongest plug on the menu — a TEE oracle — secures the wrong layer for the honesty question. The socket is empty, and the most-built plug, once installed, still does not check the thing the marketplace was afraid of.

## What this post is not claiming

Three qualifications, because the version of this argument that overstates loses the reader who knows the standard.

First, the Identity Registry's cryptography is real and the critique does not touch it. The registration file _does_ provably correspond to the on-chain agent; the hash binding is sound. The claim is narrow: binding a manifest to a handle is not the same as proving the manifest's claims, and "trustless identity" delivers the former while the name suggests the latter. The [existing ERC-8004 walkthrough](/blog/erc-8004-agent-identity/) covers what the identity layer does well; this post is only about the layer above it.

Second, "empty socket" is a statement about the standard today, not a verdict on the ecosystem's future. The EIP is deliberately a _minimal interface_, and minimal interfaces that get adoption can have rich plugs built into them later, exactly as intended. Stake-secured re-execution networks, zkML verifiers, and TEE-oracle services may well arrive and snap into the registry's hooks. The point is precise and present-tense: today the socket is standardized and the plug is not, so "my agent is in the Validation Registry" asserts that a response was _recorded_, not that a check was _passed_.

Third, deferring economic security to a separate layer is a defensible design choice, not a bug — keeping incentives and slashing out of a base identity standard is arguably correct, the same way [ERC-8004 leaves payments to x402](/blog/erc-8004-agent-identity/) rather than bundling them. The error this post targets is not the standard's modularity. It is the reader who sees a registry named "Validation" and concludes the validating is done.

## What "ERC-8004 verified" has to mean before you trust it

The fix is not to wait for a better standard. It is to stop reading the standardized half as the whole, and to supply the deferred half yourself — at the application layer — until the plugs exist.

**Treat an Identity Registry entry as a name, not a warrant.** A handle resolving to a manifest proves the handle published the manifest, and nothing in it. Write down that "registered" means "identifiable," not "trustworthy" — the discipline the [agent identity stack](/blog/agent-identity-stack/) demands when it separates an identifier from the credentials and authorization above it.

**Read a Validation Registry receipt as "a validator responded," never "a check passed."** The record stores a response hash and a validator address. Before you weight it, ask what the registry cannot: _who is this validator, what did it run, and what does it lose if it lied?_ If you cannot answer the third part, the receipt is a claim, not a check.

**Supply the economic security the standard scopes out, or do not lean on validation.** Either point at a specific validation protocol that _does_ stake and slash its validators — and understand that protocol's security yourself — or treat the registry as decorative and decide on other grounds. There is no middle setting where the bare registry secures you.

**De-Sybil reputation yourself.** "What others said" is gameable by colluding handles, and spam detection and reviewer scoring are left to off-chain aggregators outside the spec. Require attestations from distinct, independently-reputable sources, or use a published aggregator — your job, not the registry's.

**Match the trust tier to the value at risk, the way the EIP says.** Reputation alone is fine for low-stakes, reversible tasks. For high-stakes work the standard itself says reputation is insufficient — so an interaction backed by _only_ identity and reputation, with the Validation socket empty, is under-secured by the standard's own tiering.

**Remember the substrate is not the answer.** Even a TEE-oracle plug, once it exists, certifies the model ran untampered, not that it was right. Execution guarantees do not close the hallucination gap. Keep a human checkpoint on consequential, irreversible actions regardless of what the registry says.

## The checklist

Before you call an "ERC-8004 verified" agent trustworthy:

- [ ] An Identity Registry entry is treated as proof of _identity_ — handle resolves to manifest — and explicitly not as proof of any claim inside the manifest.
- [ ] A Validation Registry receipt is read as "a validator posted a response," and the validator's identity, method, and stake-at-risk are interrogated before the receipt is weighted.
- [ ] The specific validation protocol supplying economic security — staking, slashing — is named and its security understood; absent that, validation receipts are not load-bearing.
- [ ] Reputation signals are de-Sybiled by your own aggregation, not consumed raw, since spam detection is outside the standard.
- [ ] The trust tier matches value at risk: high-stakes interactions are not backed by identity-plus-reputation with the Validation socket empty.
- [ ] It is documented that a TEE/zkML/re-execution plug, even once present, secures execution — not the correctness or honesty of the model's output.
- [ ] Consequential, irreversible actions retain a human checkpoint regardless of any on-chain trust signal.

## Reading list

- [ERC-8004: Trustless Agents](https://eips.ethereum.org/EIPS/eip-8004) — the primary source: defines the three registries and concedes in its own text that it cannot cryptographically guarantee an agent is functional or non-malicious, with incentives and slashing explicitly outside the registry's scope.
- [ERC-8004: a practical explainer for trustless agents](https://composable-security.com/blog/erc-8004-a-practical-explainer-for-trustless-agents/) — an audit firm's reading that registration does not prove an agent fulfills its capabilities, and that incentives, staking, and slashing are outside the standard while any verification approach merely "can plug in."
- [ERC-8004: Trustless Agents with Reputation, Validation & On-Chain Identity](https://www.buildbear.io/blog/erc-8004) — a tooling firm's explainer confirming the registry is validator-agnostic, defines no validator economics, and leaves Sybil-resistant reputation aggregation to off-chain systems not part of the spec.
- [ERC-8004 Explained: Ethereum's AI Agent Standard Guide 2025](https://learn.backpack.exchange/articles/erc-8004-explained) — quotes the EIP's core limitation verbatim and confirms the Validation Registry is request/record hooks delegating to three external mechanism families: staking, zkML, and TEE oracles.
- [Onchain AI Identity: What ERC-8004 Unlocks for Agent Infrastructure](https://www.allium.so/blog/onchain-ai-identity-what-erc-8004-unlocks-for-agent-infrastructure/) — frames the Reputation Registry as recording "what others say," and concedes the standard mandates no validation technique and that reputation alone is insufficient for higher-stakes interactions.
- [The Identity Problem in Agentic Commerce: How ENS Can Enable Trust for AI Agents](https://ens.domains/blog/post/ens-ai-agent-erc8004) — describes ERC-8004 as a three-registry trust framework and treats "whether an agent is trustworthy" as a concern layered on alongside payment and naming, not something the identifier settles.
- [Trustless Autonomy: Understanding Motivations, Benefits, and Governance Dilemmas in Self-Sovereign Decentralized AI Agents](https://arxiv.org/abs/2505.09757) (arXiv 2505.09757) — peer research showing tamper-resistant blockchain/TEE substrates deliver self-sovereignty and control, but not reliability, because LLM hallucination persists underneath the cryptography.

The team saw a registry named "Validation" and reasonably assumed something gets validated. What the registry does is take a request, record a response, and store the hash — a receipt that a validator spoke, not a verdict that the agent is honest. The standard says as much in the open: it binds the manifest to the handle and concedes it cannot guarantee the agent is functional or non-malicious, and it pushes the stake-and-slash machinery that would give a validator's word weight to "the specific validation protocol," which nobody has yet shipped as a production validator. So ERC-8004 standardizes who the agent is and what others said about it, and leaves the one question a marketplace actually has — is this agent honest and competent — to an empty socket. The identity half is good and worth adopting. Just do not mistake a name and a pile of reviews for a guarantee. Until something is plugged into the Validation socket, "ERC-8004 verified" tells you the agent exists and has opinions attached. It does not tell you the agent is honest.