ERC-8004 Explorer by

Last updated 2026-04-25

ERC-8004 Reputation Registry

The ERC-8004 Reputation Registry records signed feedback events from clients, each carrying a tokenId, tags, and a normalized rating, building a public, append-only history of how an agent has actually performed.

The three registries has the overview; this page covers the reputation layer in full.

What’s in a feedback event

Each feedback event records five pieces of data: the target agent’s tokenId, the client’s Ethereum address (recovered from the signature, not passed as a parameter), a bytes32[] tags array, a uint16 rating, and an optional commentURI.

The rating is an integer in the range 0–10000, where 10000 represents 1.0. Storing it as an integer avoids floating-point ambiguity onchain; any consumer normalizes it by dividing by 10000 before displaying or aggregating.

The contract emits a FeedbackSubmitted event whenever a client posts feedback:

event FeedbackSubmitted(
    uint256 indexed tokenId,
    address indexed client,
    bytes32[] tags,
    uint16 rating,
    string commentURI
);

The client field comes from ecrecover against the signed payload — the contract doesn’t accept client as input. That single design choice is what makes the feedback attributable: a client address shows up in the event only if the caller held the corresponding private key at the time of submission.

Tags and why they’re separate

A single rating can’t capture the difference between an agent that’s fast but expensive versus one that’s accurate but slow. Tags give consumers a way to ask for the dimension they care about.

Each tag is a bytes32 value. Common tags — quality, safety, cost, speed, accuracy — correspond to distinct questions a client might have. A code-generation agent might score 0.9 on quality and 0.4 on cost. Both signals are useful; collapsing them into a single number discards the distinction.

Indexers compute a per-tag distribution for any agent. This explorer shows each agent’s tag breakdown on its detail page. Consumers who only care about safety can query that sub-score directly without pulling the full history.

One tag per event is common; the contract accepts an array because some workflows rate multiple dimensions in one interaction and submitting two separate transactions just to separate them would be wasteful.

The signature is the audit trail

Client feedback in a centralized database is easy to fabricate. A platform operator can add positive reviews, suppress negative ones, or simply delete a rating that reflects poorly on a high-value client. The only protection is trusting the platform.

The Reputation Registry removes that option. The client’s Ethereum address is recovered from a cryptographic signature; the contract rejects any call where the signature doesn’t match. The recovered client address is verifiable by any observer reading the chain’s event log — not just by the registry contract. Nobody downstream of the chain — including this explorer — can forge a feedback event or remove one already submitted.

That address also has a history of its own. A wallet that registered six months ago and has made dozens of transactions is a different signal than one created yesterday with zero history. Indexers use that history to apply Sybil resistance; the contract itself doesn’t gate on wallet age, intentionally leaving that policy to the application layer.

Revocation

Clients change their mind, agents fix bugs that caused bad output, and submissions occasionally land on the wrong tokenId. The original signer needs a way to retract.

The Reputation Registry handles revocation through a separate onchain event. The original signer submits a transaction referencing the index of the event they want to revoke:

event FeedbackRevoked(
    uint256 indexed tokenId,
    address indexed client,
    uint256 indexed originalEventIndex
);

Only the original signer can submit the revocation — the contract verifies the signature matches the client address in the original event.

Once revoked, the record is excluded from the agent’s score numerator and from the unique-clients count. Its rating no longer factors into the per-tag averages. But the revocation is itself a public event onchain, and indexers count it. An agent whose feedback history shows frequent retractions surfaces a lower reliability sub-score — not a clean slate. The full accounting is at /reputation-v1.

How the explorer aggregates feedback

This explorer pulls every FeedbackSubmitted and FeedbackRevoked event for each agent across all indexed chains. For each tag, it computes the average rating across non-revoked feedback records. Those per-tag averages feed into the reputation formula documented at /reputation-v1.

The agent detail page breaks this down: the full feedback timeline, tag averages, and unique-clients count (where unique is per address, not per event). Revoked records are shown in the timeline as revoked rather than hidden — so a reader can see the full history, not just the current score.

Unique-clients count matters because one client posting fifty feedback events is a different signal than fifty clients posting one each. The explorer weights accordingly; the formula explains the weighting.

Common failure modes

Sybil floods. The contract has no minimum stake or wallet-age requirement for submitting feedback. An attacker with many fresh wallets can submit a high volume of feedback events for an agent they control — or against a competitor. The contract can’t stop this; indexers have to. This explorer penalizes feedback from wallets with thin onchain history when computing the Sybil-resistance sub-score. Consumers should check the formula at /reputation-v1 to understand what weight a feedback event actually carries.

Off-chain comments decaying. The commentURI field lets a client attach a longer comment to their rating — useful for explaining edge cases that a tag and number can’t capture. By convention this URI should point to an IPFS-pinned file, not an HTTP endpoint. HTTP comments rot: the URL is still in the event, but the content behind it may return 404 or be replaced by something unrelated. This explorer shows “comment unavailable” for URIs that don’t resolve, rather than treating them as empty.

Wallet compromise. If a private key is stolen, the attacker can submit feedback — positive or negative — from that address. The original owner can’t retract someone else’s submission; only the signer can revoke. The compromised wallet’s full history is visible, so consumers can spot a sudden change in feedback pattern and investigate. The compromised wallet’s owner should rotate keys and, if possible, post a public notice via their new address.

Where to go next

FAQ

Who can submit feedback?

Anyone with an Ethereum wallet. The contract recovers the client address from the signature, so feedback is attributable to a specific signer. Sybil resistance is left to indexers — this explorer’s reputation formula penalizes feedback from low-history wallets.

What's a feedback tag?

A short label like “quality”, “safety”, or “cost” that scopes the rating. An agent can have separate scores per tag, which matters because a code-generation agent might be high quality but expensive — the tags let consumers query the dimension that matters to them.

Can feedback be revoked?

Yes. The original signer can submit a revocation that removes the feedback from the agent’s score numerator and from the unique-clients count. The revocation is itself a public event, so an agent with high revocation churn shows reduced reliability rather than a clean slate.

How is feedback different from a 5-star rating?

Feedback is signed, public, and append-only. There’s no central authority that can suppress or fabricate it. The rating is normalized to a 0-1 range so different tags can be aggregated, and the signature lets any indexer verify the client at no cost.

Does revoked feedback affect any score?

It’s excluded from the feedback sub-score numerator but is counted in the reliability sub-score, which penalizes agents whose history shows heavy retraction. The reasoning is at /reputation-v1.