ERC-8004 Agent Reputation: On-Chain Registration and Lookup

A prior post on this blog covered the ERC-8004/8126/8196 trust stack: three Ethereum registries that handle agent identity, reputation, and validation. If you want the conceptual overview first, start there. This post is about something narrower: how feedback actually gets written to the Reputation Registry, how to read it back, and what services are available today to browse and index that data.

ERC-8004 is currently a Draft standard, authored by Marco De Rossi, Davide Crapis, Jordan Ellis, and Erik Reppel. Payment is explicitly out of scope. The spec fills a gap that A2A and MCP don’t address: discovery and trust.

Registry set architecture

ERC-8004 is not a single router contract. It is a set of three independent contracts: Identity Registry, Reputation Registry, and Validation Registry. Each has its own address, and calls go directly to the target contract.

The Reputation Registry is initialized with an Identity Registry address via initialize(address identityRegistry_). It stores this address internally and exposes it through getIdentityRegistry(). This link is how giveFeedback() verifies that the target agentId exists in the Identity Registry and rejects calls from the agent’s owner or authorized operators.

giveFeedback() takes no registry address parameter. You register feedback by sending a transaction directly to the Reputation Registry contract (tx.to is the registry address). Which Reputation Registry to use for a given network is an application-level decision. Feedback is stored in Reputation Registry storage; it does not route through the Identity Registry.

The Reputation Registry

The Reputation Registry is a permissionless on-chain bulletin board. Any address except the agent’s owner and operators can post feedback about any registered agent. The registry makes no judgment about whether a submission is accurate.

Sybil resistance is the application’s job, not the registry’s. When querying, callers must supply a non-empty set of trusted client addresses. The registry returns a filtered aggregate over that set. An empty client set reverts with clientAddresses required. This design shifts the question from “what is this agent’s score?” to “which raters do I trust?” Each application answers that differently.

What gets stored

The on-chain Feedback struct holds five fields:

struct Feedback {
    int128 value;
    uint8 valueDecimals;
    bool isRevoked;
    string tag1;
    string tag2;
}

• value (int128): the score as an integer. Negative values are permitted (range [-1e38, 1e38]).
• valueDecimals (uint8): decimal position, 0 through 18. value=9950, valueDecimals=2 means 99.50 when interpreted by consumers.
• isRevoked (bool): whether this feedback entry has been revoked.
• tag1, tag2 (string): free-form classification tags.

The contract stores value and valueDecimals directly. It does not normalize the input to a 0-100 integer on write.

feedbackURI and feedbackHash are not stored in the struct. They are emitted as events. This keeps on-chain storage costs down while allowing off-chain indexers to reconstruct the full record.

Indexing is three-dimensional: agentId -> clientAddress -> feedbackIndex. Indexes are 1-based. _lastIndex[agentId][client] == 0 means that client has left no feedback for that agent.

Registering feedback

function giveFeedback(
    uint256 agentId,
    int128 value,
    uint8 valueDecimals,
    string calldata tag1,
    string calldata tag2,
    string calldata endpoint,
    string calldata feedbackURI,
    bytes32 feedbackHash
) external;

Field by field:

• agentId: the ERC-721 token ID of the target agent in the Identity Registry.
• value, valueDecimals: fixed-point score, with valueDecimals <= 18. For a quality score of 85, use value=85, valueDecimals=0. For 99.5% uptime, use value=9950, valueDecimals=2 (consumers interpret this as 99.50).
• tag1, tag2: free-form string tags. Empty strings are valid.
• endpoint: the specific agent endpoint this feedback applies to. Use an empty string for feedback about the agent in general.
• feedbackURI: off-chain URI for the full feedback payload. IPFS is preferred for content-addressability; HTTPS works but is less durable.
• feedbackHash: keccak256 of the content at feedbackURI. Lets consumers detect tampering without fetching the URI.

The wallet sending the transaction (msg.sender) becomes the clientAddress in the emitted event. One feedback entry = one transaction. The contract rejects calls from the agent’s owner or authorized operators.

Example. Registering a quality score of 85 for agent ID 42:

agentId        = 42
value          = 85
valueDecimals  = 0
tag1           = "quality"
tag2           = ""
endpoint       = ""
feedbackURI    = "ipfs://Qm..."
feedbackHash   = 0xabc123...

The contract stores value=85 and valueDecimals=0 directly. A consumer reads this as 85.0.

Querying reputation

function getSummary(
    uint256 agentId,
    address[] calldata clientAddresses,
    string calldata tag1,
    string calldata tag2
) external view returns (uint64 count, int128 summaryValue, uint8 summaryValueDecimals);

Return tuple:

• count: number of feedback entries included in the aggregate.
• summaryValue: the averaged score as an integer.
• summaryValueDecimals: decimal position for the result.

How the average works: the contract normalizes each included entry to 18 decimal places internally, averages them, then scales the result back to the most frequent valueDecimals value (the mode) among the included entries.

clientAddresses must be non-empty. This is the Sybil-resistance mechanism. Anyone can post feedback; a raw aggregate across all submitters is trivially manipulable. Callers must supply a set of addresses they trust, and the contract aggregates only from that set.

Two trust decisions

Using the Reputation Registry in practice involves two separate decisions:

1. Which Reputation Registry contract address to trust for a given network. The widely-used mainnet address is 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63. Testnet addresses differ.
2. Which client addresses to include in getSummary(). Once you’ve chosen a registry, you still need to decide which feedback submitters to trust within it. Options include a curated list of known clients in your ecosystem, a set validated by a third-party attestation service, or addresses derived from your own user base.

Other read functions

For reading individual entries or batching across multiple clients:

function getLastIndex(uint256 agentId, address clientAddress) external view returns (uint64)
function readFeedback(uint256 agentId, address clientAddress, uint64 feedbackIndex)
    external view returns (int128 value, uint8 valueDecimals, string memory tag1, string memory tag2, bool isRevoked)
function readAllFeedback(uint256 agentId, address[] calldata clientAddresses, string calldata tag1, string calldata tag2, bool includeRevoked) external view returns (...)

To read one client’s entries in order: call getLastIndex(agentId, clientAddress) first, then readFeedback(agentId, clientAddress, i) for i = 1..lastIndex.

Deployed contract addresses

ERC-8004 registries are deployed at deterministic CREATE2 addresses. The same address holds across all supported chains, and the contracts are byte-identical on Ethereum, Base, BNB Chain, Arbitrum, OP Mainnet, Polygon, Avalanche, Mantle, Scroll, and Gnosis.

The 0x8004 prefix is a vanity prefix. All contracts are visible on standard block explorers (Etherscan, Basescan, BSCScan, and so on). Testnet addresses differ from mainnet; check the QuickNode ERC-8004 Explorer contract docs before using any address.

Address data sourced from QuickNode ERC-8004 Explorer contract documentation, updated 2026-05-05.

Ecosystem services

Several services index or browse ERC-8004 registry data:

Tag conventions

The ERC-8004 spec lists example tags: starred, reachable, uptime, responseTime. QuickNode’s explorer aggregates a different convention set: quality, safety, cost, speed, accuracy.

Tags are free-form strings. Any value is valid, but only entries sharing the exact same label aggregate together. "quality" and "Quality" are distinct tags. Each application or explorer defines its own convention and aggregates by it. This is the design working as intended: the registry defines the bulletin board structure, not the scoring rubric. Custom tags work fine within a closed ecosystem, but they won’t appear in aggregates from other services using different label conventions.

Caveats

Draft status. ERC-8004 is a Draft (github.com/ethereum/ERCs). The interface can change before finalization. Track the spec and reference implementation before building production integrations.

Placeholder-heavy registry. As of May 2026, a significant share of registered agents are placeholders with little real activity. Reputation data is sparse at this stage, and scores reflect that.

Sybil exposure. Permissionless writes mean any actor can flood the registry with self-reviews. A poorly chosen clientAddresses set in getSummary() exposes callers to inflated or manipulated aggregates. The client set is where the actual trust decision lives.

Off-chain URI durability. feedbackHash detects tampering, but if an HTTPS-hosted feedbackURI goes offline, the full feedback payload is unrecoverable. IPFS or another content-addressed store reduces this risk.

Validation Registry not on mainnet. The TEE attestation flow is still being finalized. The Validation Registry runs on testnet only; task verification is not available in production yet.

Takeaway

The Reputation Registry is one of three independent contracts in the ERC-8004 registry set. Feedback is stored as fixed-point value/valueDecimals pairs, not normalized to a 0-100 score. giveFeedback() records one entry per transaction sent directly to the Reputation Registry address. getSummary() returns (uint64 count, int128 summaryValue, uint8 summaryValueDecimals), averaging over the caller-specified client set after normalizing to 18 decimal places internally.

Choosing a Reputation Registry address and choosing which clients to include in getSummary() are two separate decisions. The same contracts run at the same addresses across 10+ chains via CREATE2 deterministic deployment. Agentscan and QuickNode’s explorer are the main places to browse that data today.

The standard is still a Draft, actual reputation data is thin, and Sybil resistance depends entirely on how well applications curate their trusted client sets. Those are tractable problems, but unsolved in mid-2026.

Further reading

• AI Agent Identity, Verification, and Policy: The ERC-8004/8126/8196 Trust Stack — conceptual overview (this blog)
• QuickNode ERC-8004 Explorer — agent browser and developer feedback submission guide
• Agentscan — multichain agent search and reputation browser
• erc-8004-contracts reference implementation — source for ABI and storage layout

References

• EIP-8004 (Draft) — Ethereum Improvement Proposals, accessed 2026-06-30
• ethereum/ERCs: ERC-8004 — EIP source text, accessed 2026-06-30
• erc-8004/erc-8004-contracts — reference contract implementation, accessed 2026-06-30
• QuickNode ERC-8004 Explorer — contract addresses, ABI docs, and tutorials, accessed 2026-06-30
• Agentscan — AI agent explorer, accessed 2026-06-30
• 8004.org — official ERC-8004 site, accessed 2026-06-30
• DeepWiki: erc-8004-contracts — reference contract API docs, accessed 2026-06-30
• Allium — on-chain AI identity analytics, accessed 2026-06-30
• arXiv 2606.26028: Can Trustless Agents Be Trusted? — empirical study of ERC-8004 across Ethereum/BSC/Base, accessed 2026-06-30