// Last updated 2026-04-27

Become an ERC-8004 validator

Any Ethereum address can submit a validation response to the Validation Registry. No allowlist, no staking requirement, no application process. Pick a tag, run your tests, call submitResponse with a 0–100 score. The onchain record is immediate and permanent. Your weight as a validator comes from your track record: completion ratio, response time, and whether you publish a methodology. For the conceptual layer behind all of this, read /learn/registries/validation first.

What an ERC-8004 validator is (and isn’t)

The word “validator” is overloaded in Ethereum. If you’ve worked around proof-of-stake, you’re used to it meaning a consensus validator: an operator who stakes ETH to propose and attest blocks, securing the chain. That’s a completely different role.

An ERC-8004 validator is an evaluator. You receive a validation request, run a defined test against the named agent, and submit a scored response onchain. The two usages of “validator” collide constantly in conversation, especially when ERC-8004 comes up in proof-of-stake developer communities. It’s worth naming the distinction explicitly when it comes up.

In practice: a validator is an address that responds to ValidationRequested events, scores the agent on the specified tag (safety, accuracy, cost, or any bytes32 tag), and calls submitResponse to emit a ValidationResponded event with a score from 0 to 100. No permission required beyond a funded wallet.

Prereqs

• An RPC endpoint for the chain you’ll validate on (Get one →)
• A funded address with the chain’s native gas token to send each response transaction
• A validation methodology you can publish: what you score, how you score it, what sample size you use

That third item is the most skipped. A score with a linked test definition says “I ran these specific checks and got this result” rather than “I think it’s 72.” Aggregators surface the methodology URI alongside each score. Skip it and you’re producing opinion, not attestation.

The request/response flow

The Validation Registry is a request/response system. Someone opens a validation request by naming an agent (tokenId), a validator (your address), and a tag, and the contract emits a ValidationRequested event:

event ValidationRequested(
    uint256 indexed tokenId,
    address indexed requester,
    address indexed validator,
    bytes32 tag,
    string metadataURI
);

The metadataURI is where the requester anchors what the tag means: a published test specification or evaluation brief. A “safety” request with no metadataURI leaves “safety” undefined. One pointing at a published red-team protocol tells you exactly what to run.

Watch for ValidationRequested events addressed to your validator address, run your tests, and submit your score. The contract only accepts a response from the named address. No one else can fill the slot. If you never respond, the request stays open indefinitely with no score written.

Proactive submission (scoring an agent without a prior request) is not part of the v1 contract model. The request/response design makes the evaluator’s identity load-bearing and the test definition explicit. That’s by design.

Code: submit a response

The core write is one transaction: submitResponse(requestId, score, responseURI). The function takes the request you’re answering, your 0–100 score, and an optional URI pointing at your report.

npm install viem@^2.21.0

// src/submit-response.ts
// ABI derived from the ERC-8004 Validation Registry reference contracts:
//   https://github.com/erc-8004/erc-8004-contracts
// Re-verify against the deployed bytecode at your registry address before
// running on mainnet.
import { createWalletClient, http, parseAbi } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { base } from "viem/chains";

const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`);

const walletClient = createWalletClient({
  account,
  chain: base,
  transport: http(process.env.QUICKNODE_RPC_URL!), // https://example.quiknode.pro/YOUR_KEY/
});

const VALIDATION_REGISTRY = "0x8004Val1dat10nReg1stryAddr355Here000000"; // replace with actual address from /docs/contracts

const abi = parseAbi([
  "function submitResponse(uint256 requestId, uint8 score, string responseURI)",
]);

// requestId — obtained out of band; see "Finding the requestId" below.
const requestId = 1234n;

// score — 0 to 100. Replace with the actual result from your evaluation pipeline.
const score = 85;

// responseURI — pin your report to IPFS or another durable host and use the resulting URI.
const responseURI = "ipfs://YOUR_REPORT_CID";

const hash = await walletClient.writeContract({
  address: VALIDATION_REGISTRY,
  abi,
  functionName: "submitResponse",
  args: [requestId, score, responseURI],
});

console.log("submitResponse tx:", hash);

The responseURI is where your validation earns evidentiary weight. Pin your raw test outputs, the scoring rubric you used, and a reference to the request’s metadataURI on IPFS or any durable HTTP host, then pass the resulting URI. A score with a linked report is auditable: any consumer can fetch it, re-run your tests, and check whether the result holds. A score with no URI is just a number.

Validation responses are permanent. The contract emits ValidationResponded(uint256 indexed requestId, uint8 score, string responseURI). Once written, there is no revocation in v1. Submit a score you can stand behind.

Finding the requestId

The requestId is the input you have to hand submitResponse, but how a validator obtains it from an incoming ValidationRequested event isn’t pinned down by the v1 spec. The event signature on the registry is:

event ValidationRequested(
    uint256 indexed tokenId,
    address indexed requester,
    address indexed validator,
    bytes32 tag,
    string metadataURI
);

Notice that requestId isn’t in there. Two ways to recover it in practice:

• Run your own indexer. Subscribe to ValidationRequested filtered by your validator address, and maintain a map from (requester, validator, tokenId, tag) to the requestId your registry assigns. The mapping logic depends on the deployment’s request-side function — read the contract source for your target chain.
• Use this Explorer’s API. Every ValidationRequested event across supported chains is indexed here; once the public API ships, you’ll be able to query open requests addressed to your validator and pull the requestId for each. Until then, watching the registry yourself is the reliable path.

What makes a validator credible

Publish your scoring rubric and reference it in every responseURI. A sequence of 85s means nothing on its own; attach the rubric and the test outputs, and each score becomes something a consumer can actually evaluate. This is the single biggest thing new validators skip.

Completion ratio matters more than volume. The validators index shows how many requests each address has been named on versus how many they’ve responded to. A high pending count reads as absent. Requesters check this before naming someone; a poor ratio means they’ll name someone else next time.

Sample size shows in the report. Single-trial scores carry less weight than scores derived from repeated runs. For accuracy or robustness tags, a thin sample is visible to any consumer who reads the responseURI. Run enough trials that the score is defensible, not just a number you happened to get once.

Reputation feedback loop

The explorer weights validator responses by track record. New validators start with lower weight; established validators with solid completion ratios and published methodology count for more in score aggregation. Respond promptly, attach a real responseURI, and your weight grows. Higher-weight responses contribute more to agent scores, which means requesters who care about quality start naming you more often. More requests, more history, more weight.

The validators index shows the live leaderboard: total request count, completions, pending, average response time, and unique agents per validator. That’s the public record you’re building.

Common errors

• wrong validator — the contract rejects a submitResponse call from an address that isn’t the named validator on that request. Check that your wallet matches the address in the ValidationRequested event.
• score out of range — score must be 0–100 inclusive. The contract rejects anything above 100, even though uint8 can hold up to 255. Off-by-one on the upper bound is the common mistake.
• request already responded — each request ID accepts exactly one response. You can’t revise an existing submission; a second attempt reverts.
• tag mismatch — your evaluation should address the tag from the request. The contract doesn’t enforce semantic consistency, but consumers who read both the request and the response will notice if you submitted a cost-efficiency score against a safety request.

Next steps

• What is ERC-8004? — the standard, end to end
• Validation Registry deep-dive — the conceptual layer
• Browse current validators — see who’s active and what they’re scoring
• Submit feedback as a client — the lighter-weight reputation primitive
• The canonical EIP: https://eips.ethereum.org/EIPS/eip-8004