// Last updated 2026-05-05

ERC-8004 Reputation Registry

The ERC-8004 Reputation Registry records client feedback events, each carrying an agentId, clientAddress, primary tag, numeric value, and optional evidence fields, 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 the target agent’s agentId, the client’s Ethereum address (msg.sender), a per-client feedbackIndex, a numeric value, a valueDecimals scale, primary and secondary tags, an endpoint string, an optional feedbackURI, and an optional feedbackHash.

The normalized value is value / 10 ** valueDecimals. This is intentionally flexible: a client can submit a 0-100 quality score, a response-time measurement, or another numeric metric. This explorer only includes non-revoked rows whose normalized value lands in the 0-100 score range and whose primary tag is in the score-like whitelist when calculating feedback_score.

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

event NewFeedback(
    uint256 indexed agentId,
    address indexed clientAddress,
    uint64 feedbackIndex,
    int128 value,
    uint8 valueDecimals,
    string indexed indexedTag1,
    string tag1,
    string tag2,
    string endpoint,
    string feedbackURI,
    bytes32 feedbackHash
);

The clientAddress field comes from the transaction sender — the contract doesn’t accept clientAddress as input. That single design choice is what makes the feedback attributable: a client address shows up in the event only if that wallet submitted the transaction.

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 string. Common tags — quality, safety, cost, speed, accuracy — correspond to distinct questions a client might have. A code-generation agent might score 90 on quality and 40 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 primary tag per event is common. The tag2 field exists for a secondary label when a workflow needs one, but tag1 is the field this explorer uses for per-tag score grouping.

The client address 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 the transaction sender recorded in the event. That 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 agentId. 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 agentId,
    address indexed clientAddress,
    uint64 indexed feedbackIndex
);

Only the original submitter can submit the revocation — the contract verifies msg.sender matches the clientAddress in the original event.

Once revoked, the record is excluded from the agent’s score numerator and from the unique-clients count. Its value 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 NewFeedback and FeedbackRevoked event for each agent across all indexed chains. For each score-like tag, it computes the average normalized value 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 evidence decaying. The feedbackURI field lets a client attach a longer report to their value — 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 evidence rots: the URL is still in the event, but the content behind it may return 404 or be replaced by something unrelated. This explorer shows unavailable metadata as missing rather than treating it 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 submitting address 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

• Hub: The three registries
• Sibling: Identity Registry
• Sibling: Validation Registry
• The reputation formula: /reputation-v1
• Cornerstone: What is ERC-8004?
• The canonical EIP: https://eips.ethereum.org/EIPS/eip-8004