ERC-8004 and the missing memory of the agent economy

The stranger on the other side of the task

A research assistant needs a specialized dataset and discovers an agent offering to supply it. The offer is clear; the surrounding relationship is thin. Who operates this service? Has it delivered useful work before? Does the available evidence apply to this particular dataset? The assistant also needs to know whether its owner has authorized a purchase. These questions become unavoidable once work moves beyond a familiar set of services.

Within a single product, an operator can maintain its own account records, feedback history, and rules for admitting suppliers. Across independently operated applications, those records may be difficult to discover or compare. ERC-8004 proposes common onchain registries that applications can use for agent discovery and trust signals. That gives an unfamiliar service something more inspectable than its own description.

The specification remained Draft when checked on September 27, 2026. The reference implementation repository lists deployed Identity and Reputation registries, while the Validation Registry design remains under active discussion. A live implementation demonstrates that specific contracts exist; it does not make every proposed part of the standard final. Builders need to know which version and deployment they are reading before treating its records as an input to a decision.

A record is useful when its question is clear

The Identity Registry associates an ERC-721 identifier with an agent registration file. This gives an application a handle through which it can discover the agent and its advertised services. It is a point of reference for further investigation. Because the identity token is transferable, continuity of the identifier does not establish that the same human operator, model, or capabilities remain behind it.

The Reputation Registry adds feedback about interactions. Feedback can help an evaluator find evidence worth examining, but its meaning depends on context: who supplied it, what task it concerns, and whether it is credible. A history of easy successful jobs may say little about a difficult new assignment. The specification also recognizes manipulation risks. Publishing a record onchain makes the record inspectable; it does not remove the need to assess the source.

The evolving Validation Registry design adds a place for requests and assessments from validators. The important question becomes what a particular validator checked, using which method, and with what limits. A check of a dataset’s format has a different meaning from a check of its provenance. An application that treats both as an undifferentiated seal of approval loses the distinction that makes the evidence useful.

These layers therefore offer different forms of memory: a reference for an agent, a history of feedback, and a record of a particular assessment. Their usefulness grows when an evaluator can explain which of those records supports the decision at hand.

Trust has to fit the transaction

For the hypothetical dataset purchase, a reasonable first question is whether the supplier can deliver a sample that satisfies the agreed requirements. Identity helps locate the service and its records. Feedback can point to prior work. A task-specific evaluation might examine the sample’s schema, provenance, coverage, or agreement with known observations. None of those checks should silently stand in for all the others.

This is why an application still needs its own risk rules. A small exploratory purchase may justify a different level of investigation from a dataset that will guide a consequential business decision. Sparse history can lead to a limited trial. Conflicting evidence can trigger review. Missing provenance can be enough to decline. These are choices about the task and the consequences of being wrong, not answers supplied automatically by the registry.

An application also needs to recognize changes in what it is evaluating. A service may update its model or change ownership. The identifier can remain a useful way to find past records while the relevance of those records changes. A thoughtful evaluator asks what carries forward and what needs to be demonstrated again.

Our interpretation is that this separation can make open coordination more credible. Different applications can consult common evidence while applying standards appropriate to their users. The decision remains local, but its supporting materials become easier to inspect and contest.

A good reputation cannot spend your money

Once the research assistant has evaluated a supplier, it still needs authority to act. ERC-8004 places payments outside its scope. Its agentWallet binding concerns an address controlled by the agent; it does not give that agent permission to spend assets belonging to someone else. A favorable evaluation cannot create that permission either.

Coinbase’s Spend Permissions contracts illustrate one independent approach to constrained authority: an owner grants an allowance with defined conditions and can revoke it. A payment protocol such as x402 deals with another part of the exchange, allowing a service to request payment over HTTP and having that payment verified and settled. Neither is a feature supplied by ERC-8004.

Following the dataset purchase through these layers makes their different jobs visible. Evidence supports a decision to use the supplier. A permission determines whether the assistant may spend. Payment settlement records that the exchange of value occurred. The delivered data then has to meet the requirement. A successful payment proves nothing about the accuracy of the research it bought.

Keeping those boundaries separate helps a product explain failure. It can distinguish an unconvincing supplier from an unauthorized purchase, a failed payment, or an unacceptable result. That explanation is more useful to a user than a single claim that an agent is “trusted.”