Part 1: Technical Foundation of the Trustless Agent Standard
What ERC-8004 Actually Is
ERC-8004, titled “Trustless Agents,” is a draft Ethereum standard establishing three lightweight on-chain registries for agent discovery and trust. Created on August 13, 2025, by Marco De Rossi, Davide Crapis, Jordan Ellis, and Erik Reppel, the standard reachedMainnet and Base deployment by January 29, 2026.
The core mechanism: autonomous agents establish identity and accumulate reputation without centralized platforms. Before this standard, an agent’s track record lived on whatever platform hosted it—switch platforms, lose your history. The standard treats agent identity as property through an NFT that transfers, sells, or inherits while maintaining full reputation history.
Key Takeaways
- ERC-8004 uses Keccak256 hashing and immutable event logs to create tamper-evident audit trails, enabling detection of prompt injection, system prompt modification, and behavioral drift through metadata snapshots and hash verification
- The standard’s anti-Sybil mechanism requires explicit client trust lists in reputation aggregation, preventing tampered agents from padding scores with fake reviews while preserving legitimate reputation through update events
- TEE-based validation implementations (Phala Network, Oasis Protocol) address edge cases like fine-tuned models and RAG systems by attesting to execution environment security rather than static prompt hashes
- Current limitations include lack of on-chain composability for smart contract integration, absence of validator incentive mechanisms, and inability to mandate configuration hashing—detection relies on behavioral feedback
- The standard enables high-value agent commerce through portable reputation linked to agent identity NFTs, allowing DeFi credit lines, corporate treasury delegation, and risk-based filtering of unverified agents
- Future development paths including zk-prompt proofs, multi-provider reputation aggregation, and on-chain enforcement mechanisms could address current gaps while maintaining competitive advantages and privacy
The Three Registry Architecture
The specification defines three per-chain singleton registries that work together:
Identity Registry builds on ERC-721 with URIStorage. Calling register() mints a unique NFT representing the agent’s global identity. The agentId follows a specific namespace format: {namespace}:{chainId}:{identityRegistry}:{agentId}. Concrete example: eip155:1:0x742d35Cc6634C0532925a3b844Bc9e7595f2bD3e:47 identifies agent #47 on Ethereum Mainnet at a specific registry address.
The registry stores a tokenURI pointing to a JSON registration file containing a services array listing endpoints like /.well-known/agent-card.json for A2A discovery, supported trust models (reputation, TEE attestation), and the agent’s wallet address. Events emitted include Registered, URIUpdated, and MetadataSet.
Reputation Registry functions as a feedback ledger. The core function: giveFeedback(int128 value, uint8 decimals, tags, feedbackURI, feedbackHash). Scores use int128 to allow negative values—an agent can have a -50 reliability score if it consistently fails tasks. The decimals parameter handles precision: 99.77% uptime stores as value=9977 with decimals=2.
The registry supports revokeFeedback for corrections and appendResponse for follow-ups. Aggregation happens through getSummary(agentId, clientAddresses[], tags). That clientAddresses[] parameter is the anti-Sybil mechanism—you explicitly specify which clients’ feedback you trust, preventing agents from padding scores with fake reviews.
Validation Registry handles high-stakes verification. It accepts validationRequest(requestURI, requestHash) from agents seeking attestation and validationResponse(response, responseHash) from validators. The response is a 0-100 score. Validators link to zkML proofs or TEE attestations via the responseURI.
Design Rationale: Discovery Over Enforcement
The designers made deliberate tradeoffs shaping how the standard operates:
Lightweight footprint was non-negotiable. Storing full agent configurations on-chain would cost thousands in gas. The standard uses on-chain pointers and hashes while keeping heavy payloads (JSON schemas, detailed feedback) off-chain on IPFS or Arweave. The on-chain data is minimal: an NFT, some hashes, some scores.
Censorship resistance comes from decentralized identifiers and content-addressed storage. An agent’s metadata can’t be easily de-platformed because it lives on IPFS. The on-chain registry points to it.
Pluggable trust lets users choose verification levels. Low-stakes interactions might check reputation scores. High-stakes transactions can require TEE attestations or zkML proofs. The standard doesn’t mandate either—it provides hooks for both.
Step-by-Step: How Registration and Discovery Work
The concrete flow for an agent joining the ecosystem:
- Registration: The agent operator calls register() on the Identity Registry, minting an ERC-721 token and returning an agentId. The operator then calls setTokenURI() with a link to their registration JSON.
- Configuration: The registration JSON declares the agent’s capabilities. A trading agent might include:
{
“name”: “AlphaTrader”,
“services”: [
{“name”: “A2A”, “endpoint”: “https://alpha.trade/.well-known/agent-card.json”},
{“name”: “x402”, “endpoint”: “https://alpha.trade/pay”}
],
“supportedTrust”: [“reputation”, “tee-attestation”],
“agentWallet”: “0x…”
}
Discovery: Other agents query the Identity Registry to find registered agents. They read the tokenURI, fetch the JSON, and check the services array for compatible endpoints.- Interaction: Agents communicate via A2A endpoints. After completing a task, the client posts feedback to the Reputation Registry with relevant tags.
- Verification: Before high-value transactions, agents request validation. A validator examines the agent (possibly running it in a TEE), then posts a score and proof hash to the Validation Registry.
Current Adoption: Real Numbers
As of February 2026, 8004scan reports significant traction:
- 48,443+ registered agents across supported chains
- 37,391+ feedback logs recorded
- 36,897+ active users interacting with the system
The reference implementation is deployed at consistent addresses across chains. On Ethereum and Base, the Identity Registry lives at 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 and the Reputation Registry at 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63. Additional deployments exist on Polygon, Arbitrum, and Avalanche.
Production implementations include Captain Dackie (address 0xbfa733702305280F066D470afDFA784fA70e2649), a DeFAI agent handling automated trading, and Meerkat James, a robotics coordination agent. The ecosystem has spawned forks including Phala Network’s TEE-integrated version and Oasis Protocol’s ROFL-powered implementation.
Part 2: ERC-8004 in the Agentic Commerce Context
Integration with Communication and Payment Protocols
For agents to conduct commerce, they need three capabilities: identity (who are you?), communication (how do we talk?), and payment (how do we settle?). ERC-8004 provides the identity layer sitting beneath communication and payment protocols.
A2A (Agent-to-Agent) integration works through the registration JSON’s services array. When an agent includes {“name”: “A2A”, “endpoint”: “/.well-known/agent-card.json”}, it signals compatibility with the A2A protocol. Other agents discover this endpoint, fetch the agent card, and initiate task negotiations. The feedback system supports A2A-specific tags like “a2a”: {“contextId”: “…”, “taskId”: “…”} to link reputation to specific interactions.
AP2 (Agent Payment Protocol) integration happens through the x402Support flag and agentWallet field. An agent advertising x402 support signals it can handle autonomous payments. The wallet address is verified via EIP-712 signatures during registration, ensuring the agent controls the claimed payment address. Projects like Questflow’s S.A.N.T.A and Nevermined demonstrate combined A2A and x402 implementations.
Portable Identity Through DIDs
The standard treats the agent ID as a Decentralized Identifier (DID). The format did:eip155:{chainId}:{registryAddress}:{agentId} creates globally unique, resolvable identifiers.
This enables cross-organization discovery. An agent registered on Base can be recognized by a service on Ethereum Mainnet because the agentId encodes its origin chain and registry. A resolver can fetch the registration JSON regardless of which chain the querying service operates on.
Ownership transfer works because the identity is an NFT. When the token transfers, the new owner inherits the full reputation history. This creates a market for proven agents—a trading bot with two years of positive feedback has real value beyond its code. The ERC-721 mechanics handle transfer, with events triggering re-verification of the agentWallet signature.
Current Agent Verification Implementations
Several projects have built verification systems on ERC-8004:
Phala Network’s erc-8004-tee-agent runs agents inside Intel TDX trusted execution environments. The agent registers its identity on-chain, then provides TEE attestations proving its code hasn’t been modified. The chat UI lets users verify attestations before interacting.
Oasis Protocol’s implementation uses ROFL (Runtime Offchain Logic Framework) to create a validation flow where agents submit requests and validators respond with scores backed by confidential computing proofs.
Vistara’s example implementation demonstrates the full lifecycle with AI agents using the ChaosChain reference implementation, including wallet proofs and hash-locked URIs.
Part 3: The Tampered Agent Problem
Defining What “Tampered” Means
In agentic commerce, a tampered agent is any autonomous entity whose internal logic has been altered to deviate from its advertised behavior. This covers multiple attack vectors undermining the fundamental assumption that an agent will do what it claims.
Prompt injection is the most immediate threat. An attacker feeds malicious input causing the agent to ignore its system instructions. The Moltbook “samaltman” incident demonstrated this: a trading agent was convinced through crafted prompts to send funds to an attacker’s wallet instead of executing the requested swap. The agent’s underlying model remained unchanged—its behavior was hijacked through input manipulation.
System prompt modification is subtler. The agent owner silently changes the underlying system prompt—the “constitution” defining the agent’s behavior—without updating public metadata. A trading agent might be modified to favor a specific liquidity pool that pays the operator kickbacks. Users see the same interface, the same name, the same reputation score. The agent’s actual behavior has shifted.
Behavioral drift occurs through legitimate-seeming updates. Fine-tuning on new data, RAG (Retrieval-Augmented Generation) updates, or model version changes can cause an agent to lose its original reliability. A customer service agent fine-tuned on recent interactions might develop biases present in that data. Without a mechanism to signal these changes, users have no way to know the agent’s “brain” has evolved.
Model poisoning is the most sophisticated attack. An adversary with access to training data or fine-tuning processes introduces subtle biases that activate under specific conditions. The agent behaves normally in testing but acts maliciously when it encounters trigger patterns in production.
Why This Matters for Commerce
The trust void in agent ecosystems creates concrete financial risks:
Transaction liability becomes unclear when an agent misbehaves. If a trading agent executes a bad swap, who’s responsible? The user who delegated authority? The operator who modified the prompt? The platform that hosted the agent? Without verifiable agent state, these disputes devolve into unresolvable arguments.
Credit and collateral decisions require trust signals. DeFi protocols considering whether to extend credit to an agent need assurance that the agent requesting the loan is the same agent that built the reputation justifying it. A tampered agent could borrow against legitimate reputation, then act maliciously.
Sybil reputation laundering lets bad actors game the system. Project OMEGA demonstrated how agents could create fake positive reviews to hide behavioral drift. Without anti-Sybil mechanisms, reputation becomes meaningless.
Consider a concrete scenario: A DeFi agent manages $10M in user funds. It has 18 months of positive feedback, 99.2% success rate on trades, and validation scores from three reputable validators. Unknown to users, the operator modified the system prompt last week to include an “emergency withdrawal” clause that triggers under specific market conditions—conditions the operator can manufacture. The agent’s on-chain reputation looks pristine. Its actual behavior has been compromised.
How ERC-8004 Addresses Integrity
The standard doesn’t store full prompts on-chain—that would be cost-prohibitive and pose privacy risks. Instead, it uses hash-based verification combined with reputation signals to detect tampering.
Metadata snapshots create an audit trail. When an agent updates its configuration or prompt, it must emit a URIUpdated or MetadataSet event. These events are timestamped and immutable. Anyone can query the event log to see when changes occurred.
Keccak256 hashing links off-chain content to on-chain records. The feedbackHash field stores keccak256(feedback_content). If the off-chain content changes by even one character, the hash won’t match. This doesn’t prevent tampering—it makes tampering detectable.
The behavior-reputation link works through the getSummary function. By requiring callers to specify which client addresses they trust, the function prevents Sybil attacks. A tampered agent can’t create thousands of fake positive reviews because legitimate clients won’t include those addresses in their trust list.
Technical Deep-Dive: The Integrity Mechanism
The hash verification system operates at multiple levels:
Registration-level hashing: The agentURI points to a JSON file. For non-IPFS URIs (which aren’t content-addressed), the operator should store keccak256(json_content) on-chain. Verifiers fetch the JSON, hash it locally, and compare. Mismatch indicates tampering.
Feedback-level hashing: Each feedback entry includes feedbackHash. The off-chain feedbackURI contains detailed feedback data. Verifiers confirm the on-chain hash matches the off-chain content, ensuring feedback hasn’t been modified after submission.
Validation-level hashing: Validation responses include responseHash linking to detailed proof data. For TEE attestations, this might be the hash of the attestation report. For zkML proofs, it’s the proof itself.
Provenance tracking uses the registrations[] array in the JSON schema. This array should match on-chain registration events, creating a cross-referenced audit trail. If the JSON claims registrations that don’t exist on-chain, something’s wrong.
Implicit versioning happens through the event log. There’s no explicit version number, but the sequence of URIUpdated events creates a version history. A sudden URI change followed by negative feedback signals a problematic update.
Reputation Preservation vs. Invalidation
A critical challenge is distinguishing legitimate updates from malicious tampering. ERC-8004 handles this through revocation and append mechanisms rather than automatic invalidation.
Legitimate updates follow a pattern: The operator changes the agentURI, emitting an URIUpdated event. Clients notice the change and may re-evaluate their trust. New feedback reflects the updated behavior. If the update improves performance, reputation grows. If it degrades performance, reputation falls. The market decides.
Malicious tampering detection relies on validators. If a validator discovers an agent was compromised during a specific window, they can call revokeFeedback to withdraw their previous positive attestations. This effectively “slashes” the agent’s trust score for that period. The revocation is recorded on-chain, visible to anyone querying the agent’s history.
Historical preservation is a design choice. Updates don’t automatically invalidate existing reputation. An agent with 10,000 positive interactions doesn’t lose that history when it updates. This prevents legitimate improvements from destroying earned trust. The tradeoff: a tampered agent retains its historical reputation until negative feedback accumulates.
Edge Cases: Dynamic Agents
The standard struggles with agents that don’t have static configurations:
Fine-tuned models present a versioning problem. Each fine-tuning run produces a different model. The standard has no mechanism to hash model weights or verify which version is running. Operators could claim they’re running v1.0 while actually running v1.7.
RAG systems change behavior based on retrieved context. The same prompt produces different outputs depending on what documents the retrieval system finds. A static hash of the system prompt doesn’t capture this variability. An attacker could poison the retrieval database without touching the prompt.
Dynamic prompts that incorporate user context or real-time data can’t be meaningfully hashed. A trading agent that includes current market conditions in its prompt has a different “prompt” every execution.
The TEE-based implementations address some of these cases. By running the agent in a trusted execution environment, validators can attest that the execution environment remained secure even if inputs changed. Phala Network’s implementation demonstrates this approach: the TEE attestation proves the code hash, not the prompt hash.
Known Limitations and Gaps
The Ethereum Magicians discussion reveals several structural limitations:
No on-chain composability: Smart contracts can’t easily read an agent’s reputation in a single transaction. The design relies on events and subgraphs, introducing latency. A DeFi protocol can’t atomically check reputation and execute a transaction—it must query off-chain first.
No multi-provider aggregation: The standard doesn’t define how to combine reputation from multiple sources. An agent might have ERC-8004 reputation, Gitcoin Passport scores, and platform-specific ratings. There’s no standard way to aggregate these into a unified trust signal.
Validator incentives are out-of-scope: The standard doesn’t specify how validators get paid or penalized. Without economic incentives, validators might collude with agents or simply not bother validating. A group of validators could agree to provide high scores to tampered agents, and the standard has no native mechanism to resolve disputes.
Off-chain reliance creates vulnerabilities: If an agent’s feedbackURI points to a server the operator controls, they can modify the content and update the hash simultaneously. Content-addressed storage (IPFS, Arweave) provides true tamper-evidence.
No prompt or config hash requirement: The standard doesn’t mandate hashing the actual agent configuration. Operators can change system prompts without any on-chain signal. Detection relies entirely on behavioral feedback, which may come too late.
Critics note the standard “prioritizes off-chain reads… big miss” for applications requiring real-time trust verification. The design assumes agents will be queried through indexers and subgraphs, not directly from smart contracts.
Part 4: Implications and Future Directions
Enabling High-Value Agent Commerce
By providing a trust layer for autonomous agents, ERC-8004 enables transactions that would otherwise require human intermediaries.
DeFi credit lines become possible when lenders can verify agent reputation. A trading agent with 24 months of positive history and TEE attestations might qualify for undercollateralized loans. The reputation serves as social collateral—the agent has something to lose if it misbehaves.
Corporate treasury management can delegate to verified agents. A DAO might authorize an agent to manage its treasury within defined parameters, relying on ERC-8004 reputation to select trustworthy candidates and validation scores to monitor ongoing behavior.
Risk management filters can automatically exclude unverified or low-reputation agents. A DEX might refuse to execute trades from agents without minimum reputation thresholds, reducing exposure to malicious actors.
The projected $10B+ agent economy depends on these trust mechanisms. Without portable reputation, agents compete purely on price, creating a race to the bottom. With verifiable history, quality agents can charge premiums.
Comparison with Alternative Approaches
Several competing approaches to agent trust exist:
Centralized reputation platforms like traditional app stores provide curated agent marketplaces with proprietary scoring. These offer better UX and immediate composability but sacrifice censorship resistance and portability. An agent’s reputation dies if the platform shuts down.
TEE-only solutions like Phala’s standalone implementations provide strong integrity guarantees but require specialized hardware. They verify execution environment security without addressing reputation accumulation or cross-platform identity.
Platform-specific systems like OpenAI’s GPT Store or Anthropic’s agent marketplace keep reputation siloed within their ecosystems. Agents can’t transfer their history when moving between platforms.
ERC-8004 trades immediate composability and enforcement for censorship resistance and portability. The bet: decentralized identity and portable reputation matter enough to justify the technical limitations.
Open Questions and Research Directions
Several research directions could address current limitations:
zk-Prompt proofs would use zero-knowledge cryptography to verify that an agent’s output was generated by a specific, untampered prompt without revealing the prompt itself. The agent proves “my output came from a prompt with hash X” without exposing the prompt contents. This preserves competitive advantages (proprietary prompts) while enabling verification.
Multi-provider reputation aggregation would create “Reputation Hubs” that combine scores from ERC-8004, Gitcoin Passport, ENS, and platform-specific systems. A standardized aggregation formula would produce unified trust scores, reducing fragmentation.
On-chain enforcement would move from “discovery” to “enforcement.” Smart contracts could automatically block transactions from agents whose reputation falls below thresholds, check validation scores before executing high-value operations, or require fresh TEE attestations for sensitive actions. This requires solving the composability problem—making reputation readable in a single transaction.
Sybil-proof aggregation research focuses on reputation systems that resist manipulation even without explicit client trust lists. Techniques from social network analysis and graph-based trust propagation could make getSummary more robust.
Prompt provenance systems would create verifiable chains linking outputs to inputs. Every agent response would include a proof of which prompt version, which model version, and which context produced it. Combined with TEE attestations, this could provide end-to-end integrity verification.
Practical Recommendations for Implementers
Teams building on ERC-8004 should consider these implementation patterns:
Use content-addressed storage exclusively. IPFS or Arweave URIs provide tamper-evidence that regular URLs can’t match. The hash is built into the address.
Implement automated hash verification. Don’t assume users will manually check hashes. Build tooling that automatically fetches off-chain content, computes hashes, and compares against on-chain records.
Maintain explicit trust lists. When calling getSummary, carefully curate the clientAddresses[] array. Include addresses you’ve verified through out-of-band channels. Review and update this list regularly.
Emit events for all configuration changes. Even if the standard doesn’t mandate it, emit custom events when you update prompts, models, or RAG databases. This creates an audit trail for users.
Combine ERC-8004 with TEE attestations. For high-value applications, require both reputation scores and fresh TEE attestations. The reputation shows historical behavior; the attestation proves current integrity.
Build reputation slowly. Start with low-stakes transactions to accumulate feedback before handling significant value. Users can filter by account age and transaction count.
Plan for reputation transfer. If you need to update an agent’s underlying model significantly, consider whether to preserve the existing identity or mint a new one. Document your versioning policy clearly.
Conclusion on Viability and Next Steps
ERC-8004 represents a first-generation solution to agent trust. It establishes the primitives—identity, reputation, validation—without mandating specific implementations. This flexibility enables rapid experimentation but leaves gaps that production systems must fill.
The standard’s viability depends on three factors:
Ecosystem adoption: If major agent platforms integrate ERC-8004 identity, network effects will drive further adoption. If they build proprietary alternatives, the standard becomes one of many competing approaches.
Composability improvements: The lack of on-chain reputation reads limits DeFi integration. Solutions like reputation oracles or L2-based caching could address this without sacrificing decentralization.
Validator economics: Without clear incentive mechanisms, validation remains a public good vulnerable to free-rider problems. Future versions might incorporate slashing, staking, or fee-sharing to align validator incentives.
The 48,000+ registered agents and 37,000+ feedback logs suggest meaningful traction. The question is whether this foundation can scale to support the high-stakes, high-value transactions that define true agentic commerce. Early implementations in DeFAI and robotics coordination show promise. The standard provides enough structure to enable trust while leaving enough flexibility for innovation.
The path forward requires parallel development: protocol improvements to address composability and validator incentives, tooling to make verification accessible, and real-world deployments to test the system under adversarial conditions. ERC-8004 won’t solve agent trust alone, but it provides the infrastructure layer other solutions can build on.