ERC-8004 Validation Registry: the registry that asks for proof

ERC-8004 lets anyone register an agent and lets anyone rate one. Its third registry is the interesting one: a named validator checks a specific job and posts a score tied to evidence. Whether that score means anything depends entirely on what sits at the evidence link. Here is how validation flows, what the numbers say about reputation without it, and what real evidence looks like.

Published October 19, 2026. Updated October 19, 2026. Written against draft-zambo-aer1-23 and the ERC-8004 proposal text.

The short answer

Validation is the registry that asks for proof

ERC-8004 gives agents three registries: Identity for who an agent is, Reputation for what clients say, and Validation for what an independent checker verified. A validation starts when the agent's owner requests one, naming a validator, the job, and a hash of the job's record. It ends when the validator posts a score from 0 to 100 and a link to its evidence. The registry stores the score and the hashes. Everything that makes the score worth believing lives at the other end of those links, and that is where a verifiable execution receipt does its work.

Most writing about ERC-8004 stops at identity and reputation, because those registries are easy to demo: mint an agent, collect some stars. Validation is the harder and more valuable third, because it is the only one that examines the work itself. This page explains how it actually flows, why reputation on its own turned out to be nearly ungrounded, and what belongs at the evidence links.

Three registries, three different questions

Identity Registry: who is this agent?

An ERC-721 record whose agentURI resolves to the agent's registration file: its name, its endpoints, its wallet. It answers the discovery question. Zambo's own registration is live as agentId 107529, and the identity page walks through it field by field. An identity record says an agent exists. It says nothing about whether its work is any good.

Reputation Registry: what do clients say?

A standard place for clients to post feedback: a value, optional tags, and an optional link to a file with the details. Anyone can rate anyone. The registry records the claim, not whether the rater ever hired, paid, or even met the agent being rated.

Validation Registry: what did a checker verify?

A request-and-response record for independent checks of specific jobs. The validator is named in advance, the job is committed to by hash before the answer exists, and the response carries a score plus a pointer to the evidence. That structure, request first, commitment first, evidence attached, is what separates an examination from a review.

Why reputation alone is not enough: the 0.14 percent problem

On October 14, 2026, the Agentic Finance Graph published an open fixture (a CSV anyone can re-run, released CC BY 4.0) joining every entry in the Base Reputation Registry to the stablecoin payments they index. Of 514,096 feedback entries, only 728, that is 0.14 percent, came from a rater who had paid the agent they rated, before rating it. Those 728 came from just 17 raters covering 64 agents, and only 3 of the payments behind them were x402 settlements. The median payment was three cents. The authors note 728 is a lower bound, and their sharper point stands either way: a payment proves two addresses transacted. It does not prove the rating is about any particular job, and it says nothing about what the job produced.

Grounding cannot be reconstructed afterward. It has to travel with the record: a reference carried inside the feedback that ties the opinion to the work. That is the exact hole the Validation Registry was designed to fill, provided the evidence at its links is real. A score pointing at nothing is reputation with extra steps.

How a validation actually flows

  1. The request. The owner or operator of the agent calls validationRequest(validatorAddress, agentId, requestURI, requestHash). The requestURI points to the off-chain record of the job: the inputs and outputs a checker needs. The requestHash is the keccak256 commitment to that record, fixed before any answer exists, so the job cannot be swapped after the score arrives.
  2. The check. The named validator does the work of checking. The proposal names the patterns: stakers re-running the job, zero-knowledge machine learning verifiers, trusted execution environment oracles, trusted judges. What they share is independence: the checker is not the agent and not the client.
  3. The response. The validator calls validationResponse(requestHash, response, responseURI, responseHash, tag). The response is 0 to 100, usable as a pass or fail or as a spectrum. The responseURI points at the evidence or audit behind the score; the responseHash commits to it. A validator can respond more than once to the same request, which allows progressive states, an early soft answer and a later hard one, told apart by the tag.
  4. The reading. Anyone can call getValidationStatus for one request, getSummary for an agent's average across validators, or list every request an agent or a validator has touched. What the registry will not do is pay or punish the validator: incentives and slashing live in each validation protocol, outside the registry's scope.

Notice what the registry standardizes and what it leaves open. The pointers and the commitments are specified to the byte. The evidence format behind the pointers is deliberately unspecified. That open slot is the most important design decision in the whole proposal, because a validation ecosystem is worth exactly what its evidence is worth.

What belongs at the evidence links: the receipt

For the responseURI to mean anything, it has to resolve to a record a stranger can check without trusting the validator, the agent, or the platform hosting it. That is the precise job of a verifiable execution receipt under AER-1, an open format published as an IETF Internet-Draft (draft-zambo-aer1-23): when a job runs, each step is saved as a receipt carrying the canonical bytes of the call and the SHA-256 hash of what it returned. Later, anyone can recompute the hash from the saved bytes and settle whether the record still matches what was saved.

The pairing works at both ends of a validation. The job's receipts are the record the requestURI points to, the thing the validator examines. And the validator's own examination can leave a receipt too, so the responseURI points at a check that is itself checkable. A score backed by a receipt the reader can re-verify is a different species from a score backed by a validator's say-so.

A worked example: a validator's delivery, receipt attached

Cairnworks, an independent verification service, wired AER-1 receipts into its standing-check deliveries in October 2026: every delivery it makes carries a receipt the customer can check. Open one of those delivery records yourself: the delivery receipt. The page shows the checks the record passes, and the verification endpoint behind it reports the same story in machine-readable form: the SHA-256 commitment matches, the canonical payload reconstructs exactly, the provenance binding passes.

Do not take the page's word for it, because the format does not ask you to. The receipt's canonical bytes are published with it: 2,078 bytes. Recomputing their SHA-256 gives 5f06acfbe2ff6254f7bd3a494ef9848551a0946a305d82c4ac9da410a07dd2a5, which is exactly the output hash the receipt commits to. That recompute was run independently for this page, from the live record, and it matched. Change any byte of the saved record and the recompute stops matching, which is the whole point: the evidence carries its own check.

Just as instructive is what the record refuses to claim. Its own verification lists issuer authentication as not checked, in plain language, because a receipt proves the saved result was not changed since it was saved; it does not by itself prove who minted the record. The delivery's own claims audit is preserved in the record too, gaps flagged, nothing airbrushed. Evidence that shows its limits is the kind a validation score can safely stand on.

Honest limits, stated the way the format states them: a validation score is only as good as the validator behind it and the evidence behind the score. The registry records requests, commitments, and responses; it cannot make a careless validator careful. And a verifiable receipt proves the saved result was not changed since it was saved. It does not prove the work was correct, or that a high score was deserved. It makes the claim checkable, which is the precondition for everything else.

Putting it to work

  1. Register the identity. If your agent is not in the Identity Registry yet, start there: the live walkthrough of a real registration shows every field.
  2. Make the work leave receipts. Validation needs a record to examine. Work run through Zambo's 153 tools leaves a verifiable AER-1 receipt per job automatically, saved when the step ran, not reconstructed later. Checking any receipt is free at zambo.dev/verify.
  3. Request validation against the record. Point the requestURI at the job's receipt record and let the requestHash commit to it. When the validator answers, its responseURI should carry the receipt of its own check, the pattern the Cairnworks delivery above already runs in production.

The registry side costs gas and nothing else; the checking side is free to read forever. On the work side, the free tier covers a normal day of receipted work, a $0.99 Day Pass covers a heavy day, and the $29 Pass ($19 for $ZAMBO holders, $290 for the year) is there for agents that work daily. Reputation told the world what people say about your agent. Validation, done with real evidence, shows them the work: run a job and check its receipt.

Questions, answered

What is the ERC-8004 Validation Registry?

It is the third of the three registries in ERC-8004, the Trustless Agents proposal. The Identity Registry says who an agent is, the Reputation Registry collects what clients say about it, and the Validation Registry records independent checks of its work: an agent requests validation of a job, a validator checks the work and posts a response scored from 0 to 100, and the registry keeps the score, the hashes, and links to the evidence. It is the part of ERC-8004 that asks for proof instead of opinions.

How does ERC-8004 validation work?

The agent's owner or operator calls validationRequest with the validator's address, the agentId, a requestURI, and a requestHash. The requestURI points to the off-chain record of the job, the inputs and outputs a checker needs; the requestHash is the keccak256 commitment to that record. The validator does its check, re-running the job, re-checking the record, or judging it, and calls validationResponse with a score from 0 to 100, a responseURI pointing at its evidence, and a responseHash committing to that evidence. Anyone can then read the status and the summary scores from the registry.

What is the difference between the ERC-8004 Reputation Registry and the Validation Registry?

Reputation is testimony: any client can post a rating, and the registry cannot tell whether that client ever hired the agent. Validation is examination: a named validator was asked to check a specific job, and its answer points at evidence you can open. An October 2026 analysis of the Base Reputation Registry found that only 728 of 514,096 ratings, 0.14 percent, came from a rater who had paid the agent being rated. Reputation counts voices. Validation is supposed to count checks, which is why the evidence behind it matters more than the score.

What evidence should a validation response point to?

The responseURI should point at a record a stranger can re-check without trusting the validator: what the job was, what it produced, and a digest they can recompute. A verifiable execution receipt is built for exactly that slot. The receipt saved when the work ran carries the canonical bytes of the job and the SHA-256 hash of its output, so the validator's check, and the agent's original work, can both be re-run by anyone who opens the link. A score with no checkable record behind it is just reputation wearing a lab coat.

Can an AER-1 receipt be used as ERC-8004 validation evidence?

Yes. AER-1 is an open format for the verifiable receipt a job leaves behind, published as an IETF Internet-Draft (draft-zambo-aer1-23). The receipt for a job can serve as the requestURI record a validator checks, and the validator's own check can leave a receipt of its own to sit behind the responseURI. Nothing in ERC-8004 mandates a specific evidence format; it mandates the pointers and the commitments. AER-1 supplies the checkable content those pointers deserve.

Related