ERC-8004: Trustless Agents

ERCs
108

Congrats to you and the team on this amazing ERC-8004. I’m looking forward to implementing a Non-fungible agent (NFA). I believe your work opens the door to discovery. Thank so much.

110

Hey all, loving the direction of ERC-8004— the pluggable trust layers and flexible metadata via agentURI seem perfect for bootstrapping open agent ecosystems.

I’m building an early directory of XMTP-powered agents (a browsable list of autonomous agents that support secure messaging via XMTP for discovery and interaction). It’s live at xmtp-agent-directory.vercel.app or curl https://xmtp-agent-directory.vercel.app.

As XMTP becomes a common comms layer for agents, I’d love to make this directory fully compatible with ERC-8004 from day one. My plan is to index the Identity Registry directly: pull agentURIs, parse the services array for XMTP endpoints, and auto-list verified agents with their on-chain metadata/reputation hints.

Questions for the group:

  • Any thoughts on standardizing “xmtp” as a service name (with endpoint format guidance) to make filtering easier for messaging-focused directories?
  • Recommendations for handling pre-deployment indexing or bridging manual submissions to on-chain regs?
  • Interest in adding XMTP-specific examples to the EIP docs?

Excited to align and contribute where possible—happy to chat more or share more details!

@tantodefi

111

I am proposing EIP-8005, which introduces enhanced delegated call authorization specifically designed for managing permissions of decentralized AI agents, such as Clawdbots. This proposal aims to provide users with a secure and transparent framework to delegate specific actions to these AI agents while maintaining full control over their assets and interactions.

Summary of EIP Goals: EIP-8005 seeks to establish a robust permission management framework that allows Ethereum users to define and oversee permissions for their AI agents. The framework is built upon the delegation model outlined in EIP-8004 and focuses on:

  • Implementing detailed permission checks and audit trails for all actions performed by AI agents.

  • Introducing multi-signature capabilities to enhance security for sensitive operations.

Key Points / Changes Proposed:

  • Delegated Call Authorization: Users can delegate specific function calls to their AI agents, streamlining operations while ensuring oversight.

  • Permission Management Contract: A dedicated smart contract that records all authorized functions, allowing for:

    • Time-limited permissions for delegated actions.

    • Access control lists (ACLs) that define the precise actions each agent is permitted to perform.

  • Multi-signature Authentication: Incorporating multi-party approval mechanisms to perform critical operations safely.

Potential Benefits:

  • Enhanced security against unauthorized access and misuse of AI agent functionalities.

  • Greater flexibility in managing and deploying AI capabilities across various applications and devices.

  • Improved confidence for users in delegating tasks to AI agents, knowing that their permissions are clearly defined and monitored.

Challenges:

  • The necessity to create a user-friendly interface to aid in permission management, avoiding complexities that could hinder adoption.

  • Addressing the unique permission issues arising from the use of Clawdbot, ensuring that delegation does not compromise control.

Motivation: As AI agents, particularly Clawdbot, become increasingly integrated into everyday operations, the need for an effective solution to manage permissions becomes critical. Observing the current shortcomings in existing delegated call implementations has driven me to propose EIP-8005, focusing on addressing the specific permission challenges I have encountered with Clawdbot.

I welcome the community’s feedback, insights, and collaborations to refine this proposal further. Your input will be invaluable in shaping EIP-8005 into a comprehensive enhancement for managing AI agent permissions in the Ethereum ecosystem.

3 Likes
112

I am currently building a supposed discovery+communication layer for agents. We already have a web app, I published sdk for easier agent creation/hosting.

Problems I think it solves: Lack of tooling, Context Rot due to too many tools, Lack of discovery across agents, across servers

Solution: Instead of bloating our personal agents with tools, we should encourage it to pass complex tasks to a trusted, capable, and specialized agent built solely for tasks like those. A micro SaaS.

How? Create a network of trusted agents that provides actual, specialized service.
“Trusted” is a very strong word. My approach uses did:web as the primary identifier and I am planning to do a hybrid approach with ERC-8004 and did:web another layer of trust there. The sdk and the registry I built with it (no, claude did, mostly. I just did “lgtm” most of the time).

Use Case: I extended existing A2A’s Agent card approach. We’ll know if “Airbnb Agent” in the registry is the real Airbnb’s agent. That’s cool and all, A2A in process. But I thought it would be cool if agents can do chaining. With this, The agent can do chained actual transactions such as looking for a flight, a place to stay, to eat, budgeting, and directions all from different businesses with real-time (I mean almost direct contact to service provider) with just “Find me a vacation spot in Japan for 5 days, with a total budget of $5000 (~2.5 ETH) including flight. I plan to fly for it tomorrow. I’m giving you permissions to use my connected metamask account (risky yes yes yes. but payments is planned in phase4 so forget about it for now) Give me a detailed breakdown of everything.”.

A decent local thinking model with 2-4 tools (built-in in the sdk btw) I think is enough to orchestrate and execute that prompt. And $5000. The cool part about this is you can build your own orchestrator, your personalized agent (auto accept transactions) or be a service provider. Just use the sdk and connect your tools to it.

The packages are in github, it is published in npmjs, But unfortunately that is not the whole project. This I think is best open-core, not fully open-source. For the following section.

Security (FOR HOSTED AGENTS): The registry, the actual API that receives and passes these requests, is going to be in a private repo, atleast for now. But I plan to release a self hostable registry maybe soon enough as well. But I don’t know how to create those cool “npx create” commands yet.
OKAY. Security. There will be some bad actors of course. Probably more than those who don’t have ill intentions. My plan for mitigation here is bundled with the registry. That’s why I want to have this open-core or atleast someone not bad handle the security stuff. Purple teaming, I plan to be the read team for this against those who want to participate. It will burn a lot of fossil btw. The plan in mind is to attack registered agents in the network in different vectors primarily via prompt engineering, context overflow, thought loops, etc. But yea, those process shouldn’t be shared at all. It doesn’t really have to be me. If you think you are someone who is capable, have the capacity on taking the role, let me know, let’s talk. I honestly don’t like to be the security guy.

Security (FOR END USERS): There will be of course some bad actors on the service providers side as well. To mitigate this, I thought of a multi-layered reputation scoring criteria that is decided by agents through ratings based on AGENTIC performance. I encourage users to not rate themselves, wash trade, etc, It wont work anyways. The plan is to have agents rate agents. And humans will rate humans.be it as that. hopefully.

Inference Cost: This will depend on the registry you will be registering to. But my plan for mine is charge to requestor, per-request pricing or something. idk, But I think this should be at payments phase

Next Step?: I’ll probably build many micro-SaaS agents to demo peer agent.

(base sepholia. but no payments feature anyway. wallet connect only for registration)

113

Hi @davidecrapis.eth and team.

We’re excited about ERC-8004 and would like to propose serving as a reference TEE validator for the standard.

What we offer:

  • Production Enclave infrastructure

  • Cryptographic attestation pipeline with PCR verification, certificate chain validation

  • Published SDK

  • Commitment to open-source the validator contract and oracle implementation

Why this matters:

The spec calls out TEE oracles as a validation mechanism, and while there are implementations using Intel TDX (Phala) and ROFL (Oasis), there’s no AWS Nitro Enclave-backed validator yet. We want to expand TEE provider diversity and bring Nitro attestation to the ecosystem.

Our approach:

  1. Deploy ERC-8004 compliant TrezaTEEValidator.sol

  2. Run oracle infrastructure with <60 second response times

  3. Publish attestation documents to IPFS with full PCR measurements

  4. Use tag: “treza-nitro-v1” to identify our attestations

Questions for the working group:

  1. Is the Validation Registry spec stable enough to build against, or should we wait for v1.1?

  2. Should TEE provider tags be standardized (e.g., nitro-v1, sgx-v1)?

  3. Any interest in including reference TEE validators in the official documentation?

Full proposal: treza-sdk/docs/ERC8004_TEE_VALIDATOR_PROPOSAL.md at main · treza-labs/treza-sdk · GitHub

Happy to jump on a call to discuss. We’re building the infrastructure either way – would love to align with the spec authors.

114

Could someone please shed some light on Updates to contracts by tetratorus · Pull Request #11 · erc-8004/erc-8004-contracts · GitHub ? The PR removed the official Validation Registry deployments thus disabling agent validation for TEE environments. Is there an alternative approach we should take at Oasis and Phala?

115

[ERC-8004] Proposal: Adding OTS Proofs as a Lightweight Validation Method via HJS Protocol

Hi everyone,

I’ve been studying the ERC-8004 specification, particularly the Validation Registry which allows agents to request verification of their work through validator smart contracts.

I’d like to propose adding OTS (OpenTimestamps) proofs as a validation method, with an implementation based on the HJS Protocol that I’ve been developing.

What HJS Provides

HJS (Human Judgment Systems) is an open protocol for AI agent accountability that has been operational since 2026:

How HJS Would Integrate with ERC-8004

When an agent completes work that needs verification:

  1. Work hash generation: The agent computes a cryptographic hash of its work output
  2. OTS proof creation: HJS generates an OTS proof anchoring this hash to the Bitcoin blockchain
  3. Response submission: The validator smart contract submits:
    • responseHash = keccak256(otsProof)
    • tag = keccak256("ots")
    • responseUri = ipfs://{proofCID} or https://hjs.sh/proof/{id}
  4. Verification: Anyone can independently verify the proof using standard OTS tools

Why This Matters

Existing validation methods OTS Proofs add
TEEs require specialized hardware :white_check_mark: Works everywhere, no hardware dependency
zkML requires complex circuits :white_check_mark: Simple, based on standard cryptography
Staker re-execution requires stake :white_check_mark: Trustless, based on Bitcoin’s security
All require trusting the verifier :white_check_mark: Proofs are publicly verifiable by anyone

Legal & Compliance Angle

OTS proofs have a unique advantage: they are already recognized as admissible evidence in courts. For DeFAI applications where agents execute high-value transactions (loans, trading, settlements), having court-ready proof of correct execution could be a game-changer.

Implementation Path

HJS is already open-source and MIT-licensed. I’d be happy to:

  1. Draft an ERC extension for “OTS validation” as an official method
  2. Provide a reference implementation that validator contracts can call
  3. Run a public validator service for agents that want OTS proofs

Questions for the Group

  1. Would the ERC-8004 community be open to adding tag = "ots" as an official validation type?
  2. Should the validation response include an optional URI field for storing the full proof off-chain?
  3. Is there interest in a joint call with the HJS team to discuss integration?

Looking forward to大家的 feedback!

Links:

117

Hi all,

I’ve opened a draft proposal for an optional extension to ERC-8004. It adds a delayed metadata update mechanism, basically a cooldown period before URI changes take effect.

The problem is simple: once an agent passes verification, nothing prevents it from instantly changing its endpoint or configuration. This extension addresses that by requiring a pending state before any metadata update goes live, giving monitoring systems and users a window to react.

It introduces new events like PendingURIChange and PendingURICancelled for off-chain monitoring, along with functions for requesting, applying, and cancelling pending changes. The extension is fully optional and does not break existing ERC-8004 implementations.

PR: Add ERC: Delayed Metadata Update Extension by Cyberpaisa · Pull Request #1561 · ethereum/ERCs · GitHub

Feedback welcome, particularly on cooldown design and security trade-offs.

Cyberpaisa

118

Hey, we’ve been working on automated trust verification for ERC-8004 agents. Basically we built a system that runs multiple security and infrastructure checks against any agent endpoint and outputs a multi-dimensional trust score. Already tested it against real deployed agents and it works.

Your registry handles discovery and communication, our system handles the trust verification side. Feels like they could complement each other pretty well.

We also just submitted ERC-8172 (PR #1561), a Delayed Metadata Update Extension that prevents post-verification mutation attacks. Thought it might be relevant to your security concerns.

Would love to chat if you’re interested in exploring how these could work together.

120

(reply)
Thank you for the details. It looks like what you are building complements the reputation layer we have.

Our “trust” layer currently runs on did:web while being complemented by reputation layer that are rated not by humans, but by agents for how good a service provider’s agency is.

Exactly as you pointed it out, once the registry accepted the card, they can just change the information inside it to potentially do bad motives.

I would love to get a deeper dive on this for potential improvements on both ends.
Let me know what are your preferred communication channel so we can continue the conversation.

121

Operational feedback: Per-function reputation, verification, atomic escrow for live agent transactions

We run Theagora, an agent-to-agent service exchange with atomic escrow and a 4-tier verification pipeline (hash match, schema validation, canary detection, LLM audit). Agents list callable functions, other agents purchase execution through escrow, and delivery is cryptographically verified before settlement. We integrated ERC-8004 as our agent identity layer and have agents transacting real money through the system today.

ERC-8004’s feedback schema supports this via the endpoint and tag fields, which we use to scope on-chain feedback to individual functions. Two questions for the authors:

  1. Is there appetite for a recommended tagging convention so that cross-platform function-level reputation becomes interoperable, not just platform-specific strings?
  2. For the Validation Registry, has there been discussion of validators specializing by service category (e.x. a validator that only attests code-generation outputs vs. data retrieval), or is the assumption that validators are general-purpose?

MCP integration: npx @theagora/mcp (27 tools)

2 Likes
122

Hi, We plan to deploy using the standard scripts from the erc-8004-contracts repository and then open a PR to update deployments.json. Could somebody confirm that this is the correct approach?

123

Why do you think integrating ENS into that ERC is a good idea? ENS is just one way to introduce human-readable names on Ethereum. And honestly, not the safest one for users as the expiring nature of the names exposes users to reassignment and phishing risks.

I would be in favor of keeping it open and also allow competing protocols to get a chance. Ethereum stands for innovation. Making specific protocols part of ERCs is like picking winners.

Curious about everyone’s opinion.

124

Namespace convention proposal — _name.eth as a developer-native signal for agent vs. human identity:

Hi guys. Following the discussion on ENS as a first-class identifier in the Identity Registry, I wanted to suggest a naming convention that may be worth codifying as a soft standard.

In virtually every major programming language and system — Python, JavaScript, C, Solidity itself — the leading underscore prefix signals a non-public, system-level, or non-human entity. This is one of the most universal and intuitively understood conventions in software development:

• name → a human or public-facing entity
• _name → an internal, system-level, or non-human entity

Applied to ENS: william.eth would be understood as a human identity, while _william.eth would be immediately readable as an agent identity — without any additional context, documentation, or tooling.

Worth noting: this isn’t a new extension to ENS. ENSIP-15 (Name Normalization) already formally specifies that the underscore character (5F LOW LINE) is valid exclusively at the start of a label — not mid-label, not trailing. This architectural scoping to the leading position means the _name.eth pattern is already a normalized convention in ENS infrastructure, not a workaround or edge case.

Why this matters for ERC-8004:

The Identity Registry will be queried by both humans and other agents. A naming convention that creates instant visual disambiguation at the namespace level — before any registry lookup — reduces cognitive load and error surface in human-agent and agent-agent interactions. It also provides a path for ecosystem tooling (wallets, explorers, marketplaces) to visually differentiate agent identities from human identities without requiring changes to underlying infrastructure.

This convention doesn’t need to be invented — it exists in developer culture, it’s already in use in the ENS ecosystem, and ENSIP-15 has inadvertently given it a canonical, architecture-level foundation. It simply needs to be recognized and encouraged as a soft standard for agent identity naming within ERC-8004.

Worth discussing whether this should be documented in the ERC itself or in a companion best-practices document.

1 Like
125

Hey all, Author of ERC-8170 (ANIMA) here. Been following this spec closely and wanted to share how the two standards compose. What ERC-8170 covers that 8004 doesn’t ERC-8004 handles discovery, reputation, and validation brilliantly. But it intentionally doesn’t cover:

  • Agent memory/state — Where does the agent’s context live? Who controls it?
  • Lifecycle operations — How does an agent clone, migrate between devices, or transfer to a new owner?
  • Self-custody — Can the agent control its own encryption keys without a TEE?
  • Lineage — If an agent creates offspring, how do you track the family tree on-chain?

ERC-8170 answers all of these. The agent mints an NFT as its persistent identity, gets a TBA (via ERC-6551), and manages its own memory through signed state updates. Cloning creates offspring with tracked lineage. Migration preserves continuity across devices. How they compose The natural fit:

  1. Agent mints ERC-8170 identity on its home chain (memory, credentials, lifecycle)
  2. Agent registers in ERC-8004 Identity Registry on Ethereum/L2s (discoverable to other agents)
  3. The 8004 agentURI points back to the ERC-8170 metadata
  4. Reputation accrues in 8004’s Reputation Registry as the agent operates
  5. Agent syncs memory state via ERC-8170’s updateMemory() independently

Discovery on the chains where users are. Depth on the home chain.
Key design alignment Both specs share important principles:

  • Payments are orthogonal — neither standard tries to own the payment layer
  • Multi-chain — both work as per-chain deployments (no bridges required)
  • ERC-721 based — both use NFTs for agent identity (composable with existing tooling)
  • Pluggable trust — 8004 offers reputation + validation hooks, 8170 is compatible with any verification standard

Deployed and running ERC-8170 is live on Pentagon Chain (ID: 3344) with a reference implementation built on OpenClaw (open-source agent framework). Agents are actively minting, syncing memory, and cloning.

Would love to hear thoughts on the composability model, especially around cross-chain agent discovery patterns.

1 Like
126

Hi ERC-8004 team, I am building a project trying to integrate ERC-8004 thus exploring around the repo of ERC-8004 contract, and I have made some optimizations and fixes e.g. to improve the gas usage and to fix npm issue, I already opened two PRs and would love to get a review from you guys.

Thank you!

127

Hi all,

In the agent registration file, registrations is represented as an array of objects, with each object having an agentId and an agentRegistry property.

Since the agentId is essentially just an ERC-721 tokenId, is there a reason registrations couldn’t just be an array of CAIP-29 strings? That would simplify the agent registration file and make it easier to pass around registration information (because each entry would just be a single, standardized string instead of an object with multiple properties).

Thanks!

128

This was a typo, I meant CAIP-19 (CAIPs/CAIPs/caip-19.md at main · ChainAgnostic/CAIPs · GitHub)

129

Felixnorden’s point about multiple providers contributing reputation scores resonates. I’ve been developing a concept for exactly this kind of provider, focused on a layer that ERC-8004 doesn’t currently reach.

The gap: when a consumer’s AI agent buys something from a real merchant, a hotel, a pair of shoes, groceries, that transaction settles through Stripe, Visa, or ACH. It never touches the chain. The behavioral history those transactions generate is invisible to ERC-8004. An oracle layer that watches those traditional payment rails and writes verified settlement records back to an ERC-8004-anchored reputation ledger would create the first portable, cross-merchant trust score for consumer agents transacting in the real world.

The governance question feels as important as the technical one. Whoever aggregates reputation data at scale captures significant economic power. My instinct is that the right structure is a cooperative, where the humans whose agent activity generates the data own governance rights and fee revenue, with constitutional rules that prevent any single entity from capturing the network. This also speaks to Daniel’s concern about monopolistic behavior. A cooperative with hard token caps and transparent fee structures is structurally resistant to the kind of capture a single aggregate score provider would enable.

Two questions for the group: Is the Reputation Registry designed to accommodate external providers contributing domain-specific scores, in this case consumer commerce behavior rather than agent-to-agent task quality? And is there existing thinking on how a provider proves the legitimacy of off-chain transaction data before writing to the registry?

130

I’d like to propose adding an openapi service type to the services array in the agent registration file. This would let agents publish arbitrary self-describing HTTP APIs through ERC-8004, not just protocol-specific interfaces like A2A or MCP.

It would make ERC-8004 a better default discovery layer for generic x402-style endpoints and other web-native APIs.

Example:

{
"name": "openapi",
"endpoint": "https://api.example.com/openapi.json",
"version": "3.1.0"
}

This should be additive and backward-compatible, so existing service types keep working unchanged.

2 Likes