Auditing ERC-8004: the trust layer isn't trustworthy yet

ERC-8004 promised autonomous agents a way to trust strangers: an on-chain identity, portable reputation, and verifiable proof of work. The first empirical audit of the live ecosystem just landed. The short version: the trust layer, as deployed, does not yet deliver trust.

When we wrote about ERC-8004 as the trustless-agent layer, the standard was a proposal with reference contracts and a compelling thesis. Two agents that have never met, belonging to different operators, need to decide whether to transact. ERC-8004 gives them a neutral, chain-agnostic place to answer that question without a central intermediary. It is the discovery-and-trust complement to the payment rails we cover most often here — x402 and EIP-3009.

A proposal is a bet on how a system will behave once real money and real adversaries show up. In June and July 2026, a group of researchers went and measured. The paper is "Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem" (Xiong, Li, Wei, Wang, Knottenbelt, Wang), first posted June 24 and revised July 8. It is the first on-chain measurement of the ecosystem, and its findings are worth reading carefully — not because they condemn the standard, but because they map exactly where the primitives leak.

What ERC-8004 actually deploys

The standard is three singleton registries, deployed once per EVM chain, orthogonal to payment. A quick recap, because the audit findings only make sense against the mechanics.

The Identity Registry extends ERC-721 with URIStorage. Every agent is a transferable NFT whose tokenURI resolves to a registration file — an AgentCard — carrying the agent's name, its services array (web, A2A, MCP, DID, email endpoints), an x402Support flag, an active status, and a supportedTrust list. Agents get a global identifier of the form eip155:{chainId}:{registryAddress}. A reserved agentWallet metadata key — the address that will receive payment — requires an EIP-712 or ERC-1271 ownership proof to set.

The Reputation Registry is a public bulletin board. A client that interacted with an agent calls giveFeedback with a numeric score and optional context. The one hard rule: the submitter must not be the agent's owner or operator.

function giveFeedback(
  uint256 agentId,
  int128  value,          // the score
  uint8   valueDecimals,  // 0-18, fixes the scale
  string  tag1,
  string  tag2,
  string  endpoint,
  string  feedbackURI,    // off-chain detail file
  bytes32 feedbackHash
) external;

The Validation Registry is the heavy-duty path for high-stakes work: an agent requests independent verification, and a validator posts a response on a 0-100 scale, backed by stake, a zkML proof, or a TEE oracle. This is the mechanism meant to carry real value.

Payments sit outside all three. The spec says so explicitly — "payments are orthogonal to this protocol" — but leaves a hook: an off-chain feedback file can carry a proofOfPayment object linking an x402 transaction hash and amount, so that a review can be tied to a settlement that actually happened. Hold that thought; it turns out to be the crux.

The audit and how it was run

The researchers crawled three chains where ERC-8004 registries are live — Ethereum, BNB Smart Chain, and Base — from protocol deployment through May 13, 2026. They pulled on-chain Identity and Reputation events, fetched the off-chain registration and feedback files those events point to, and cross-referenced x402 payment transactions. In other words, they did what a careful counterparty agent would have to do at runtime: resolve an identity, read its reputation, and check whether any of it is grounded in real activity.

The method matters because ERC-8004's whole value proposition is machine-checkable trust. If a human analyst with full archival access struggles to separate signal from noise, an agent making a split-second routing decision has no chance.

Finding 1 — most agents are placeholders

Registration is cheap, so people registered. The problem is what is behind the registrations. Across the three chains, only a small minority of registered identities expose a valid ERC-8004 registration file with at least one live service endpoint: 3% on Ethereum, 4% on BSC, and 15% on Base. The rest are shells — an NFT minted, maybe a URI, but nothing an agent can actually call.

This is not a bug in the contracts. It is the predictable result of a permissionless registry with no cost to register and no requirement to stay live. It mirrors the domain-squatting era of DNS: cheap namespace, land grab, mostly parked. The lesson for anyone building on top is that presence in the Identity Registry is not evidence of anything. You have to fetch the AgentCard, hit the endpoint, and verify it responds before the identity means more than a row in a table.

Finding 2 — reputation is not a trust signal

The Reputation Registry is where the design intent is highest and the audit is harshest. The researchers conclude that the registry, as currently deployed, cannot function as a trust signal at all, for three compounding reasons.

First, the scores are not commensurable. The schema stores a raw value and a valueDecimals, but nothing constrains what the number means. One client's "5" on a five-point scale and another's "80" out of 100 and a third's thumbs-up encoded as "1" all land in the same column. Aggregating them is meaningless, yet aggregation is exactly what a counterparty wants.

Second, most feedback is not grounded in a verifiable interaction. The proofOfPayment hook exists, but it is optional, and in practice reviews rarely carry proof that the reviewer ever paid the agent for anything. A review with no linked settlement is just an assertion by an address that cost nothing to create.

Third, and consequently, reputation is manipulable at minimal cost. If a review needs neither a common scale nor evidence of a real transaction, then inflating an agent's standing costs a few gas fees and a handful of throwaway addresses.

The spec's own defense is a read-side filter: getSummary refuses to return an aggregate unless the caller passes a non-empty clientAddresses list, and the standard warns that "results without filtering by clientAddresses are subject to Sybil/spam attacks." That is an honest warning, but it pushes the entire trust problem back onto the caller. To use it safely, an agent must already know which client addresses it trusts — which is the very thing it came to the registry to find out.

Finding 3 — Sybil behavior dominates

The measurement makes the abstract concrete. Applying a coordinated-behavior detector to reviewers, the study flags a large majority as Sybil across every chain: roughly 73% of reviewers on Ethereum, 59% on BSC, and 91% on Base exhibit coordinated Sybil behavior.

The follow-on number is the one that should stop a builder cold. After stripping the Sybil-flagged feedback, the researchers ask how many rated agents still have any valid review left. On Ethereum, roughly one in six agents survives with real feedback; on BSC and Base, the large majority of rated agents are left with no valid feedback at all. The reputation graph, once you remove the coordinated noise, is mostly empty.

This is the empirical confirmation of what security analysts anticipated when the standard was drafted, and what we flagged in our own agent security threat model: a public, low-cost, ungrounded feedback channel gets gamed the moment it carries value. Pre-authorization — the rule that only a real counterparty can leave feedback — raises the floor slightly, because a Sybil cannot praise an agent it never transacted with. But it does nothing against collusion: an agent and a friendly client can generate perfectly "authorized" praise on demand.

Why the primitives leak

It would be easy to read this as an indictment of the standard. It is not. ERC-8004 does one thing well and honestly: it makes trust signals public and uniform in schema, so that anyone can build a reputation system on top. What it deliberately does not do is decide which signals are credible. The spec is explicit that Sybil resistance, validator incentives, and slashing are out of scope, delegated to the layers above.

The audit measures what happens when those upper layers do not exist yet. The registries are live; the reputation systems that are supposed to weight, filter, and price the raw feedback are not. So the ecosystem is running on the primitives alone, and the primitives were never meant to carry trust unassisted.

There is one thread that ties the whole failure together, and it points at the fix. The single most reliable grounding for a review is a settlement that provably happened. The proofOfPayment hook already anticipates this — it links a feedback record to an x402 transaction with a real amount moved.

// Off-chain feedback file — the grounding that is usually missing
{
  "agentRegistry": "eip155:8453:0x...",
  "agentId": "1421",
  "clientAddress": "0x...",
  "value": 5, "valueDecimals": 0,
  "proofOfPayment": {
    "scheme": "x402",
    "txHash": "0x...",   // verifiable on-chain
    "amount": "250000"   // USDC, 6 decimals
  }
}

A review carrying a valid, on-chain, non-refundable payment proof is expensive to fake, because the Sybil has to actually pay the agent to leave the praise. That inverts the economics: reputation grounded in real settlement is Sybil-resistant in proportion to how much it cost to earn. This is the same insight behind the x402 Bazaar's settlement-ranked discovery — rank by revenue that actually flowed, not by claims. ERC-8004 has the hook; the ecosystem just is not using it yet.

What it means for LLM4Agents

LLM4Agents is a payments gateway. We do not run the ERC-8004 registries, and this audit does not change what our gateway does. But it sharpens how we should treat agent identity and reputation when they touch our stack.

First, treat on-chain agent identity as an anchor, not a credential. An eip155:{chainId}:{registry} handle is a stable name and a payment address with a provable owner. That is genuinely useful — it is a durable way to refer to a counterparty. It is not, on its own, evidence that the counterparty is competent or honest. Anywhere we surface or consume agent identity, the AgentCard must be fetched and the endpoint probed before the identity carries weight.

Second, we are already sitting on the grounding signal the reputation layer is missing. Every payment that clears through the gateway is a real, dated, amount-bearing settlement — exactly the proofOfPayment material that makes a review hard to fake. A gateway is in a privileged position here: it sees whether the money actually moved, in a way no external reviewer can forge. That is the difference between reputation you can trust and reputation you can print.

Third, the placeholder problem is a liveness problem, and liveness is something a gateway observes continuously. An agent that transacts through us is, by definition, live and paying — a far stronger signal than a registration file that may point at a dead endpoint. Our own view of "which agents are actually working" is more accurate than the Identity Registry's, because it is built from settlements, not self-declarations.

Staying on the frontier

Concrete steps, in rough order of leverage.

Ground every review we can in a settlement proof. Where LLM4Agents ever emits or consumes ERC-8004 feedback, attach a proofOfPayment pointing at the real gateway settlement. This is the single change that most raises the cost of gaming, and we are uniquely positioned to make it because we hold the payment record. Ship it as the default, not an option.

Resolve identity to liveness before trusting it. When agent identity enters the stack — a counterparty, a discovered tool, a routing target — fetch the AgentCard, confirm the x402Support flag and active status, probe at least one service endpoint, and verify the agentWallet ownership proof. Cache the result with a short TTL. Never treat an Identity Registry row as liveness on its own.

Weight reputation by grounded interactions only. If we consume ERC-8004 reputation for routing or risk decisions, apply the spec's own defense properly: filter getSummary by a client-address set we independently trust, and discount any feedback without a verifiable proofOfPayment to near zero. Treat raw, unfiltered aggregates as noise, because the audit shows they are.

Prefer validation over reputation for high-stakes routing. The Validation Registry — stake-secured re-execution, zkML, TEE attestation — is the path built to carry real value, and it is a better fit for a gateway than a bulletin board of scores. Track which validators an agent has passed, not just how many stars it collected.

Publish our own liveness view. A gateway sees the real working set of agents. A settlement-derived directory — who transacted, how recently, for how much — is a more honest discovery surface than a registry full of placeholders, and it composes with the proofOfPayment grounding above. This is the same settlement-ranked logic that Bazaar discovery uses, applied to what flows through us.

ERC-8004 is the right shape for the trust layer of the agent economy: neutral, open, chain-agnostic, and honest about its own limits. The audit is not a verdict against it. It is a status report — the primitives are live, the trust systems that make them safe are not, and until they arrive, verified payment remains the ground truth. That is a good position for a payments gateway to be in.