Your agent found a stranger. Should it trust them?

A marketplace needs a way to remember

Picture a research assistant buying a specialized dataset from a service it has never used. A friendly description tells it very little. It needs a stable identity to inspect, evidence from previous interactions, and a way to judge the current result. It also needs a separate answer to a much more personal question: who gave it permission to spend?

ERC-8004 proposes shared onchain infrastructure for the discovery and trust part of that encounter. The specification is still marked Draft as of September 27, 2026. The team’s implementation repository lists deployed Identity and Reputation registries, while the Validation Registry design remains under active discussion. A deployed implementation and a finalized standard are different milestones.

Three signals, three different questions

The identity registry uses an ERC-721 identifier associated with an agent registration file. It gives applications a handle for discovering an agent and its advertised services. A reputation registry records feedback. The validation design provides a way to request and record assessments from validators.

These signals answer different questions: which agent is this, what feedback exists, and what did a particular checker say about a task? An identity record cannot establish that every advertised capability works. Feedback can be manipulated, and a validator’s verdict depends on the validator and its method.

The diagram is an illustrative application design. The app decides which evidence it needs and when to reject a request or ask a person to review it. The validation layer is shown as evolving because its implementation design is still being updated.

Give every signal a specific job

For our hypothetical dataset purchase, identity helps the assistant find the same supplier again. Feedback gives it leads to investigate. A task-specific check might compare a sample against known data or test whether the delivered file meets an agreed format. None of those checks establishes that every row is true.

The application can make that uncertainty manageable. It might permit a small trial, require review for a larger purchase, or reject results whose provenance is unclear. Those are product policies chosen for the task. They are not conclusions automatically produced by writing a record to a blockchain.

This is where the smart-contract design becomes interesting: a common record format allows different applications to apply their own standards to the same evidence. The hard work of deciding which evidence matters remains visible.

A reputation score cannot authorize a payment

Payments sit outside ERC-8004’s scope. Its agentWallet binding concerns an address controlled by the agent; that does not authorize it to spend someone else’s assets. Spending authority needs its own mechanism and rules.

Coinbase’s Spend Permissions contracts illustrate a separate authorization design: an owner can grant a token allowance with defined conditions, and revoke that permission. That is one implementation example, not a component supplied by ERC-8004.

A payment protocol such as x402 addresses another boundary: how a service requests payment over HTTP and how that payment is verified and settled. Successful settlement tells you something about payment, not whether the purchased research is accurate. An application must connect these layers deliberately.

Build around the failure case

An open agent marketplace will contain incomplete profiles, thin feedback histories, conflicting assessments, and failed tasks. A useful integration begins by deciding what the app does in each of those cases.

For builders, the opportunity is a product that can explain its decision: the identity it found, the evidence it considered, the permission it used, and the result it received. Shared registries can make that explanation portable. Careful application design makes it meaningful.

• Check the exact registry deployment and specification version your app uses.
• Choose evidence appropriate to the task and the value at risk.
• Keep spending scope and revocation separate from reputation.
• Provide a reject or review path when the evidence is insufficient.