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.
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!
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
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)
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:
-
Deploy ERC-8004 compliant TrezaTEEValidator.sol
-
Run oracle infrastructure with <60 second response times
-
Publish attestation documents to IPFS with full PCR measurements
-
Use tag: “treza-nitro-v1” to identify our attestations
Questions for the working group:
-
Is the Validation Registry spec stable enough to build against, or should we wait for v1.1?
-
Should TEE provider tags be standardized (e.g., nitro-v1, sgx-v1)?
-
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.
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?
[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:
- Four primitives (Judgment/Delegation/Termination/Verification) for recording complete responsibility chains
- OTS proofs anchored to the Bitcoin blockchain that provide cryptographic timestamping and integrity guarantees
- Legal admissibility – OTS proofs have been accepted as evidence in multiple jurisdictions
- Complete open-source implementation (API, console, verification UI)
- IETF aiproto working group participation ( HJS: A concrete implementation for "User Confirmation Protocol" (item 3) · Issue #2 · jdrosen/aiproto-wg · GitHub )
How HJS Would Integrate with ERC-8004
When an agent completes work that needs verification:
- Work hash generation: The agent computes a cryptographic hash of its work output
- OTS proof creation: HJS generates an OTS proof anchoring this hash to the Bitcoin blockchain
- Response submission: The validator smart contract submits:
responseHash = keccak256(otsProof)tag = keccak256("ots")responseUri = ipfs://{proofCID}orhttps://hjs.sh/proof/{id}
- Verification: Anyone can independently verify the proof using standard OTS tools
Why This Matters
| Existing validation methods | OTS Proofs add |
|---|---|
| TEEs require specialized hardware |  Works everywhere, no hardware dependency |
| zkML requires complex circuits | Simple, based on standard cryptography |
| Staker re-execution requires stake | Trustless, based on Bitcoin’s security |
| All require trusting the verifier | 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:
- Draft an ERC extension for “OTS validation” as an official method
- Provide a reference implementation that validator contracts can call
- Run a public validator service for agents that want OTS proofs
Questions for the Group
- Would the ERC-8004 community be open to adding
tag = "ots"as an official validation type? - Should the validation response include an optional URI field for storing the full proof off-chain?
- Is there interest in a joint call with the HJS team to discuss integration?
Looking forward to大家的 feedback!
Links:
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.
Feedback welcome, particularly on cooldown design and security trade-offs.
Cyberpaisa
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.
(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.
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:
- Is there appetite for a recommended tagging convention so that cross-platform function-level reputation becomes interoperable, not just platform-specific strings?
- 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
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?
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.