ERC-8004: Checking an Agent Identity Before Paying for Its Work

A marketplace lists two agents that claim to produce the same analysis. Before paying either one, a client needs to know which service the listing identifies, whose feedback it is reading and what any validation result actually checked. A recognizable name and a large score are not enough to answer those questions.

ERC-8004 supplies shared records for part of this evaluation. The selection policy still belongs to the application.

Research boundary: official specification and project-maintained documentation reviewed November 1, 2026. ERC-8004 remains Draft. We did not verify a live agent’s performance, inspect a deployment onchain or submit feedback.

Three records with different meanings

The ERC-8004 draft separates an agent’s onchain identity, feedback signals and validator records. An identity combines a registry reference with an agent ID and points to a registration document. Reputation records expose feedback; validation provides a separate interface for checks by validators. Payments are explicitly outside the protocol’s scope.

Conceptual flow: Candidate agent → Registry identity; Registry identity → Resolve service endpoint; Registry identity → Inspect selected feedback; Registry identity → Inspect validation evidence; Resolve service endpoint → Client selection policy; Inspect selected feedback → Client selection policy; Inspect validation evidence → Client selection policy; Client selection policy → Separate payment decision. — Source-informed conceptual flow, not a payment test. Source: ERC-8004 specification. Scroll horizontally to read the full diagram on a narrow screen.

Conceptual selection process, not a trust score or an evaluated agent. Each evidence branch can fail independently.

For an implementation team, keep those branches distinct in both storage and UI. “Registered,” “reviewed” and “validated” should not collapse into the same green badge.

Resolve an identity all the way to the service

The team’s contract repository explains the compound identity and optional receiving-wallet verification. It also describes clearing that wallet association when the identity changes owner. These details matter when a marketplace caches information: a previously observed payment destination should not quietly become a permanent fact about the agent.

Our proposed listing record would retain the registry and agent ID, the endpoint inspected, the observation time and the receiving-wallet evidence separately. If a service URL or ownership changes, the marketplace can trigger review of the affected fields rather than copy the old “verified” state onto the new configuration.

Do not turn a registration into proof of a real-world company identity. Decide what additional onboarding evidence your particular marketplace requires, especially where a user expects an identifiable counterparty or a route for disputes.

A number needs a measurement definition

The project’s reputation guide treats ERC-8004 as a shared feedback layer; applications choose how to filter, weight and display it. Tags and numeric precision help describe signals, but do not impose a universal quality metric.

Consider two hypothetical observations: one client measured delivery latency, while another rated the usefulness of a report. Averaging them would produce a number with no coherent meaning. Even two quality scores may use different scales or task definitions.

A useful display should therefore answer:

What property was measured, in which units and for which task?
Which reviewers are included, and why are they relevant?
How recent is the evidence, and what is the sample size?
Does the aggregation exclude revoked feedback and handle missing context?

These are editorial design criteria, not extra guarantees supplied by the standard. The draft acknowledges Sybil risk; a large number of public records is not, by itself, a reason to trust the represented service.

Read the claim behind a validation result

A validator’s check is only useful relative to its method and scope. Reproducing an output, verifying an execution attestation and judging a document’s usefulness are different tasks. A product should identify what was checked before letting a user infer a broad reliability claim.

The team repository also warns that the validation portion is under active revision. Pin the specification and implementation versions during integration, and avoid presenting every proposed registry feature as deployed identically on every network.

For a first marketplace release, a defensible approach is a small number of clearly described evidence types and explicit “not available” states. That is easier to reason about than a single composite score whose inputs users cannot inspect.

Keep the payment decision separate

An application might use identity and reputation evidence to choose a counterparty, then apply an independent quote, budget and payment policy. The two decisions should be linked for auditability without treating one as authorization for the other. A favorable history does not approve today’s amount, and a payment receipt does not prove that today’s output is useful.

Start from the ERC-8004 reference, then see A2A for task communication and MCP for tool interfaces. They provide adjacent pieces; the marketplace still needs its own acceptance and dispute process.