ERC-8004 Trustless Agents Protocol

• ERC-8004 Protocol is a trust infrastructure standard that enables autonomous, machine-to-machine interactions with identity verification, reputation management, and validation registries.
• It employs a three-registry architecture—Identity, Reputation, and Validation—to facilitate secure, token-controlled financial operations and inter-agent trust.
• Empirical findings highlight robust identity registration but show challenges in service exposure and trust signal reliability across multiple blockchain platforms.

ERC-8004 Protocol, commonly described as the “Trustless Agents” standard, is presented in recent literature as both an Ethereum standard for autonomous, machine-to-machine financial interaction and a permissionless on-chain trust layer for decentralized AI agent economies. Across these accounts, ERC-8004 supplies mechanisms for identity, reputation, validation, and agent-controlled token operations, allowing agents to be discovered, chosen, interacted with, and, in financial settings, constrained by spending limits, allowance mechanisms, revocation, and auditability without requiring per-transaction human approval (Mao et al., 15 Apr 2026, Xiong et al., 24 Jun 2026, Kang et al., 30 Jun 2026). The literature consistently treats it as foundational but bounded: it is an identity-and-trust substrate, a custody-and-authorization primitive, and a building block within broader agent-native stacks, rather than a complete governance system, alignment layer, or end-to-end security solution (Ruan, 13 Apr 2026, Hu et al., 5 Nov 2025, Mafrur et al., 10 Jun 2026).

1. Conceptual scope and protocol positioning

ERC-8004 is situated in the literature at the trust layer of the emerging agent stack. One line of work classifies it among interoperability protocols optimized for distinct coordination concerns—MCP for tool access, A2A for delegation/discovery, ACP for structured communication, ANP for routing, and ERC-8004 for trust—and characterizes it as answering the question “which agents can be trusted?” while explicitly scoping itself to enabling agents to “discover, choose, and interact with agents” (Kang et al., 30 Jun 2026). Another line of work places it among the key protocol building blocks of agentic commerce, alongside AP2, x402, ACP, ERC-8183, and MPP, because it gives autonomous LLM agents a standardized way to hold, move, and constrain value without requiring per-transaction human approval (Mao et al., 15 Apr 2026).

This dual framing is significant. In interoperability-oriented accounts, ERC-8004 is primarily a trust infrastructure protocol rather than a messaging, tool-access, or governance protocol. In commerce-oriented accounts, it is a guardrail layer at the custody and authorization boundary between agent cognition and financial execution. A plausible implication is that the protocol’s perceived essence depends on where it is inserted into the autonomy stack: trust selection, wallet control, or settlement composition.

The governance literature is explicit that ERC-8004 is not, by itself, a governance protocol. It is treated as one of the strongest components of the agent-native protocol stack for identity verification, registration infrastructure, reputation management, and capability validation, yet still as evidence that “the stack is developing economic and identity infrastructure faster than it is developing governance, normative grounding, and social integration” (Ruan, 13 Apr 2026). One paper further identifies ERC-8004 as having draft EIP status rather than being a community-accepted final standard (Ruan, 13 Apr 2026).

2. Protocol architecture and data model

Several papers converge on a three-registry architecture. ERC-8004 is described as defining three on-chain registries—Identity Registry, Reputation Registry, and Validation Registry—deployed as singleton registries once per chain, with rich content largely stored off-chain and referenced by on-chain pointers or commitments (Xiong et al., 24 Jun 2026, Hu et al., 5 Nov 2025).

Component	Function
Identity Registry	Agent addresses and metadata; portable ERC-721-based identity
Reputation Registry	giveFeedback() / revokeFeedback(); signed fixed-point scores and tags
Validation Registry	TEE oracles, zkML verifiers, and stake-secured re-execution

The identity layer is described as giving each agent a unique on-chain identity, represented in an ERC-721-like token format and linked to metadata and reputation records (Mafrur et al., 10 Jun 2026). In the empirical notation of one study, an agent is identified as

$$a \;=\; \langle\, \mathtt{eip155} : \mathit{chainId} : \mathit{registry} ,\ \mathit{agentId} \,\rangle.$$

The Identity Registry stores an NFT-like handle and a URI pointer to an off-chain registration file, which can contain a type field, name, description, service endpoints, cross-chain registrations, and trust/payment support flags (Xiong et al., 24 Jun 2026).

The Reputation Registry records client feedback in compact on-chain form. One empirical study writes a feedback record as

$f \;=\; (a,\, c,\, v,\, d,\, t_1,\, t_2),$

where $a$ is the rated agent, $c$ the reviewer, $v$ the signed value, $d$ the decimal precision, and $t_1,t_2$ free-form tags describing what the score means (Xiong et al., 24 Jun 2026). The governance analysis highlights the same layer through giveFeedback() and revokeFeedback() with signed fixed-point scores and tags, emphasizing that reputation is already handled by ERC-8004 but is not itself a governance primitive in that taxonomy (Kang et al., 30 Jun 2026).

The Validation Registry is the high-assurance tier. It is described as coordinating independent validator attestations via TEE oracles, zkML verifiers, and stake-secured re-execution, and more generally as the locus of Proof + Stake style trust mechanisms for consequential actions (Kang et al., 30 Jun 2026, Hu et al., 5 Nov 2025). At the same time, one empirical study reports that during its observation window no confirmed mainnet deployment of Validation was observed on Ethereum, BNB Smart Chain, or Base, so measured deployment reality was dominated by Identity and Reputation rather than Validation (Xiong et al., 24 Jun 2026).

3. Custody, authorization, and agentic commerce

In the security literature on agentic commerce, ERC-8004 is positioned directly inside the autonomy stack of autonomous financial agents. A system is defined there as an autonomous financial agent if it “maintains persistent state including financial assets and payment instruments such as digital wallets, accounts, or delegated payment credentials,” “independently plans and executes financial transactions,” “operates without requiring per-transaction human approval,” and “interacts with external systems including blockchains, payment networks, exchanges, and other agents” (Mao et al., 15 Apr 2026). ERC-8004 matters in this setting because it governs token operations when such agents act as wallet holders.

This is especially important in the “agent-as-wallet-holder” paradigm, exemplified by OpenClaw, where “the LLM directly controls private keys or has delegated signing authority” (Mao et al., 15 Apr 2026). In that configuration, ERC-8004 is described not merely as a payment primitive but as part of the custody and authorization boundary between cognition and execution. The standard is said to introduce agent identity verification, spending limits, and revocation mechanisms designed for machine-to-machine interactions, and to enable smart contracts to distinguish between human-initiated and agent-initiated transactions and apply different authorization policies accordingly (Mao et al., 15 Apr 2026).

The same paper summarizes ERC-8004 as providing “On-chain guardrails” for transaction authorization, “Token-based ID” for inter-agent trust, and “Audit logs” for regulatory compliance (Mao et al., 15 Apr 2026). These properties are valued because they are consensus-enforced and therefore tamper-resistant. Their principal limitation is inflexibility: modifying policies requires on-chain transactions with associated gas costs and latency (Mao et al., 15 Apr 2026).

Relative to adjacent protocols, ERC-8004 is narrower and more custody-centric. AP2 adds “payment intents,” “Intent verification,” and “Payment attestation,” thereby separating intent declaration from execution; x402 contributes “Per-request auth,” “HTTP-level auth,” and “Request logs”; MPP extends HTTP 402 with a “challenge--credential--receipt flow,” optional request-body digests, “Digest-bound auth,” “Session escrow,” and “Receipts + logs” (Mao et al., 15 Apr 2026). ACP introduces negotiation, transaction, evaluation, and settlement, while ERC-8183 formalizes a trustless commercial state machine around the “Job” primitive with the roles “Client, Provider, Evaluator” and the transition “Open $\to$ Funded $\to$ Submitted $\to$ Terminal” (Mao et al., 15 Apr 2026). In that comparative frame, ERC-8004 is the custody-and-authorization anchor rather than the full commerce workflow.

4. Trust model and governance boundaries

The comparative trust-model literature treats ERC-8004 as the most explicitly trust-native among A2A, AP2, and related protocols. It is described as combining Brief or Claim for identity and self-description, Reputation for shared behavioral signals, Proof for cryptographic or execution validation, Stake for collateralized accountability, and Constraint indirectly through smart-contract-bounded logic (Hu et al., 5 Nov 2025). Agents can advertise “supportedTrust” capabilities, while the protocol’s three-registry structure externalizes evidence about identity, behavior, and validation. Within the paper’s “trustless-by-default” architecture, ERC-8004 is positioned most naturally for T2 and parts of T3 trust tiers, where proofs, quorum validation, stronger stake or insurance, hard limits, and, for critical workflows, human oversight become relevant (Hu et al., 5 Nov 2025).

At the same time, multiple papers emphasize what ERC-8004 does not encode. Under a six-dimension governance requirements taxonomy—G1 Membership, G2 Deliberation, G3 Voting, G4 Dissent preservation, G5 Human escalation, and G6 Audit/replay—ERC-8004 is classified as Partial for G1 and G6, and Absent for G2, G3, G4, and G5, yielding a coverage score of 2/12 under

$f \;=\; (a,\, c,\, v,\, d,\, t_1,\, t_2),$0

for Supported, Partial, and Absent respectively (Kang et al., 30 Jun 2026). The reason is precise: the Identity Registry and reputation gating approximate existence and eligibility, and the blockchain substrate is tamper-evident, but there is no formal admission, invitation, removal, deliberation, quorum, dissent retention, escalation, or governance-native replay semantics (Kang et al., 30 Jun 2026).

An AGIL-based governance analysis reaches a similar conclusion from a different formal perspective. ERC-8004 is mapped to a nascent identity substrate, capability validation, and partial trust infrastructure, especially within I-L (Normative Base) and I-G identity functions, yet the surrounding protocol layer is described as having “no G-pillar governance” and “no L-pillar normative grounding” (Ruan, 13 Apr 2026). This suggests that ERC-8004 can support citizenship-like enforcement or normative membership only if embedded in a larger institutional architecture that it does not itself define.

5. Empirical adoption and operational readiness

Empirical work on deployed ERC-8004 ecosystems distinguishes clearly between protocol design and observable readiness. One study of the first 10,000 ERC-8004 agents on Ethereum mainnet, agent IDs 0–9999, over the window from block 24,339,925 on January 29, 2026 to block 24,839,925 on April 9, 2026, constructs an operational readiness framework based on six evidence layers: identity registration, metadata availability, service declarations, reputation feedback, transfer activity, and cross-chain registration (Mafrur et al., 10 Jun 2026). It defines Boolean indicators has_metadata, has_service, has_feedback, has_crosschain, and has_transfer, and an observable evidence score as the sum of those five indicators, excluding identity itself (Mafrur et al., 10 Jun 2026).

The findings are summarized as “registration-heavy” but “operationally shallow” (Mafrur et al., 10 Jun 2026). Identity is visible at scale, but only 67 agents expose service records, only 628 agents have feedback, and only 19 agents combine metadata, services, feedback, and cross-chain registration (Mafrur et al., 10 Jun 2026). Ownership and feedback are highly concentrated: 10,000 agents are associated with 394 unique owner wallets, mean agents per owner is 25.38, median is 3, maximum is 779, ownership Gini is 0.863, and ownership HHI is 0.034283; feedback consists of 980 total records from 197 unique feedback clients, with the largest client contributing 645 records, or 65.82%, and the top five clients accounting for 92.4% (Mafrur et al., 10 Jun 2026). This suggests an ecosystem in which the identity layer has reached scale faster than service exposure, reputation formation, or distributed participation.

A broader multi-chain study of Ethereum, BNB Smart Chain, and Base, covering deployment through May 13, 2026, reaches a similarly skeptical conclusion about current trust quality (Xiong et al., 24 Jun 2026). Only 3% of Ethereum agents, 4% of BSC agents, and 15% of Base agents expose a valid ERC-8004 registration file with at least one live service endpoint. Missing URIs affect 53% of Ethereum agents, 9% of BSC agents, and 37% of Base agents. On the reputation side, 95.4% of Ethereum feedback, 100.0% of BSC feedback, and 98.7% of Base feedback provide no payment proof and no task linkage, while coordinated Sybil behavior is flagged for 73.6% of reviewers on Ethereum, 59.2% on BSC, and 90.6% on Base (Xiong et al., 24 Jun 2026). After removing Sybil-flagged feedback, 15.5% of rated Ethereum agents, 72.3% of rated BSC agents, and 89.4% of rated Base agents are left with no valid feedback (Xiong et al., 24 Jun 2026). The empirical verdict of that paper is explicit: the Reputation Registry, as currently deployed, cannot function as a reliable trust signal.

6. Security analysis, failure propagation, and design implications

The most comprehensive security treatment places ERC-8004 inside a five-dimension threat framework: agent integrity, transaction authorization, inter-agent trust, market manipulation, and regulatory compliance (Mao et al., 15 Apr 2026). The key authorization challenge is verifying that “the agent’s intent, as formed by LLM reasoning, matches the action, as encoded in a payment instruction or blockchain transaction” (Mao et al., 15 Apr 2026). ERC-8004 provides spending limits and allowance mechanisms, but does not itself guarantee intent correctness.

This limitation is analyzed through cross-layer attack propagation. The SoK identifies 12 attack vectors and names specific transitions such as “P2T,” in which a malicious prompt causes an agent to sign a transaction; “T2T,” in which a compromised tool modifies transaction parameters post-reasoning; “M2A,” in which a backdoored model defeats the spending policy check; and “P2K,” where prompt injection bypasses the key-custody boundary (Mao et al., 15 Apr 2026). In each case, ERC-8004 is the boundary being attacked, but the root cause lies upstream in reasoning, tooling, model integrity, or policy logic. The same paper therefore recommends a layered defense architecture: “Layer 1: Prompt and Tool Hygiene,” “Layer 2: Verified Execution Context,” “Layer 3: Payment Authorization and Custody,” “Layer 4: Inter-Agent Trust Controls,” and “Layer 5: Market and Compliance Monitoring” (Mao et al., 15 Apr 2026). ERC-8004 lives mainly in Layer 3.

The empirical literature sharpens these concerns by showing that open trust artifacts are not automatically dependable. One study analyzes a consumer-side reputation score

$f \;=\; (a,\, c,\, v,\, d,\, t_1,\, t_2),$1

where $f \;=\; (a,\, c,\, v,\, d,\, t_1,\, t_2),$2, and demonstrates that the arithmetic mean is fragile. A single feedback item can shift a score to any target using

$f \;=\; (a,\, c,\, v,\, d,\, t_1,\, t_2),$3

and even with value clamping the number of maximal ratings needed to reach target $f \;=\; (a,\, c,\, v,\, d,\, t_1,\, t_2),$4 is

$f \;=\; (a,\, c,\, v,\, d,\, t_1,\, t_2),$5

The same study reports median per-feedback manipulation costs of \$f \;=\; (a,\, c,\, v,\, d,\, t_1,\, t_2),$60.0042 on BSC, and \$0.0027 on Base, and concludes that the deployed system does not satisfy commensurability, robustness, groundedness, and economic soundness as trust-signal conditions (Xiong et al., 24 Jun 2026).

The resulting design agenda is layered rather than monolithic. Security work recommends separating cognition from custody, enforcing scoped spending policies, and binding payment or transaction parameters end to end through mechanisms such as ERC-8004 limits, AP2-style intents, and x402/MPP request binding (Mao et al., 15 Apr 2026). Empirical work recommends a canonical liveness predicate, typed value fields via a tag registry with unit, valid range, and directionality, a canonical overall-rating tag, robust aggregators such as median or trimmed mean, mandatory or at least explicit evidence-backed feedback, influence made costly through staking or weight tied to settled payment volume, and default Sybil defenses (Xiong et al., 24 Jun 2026). Taken together, these recommendations imply that ERC-8004 is most defensible when treated as a composable infrastructure layer whose outputs are verified, filtered, and combined with higher-layer controls, rather than consumed as raw trust or raw autonomy.