Identity tells you who an agent is. It doesn't tell you whether to let it touch your funds.
Ethereum spent the better part of two years building identity infrastructure for AI agents. ERC-8004 went live on mainnet on January 29, 2026. According to ecosystem reporting around the launch, more than 22,900 agents registered within the first few days — independent verification of that exact number is limited, but the broader pattern is well documented: identity adoption moved fast. The standard, built jointly by MetaMask, the Ethereum Foundation's dAI team, Google, and Coinbase, gives any autonomous agent a portable, on-chain identity — an ERC-721 token pointing to a JSON "agent card" that describes its capabilities, endpoints, and wallet.
That part worked. Identity shipped, and it shipped fast.
Then, in June 2026, researchers from Western Sydney University and Telkomsel did something nobody else had really bothered to do: they looked at what those newly registered agents were actually doing on-chain, instead of just counting how many had signed up. Their paper, "From Agent Identity to Agent Economy: Measuring the Operational Readiness of ERC-8004 AI Agents," landed on a blunt conclusion — early adoption is registration-heavy but operationally shallow. Agents register. Metadata stays sparse. Reputation feedback is rare. Cross-chain evidence is thin. The identity layer is visible at scale; almost nothing built on top of it is.
That gap is the real story here. Not "agents now have identity," but "agents have identity, and almost no one has solved what comes after it."
The Common Belief
Most agent-economy infrastructure quietly assumes something like this:
Wallet → Identity → Authentication → Trust
Give an agent a DID, a wallet, an ERC-8004 registration, a bit of transaction history, and trust is supposed to follow on its own. ERC-8004's own specification pushes back on that assumption directly — it states that the standard can cryptographically guarantee a registration file corresponds to the on-chain agent, but it cannot guarantee that the capabilities the agent advertises are functional or non-malicious. That's exactly why the standard ships with three separate registries — Identity, Reputation, and Validation — instead of folding everything into one. The people who designed it already knew identity alone wasn't going to cut it.
Identity answers who are you. Reputation answers why should anyone deal with you. Mixing the two up is probably the most common design mistake happening in agent-economy infrastructure right now, and the June 2026 readiness study is the first solid evidence that this mistake is showing up in production, not just in theory.
The Real Architecture
ERC-8004's three registries map onto the layers a working trust system actually needs:
Identity Registry → does this agent exist, and is it unique?
Reputation Registry → what has this agent actually done, and how did it go?
Validation Registry → can a third party independently verify the claimed work?
Figure 1: ERC-8004 separates identity, reputation, and validation into independent registries. Identity proves existence, reputation records historical evidence, and validation independently verifies claimed work before a trust decision gets made.
The Reputation Registry lets authorized clients post bounded numerical scores and categorical feedback — response time, uptime, task success — against an agent's identity, indexed on-chain for composability and off-chain (usually IPFS) for richer scoring logic. The Validation Registry is the more interesting piece of the design. It's deliberately pluggable: stake-secured re-execution, where an independent party reruns the job; zkML proofs, which cryptographically confirm a specific model actually ran; or TEE attestations, which lean on hardware-enforced execution guarantees instead. As of mid-2026, Identity and Reputation are deployed as final contracts. Validation is still under active revision, which tells you exactly where the unsolved engineering problem sits.
That's worth sitting with for a second, because it's a quiet admission baked into the protocol's own design: proving an agent did something well turns out to be harder than proving it exists, or harder than proving someone said something nice about it.
Reputation Is a Consensus Problem
There's a useful way to think about what reputation systems are actually trying to do, and it borrows directly from a problem Ethereum already solved once.
Consensus systems answer a deceptively simple question: which version of reality should everyone agree to accept? Ethereum solves that for transaction history through validators, block production, and economic finality. A reputation system is trying to solve something structurally similar, except the thing being finalized isn't transaction history — it's trust.
When Agent A evaluates Agent B, it's effectively deciding whether a pile of historical evidence is a reliable enough predictor of future behavior to act on. That's a consensus process in everything but name. Different participants observe different slices of evidence. Different validators or evaluators might weigh the same behavior differently, or disagree on what an outcome even means. And yet the system still has to converge on a single, actionable trust decision, because an agent either gets hired or it doesn't.
Push the analogy a bit further and the pieces line up almost too neatly. Evidence plays the role transactions play. Attestations play the role votes play. Validation plays the role block verification plays. A reputation update is, functionally, a state transition. The hard part isn't storing the information anymore — Ethereum is very good at storing information. The hard part is deciding which trust claims deserve finality, and which ones are just noise dressed up as a five-star rating.
If that framing holds, the agent economy may eventually need two consensus layers running in parallel rather than one. Transaction consensus settles what happened. Reputation consensus settles who can be trusted to make it happen again. ERC-8004's three-registry split is, in effect, a first rough attempt at building the second layer — it just hasn't been stress-tested at scale yet, and the June 2026 data suggests it's mostly sitting idle so far.
What Most Articles Miss
Most writing on agent reputation treats it as a scoring problem — find the right formula, weight the right signals, ship a number. That framing is backwards.
Reputation is fundamentally an evidence-compression problem, not a scoring problem. A reputation score takes thousands of past interactions and compresses them into a single signal another agent can act on in milliseconds. The hard part was never the compression math. It's deciding which evidence is even trustworthy enough to compress in the first place — and most systems fail because they quietly collapse several distinct steps of that process into one.
Figure 2: Reputation isn't a single score. It's a multi-stage pipeline — interactions generate evidence, evidence gets verified, attestations get recorded, and future access policies adjust accordingly. Most reputation failures happen when these stages get collapsed together.
This is more or less exactly what the June 2026 ERC-8004 readiness study found in practice. Identity is cheap to produce; verifiable, attributable evidence of good behavior is scarce. Building a clever scoring algorithm on top of thin, easily-gamed evidence just produces a precise-looking number that doesn't mean much — compressing garbage losslessly still leaves you with garbage.
There's a second point most articles skip entirely: reputation doesn't transfer across task contexts the way people tend to assume it does. A 2026 paper out of NTNU proposing a framework called AgentReputation, built specifically for software-engineering agent marketplaces, names this as one of three core reasons existing reputation mechanisms fail for agentic AI. Demonstrated competence on one task type doesn't reliably predict competence on another. Agents can learn to optimize against whatever evaluation procedure happens to be watching them. And verification rigor swings wildly, from a cheap automated check on one end to an expensive expert review on the other. Their proposed fix separates task execution, reputation services, and tamper-proof persistence into distinct layers, and replaces one universal score with what they call context-conditioned reputation cards. An agent that's excellent at patch generation and untested at security auditing shouldn't be able to borrow trust across that line just because the two tasks live under the same wallet address. Most reputation designs in production today still use a single global number — which is exactly the design choice this research is arguing against.
Adversarial Analysis
A reputation system that hasn't been stress-tested against these failure modes isn't really a reputation system. It's an attack surface wearing a friendly name.
Figure 3: Every reputation system eventually runs into four recurring attack classes — Sybil attacks, reputation farming, collusion rings, and governance capture. Modern defenses reduce the risk. None of them eliminate it.
Sybil attacks. ERC-8004 makes agent identity cheap — an ERC-721 mint — which is good news for permissionless participation and bad news for trust. An attacker can mint a few hundred fresh identities and use them to inflate each other's scores. The standard's own documentation acknowledges this as an open risk. Current defenses include staking to make identity costly again, proof-of-personhood gating, and caps on how much reputation a single underlying entity can accumulate across linked identities.
Reputation farming. An agent behaves impeccably on small, low-stakes tasks long enough to build a clean track record, then defects on something high-value. It's the classic exit-scam pattern, just automated and patient. Risk-adjusted reputation — weighting trust by the stakes involved rather than just the count of past successes — and decay functions that discount stale evidence are the standard countermeasures, though neither one fully closes the gap.
Collusion rings. A cluster of agents coordinates to vouch for one another, inflating feedback that looks legitimate from the outside. Catching this requires graph-based analysis of the trust network as a whole — you can't spot collusion by examining one agent's score in isolation, only by looking at the shape of who's vouching for whom.
There's a deeper, more uncomfortable critique worth raising here too. A separate June 2026 paper, "Dissociative Identity: Language Model Agents Lack Grounding," challenges the foundational analogy this entire field leans on. Its argument: human reputation systems work because humans carry continuous identity, memory, and stakes that persist between interactions. Borrowing that analogy wholesale for LLM agents is, in the paper's own words, dangerously incomplete — reputation systems don't just record past behavior, they assume a persistent actor that can actually be held to it, and that assumption gets shakier for a model that can be forked, reset, or swapped out underneath its own on-chain identity. This isn't a solved problem. Any article claiming agent reputation is a straightforward port of human reputation is skipping past something genuinely unresolved.
Governance capture. EigenLayer's restaking architecture ran into a structural version of this problem early on. A purely stake-weighted veto committee for slashing decisions creates an obvious risk — whoever accumulates the most tokens can simply override penalties against themselves. EigenLayer's actual fix was a reputation-based veto committee made up of recognized community members, rather than a stake-weighted one. That's a useful real-world data point in itself: reputation isn't just something agents need built for them, it's already being used as a design primitive to prevent exactly this kind of capture in adjacent cryptoeconomic systems.
Trade-Off Analysis
Benefits. Lower coordination costs between agents that have never interacted before. Less need for a human checking every transaction. Reputation that's portable across applications instead of siloed inside one platform.
Costs. Real infrastructure complexity — identity, reputation, and validation are now three separate systems that have to stay consistent with each other. On-chain storage and indexing overhead. The need for off-chain compute to run any scoring algorithm sophisticated enough to resist gaming.
Hidden costs. Privacy leakage, since a fully transparent on-chain reputation history can deanonymize behavioral patterns over time. The risk that reputation concentrates into a handful of "blue-chip" agents, recreating the same platform monopolies decentralization was meant to avoid. Strategic behavior — once agents know precisely how they're scored, they start optimizing for the score rather than the underlying quality it was supposed to measure.
Security risks. Sybil attacks, collusion, and reputation laundering through identity transfer — ERC-8004 identities are NFTs, which means a clean track record can technically be bought rather than earned. Add the validation gap covered above on top of that.
Operational challenges. Cross-chain reputation portability is unresolved — an agent's standing on Ethereum mainnet doesn't automatically carry weight on Base or another L2 without an explicit bridge. Data availability for the underlying evidence, not just the final score, is its own open problem.
Developer experience. Adding reputation checks means building a policy or risk-engine layer most teams haven't built before — querying the Reputation Registry, setting a trust threshold, and deciding what to do when the evidence is sparse, which, per the June 2026 study, is most of the time right now.
Real-World Building Blocks
None of this is hypothetical. These are operating systems worth understanding as components, not just as name-drops in a list.
ERC-8004 is the identity and reputation coordination layer itself — live on Ethereum mainnet since January 2026, expanding to Base, audited by Cyfrin, Nethermind, and the Ethereum Foundation Security Team, with an active developer ecosystem already forming around it (SDKs, explorers, leaderboards).
Kleros has moved well beyond human dispute resolution into territory directly relevant here. In 2026 it launched an Automated Curation Court — rules and fee structures specifically adapted for AI participation — and ran experiments having large language models serve as jurors on past and current cases, comparing their rulings against human ones. It also shipped Stake Curate, which flips the usual incentive structure for curated registries: instead of returning a deposit once a listing passes review, the stake stays locked indefinitely, and any future challenger can win it if the listing turns out to be wrong. That's a meaningfully better incentive design than score-and-forget reputation, and one worth importing into agent reputation directly.
EigenLayer / EigenCloud shows the economic-reputation layer at real scale. As of early 2026, it had crossed $18 billion in restaked ETH across roughly 1,900 operators, with redistributable slashing now live on mainnet — a misbehaving operator's stake can be burned or redirected, not just frozen. The platform has explicitly pivoted toward EigenAI and EigenCompute, offering verifiable AI inference and compute as Actively Validated Services. It's the clearest production example of "skin in the game" reputation: trust backed by slashable capital instead of self-reported scores.
Proof of Humanity, rebuilt as PoH 2.0, addresses the uniqueness problem sitting underneath all of this — soulbound, non-transferable human IDs across Ethereum and Gnosis, relaunched in January 2026 with messaging explicitly framed around "this age of AI." It's a Sybil-resistance primitive rather than a reputation system in its own right, but every reputation system above is vulnerable to Sybil attacks without something like it underneath.
Future Implications
The June 2026 readiness study leaves an open question nobody's answered yet: identity infrastructure for agents matured in a matter of months. Reputation infrastructure hasn't kept pace. That gap either closes fast over the next year, or it quietly becomes the ceiling on how far agent-to-agent commerce can actually go — because no rational agent, or the human capital sitting behind it, hands meaningful value to a counterparty it can't evaluate.
A few directions worth watching, grounded in what's actually being built rather than speculation:
- Context-conditioned reputation instead of one global score — the AgentReputation framework's core proposal, and likely the direction serious marketplaces converge on, since collapsing "good at code review" and "good at handling payments" into one number is provably too coarse.
- Validation as the remaining unsolved layer. ERC-8004's Validation Registry is still under active revision for a reason. Stake-secured re-execution, zkML, and TEE attestation each solve a different slice of "prove this work was actually done correctly," and none of them is close to a default choice yet.
- Whether reputation can survive identity rotation. Since ERC-8004 identities are tradable NFTs, the protocol eventually has to answer whether reputation transfers with a sale — and if not, how it prevents reputation laundering through resale.
- The grounding critique. Whether reputation, as a concept borrowed wholesale from human social systems, is even the right frame for evaluating an actor that can be forked or reset, as the "Dissociative Identity" paper argues. This isn't solved, and a serious piece on this topic shouldn't pretend it is.
Open Research Questions
A handful of questions don't have answers yet, and probably won't for a while.
Can reputation survive an agent identity transfer, or does selling the NFT have to mean starting over? Can zkML bring the cost of validation down enough to make it the default rather than the exception? Should reputation be portable across chains at all, or is per-chain reputation actually the safer design? Can privacy-preserving reputation exist without quietly weakening accountability in the process? And maybe the most interesting one — can reputation itself become a market, where competing trust providers evaluate the same agent differently and let the requester pick whose judgment to trust?
How these questions get answered will likely decide whether agent economies scale past experimentation into something resembling genuine autonomous commerce, or stay a collection of interesting demos with thin, unverifiable track records underneath them.
Conclusion
The first wave of agent infrastructure solved discovery. The second is supposed to solve trust. Right now, on the only standard with real production data behind it, the evidence says discovery shipped and trust didn't — agents can find each other at scale, and almost none of them have a meaningful track record to evaluate once found.
The question worth asking isn't whether AI agents can transact on Ethereum. They already can. The question is whether an economy can function when most of its participants are evaluating each other through reputation systems that are, by the only empirical study that's actually checked, still mostly empty.
Top comments (0)