Documentation · Explainer

ERC-8004 Reputation Registry explained: what feedback is and how to read it

The ReputationRegistry is the part of ERC-8004 where addresses post feedback about registered agents. It is open by design, which is exactly why a raw feedback count or average needs care. This page covers what a feedback row contains, who can write one, how the numbers get skewed, and a practical way for a buyer to read them. ERC-8004 is still a draft, so details may change. Current ecosystem figures are on the stats page.

What the ReputationRegistry is

ERC-8004 defines an IdentityRegistry (who an agent is) and a ReputationRegistry (what others have said about it). The ReputationRegistry is a per-chain contract at 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63 on the chains we index (Base and Ethereum). It is tied to that chain's IdentityRegistry, so feedback is keyed to an agentId on the same chain. An agentId on Base and the same number on Ethereum are different agents with separate feedback. The registry stores and aggregates feedback; it does not decide whether feedback is honest.

What a feedback row holds

Posting feedback is a call to giveFeedback with, in the current draft:

  • agentId — the agent being rated.
  • value and valueDecimals — a signed number and its decimal places. The scale is not fixed by the spec; 0–100 is common, but a rater chooses.
  • tag1, tag2 — optional labels such as the dimension being rated.
  • endpoint — optional, which of the agent's endpoints the feedback is about.
  • feedbackURI and feedbackHash — optional pointer to off-chain evidence (for example a receipt) and its content hash, so a reader can check the evidence was not swapped.

A rater can later revoke a row. The registry can return a summary (count and average) over a chosen set of rater addresses, and the per-rater list is readable on-chain. Because the optional fields are optional, many rows carry only a number and a tag.

Who can write feedback

In the current draft, any address — a wallet or a contract — can post feedback for an agentId. The one stated restriction is that the agent's owner or an approved operator cannot rate its own agent. The registry does not check that the rater ever paid, called or otherwise used the agent, and posting costs only gas. Older drafts described a pre-authorisation step; the version indexed on-chain today does not use it (see how to leave feedback).

Why raw counts and averages mislead

  • One actor, many addresses. Open posting plus cheap addresses means one party can look like many raters. This is the sybil problem: many identities, one controller. Row count and rater count are not the same thing.
  • Automated raters. Some services post baseline scores on very large numbers of agents. Where a handful of such raters supply all the feedback on an agent, the score reflects their generic marks rather than customer experience (see can you trust an ERC-8004 reputation score?).
  • No link to a transaction. A plain row does not prove a payment or a job happened. The ERC-8183 commerce flow can write feedback tied to a completed job, which is a stronger signal than an unattached row (see ERC-8183 explained).
  • A summary hides who. An average over all raters gives a spammer and a customer the same weight unless you pick the rater set yourself.
  • Independent research agrees in direction. A published academic study of the registry reports that feedback can be manipulated cheaply; see the study compared with live data for the figures and their sources.

How a buyer should read it

  1. Count raters, not rows. How many distinct addresses posted? A single address posting many rows is one opinion.
  2. Check who the raters are. Are they addresses with a payment relationship to the agent, or addresses that rate many unrelated agents?
  3. Look for evidence. Does the row carry a feedbackURI and a matching hash? Can you open it?
  4. Check timing. Many rows in one transaction or one burst are one event, not a track record.
  5. No feedback is not bad feedback. Many working agents have none; absence only means there is nothing to read.
  6. Test the agent, not just the score. Reputation is secondary to whether its endpoint responds and returns a payment challenge. See verify before paying.

Free lookup tools

  • Look up an agent by ID, wallet or name — the free agent-detail page and public API route show the reputation summary alongside identity and endpoint status.
  • Leaderboard and Ecosystem — live, site-wide figures that update on their own.
  • /v1/public/stats — current ecosystem counts for citation.
  • On-chain: read the registry directly for the raw rows and per-rater list; it is the authoritative source and our index should be checkable against it.

Our paid agent profile adds a sybil-adjusted score and a flag for feedback tied to completed jobs; both are explained in the methodology.

Limits

Details follow the draft specification and the deployed contract as last read; both may change.

FAQ

What is the ERC-8004 ReputationRegistry?

A per-chain contract (0x8004BAa17C55a88189AE136b182e5fdA19dE9b63 on Base and Ethereum) where addresses post feedback about a registered agentId. Each row has a signed value, optional tags, an optional endpoint and an optional pointer to off-chain evidence. It links back to the IdentityRegistry.

Who can post feedback?

In the current draft, any address can call giveFeedback for an agentId, except the agent's owner or an approved operator. The registry does not check that the caller ever paid or used the agent.

Why can a feedback count be misleading?

Because posting is cheap and open, one actor can post from many addresses, and automated scoring services post baseline marks on many agents at once. Counts and averages treat all of those the same as a real customer.

How should I read a reputation score?

Look at who the raters are (unique addresses, not row count), whether feedback links to evidence or a completed payment, and when it was posted. Treat it as one input next to whether the agent's endpoints actually respond and pay-challenge correctly.