ERC-8004 is a draft Ethereum standard for agent identity, reputation and validation records. It helps buyers connect an agent to evidence about its work. Registration alone does not establish competence or authorize a payment.
ERC-8004 proposes shared onchain records for agent identity, feedback and validation. Those records can help software discover an agent and inspect evidence about its work. A registration doesn't certify competence, and a large reputation score still needs interpretation.
The Ethereum specification was marked Draft when reviewed on October 13, 2026. Implementations and interfaces should therefore be checked against the exact version in use. The useful idea is portable evidence that services can evaluate, with the evaluation still depending on the task.
Identity gives the agent a reference
The identity registry uses an ERC-721-based identifier linked to a registration file. Its full reference includes the chain, registry address and agent ID, so agent 42 in one registry isn't confused with agent 42 elsewhere. The owner can update the record or transfer the identity under the design's rules. ERC-8004 specification.
For a buyer, the reference helps distinguish a named agent from a copied website label. It can provide a common identifier across directories and service interactions. The endpoint still needs checking: a description can claim capabilities the service doesn't deliver.
Consider two agents both calling themselves “Treasury Research Assistant.” A persistent registry identifier lets a buyer connect earlier feedback to the intended service rather than rely on the name. That is useful even when the actual computation happens outside a blockchain.
The registration also has an owner and update authority. A familiar identity can later point at a different endpoint or operator. Transferring it clears the registered receiving wallet, which the new owner must verify again. The buyer should know which changes occurred since the work used to judge it.
An agent identifier is only one trust signal
ERC-8004 separates registration from reputation and validation.
Agent identifier
A reference that connects the relevant records
Registration and service information.
Feedback records with context and attribution.
Validation requests and responses under a chosen model.
Conceptual view of the draft standard reviewed in the article. Deployment and validation models must be checked separately.
Discovery and payment are separate layers
The standard doesn't define the payment system. It can coexist with x402 or another payment route, but an agent being registered doesn't establish that a particular invoice or transaction is authorized.
The wallet used to receive money is also an assertion requiring its own control checks. The specification describes a proof-of-control process for changing the registered receiving wallet. That helps bind the wallet to the identity without proving that the service behind it is trustworthy. Identity and wallet binding.
MCP and other agent interfaces describe ways to advertise or invoke capabilities. A payment protocol describes a commercial exchange. The identity record gives those interactions a reference that can be tracked over time.
Keeping the layers separate prevents a dangerous shortcut: “registered agent” becoming a reason to approve any spending request. Our wallet-control article explains why the signer still needs an independent policy.
Feedback is evidence to evaluate
The reputation registry records feedback signals linked to an agent. Its interfaces allow tagged feedback and references to additional evidence. Applications can aggregate those signals using their own methods rather than assuming one universal score. Reference contract specification.
For a buyer, the important detail is the work the feedback describes. A positive result for image generation says little about the same agent's ability to reconcile financial records. Task tags and endpoint references can keep unrelated experience from being blended together.
Timing matters too. Older feedback can concern a different model, service version or operator. A history of successful tasks is more useful when the buyer can connect it to what the agent will run now.
The trust-signal visual below organizes questions about feedback quality. It doesn't assign a numerical score to real agents or claim that a set of checkboxes can establish honesty.
A reputation number needs a denominator
Imagine one agent with many enthusiastic reviews from a closely connected group of wallets. Another has fewer reviews but provides reproducible job evidence from independent customers. The larger count doesn't settle which one deserves the next task.
Inspect who supplied the feedback and whether the work can be checked. A payment accompanying a review can show an interaction under the payment mechanism. It doesn't prove the purchase was economically independent or the result was good.
Cheap self-funded purchases can manufacture activity. Preventing an owner from reviewing its own agent doesn't stop the owner from controlling other addresses. Reputation consumers need a model for those relationships and the cost of fake activity.
The right denominator depends on the task. For a specialist agent, successful jobs of the same type can be more relevant than total interactions. For a service with safety-critical output, generic customer satisfaction is an incomplete quality test.
Validation has to name the claim
The validation registry provides hooks for requesting and recording checks by independent validators. A particular implementation might use re-execution, a proof system or another assessment method. Validation registry design.
Ask exactly what the validator checked. Reproducing a computation from fixed inputs can establish that the output followed those inputs and rules. It doesn't automatically prove that the original inputs were complete or truthful.
For a research agent, a useful check could test citations against a supplied source set. That leaves another question: whether the source set omitted relevant evidence. A valid check should make its scope visible to the buyer.
The validator has its own competence and incentive questions. An onchain response makes a record inspectable. It doesn't remove the need to understand how the response was produced.
Choose the evidence for the job
For a cheap, reversible data lookup, a buyer may tolerate a service with a short history and verify the result afterward. For a large financial instruction, it can require stronger controls and human approval. The same identity system can support different trust policies.
This is a practical reason to avoid a single “trusted agent” badge. A service can be suitable for one workflow and unsuitable for another. The permissions it receives should reflect that difference.
The agent's spending authority also needs a separate limit. Selecting a reputable data service doesn't grant your purchasing agent an unlimited budget, and identifying the purchasing agent doesn't guarantee it chose a good price.
Selling data to agents examines what a seller can disclose to make that choice easier. Clear capabilities and verifiable delivery can provide stronger commercial evidence than an inflated score.
What I would inspect in a registry demo
Show the identity record, its current owner and endpoint history. Then open a piece of feedback and the work it refers to. If validation exists, identify the checked claim and the party responsible for the check.
Next, change an endpoint or transfer the identity in a test environment. The buyer should be able to distinguish the old reputation context from the new operating setup. A portable identifier is useful only if the changes around it remain understandable.
ERC-8004 supplies a place to attach evidence. Better selection comes from the buyer's ability to interpret that evidence for a specific task. Payment remains another layer, covered in the x402 introduction.
Compare the same job before comparing reputation
Imagine Agent A has feedback on 1,000 image-generation jobs. Agent B has feedback on 40 company-filing extraction jobs. For a filing-research task, A does not become the better candidate simply because its count is larger.
Inspect task tags, the evidence behind the relevant jobs and whether those jobs used the current endpoint and operator. Then run a small test using a filing with a known answer. The example is fictional; ERC-8004 supplies records, while this selection rule belongs to the buyer. ERC-8004 specification.