// Last updated 2026-05-13

ERC-8004 Validation Registry

The ERC-8004 Validation Registry is a request/response system for third-party agent scoring. Anyone can open a validation request against a named agent and a chosen validator; the validator submits a 0 to 100 score against a tag, written permanently onchain.

If you’ve read The three registries and want the full picture of the validation layer, this is the place.

Mainnet deployment status

The Validation Registry isn’t live on mainnet yet. The ERC-8004 working group is finalizing the contract with the TEE community. When the production address ships, we publish it in this article and the indexer picks it up the same week.

For now, mainnet agents show “Coming Soon” in their Validations column on /agents and on the per-agent page. There’s no validation activity to index because the contract doesn’t exist on those chains yet.

Testnets are different. The registry is deployed there, the indexer runs against it, and validation events for testnet agents show the same way feedback and identity events do. Turn on the Show testnets pill in the top nav to browse them.

The Identity and Reputation registries are live on every supported mainnet. Validation is the only piece still gated on an upstream deploy. When the address lands, the placeholder goes away in the same release. No flag, no migration. The canonical thread to follow is the EIP-8004 reference.

The request/response shape

A validation starts with a ValidationRequest event. The requester names the agent by agentId, picks a validator by address, and attaches a request URI/hash that points at the test specification or evaluation brief.

event ValidationRequest(
    address indexed validatorAddress,
    uint256 indexed agentId,
    string requestURI,
    bytes32 indexed requestHash
);

When the named validator submits their response, the contract emits ValidationResponse:

event ValidationResponse(
    address indexed validatorAddress,
    uint256 indexed agentId,
    bytes32 indexed requestHash,
    uint8 response,
    string responseURI,
    bytes32 responseHash,
    string tag
);

The requestHash ties the response to the original request. The response is a uint8 capped at 100. The responseURI is optional — a validator can point it at a detailed report or leave it empty — and responseHash can commit to the report content. Both events are onchain and readable by any observer without asking this explorer or any other aggregator.

Why request/response

Reputation feedback is a push model: a client interacts with an agent and posts a NewFeedback event at their own initiative. Anyone can do it at any time.

Validation is a pull model. The requester explicitly names a validator (a specific Ethereum address), and the contract only accepts a response from that address. The validator must act; no one else can fill the role.

This matters for use cases where the evaluator’s identity is load-bearing. A regulated financial agent might need a score from a named audit firm. A safety-certified agent might need a score from a red-team organization the end consumer already trusts. The request/response model lets the requester pick exactly who evaluates the agent, and the onchain record shows exactly who responded.

The requester pays gas to open the request. The validator pays gas to respond. No off-chain coordination is required. The contract handles that.

For contrast, the Reputation Registry collects feedback from any signer. Validation adds the named-party constraint.

Scores: 0 to 100

The Reputation Registry uses an int128 value plus uint8 valueDecimals, which lets clients encode score-like values and other metrics. Validation uses a stricter uint8 response in the range 0–100.

The wider integer range exists for the same reason a test suite uses a percentage: a validator certifying an agent for safety needs to express “passed 87 of 100 attack scenarios,” not just “passed” or “failed.” A binary result discards information that regulators, insurers, and agent orchestrators need to make decisions.

The score is capped at 100. A uint8 can hold values up to 255, but the contract rejects anything above 100 to prevent validators from accidentally or intentionally submitting out-of-range values. Once written, the score lives onchain indefinitely. There’s no expiry or decay; consumers who want to weight recent scores more heavily do so in their own indexing logic.

What “tags” mean for validation

Tags in the Validation Registry use the same string convention as the Reputation Registry’s primary tag1. That alignment is intentional. A client submitting safety feedback and a validator submitting a safety score are both tagging the same dimension, which lets aggregators query or compare across both sources.

Common tags for validation reflect the types of structured evaluation that make sense for agents: safety (resistance to adversarial inputs), accuracy (correctness against a defined test set), robustness (behavior under distribution shift), and cost-efficiency (compute or token consumption per task). Tags are free-form strings. The standard doesn’t enumerate them; indexers and consumers define which ones they recognize.

The requestURI is where the validation brief gets meaning. A request URI pointing at a published red-team protocol tells the validator what to run, and the response tag tells consumers which dimension was scored. Without the URI, “safety” is ambiguous. Attestation is only as useful as its test definition.

Validators on this explorer

The validators index on this explorer lists every address that has responded to a validation request across indexed chains. Each row shows the validator’s total request count, how many they’ve completed, how many are still pending, their average response time, and the number of unique agents they’ve evaluated. Filter by network to narrow the list to a single chain, then click into any validator to see their recent validations with the agent, tag, and response score on each row.

A validator with a thin history isn’t necessarily less capable. They may be new, or they may specialize in a tag that few agents have requested. The pending count on the index is often the more useful signal: a validator with twenty requests and zero completed is probably absent, while one with a high completion ratio and a low average response time is actively serving requests. History is context for the judgment, not a verdict.

Validators aren’t approved or listed by any central authority. If an address has submitted a ValidationResponse event, it appears in the index. Consumers decide independently whether they find a given validator credible. The standard only provides the onchain record.

Common failure modes

Validator never responds. The named validator address is locked at request time. If the validator goes offline, loses their key, or decides not to respond, the request stays open with no score. The contract has no onchain timeout in v1. There’s no escrow; payment and SLA terms are off-chain between the requester and validator. If a request sits unanswered, the requester’s only option is to open a new request to a different validator.

Validator collusion. A validator who is captured (paid to issue inflated scores, or acting as a shill for an agent they control) can submit maximum scores without the contract detecting anything wrong. The onchain mechanism only verifies that the response came from the named address. The guard against this is the validator’s own history. A validator who consistently scores every agent at 95–100 across all tags shows a pattern that any careful consumer will notice. The validators index on this explorer makes that pattern visible.

Tag mismatch. A “safety” validation means nothing if the validator ran a cost-efficiency test against it. The requestURI field exists specifically to anchor what the evaluation means in a given request. A response tagged “safety” against an empty or unrelated request URI produces an onchain score with no auditable basis. Consumers should treat unanchored validation requests as weaker signals than those with a published test definition at the URI.

Where to go next

• Hub: The three registries
• Sibling: Identity Registry
• Sibling: Reputation Registry
• Validators index: /validators
• Recent validations: /validations
• Cornerstone: What is ERC-8004?
• The canonical EIP: https://eips.ethereum.org/EIPS/eip-8004