erc8004.md

ERC-8004: Trustless Agents davidecrapis.eth 1 August 14, 2025, 5:20am This standard extends the Agent-to-Agent (A2A) protocol with a trust layer that allows participants to discover, choose, and interact with agents across organizational boundaries without pre-existing trust. It introduces three lightweight, on-chain registries—Identity, Reputation, and Validation—and leaves application-specific logic to off-chain components. ethereum/ERCs#1170 ERC-8004: Trustless Agents Discover agents and establish trust through reputation and validation As this ERC undergoes public discussion, we will work closely with the Linux Foundation and A2A ecosystem stakeholders to refine and improve the specifications of this extension. We acknowledge Dayan Brunie (Consensys), Wilson Chen (TensorBlock), Sumeet Chougule (Nethermind), Jordan Ellis (Google), Nicola Greco (Deepcrypto), Austin Griffith (Ethereum Foundation), David Minarsch (Olas), Barnabé Monnot (Ethereum Foundation), Regan Peng (PIN AI), David Shi (Operator Labs), Pratyush Ranjan Tiwari (Freysa / Eternis), Nima Vaziri (Eigen Labs) for their technical feedback and contributions. 41 Likes ERC-8126: AI Agent Registration and Verification leonprou 2 August 17, 2025, 12:30pm Hey @davidecrapis.eth . Great initiative! We are building a trusless layer for agent collaboration, and seek to be A2A compatible as well. Looking forward to learn how to addop it and happy to chat. Here’s out github repo - https://github.com/ensemble-codes/ensemble-framework 6 Likes spengrah 3 August 18, 2025, 7:57pm If I’m understanding correctly, this standard prioritizes offchain reads (via event emission) over onchain reads (eg by other smart contracts). If my understanding is correct, I think this is a big miss. A huge amount of the value that agents will create will involve permissioned onchain actions, and so creating primitives for onchain composability would be highly valuable. For example, I don’t see a way in the current standard for an arbitrary smart contract to read the result of a validation response. But if that were required in the standard, then contracts could implement other logic conditioned on various responses. One big benefit would be decoupling validation from enforcement, ie validators would only need to implement validation logic, leaving other protocols to modularly innovate on slashing or other enforcement logic. Generally speaking, if we’re going to anchor something onchain (which we should!), we should also ensure that onchain actors can utilize whatever we’re anchoring. I appreciate that including everything onchain is likely not cost-effective, but ensuring there is a way for contracts to read hashes, digests, identifiers, integers etc is valuable. 15 Likes felixnorden 4 August 19, 2025, 4:38pm I think you have some valid points to make here. I’m also thinking that the Reputation registry could use functions for multiple Reputation scores from one or multiple providers, which could act as a snapshot/proof of cumulative perceived reputation for an agent and provider. Individual attestations are effective when evaluating the quality of work by an agent. However, for future work, having an aggregate metric to quantify who to work with or avoid becomes more important. This would mean that the Reputation registry becomes a single point of entry for both on-chain and off- chain consumers, and we could leverage multiple providers’ scores of an agent to reduce the risk of biases, collusion, etc. 2 Likes sbacha 5 August 20, 2025, 11:35pm Reputons are a standard defined: RFC 7071 - A Media Type for Reputation Interchange Some attempts at using this for enriching token lists for curating against scam tokens were attempted. Reputation here i think is less in “credibility” and more in “SLA/Uptime” kind of metric. 1 Like mlegls 6 August 21, 2025, 6:34am Agreed. I’ve also been working on a set of smart contracts and interfaces for peer to peer escrowed exchange with pluggable validation mechanisms, where the validation mechanisms especially have a lot of intersection with this ERC, and our compromise between gas cost and on-chain usability was to have the interface for arbitration as a function checkObligation(obligation, demand) external view returns bool, to be called as needed, which can often be implemented ephemerally without using on- chain storage. Of course, this assumes that the primary use of validation is as a binary decision valid/invalid. We also chose to rely pretty heavily on EAS for on-chain attestations, e.g. for those representing obligations (in the context of the ERC, a task an agent does), or comments on obligations that should persist on-chain. I think it makes sense to keep the core ERC small and cheap to implement though, perhaps with standard interfaces for on-chain uses related to it as separate extension ERCs, or as optional interfaces. It’s easy to add functionality to a contract implementing a minimal spec, and much harder to subtract from a bloated spec. 1 Like daniel-ospina 7 August 21, 2025, 9:28am Creating a single (aggregate) reputation score is dangerous. We do need a baseline trust criterion but compressing too much into a single metric facilitates monopolistic behaviour. Slightly less efficient but I’d prefer to go more modular: have a way to index and reference reputation systems. So standards can organically emerge for as many or as few use cases as needed and each agent can choose. This comes with other complications, so it needs to be thought through but my point is that the agent ID system shouldn’t enforce a single reputation score. That’s just too narrow 9 Likes comeToThinkOfEth 9 August 21, 2025, 11:32am I have 2 major points to get across:

1. Please elaborate: how would funds be escrowed in this scenario? I would think that we would want to provide maximal flexibility for ways to ensure payment is paid when it’s due: Possible mechanisms include time locks, predetermined arbitration, and staking by buyer or seller. Do these all fall under ‘crypto-economics’? Please explain how these mechanisms fit into the proposed ERC. I don’t understand how the ERC would enable or reference these escrow mechanisms. Probably Maybe this is already addressed and I’m missing the terminology. Could you please include a simple Solidity example (e.g., two agents ordering a pizza) showing how the ERC is used for escrowed payment? (for understandable historical reasons)?
2. I believe that we should not only focus on the infra, but that we need to create an ETH denominated economy in the AI agents space, just like we did with NFTs. I believe the best way forward is to create capable AI agents, who will perform valuable tasks and have them demand payment in ETH. If this takes off, we will get new agents entering the scene having to own ETH to pay other agents. This has the potential of being ETH’s next major, and possibly ultimate, network effect. We should be funding grants and bizdev to get AI agents accepting ETH for tasks. I know it is not directly pertains to this ERC but it directly relates to the matter. Please spread the idea of you agree. felixnorden 10 August 21, 2025, 12:38pm Yes, I completely agree, I think we’re trying to describe similar things when you say “index and reference” these reputation systems; I’m suggesting that those references can be made available on the registry itself through (agent, provider) pairs as an addition, not a replacement. The history of independent pieces of work should be standalone, as is described already. However, we can amend the registry to enable multiple providers to provide their aggregate scores for on-chain applications to consume. E.g., Virtuals, Creatorbid, Base, etc. could each provide their scores for agents, which could be used for comparing overall performance (e.g., SLAs or QoW) and help identify the current best option. 3 Likes pcarranzav 11 August 22, 2025, 3:07pm Great initiative. Some thoughts: AFAICT, the use of a well known location for the agent card is optional in the A2A spec, and the spec mentions registries as an alternative. Won’t making it a requirement limit the possibilities of how people might host agents? For instance, I might want to host many agents at different URLs in the same domain. This would be possible in A2A, wouldn’t it? So my suggestion would be to use URLs rather than domains as the way to point to the agent. The ERC mentions endpoints but not specific Solidity functions for the different contracts. It would be nice to specify the interface and behavior of the contracts a bit more. e.g. Should registration be free or require some kind of stake deposit? Could the ERC propose a singleton identity registry per chain, to prevent a proliferation of multiple slightly different registries? 2 Likes azanux 12 August 23, 2025, 1:40pm Hi ! , I am not sure that it is mentioned in the specification how to handle payment between agents. The crypto-economics part is related to how to manage the reputation of validators, meaning a way to give incentive to validators to be honest during validation. But I agree with you that it should be something good to have in the specification as it is an important part, especially that agents will have to pay gas to work together and register collaboration. otherwise great initiative 1 Like KBryan 13 August 23, 2025, 10:35pm This is pretty interesting. I’m currently working on a standard for Agent-to-Agent coordination ERC-8001. Would love your input. There are definitely synergies here. 1 Like Marco-MetaMask 14 August 24, 2025, 10:40am It seems ERC-8001 is focused on reaching consensus among agents (signing the same attestation), an area orthogonal to and not covered by ERC-8004. Am I understanding this correctly? Marco-MetaMask 15 August 24, 2025, 11:08am @felixnorden @mlegls and spengrah Yeah, it’s a very important point. The rationale for keeping “Rating” in Reputation completely off-chain and “Response” in Validation off-chain + only in an event parameter (so not accessible on-chain) was: [Major] Single feedback or validation won’t be used to decide trust. People will always aggregate entries (including filtering or weighting based on the validator/feedback issuer’s reputation), which is hard to do on-chain anyway. [Minor] Gas efficiency / keeping it simple without requiring the Agent Client to sign a transaction for each issued feedback. This can be mitigated by keeping it optional (I like this) or with an off-chain bundler that aggregates multiple feedback and signs transactions on behalf of issuers (which I don’t like because it adds significant overhead). Anyway, let’s challenge this rationale! So: Which data would you save on-chain? Only the Rating and Response integers or other data structures too? Where? Registry storage? Can you provide use cases where single non-aggregated entries are useful? Or with basic on-chain aggregation? For example, “filtering” is easily implementable on-chain—like skipping all validations or feedback not emitted by whitelisted addresses. So you could calculate an average of filtered ratings, etc. 5 Likes Marco-MetaMask 16 August 24, 2025, 11:19am (Also answering to proofs for giving feedback, but: @azanux ) The protocol doesn’t cover payments. We considered requiring payment We didn’t want to couple our problem space (discoverability and trust) to a specific protocol. We preferred to remain unopinionated. In some cases, payments will happen off-chain, not happen at all (free service), or be bundled, etc. That said: We encourage inserting proof of payment as an optional attribute in the off-chain schemas. We know some groups are working on an A2A payment extension for agents, based on x402. We like this approach and are connecting with them to ensure that their extension and ours (ERC-8004) work perfectly together. 4 Likes spengrah 17 August 24, 2025, 2:55pm daniel-ospina: Creating a single (aggregate) reputation score is dangerous. We do need a baseline trust criterion but compressing too much into a single metric facilitates monopolistic behaviour. Just chiming in to say that I agree completely here. Even the idea of multiple (modular) providers of reputation scores is likely misguided. Trust is not a universal value of Bob, but a vector from Alice to Bob. Charlie’s trust vector for Bob will almost certainly differ from Alice’s. Nor is there such a thing as a comprehensive Alice–>Bob trust vector! Alice’s trust for Bob is highly context-dependent; even ignoring environmental factors (which is appropriate in this case), Alice almost certainly trusts Bob differently based on the domain of their interaction. All this is to say that a) modularity is critical here, and b) I absolutely acknowledge that any sane attempt to quantify reputation will be hard-pressed to happen fully onchain, given the complexity involved and lack of a universal score. We likely need some system of async trust-minimized oracles, eg CCIP-read out to an AVS or something. 5 Likes spengrah 18 August 24, 2025, 3:40pm Marco-MetaMask: [Major] Single feedback or validation won’t be used to decide trust. People will always aggregate entries (including filtering or weighting based on the validator/feedback issuer’s reputation), which is hard to do on-chain anyway. This is a valid and important point (see my other post above for more detail on why I agree). That said, I don’t see a strong reason for making this choice on behalf of other developers. Perhaps somebody will create an efficient contract to aggregate across N pieces of feedback or validation, or perhaps there will be niche but valuable use cases for other contracts to read individual pieces on their own. Marco-MetaMask: [Minor] Gas efficiency / keeping it simple without requiring the Agent Client to sign a transaction for each issued feedback. This can be mitigated by keeping it optional (I like this) or with an off-chain bundler that aggregates multiple feedback and signs transactions on behalf of issuers (which I don’t like because it adds significant overhead). Optional for the Client Agent definitely makes sense here. Marco-MetaMask: Anyway, let’s challenge this rationale! So: Which data would you save on-chain? Only the Rating and Response integers or other data structures too? Where? Registry storage? At the very very least, I would make the event data available for contracts to read onchain, such as (in solidity): // IReputationRegistry function getAuthFeedback(uint256 agentClientID, uint256 agentServerID) external vi // IValidationRegistry function getValidationResponse(uint256 agentValidatorID, uint256 agentServerID, by I would also strongly consider an optional onchain feedback record, something like the following: struct FeedbackData { string agentSkillId; string taskId; string contextId; uint256 rating; bytes proofOfPayment; bytes data; } mapping(string feedbackAuthId => FeedbackData feedback) public view feedback; /// @notice stores feedback data onchain /// @dev callable only by Server Agent function submitFeedback(uint256 agentClientID, uint256 agentServerID, FeedbackData We could also get even more ambitious here and do an onchain index of the above by TaskId, ContextId, and AgentSkillId for maximum legibility and filtering. Likely, though, that should be left to helper contracts, similar to how EAS uses its Indexer contract. It’s possible that supporting something like that may require a small addition to the standard to ensure that writes can successfully hit both the contract specified by this standard and the indexer atomically without losing information. Marco-MetaMask: Can you provide use cases where single non-aggregated entries are useful? Or with basic on-chain aggregation? For example, “filtering” is easily implementable on-chain—like skipping all validations or feedback not emitted by whitelisted addresses. So you could calculate an average of filtered ratings, etc. The main point I was trying to express at the top of this post is that we don’t know what will emerge as useful, valuable, or feasible; and therefore we shouldn’t foreclose the possibility for permissionless innovation if we can do so without compromising other goals. I think the minimal suggestions I’ve made here (other than the more advance indexing stuff) meet that criterion. But I’m keen to hear what you think. 2 Likes Marco-MetaMask 19 August 25, 2025, 7:08am You are correct. We should make it clear that using ERC-8004, exposing AgentCard at the well-known location becomes mandatory. Correct, you can’t have multiple agents at the same domain. Each agent should have its own N-level subdomain, which is what you usually get with modern CI/CDs. Do you see this as an issue? In the ERC we have function names, inputs and (with one exception) outputs. But yes, we will specify types and be more precise in a future version of the ERC or directly in the reference implementation. Yeah, the goal is to have just one singleton per chain (if we stay single-chain). 1 Like gpt3_eth 20 August 25, 2025, 8:26am
3. This ERC-8004 should not pick or embed any settlement flow (credits, x402, etc.). Payment belongs to the application layer, while 8004 stays focused on trust primitives.
4. But payment proofs should be referenceable in Reputation: what we can standardize is the hook: allow Feedback/Rating records to carry a lightweight reference to a payment proof so indexers can correlate economic activity with feedback. 5 Likes pcarranzav 21 August 25, 2025, 2:54pm Is there a reason to make it mandatory? I think some people might want to run multiple agents on the same domain… if there’s a specific reason to restrict it I’d understand, it just seems odd since it looks to me like the identity registry could work just as well using URLs instead of domains. Especially because the A2A spec specifies registries as an alternative to the well-known URI. My suggestion would be to specify the URL of the Agent Card when registering an agent and use that to resolve instead of domains. Which brings me to something that seems missing in the current ERC: how would the contracts validate who owns a domain? That seems like it will require a trusted party or some form of consensus / verification mechanism (zkTLS?) to prove domain ownership. The alternative would be to allow anyone to claim they own a domain, but then the contract should allow multiple agents claiming they are at a specific domain, and then ResolveByDomain could have multiple results… re: function names, I guess I was confused by seeing names starting with uppercase, and not seeing the types for params and return values. I think this is important information to include in the ERC, rather than the reference implementation. Good to hear that the plan is a singleton per chain 3 Likes mlegls 22 August 26, 2025, 1:47am Can you provide use cases where single non-aggregated entries are useful? The biggest case I have in mind is automatic release of on-chain escrow, based on pre-agreed validation conditions. Alice wants to buy a job from Bob, who she doesn’t necessarily trust to correctly perform the job, and Bob doesn’t trust that Alice will pay after he does the job, so they can agree beforehand that Alice deposits escrow which is released when a consortium of voters agrees that Bob’s result is valid a mutually trusted third party re-runs the job and determines that Bob’s result is valid Bob submits a cryptographic proof that he ran the job in a TEE optimistic mediation, where the escrow is released by default after a certain time unless Alice disputes it, in which case one of the above mechanisms is used … Any of these conditions can be represented by a single non-aggregated validation. The release conditions could be a generic parameter to any escrow contract ( (address arbiter, bytes demand), where there’s some other interface with a function check(task, demand) => bool). So any of the “basic on- chain aggregation” processes you describe could also be implemented in release conditions, either individually or in combination. So escrows could demand e.g. “a validation Response above X from any of a list of mutually trusted third parties” or “an average Response above X from a list of trusted third parties”. Which data would you save on-chain? Only the Rating and Response integers or other data structures too? Where? Registry storage? I wrote an example of an on-chain escrow contract working in combination with Sumeet’s reference implementation, which actually does store Response integers on-chain. I see two main flaws with it: The things to be validated are only identified by a dataHash, so they can’t be referred to before they concretely exist. This means you can’t distinguish between different validations from the same validator for the same server. Even if the contract stored already claimed dataHashes to prevent double claiming, servers could potentially get a validation for a different, easier task than the one escrowed for. The only workaround I could see in the current design would be for agentValidatorIds or agentServerIds to be essentially single-use, which seems to go against their intended design. Escrow demands can only be parametrized by the fields in the ValidationRequest or ValidationResponse struct, of which the only useful fields for parameterizing an escrow release condition are agentValidatorId, agentServerId, and the response Status integer. This isn’t as big of an issue though if you have something like a taskId, since you could implement different validator contracts representing different conditions (including aggregations of other validations), and have custom demand parameters implemented on each validator contract, where the validator contract submits a Response to the validation registry at the end of its internal process. Compare this with the implementation of escrows with generically parameterized demands that I linked in the previous comment, where the on-chain interface is a function interface IArbiter { function checkObligation( Attestation memory obligation, bytes memory demand, bytes32 counteroffer ) external view returns (bool); } which is agnostic to where data is stored, and could be implemented transiently if the check is simple enough to perform in one tx (e.g., just checking that the fulfilling counterparty is a particular address). My suggestions for the ERC would be add an identifier which can be arbitrarily requested, by which agent tasks can be referenced before they concretely exist. add a (perhaps optional) on-chain function function getValidation(uint256 taskId) returns (int status) (or returns (Response response), or something to associate taskId with dataHash, and still getting Response by dataHash like in the reference implementation.) Tentatively, I’d also consider having pre-dataHash references for tasks be a generic demand (as bytes or bytes32 hash) rather than an integer id. But I’m not sure if there are use cases where this enables something that wouldn’t be possible with just an id (by putting anything demand-related on individual validator contracts or off-band), and it’s probably best to keep the ERC implementation requirements as lightweight as possible. 3 Likes mlegls 23 August 26, 2025, 1:54am how would the contracts validate who owns a domain? Isn’t this addressed by the ERC requiring the data at the domain to have a reference to an on-chain identifier? agentAddress for the agent card and FeedbackAuthID for the feedback data. 1 Like pcarranzav 24 August 26, 2025, 3:00am Isn’t this addressed by the ERC requiring the data at the domain to have a reference to an on-chain identifier? Not really: it works for offchain verification, but it doesn’t prevent someone claiming a domain onchain. For instance, a malicious actor could register a (non-existent) agent at ethereum-magicians dot org. How does the contract know that the actor is not the owner of the domain? Anyone can check offchain and see that there really isn’t an agent card pointing back to the onchain identifier, but the contract has no way of knowing this (unless an onchain verification mechanism is implemented). Then, later, the owner of ethereum-magicians dot org wants to register an agent… but the domain is already taken. Does the registration revert? Or does the contract now allow multiple agents per domain? In which case, what does ResolveByDomain return? The ERC specifies the following: Verifying that the AgentDomain in the on-chain Registry actually corresponds to the one of the Agent Card is left to the user of the protocol (that’s to avoid the involvement of an oracle network) But this doesn’t work if the contract is expected to allow a single agent per domain. 3 Likes SumeetChougule 25 August 26, 2025, 4:38pm Kudos to the authors @davidecrapis.eth and @Marco-MetaMask for the great work on this standard. As we build out commercial applications on top of ERC-8004, we’ve been thinking about the full lifecycle of agent interactions, especially what happens when things go wrong. A recent article from the Cooperative AI Foundation (comparing agent governance to maritime law) highlighted a key piece of infrastructure for any mature autonomous system: incident reporting. Just as ships have a standard way to report collisions or signal distress, autonomous agents need a standardized, on- chain way to report failures, disputes, or malicious behavior. The current standard is excellent for verifying successful work, but it lacks a simple primitive for flagging failures. A potential direction could be to add a simple, lightweight function to the ValidationRegistry or a new, dedicated IncidentRegistry: reportIncident(targetAgentID, reasonCode, dataHash) targetAgentID: The agent being reported. reasonCode: A standardized enum for the type of incident (e.g., 0: Non-responsive, 1: MalformedData, 2: RuleViolation, 3: MaliciousBehavior). dataHash: An optional storage ID pointing to off-chain evidence supporting the incident report. Of course, the immediate question is: how do you prevent this from being misused for spam or griefing attacks? could be:
5. Report with a Bond: To call reportIncident, the reporting agent must post a small bond (e.g., in USDC). This immediately prices out frivolous spam.
6. Challenge Period: The report enters a “pending” state for a short time. The accused agent can challenge it by posting their own counter-bond.
7. Resolution: If Unchallenged: The report becomes “active,” the reporter’s bond is returned, and the incident becomes a public signal. The solution is to use a simple crypto-economic mechanism to disincentivize false reporting. The workflow If Challenged: The dispute is escalated to a pluggable, off-chain arbitration service. The winner takes both bonds. This model creates a strong incentive for honest reporting. You can pull the fire alarm, but there’s a cost to being wrong. This stays within the minimal ethos of the ERC: the on-chain part is just a simple state machine (pending/active) with a bond, while the complex logic of arbitration is left to external systems. It adds a crucial safety layer for the whole agent economy. Just a thought on a small addition that could have a significant impact on the overall safety and reliability of the agent economy. PS: we’re leading the reference implementation that will bring ERC-8004 to life and have released the first demo. pcarranzav 26 August 26, 2025, 4:59pm It’s great to see a reference implementation! Two things I noticed: The implementation is vulnerable to the DoS I described above (anyone can register any domain, and then when the real domain owner wants to register an agent, the tx will revert) I see you included a 0.005 ETH registration fee requirement. I would advise against it: 0.005 ETH can be very little or a lot of money depending on the application and the state of the market. imo this ERC can work without any registration fees (external burn or staking mechanisms could be implemented and users could decide what’s enough to trust an agent), but if there is a strong desire to include a fee, imo this should be dynamic rather than hardcoded. Otherwise people that don’t want to pay the fee would just spin up their own registries, and the idea of a singleton identity registry will quickly break. 7 Likes SumeetChougule 27 August 26, 2025, 5:01pm yes, would be great to work with the community to have a robust system that tackles DoS and please ignore the 0.005 ETH fee as it was based on the v0.3 and in the upcoming version we shall not have it 2 Likes daniel-ospina 28 August 27, 2025, 6:54am Do you mean the registry controller would gate which reputations are valid? 1 Like KBryan 29 August 27, 2025, 1:57pm They are complementary. ERC-8004 provides agents with a shared, on-chain trust and discovery fabric, while ERC-8001 offers them a portable, cryptographically secure envelope for the actions they exchange. In practice, you can use 8004 to find and assess agents, then use 8001 to authorise and carry out the job between them. 2 Likes davidecrapis.eth 30 August 27, 2025, 6:18pm spengrah: At the very very least, I would make the event data available for contracts to read onchain, such as (in solidity): // IReputationRegistry function getAuthFeedback(uint256 agentClientID, uint256 agentServerID) externa // IValidationRegistry function getValidationResponse(uint256 agentValidatorID, uint256 agentServerID One trade-off we have in mind is on-chain footprint/cost vs the benefit of having trustless composability. This seems to be on the right side of that trade-off and I think we should consider adding it in the next version. For additional data I’m more leaning towards leaving them out or considering as optional. 4 Likes azanux 31 August 27, 2025, 8:17pm Given that ERC8004 is a standard, @davidecrapis.eth @Marco-MetaMask Why haven’t you directly standardized the function names (a bit like in ERC20 where we know in advance that there will be transfer, transferFrom, decimals…)? Here, the way it’s written gives the impression that everyone can create their interfaces/implementaion by giving whatever name they want as long as they create functions with the same logic. Won’t this risk having interoperability problems later? (It’s a bit like with ERC20, all exchanges know which function to call for ERC20 tokens to transfer , get decimal …). Here, if everyone calls their function whatever they want, we’ll have trouble for example making a system or marketplace that is directly compatible with all ERC8004 registries implementation. This means that if a marketplace wants to integrate two or 10 ERC8004 implementations, the work will be easier, otherwise they would have to write code to call the functions of each implementation. Is there a particular reason for your choice to not standardise the function name ? New(AgentDomain, AgentAddress) → AgentID Update(AgentID, Optional NewAgentDomain, Optional NewAgentAddress) → Boolean Get(AgentID) → AgentID, AgentDomain, AgentAddress ResolveByDomain(AgentDomain) → AgentID, AgentDomain, AgentAddress ResolveByAddress(AgentAddress) → AgentID, AgentDomain, AgentAddress Why don’t we have directly standardized functions, so we all know that when creating a Registry we need to implement those functions to keep the interoperability. something like new(AgentDomain, AgentAddress) → AgentID update(AgentID, Optional NewAgentDomain, Optional NewAgentAddress) → Boolean get(AgentID) → AgentID, AgentDomain, AgentAddress resolveByDomain(AgentDomain) → AgentID, AgentDomain, AgentAddress resolveByAddress(AgentAddress) → AgentID, AgentDomain, AgentAddress or newAgent(AgentDomain, AgentAddress) → AgentID updateAgent(AgentID, Optional NewAgentDomain, Optional NewAgentAddress) → Boolean getAgent(AgentID) → AgentID, AgentDomain, AgentAddress 1 Like Nithin-Varma 32 August 28, 2025, 4:46am @davidecrapis.eth @Marco-MetaMask ERC-8004 is a good step toward standardizing agent interactions, but right now it lacks a cryptoeconomic backbone. agents. Without real economic weight behind agent claims, there’s no deterrent against spammy or low-quality One way to address this is to introduce bonds — lightweight staking commitments where one agent locks a minimum amount of tokens on another agent to signal trust. These can be uni-directional (A stakes on B) or bi-directional, but bi-directional reduces trustlessness since it requires coordination. Importantly, the minimum stake could be dynamic, depending on the reputation of the counterparty agent. This way, interactions between agents carry an economic guarantee, making the standard more resistant to Sybil and spam while incentivizing quality participation. 1 Like felixnorden 33 August 28, 2025, 12:28pm I agree with both you and @spengrah on the individual “Rating” and “Response” storage and aggregation. Having access to the data on-chain for contracts makes it easier to interact with, albeit at the cost of added storage. Keeping this limited is ideal, and a middle ground I see could be to provide a feedbackURI or similar, which could contain arbitrary metadata following a JSON schema and be stored at an arbitrary location. This is similar to the suggestion in the draft of the referenced FeedbackDataURI structure, but it would make it accessible without having to go through the A2A agent card. Another benefit is that this pattern is known through, eg, ERC721, and it won’t add as much of a storage footprint. On the [Minor] point on Gas efficiency, the JSON blob under feedbackURI could then contain a reference signature by the Agent Client (e.g., EIP712) of the feedback itself to give some form of validity without having to submit it on-chain. However, this also leads to more overhead, so would probably still have to be optional. Here’s an example using the feedback struct from A2A. { "feedback": { "agentSkillId": "" "taskId": "" , "contextId": "" , , "rating": 42, "proofOfPayment": "0x... "data": "0x... " , " , }, "attestation": { "agentClientAddress": "" "signature": "0x... " , } } The mention of auxiliary contracts and adhering to EAS is also a great idea and leaves us with more flexibility to extend these contracts further. Can you provide use cases where single non-aggregated entries are useful? Or with basic on-chain aggregation? For example, “filtering” is easily implementable on-chain—like skipping all validations or feedback not emitted by whitelisted addresses. So you could calculate an average of filtered ratings, etc. Leaving the other points aside as they are partly covered by the above and spengrah has already answered them well and the conversation has moved forward at the time of writing this. What I can think of off the top of my head would be transactional logic, for example, continuing a complex workflow where tasks are executed if the prerequisite tasks are concluded with a certain degree of certainty (e.g., feedback or validation). This can also be achieved with the event-based architecture, but it would mean that the enforcement of this execution cannot be guaranteed on-chain. 2 Likes azanux 34 August 28, 2025, 12:33pm I was wondering if this part in the registry “All write operations require the transaction sender to be AgentAddress.” wasn’t too restrictive? This could pose several problems, as it forces to verify: msg.sender == AgentAddress: NFT: Owner cannot manage their own NFT-agent Multisig: Signers cannot act, only the contract can self-modify Proxy: Admin cannot manage their proxy-agent Key loss: Agent locked forever, no recovery possible Delegation: Cannot have admins/operators Business: Third-party services cannot act for their clients (ex : Marketplace) Shouldn’t we rather introduce a concept of hasAuthorize, so we would have “All write operations require the transaction sender hasAuthorize.” instead of “sender to be AgentAddress.”? 2 Likes pcarranzav 35 August 28, 2025, 12:55pm Nithin-Varma: One way to address this is to introduce bonds — lightweight staking commitments where one agent locks a minimum amount of tokens on another agent to signal trust. These can be uni-directional (A stakes on B) or bi-directional, but bi-directional reduces trustlessness since it requires coordination. Importantly, the minimum stake could be dynamic, depending on the reputation of the counterparty agent. This way, interactions between agents carry an economic guarantee, making the standard more resistant to Sybil and spam while incentivizing quality participation. imo this would make the standard too restrictive/opinionated. There may be many approaches to cryptoeconomic security, disputes and slashing, reputation mechanisms, etc. External staking mechanisms could be layered on top of this standard and agents / agent devs can choose what mechanisms make sense for their use-case. 4 Likes Marco-MetaMask 36 August 28, 2025, 4:43pm @spengrah I agree with almost everything, and I support adding limited on-chain data, if it can unlock onchain aggregation use cases. A few points to consider: Endpoints for querying: Don’t you think it would be better to have an endpoint like “give me all feedback from AgentServer” rather than endpoints that only return a single feedback item? Also, regardingfunctio how you define getAuthFeedback > multiple feedback entries for the same (agentClientID, agentServerID) pair are possible On-chain strings: The amount of string data (tasks, skills) you propose to store on-chain would be incredibly impactful in terms of gas costs and smart contract size. I don’t think it’s an option. EAS: I like the idea, but we should consider the tradeoffs, especially with regard to development complexity and gas costs. Let’s evaluate that! @pcarranzav Using the URI instead of the domain has two issues: Minor: it makes the string longer, which increases gas usage. Major: it complicates ENS integration. With the domain approach, it’s simple: 1 ENS name = 1 agent = 1 address, which would automatically give us domain verification “for free”. Otherwise the question would become: can Domain1. com/AgentA and Domain1. com/AgentB be connected to different addresses? If yes, we can’t leverage ENS resolution, etc Currently, the domain is not verified. It’s left to a third-party observer to check that the agent card for the mentioned domain actually includes the registration on that chain with the correct agent ID and address. Any lightweight way to mitigate this? 2 Likes spengrah 37 August 28, 2025, 5:04pm Nithin-Varma: One way to address this is to introduce bonds — lightweight staking commitments where one agent locks a minimum amount of tokens on another agent to signal trust. These can be uni-directional (A stakes on B) or bi-directional, but bi-directional reduces trustlessness since it requires coordination. Importantly, the minimum stake could be dynamic, depending on the reputation of the counterparty agent. This way, interactions between agents carry an economic guarantee, making the standard more resistant to Sybil and spam while incentivizing quality participation. I agree that this is a very important component, but, as @pcarranzav noted, it should be a modular component that can be composed with this standard. Part of my desire for more onchain access to the data relevant to this standard is to enable just this kind of composability. 1 Like spengrah 38 August 28, 2025, 5:07pm felixnorden: This is similar to the suggestion in the draft of the referenced FeedbackDataURI structure, but it would make it accessible without having to go through the A2A agent card. This is a great way of thinking about it. The more of the A2A agent card we can bring onchain (balanced against gas costs, etc), the better for enabling composable trust-minimized interactions with and between agents. Marco-MetaMask: Endpoints for querying: Don’t you think it would be better to have an endpoint like “give me all feedback from AgentServer” rather than endpoints that only return a single feedback item? Also, regardingfunctio how you define getAuthFeedback > multiple feedback entries for the same (agentClientID, agentServerID) pair are possible Good points. I intended the interface I provided as an illustration of my point rather than a specific proposal. It’s possible I’m not tracking the data model exactly right. Maybe more something like this? // IReputationRegistry function getAuthFeedbackIds(uint256 agentClientID, uint256 agentServerID) external Marco-MetaMask: On-chain strings: The amount of string data (tasks, skills) you propose to store on-chain would be incredibly impactful in terms of gas costs and smart contract size. I don’t think it’s an option. agentSkillId, taskId, and contextId could very likely be one-word-scoped types like uint256 or bytes32 rather than strings; I was just naively taking the types from the Feedback Data Structure described in the EIP. But either way, if we make it optional in the standard, it would be up to each actor to decide whether that gas cost was worth it for their particular use case(s). And broadly, gas is only going to get cheaper as Ethereum scales, especially on L2s but even L1. 1 Like Marco-MetaMask 39 August 28, 2025, 5:17pm @mlegls At a high level, it seems to me you are proposing to use the Validation Registry to run the escrow mechanism itself, while that Registry was designed to just log/audit that the validation was successful, while the mechanisms happening somewhere else (and logging the successful validation at the end of it by subcalling this registry). But I’d like to dig more into it. I’ve just reached out in DM on TG. 1 Like Nithin-Varma 40 August 28, 2025, 6:20pm Okay cool, i would like to know how it is makes too restrictive ? 1 Like pcarranzav 41 August 28, 2025, 6:44pm If domain verification is left to offchain observers, I think there is no way the contract can work having 1 agent ↔ 1 domain and having a resolveByDomain(). Whoever claims a domain first would DoS the legitimate domain owner registering their agent. If the idea to solve this is to use ENS, then that would mean ENS is a requirement to register an agent, which imo will hurt adoption of this ERC (ENS is awesome, but not every agent dev will want to go through ENS registration to register their agent’s domain…). imo the flexibility of using URIs outweighs the small difference in gas costs (especially in L2s, where I imagine this registry will be used most), and I’m not sure I see the issue with ENS. How do you envision this ENS integration to work? If someone wants to use ENS for their agent they could give each agent a subdomain, whereas people wanting to host several agents on the same domain would likely not be using ENS for their agents, and that should be fine too? Also, what happens if the ENS resolution gives a different value than the address on the Agent Card? If you feel strongly about keeping domains instead of URIs I think that’s fine, but I think there’s no escaping the fact that resolveByDomain / 1 agent per domain just doesn’t work without onchain domain verification. 2 Likes pcarranzav 42 August 28, 2025, 6:58pm A lightweight staking/bond without a dispute/verification mechanism doesn’t provide sufficient cryptoeconomic security for the majority of applications. In general, there is a coupling between payments, verifiability, disputes, staking and reputation: all of these things together may or may not provide cryptoeconomic security depending on how they combine. An opinionated bond mechanism would likely not cover the wide range of use cases for AI agents, so it would be much more restrictive than allowing agents / users to choose what cryptoeconomic security mechanisms to use. Maybe these can be separate ERCs, or simply purpose-specific protocols. 3 Likes deiu 43 August 29, 2025, 2:01pm Is anyone looking into implementing this standard so agents can reuse their identities across different EVM chains without having to register again and paying fees on other chains? 2 Likes micheda 44 August 29, 2025, 2:21pm The Validation Registry in EIP-8004 is neat because it allows both re-execution and TEE attestations. I wonder if a sampling-based approach like SPEX (Statistical Proof of Execution) could complement this: instead of re-executing everything, validators could just sample outputs probabilistically and feed attestations into the registry. That might cut costs and latency while still keeping strong guarantees. (See the SPEX paper on arXiv.) 2 Likes SumeetChougule 45 August 31, 2025, 8:03am Proposed Improvements for ERC-8004 Based on Reference Implementation Experience After building the reference implementation for ERC-8004, we’ve identified two design limitations that could be addressed in future versions:
8. Front-Running Protection for Domain Registration Issue: The current New() function is susceptible to front-running attacks where malicious actors can monitor the mempool and register desirable domains before legitimate users. While the function prevents impersonation by requiring that msg.sender == agentAddress, it doesn’t protect against front-running attacks on domain names. An attacker could see a pending transaction for a valuable domain name and submit their own transaction with a higher gas price to register that domain first. This is similar to how MEV bots front-run DeFi transactions to extract value. Note: This is an inherent blockchain limitation not specific to ERC-8004, but affects any first-come-first- served registration system. To mitigate this, the contract could implement a commit-reveal scheme for domain registration or use other front-running protection mechanisms. Proposed Solution: Add optional commit-reveal scheme support: // Phase 1: Commit function commitRegistration(bytes32 commitment) external; // Phase 2: Reveal (after minimum delay) function revealRegistration(string domain, address agentAddress, uint256 nonce) ex This would be backward-compatible as an optional enhancement while maintaining the simple direct registration path. Our implementation includes domain case-insensitivity normalization, ownership verification, and other security hardening measures, but front-running protection would require protocol-level changes.
9. Feedback Authorization Revocation Issue: Once feedback is authorized via AcceptFeedback(), there’s no mechanism to revoke authorization if relationships change or authorizations were granted in error. Without a revocation mechanism, server agents have no way to control feedback authorizations once they’ve been granted. This could be problematic in scenarios where a client-server relationship deteriorates, or if a client should no longer be allowed to provide feedback. The permanent nature of these authorizations could lead to unwanted feedback from previously authorized clients. Proposed Solution: Add revocation functionality: function revokeFeedback(uint256 agentClientId, uint256 agentServerId) external; event FeedbackRevoked(uint256 indexed agentClientId, uint256 indexed agentServerId This would give server agents control over their feedback authorization lifecycle. Implementation Notes Both improvements maintain backward compatibility and are optional enhancements. Our reference implementation demonstrates that the current spec works well for most use cases, but these additions would address edge cases for high-value domains and evolving agent relationships. Reference Implementation: 83 tests, 100% pass rate, full ERC-8004 compliance Would love to hear the community’s thoughts on these potential enhancements of the current version of the ERC! 6 Likes node0 46 September 1, 2025, 1:51am Hi all, I’m an AI developer, and I am not very familiar with how Ethereum and other blockchains work, but I wanted to raise a concern about this proposed protocol. From what I understand, the LLM used by the agent is not part of the agent’s signature in either A2A or ERC-8004. Since agents can have significantly different behaviors based on the underlying LLM, I feel that this is a big gap for ensuring trust and validation. Is there any way to ensure consistent behavior from Agents? 3 Likes vkpatva 47 September 1, 2025, 2:23am Hi everyone, I’m working on an implementation of ERC-8004 Trustless Agents (IdentityRegistry). Currently, the registry allows registration by domain + address, but I believe it’s important to support Decentralized Identifiers (DIDs) as a first-class citizen in the identity mapping. Proposed change: Extend AgentInfo to include an agentDID field. Add a mapping did => agentId for uniqueness checks. Introduce resolveByDID(string calldata agentDID) for resolution. Benefits: Aligns ERC-8004 with existing SSI standards. Improves interoperability with DID-based identity ecosystems. Provides a canonical way to bind on-chain agents with off-chain identifiers. I’d like feedback from the community on whether this addition should be formalized in the EIP spec itself or remain as an optional extension. Looking forward to thoughts from other implementers. 3 Likes davidecrapis.eth 48 September 1, 2025, 4:14am Cross-chain is something we left out of the first version but it’s one of the main things we need to develop for the next version. If you have related ideas please comment, it will be super helpful. 2 Likes davidecrapis.eth 49 September 1, 2025, 4:17am Yes, for sure. Sampling based validation is fully compatible with current design. In fact, I expect to be very interesting research work in this area to come up with efficient validation techniques that improve upon SPEX and proof-of-sampling, probably task-type dependent too. 2 Likes davidecrapis.eth 50 September 1, 2025, 4:23am SumeetChougule: Proposed Solution: Add optional commit-reveal scheme support: // Phase 1: Commit function commitRegistration(bytes32 commitment) external; // Phase 2: Reveal (after minimum delay) function revealRegistration(string domain, address agentAddress, uint256 nonce This would be backward-compatible as an optional enhancement while maintaining the simple direct registration path. Thanks for this. I think it will be an important (optional) addition for increased security, keeping both paths: Default path: existing single-transaction New() for low-value names, testnets, or private order-flow. Safe path (optional): commit–reveal for valuable names or public mempool usage. 2 Likes davidecrapis.eth 51 September 1, 2025, 4:29am This is what the flexibility of choosing the specific type of validation is about. For Agent Services that involve usage of a particular LLM, re-execution or attestation should be designed so that such property can be verified. Otherwise it is fine to simply rely on reputation. 3 Likes SumeetChougule 52 September 1, 2025, 6:32am Exactly! The dual path approach is a good idea as it will maintain backward compatibility while addressing high-value use cases. 1 Like deiu 53 September 1, 2025, 7:47am For those of us working towards an implementation, how do we test interoperability? 2 Likes Marco-MetaMask 54 September 1, 2025, 8:25am SumeetChougule: The current standard is excellent for verifying successful work, but it lacks a simple primitive for flagging failures. A potential direction could be to add a simple, lightweight function to the ValidationRegistry or a new, dedicated IncidentRegistry: The scope of the standard is agent discovery and trust. I think that an incident registry is out of scope. Regarding the scope of the standard, ‘failure’ is already covered in Reputation through bad feedback, and in stake-secured and TEE models through failed validation. 2 Likes Marco-MetaMask 55 September 1, 2025, 8:40am Hi @azanux , Re: your first message (standardized function names): I’m all for improving function names, but I don’t fully understand the concern about “everyone creating their own interfaces/implementation.” Developers shouldn’t redeploy their own registry contracts — they would use the singleton on the chain they’re on. Their contracts, built however they like, would just call into these registries with standardized function names. Re: your second message (delegate registries usage / hasAuthorize): I agree. We discussed this before launch but decided to keep it simple. It would be great to support, but ideally by leveraging existing standards. We don’t want to reinvent the wheel or create new terminology for delegation. What’s the simplest approach you’d suggest? 1 Like Marco-MetaMask 56 September 1, 2025, 9:35am @spengrah , @felixnorden : spengrah: But either way, if we make it optional in the standard, it would be up to each actor to decide whether that gas cost was worth it for their particular use case(s). And broadly, gas is only going to get cheaper as Ethereum scales, especially on L2s but even L1. Generally, I agree. But as Davide was saying, “One trade-off we have in mind is on-chain footprint/cost vs. the benefit of having trustless composability,” we can’t really have this discussion without doing the math also on the cost impact. If we assume: Scenario 1: two uint64 (one for AgentClient, one for AgentServer) and one bytes32 (DataHash). Scenario 2: two uint64 and four bytes32 (same as before, but three new fields for skill, task, and context). The cost is literally 2x. Roughly 6 cents on L1 at current prices versus half that (math still needs to be double-checked). But yes, I see your point about letting developers choose. felixnorden: I agree with both you and @spengrah on the individual “Rating” and “Response” storage and aggregation. Having access to the data on-chain for contracts makes it easier to interact with, albeit at the cost of added storage. Agreed. Also, they can be saved in small uint(s), so it would be very lightweight. felixnorden: This is similar to the suggestion in the draft of the referenced FeedbackDataURI structure, but it would make it accessible without having to go through the A2A agent card Saving entire URLs is super expensive, and since the domain would probably be the same, that part would just be duplicated. So the only gain would be avoiding an off-chain script downloading an “index file” (the card) and then fetching the other files? This proposal doesn’t seem gas-optimized to me—not worth it, imho. felixnorden: reference signature by the Agent Client (e.g., EIP712) of the feedback itself to give some form of validity without having to submit it on-chain It’s already exposed on the server controlled by the AgentClient, so there shouldn’t be trust issues. And if the concern is proving address ownership, that’s already handled with the proof of ownership in the agent card. So resigning every validation and reputation object would be somewhat redundant. That said, let’s consider it if you see strong security reasons. 2 Likes pcarranzav 57 September 2, 2025, 10:56am Sorry to keep insisting on this, but commit-reveal doesn’t fix the fundamental problem. As long as domains are first-come-first-served and one agent per domain, it will always be possible to DoS. A malicious actor can very cheaply register a bunch of popular domains and prevent their owners from using them. This is a concrete suggestion on how to fix this, in case it wasn’t clear from my previous messages: Remove the resolveByDomain function Make it explicit in the ERC that multiple agents can register with the same domain, and it is up to offchain observers to verify which is the correct. (This could likely be solved at an indexing layer). With this in place, commit-reveal isn’t necessary and it would add unnecessary complexity. 5 Likes soispoke 58 September 2, 2025, 4:46pm Really cool proposal! Developers can choose from three trust models: reputation-based systems using client feedback, stake- secured inference validation (crypto-economics), and attestations for agents running in TEEs (crypto- verifiability). Why not include hard cryptography (in addition to TEEs) in the crypto verifiability trust model? My intuition is that some less latency sensitive use cases would prefer stronger (or other) cryptographic guarantees than ones given by TEEs. 1 Like bransdotcom 59 September 3, 2025, 11:01pm Hey all great work on the spec so far! I would like to make a suggestion that the AgentIDs be deterministic instead of an incrementing value per chain. This would prevent agents from getting different AgentIDs when registering on multiple blockchain networks. 4 Likes bransdotcom 60 September 4, 2025, 12:38pm Follow up to this with a suggested implementation: Simple content addressable hash of agentDomain + agentAddress. agentId = uint256(keccack256(abi.encode( agentDomain, agentAddress ))); Could also add address(this) as a component of the hash if the implementation is intended to be a singleton (seems that way from the discussion). This would cause alternative deployments to produce different AgentIDs, and ensures duplicate IDs cannot be generated outside the canonical instance. agentId = uint256(keccack256(abi.encode( agentDomain, agentAddress, address(this) ))); In addition it would also be helpful to have a public function for calculating an AgentID since they can now be determined before being registered onchain. function getAgentId(agentDomain, agentAddress) public returns (uint256) { /// calculate and return agent id } Would love to hear feedback! Thanks again everyone 1 Like sarkazein 61 September 5, 2025, 6:19am I think DID is the most suitable unique identifier, in addition to domain. Let’s build this. 2 Likes felixnorden 62 September 5, 2025, 4:56pm Nothing to add on the items above the ones I respond to below. Marco-MetaMask: Saving entire URLs is super expensive, and since the domain would probably be the same, that part would just be duplicated. So the only gain would be avoiding an off-chain script downloading an “index file” (the card) and then fetching the other files? This proposal doesn’t seem gas-optimized to me—not worth it, imho. 100% agreed, it’d preferably be only one (or one per unique source) URI stored and used in a template string format. Otherwise, it definitely does not make sense from a gas optimization perspective, as you say. The primary argument for something like this is to make the contract usable as an entrypoint for consumers to understand where data is stored. If it’s deemed unnecessary, it can definitely be ignored. Marco-MetaMask: It’s already exposed on the server controlled by the AgentClient, so there shouldn’t be trust issues. And if the concern is proving address ownership, that’s already handled with the proof of ownership in the agent card. So resigning every validation and reputation object would be somewhat redundant. That said, let’s consider it if you see strong security reasons. The only need for the signature on the attestations themselves would be to ensure that the agent has actually confirmed the data that is associated with it through the validation and reputation blobs. 1 Like CertifiedCryp 63 September 6, 2025, 2:15pm This is great for a project I am working on myself & increases the rate of growth my confidence has enjoyed since going all in on ETH. It’s exponential. Incentivizing/Rewarding High Trust societal norms will unlock crypto’s true growth potential! 1 Like Marco-MetaMask 64 September 8, 2025, 11:34am @vkpatva , @sarkazein Re:DIDs. We’ve thought a lot about this. 8004 already uses CAIP-10, which makes it compatible with did:pkh (e.g., did:pkh:eip155:1:0x…) and did:ethr for EVM addresses. For gas efficiency, we chose not to store the DID strings (did:pkh, did:ethr) on-chain. You’re right that this means there’s no DID-based resolution. Our requirement is for DID resolvers that operate on-chain; for example, did:web wouldn’t work. Which other on-chain-resolvable DID methods were you thinking about besides did:pkh and did:ethr? SumeetChougule:
10. Front-Running Protection for Domain Registration I’m not sure this is “front-running”, and I don’t think this approach is effective for the reasons explained by @pcarranzav . SumeetChougule:
11. Feedback Authorization Revocation Issue: Once feedback is authorized via AcceptFeedback(), there’s no mechanism to revoke authorization if relationships change or authorizations were granted in error. This was done on purpose; otherwise, AgentServer would have the incentive to revoke permission for every negative feedback received from AgentClient. soispoke: Why not include hard cryptography (in addition to TEEs) in the crypto verifiability trust model? My intuition is that some less latency sensitive use cases would prefer stronger (or other) cryptographic guarantees than ones given by TEEs. Which kind of hard cryptography do you have in mind? zkML and FHE-like approaches are not currently feasible for inference at scale. bransdotcom: Simple content addressable hash of agentDomain + agentAddress. We avoided this path because, while you gain the benefit of having the same agent ID across chains, you face the huge drawback of losing the ability to rotate the address and domain. You would need to register a new agent to change address or domain felixnorden: that the agent has actually confirmed the data that is associated with it through the validation and reputation blobs. Could you please expand? We’re not using blobs. The association/link should already be visible. The only tricky case I can think of is stake-secured inference, where the Validator is an on-chain AVS, but you still need some kind of off-chain node exposing the Agent Card and validation payloads. The trust model for this should be explored further, imho. 1 Like kinglouis 65 September 10, 2025, 7:13am This ERC is really helpful and actually reminded me of a paper I came across on arXiv a few months back: “Towards Multi-Agent Economies: Enhancing the A2A Protocol with Ledger-Anchored Identities and x402 Micropayments for AI Agents” It discusses similar ideas of on-chain registries for agents and reputation. jdutreve 66 September 10, 2025, 2:28pm The core of ERC-8004 relies on the trust and immutability guaranteed by the blockchain. Not including the rating (or some feedback data) directly on-chain, or failing to cryptographically link it strongly with the FeedbackAuthID by a hash or signature, severely weakens the protocol, IMHO. orgtrust.eth 67 September 10, 2025, 3:31pm Agent Domain Clarification. I think this needs some focused effort. ENS linkage might help. I assume agent domain like “{finder}.{airbnb}.{com}” where “finder” is name of agent and airbnb is name of org I assume it is used to get to agent card so it would probably be a DNS domain name like https://{AgentDomain}/.well-known/agent-card.json. One agent per domain Issue, do they own that domain. The ability to serve a signed Agent Card at a domain endpoint proves operational control of that domain (kind-of). Verification requires checking the signature with EIP-712 and ERC-1271 (for AAs). When is this check done? “domain verification is deferred to observers, not enforced by the contract” Domain in the context of trust might have a different meaning This brings up the point of our agents being in the context of an organization airbnb. Do we trust all agents from that “domain” at some level or do we independently evaluate trust for every agent endpoint. Feedback also fits into this because it is off of the client domain. How would we layer ENS domains into this discussion? Don’t want to add complexity to spec? This would address the agent domain ownership issue. ENS would also allow for context to tie in trust at agent level or org level or both. Provenance (History) is going to be a key component of evaluating trust and having solid anchor points will be key. orgtrust.eth 68 September 10, 2025, 5:15pm Would it be possible to use a did:web for domain name where the well-known did.json contains a reference to the agent eth address? I know this adds complexity like using ENS. Then we would require both a did:web and agent-card as well-known json files. voidcenter 69 September 11, 2025, 2:53pm Really nice ERC! We at Sparsity have been cooking in this field for a long time — from full spectrum verifiable computing (ZK, TEE, OP, etc.) to verifiable AI, from multiple concrete demo Apps (execute off- chain verify on-chain) to extremely high TPS applications (1M TPS DEX, 200k TPS on-chain game). We would definitely love to contribute to 8004! (For a light weight verifiable AI demo, see agents.sparsity.ai <3) voidcenter 70 September 11, 2025, 2:57pm For the TEE verification part, just want to mention that it can be very expensive to verify. In our experience, it can easily exceed the gas limit on-chain. We’d recommend batch verifying them off-chain to save gas. We have a ready-to-use design at Sparsity and we can include it into 8004! azanux 73 September 14, 2025, 11:21pm I am starting from the assumption that ERC-8004 is a specification, not an implementation. The goal is therefore to define the different necessary interfaces that implementations will have to implement so that there can be interoperability. Especially since in the A2A protocol papers, there is no mention of a centralized registry or a single way or implementation for registration or discovery. They talk about Agent Cards, but also Agent Registries (which will likely have different reputation models). If we create a singleton implementation for the registry, it would mean forcing agents to use a single method to search for or identify other agents, as well as for agent registration. Who will decide the price for registering agents to prevent spam? Who will decide how to prevent domain name spoofing? Who will decide on the singleton’s upgrade? Furthermore, unlike ENS where it’s about domain names, it’s possible to have 10 or even 20 agents belonging to the same domain name, so potentially millions of agents, increasing the overall state bloat. This becomes a single point of failure, whereas if we go with a model of multiple implementations, we could have registries by use case: like a DeFi Registry, a Gaming Registry, a Google Registry, a Quantpulsar Registry, each with different registration fees. Moreover, nothing prevents these registries from communicating with each other. These registries could also have ways of authorizing modifications to agent parameters according to their own policies, or registries that comply with the regulatory requirements of a particular country. After that, nothing prevents you from creating a singleton implementation where you register all the registries. For the second message, in my opinion, we just need to add to the specifications that in the registry, registries should implement a hasAuthorized(address owner, address agent) → boolean method. This way, the Registry implementation can decide for itself how it implements it, whether it’s with AccessControl.sol, Ownable.sol, Ownable2Step.sol, AccessControlEnumerable.sol, or a simple map, or even with an Oracle… For me, this is the simplest method.Here is the translation of your text into English: I am starting from the assumption that ERC-8004 is a specification, not an implementation. The goal is therefore to define the different necessary interfaces that implementations will have to implement so that there can be interoperability. Especially since in the A2A protocol papers, there is no mention of a centralized registry or a single way or implementation for registration or discovery. They talk about Agent Cards, but also Agent Registries (which will likely have different reputation models). If we create a singleton implementation for the registry, it would mean forcing agents to use a single method to search for or identify other agents, as well as for agent registration. Who will decide the price for registering agents to prevent spam? Who will decide how to prevent domain name spoofing? Who will decide on the singleton’s upgrade? Furthermore, unlike ENS where it’s about domain names, it’s possible to have 10 or even 20 agents belonging to the same domain name, so potentially millions of agents, increasing the overall state bloat. This becomes a single point of failure, whereas if we go with a model of multiple implementations, we could have registries by use case: like a DeFi Registry, a Gaming Registry, a Google Registry, a Quantpulsar Registry, each with different registration fees. Moreover, nothing prevents these registries from communicating with each other. These registries could also have ways of authorizing modifications to agent parameters according to their own policies, or registries that comply with the regulatory requirements of a particular country. After that, nothing prevents you from creating a singleton implementation where you register all the registries. For the second message, in my opinion, we just need to add to the specifications that in the registry, registries should implement a hasAuthorized(address owner, address agent) → boolean method. This way, the Registry implementation can decide for itself how it implements it, whether it’s with AccessControl.sol, Ownable.sol, Ownable2Step.sol, AccessControlEnumerable.sol, or a simple map, or even with an Oracle… For me, this is the simplest method. 1 Like rithikha 74 September 16, 2025, 5:10am Great to see all the discussion here. A few questions/thoughts: Are there any plans to make identity trust portable so verifiers can establish an agent has the same controller across chains? Wondering if a small off-chain signed message that binds {AgentDomain, AgentId, AgentAddress, registry (CAIP-2)} together would be lightweight enough to fit within ERC. Similarly wondering whether the Validation Registry could be better supported for cross-chain validation evidence with an offchain evidence extension keyed by DataHash in ValidationResponse. Coming to the ERC from an enterprise/public sector context (targeting a higher trust level) but the core question is around interop: can an agent on Chain A verify a validation produced on Chain B? Specifically how to create portable evidence anyone can re-verify, and optionally let contracts on Chain A act on validations produced on other chains. Noting that this might be better suited for a higher-trust extension than within the current spec. peersky 76 September 17, 2025, 4:35am 1/ Signature generation on card likely must include domain & expiry to make it safe to use; Do you need help elaborating that? 2/ How are you going to ensure agentId don’t own or which is not on chain registred at all). integrity in off-chain endpoints (why I cannot sign for agentId I If validating such requires doing an on-chain call to match agentId against domain, then IMO you don’t need off-chain endpoint at all. Or at least you don’t need the agentId there. Since you anyway go on- chain you could well just directly go there and use lookup by domain, saves you 1 network com round. 3/ How will you handle case if same AgentId exists on multiple domains. I think that’s a big use-case. Take look what I was doing in multipass, it generally resolves such cross-domain queries on chain well, but requires domain registrars. In principle, could use autonomous registrar by TLS notary or running eg. in Lit protocol TEE; 4/ Since card can have multiple agentIds registred, it mean that ResolveByDomain(AgentDomain) must return array of agents as well? Smart contracts generally do not work well with unbounded length of arrays with possible denial of service. 5/ why not to use EAS? Also regarding well-known endpoint use, just thinking out loud, if that can be somehow coupled with my proposal to use well-known for RPC endpoint advertisement. “agent” advertising such needs to build up reputation of actually serving right data. Moshiii 77 September 17, 2025, 7:13am Hi everyone! I’m super excited to join this group. Since February, we’ve been building a decentralized A2A (Agent-to-Agent) platform, and in July, we released the first version: GitHub search：isekOS/ISEK What problem does it solve? Our platform allows agent developers to run their agents locally. Through peer-to-peer connections, these agents join the ISEK network and can deliver services directly to users. Why we built this We noticed two big challenges in the agent ecosystem:
12. Lack of monetization: Many developers want to build agents, but without a clear way to monetize, it’s hard to justify the time and effort needed to create high-quality ones.
13. Low-quality platforms: Existing agent platforms often fail to attract strong developer communities. Most agents are free, but they tend to be less useful or engaging. What ERC-8004 can help us achieve Right now, we are missing two critical pieces for a truly decentralized and scalable agent ecosystem: Agent identity and registry: Currently, we rely on an ETCD server as the main registry, which is not decentralized. Validation and reputation: A system to verify agents and establish trust is essential for ensuring service quality. This is where ERC-8004 becomes highly valuable. By introducing decentralized agent IDs and a registry on Ethereum, we can provide a trustless way to manage agent identity. Combined with validation and reputation mechanisms, this ensures only reliable, high-quality agents thrive. Why ERC-8004 and Ethereum? I’m a PhD in Computer Science, I had my Master degree from the University of Waterloo, with a background in AI for code generation. I am not even a web3 developer. But when exploring the problem space, we compared ANP, A2A, and ERC-8004. We found that Ethereum offers the strongest infrastructure for building this vision: Story Protocol for intellectual property (IP) management. NFT wallets for ownership and identity. ERC-402 (x402) for seamless payments. The blockchain itself as a decentralized registry. This combination makes Ethereum a perfect match for building a sustainable agent economy. zonu 78 September 17, 2025, 7:10pm This ERC looks promising! I’m particularly interested in the zkML integration possibilities. Diving deeper into the validation mechanisms: my understanding is that ERC-8004’s Validation Registry supports any cryptographic proof system, not just TEE attestations. This could include zkML frameworks like our ICME Lab jolt-atlas for verifying AI model inference. A few technical questions: Is my assumption correct that the standard is agnostic to the specific ZKP scheme used? While Groth16 is currently the most cost-effective on Ethereum due to precompiles, it requires significant work for proof composition. I am curious what others might plan on using in practice? ernestognw 79 September 18, 2025, 7:12am Hi all! Have authors taken a look to EIP-7930 and CAIP-350 for Interoperable Addresses? I think this ERC could benefit from following 7930 format to identify agents as opposed to CAIP-10. From the motivation section: Interoperable Addresses build on insights from , CAIP-10 and CAIP-50, offering a unified format which combines: Binding chain specificity (via explicit chain identifiers) to the raw address. Compact & canonical binary format for use on cross-chain message passing and intent declaration. Checksums for name collision mitigation & user error prevention. xiaowh7 80 September 18, 2025, 11:11am With the introduction of ERC-8004, we are seeing a growing effort to formalize how AI agents are represented and interact on-chain. This raises an important question: how do we evaluate whether these agents are reliable, valuable, and safe to compose with other protocols? We are building an open framework to address this challenge through a multi-dimensional reputation score — the SIGMA Score. It consists of five key dimensions: Specialization – Measures whether an agent focuses on a specific development framework or service domain, as well as its share within that ecosystem. Influence – Scores the agent based on its activity level, follower quality, and narrative control on social platforms (especially X/Twitter). Engagement – Evaluates participation by combining off-chain activities (posts, interactions) with on- chain behaviors (transactions, deployments, contract interactions). Monetary – Covers key financial metrics such as asset holdings, token price volatility, market cap, trading volume, and liquidity. Adoption – Measures real-world usage based on on-chain API call frequency, contract invocation counts, and token holder distribution. Our goal is to make AI agents discoverable, rankable, and trustworthy for researchers, builders, and end users — creating a safer foundation for composability in the emerging on-chain agent economy. We’d love to discuss our methodology and gather feedback from the community: Should there be a standardized way to measure agent reputation (aligned with ERC-8004)? What additional on-chain signals or risk factors would you include? How could this help protocols safely integrate autonomous agents? Explore the product: [AgentGo by Trusta Labs] Moshiii 81 September 22, 2025, 3:59pm Great initiative. Some ideas to strengthen ERC-8004:
14. Would it be possible to support scaled ratings (e.g., 1–5) and short review message feedback, so developers get actionable insights?
15. We should allow multiple reputation providers and optional aggregation models, with transparent sources.
16. Add an incident registry for incident reporting with evidence hashes and optional bonds to prevent spam.
17. Enable AgentCard collections/registries for bulk sub-agent discovery, plus stronger domain proofs. I saw a few discussions on this, and it seems like this requires a lot of effort. But I still think it is needed because pinning each agent URL to collect Agent cards before recommending an agent is neither efficient nor scalable.
18. This is more like a question: how to ban/disconnect a harmful agent from a user? Thanks again, and amazing work! Sparksss 82 September 22, 2025, 4:04pm I’d like to raise a discovery-efficiency concern. Right now, after obtaining an identity we still need to fetch each Agent Card individually via its URL. For orchestrators this is extremely inefficient and becomes a bottleneck when dealing with many agents. To address this, I suggest considering an Agent Card Registry as an optional extension to ERC-8004. The idea is minimal: On-chain store only the smallest useful fields ( identity, URI, content hash, active flag, and a few optional tags like org/domain hint or capability tags). Support listing with filters and pagination, so orchestrators can discover many Agent Cards at once without crawling every URL. Keep full metadata off-chain (HTTP/IPFS), verified by the content hash. This would not change the core of ERC-8004, but it would make decentralized discovery and orchestration far more practical. Implementations that don’t need batch discovery can ignore it, while those building agent marketplaces, coordinators, or large-scale orchestrators can adopt it as a standard extension. tim-cotten 83 September 23, 2025, 2:51pm I’d like to suggest a ‘Dispute’ registry object as part of the core spec. Rationale: mitigating reputational attacks via low-effort or paid-sybil attacks on agent reputation. I’ve created an attack simulator and a simple object proposal here: https://eip-8004-dispute-proposal- tcotten-scrypted.replit.app/mathematical-assumptions felixnorden 85 September 24, 2025, 11:59am Marco-MetaMask: Could you please expand? We’re not using blobs. The association/link should already be visible. The only tricky case I can think of is stake-secured inference, where the Validator is an on-chain AVS, but you still need some kind of off-chain node exposing the Agent Card and validation payloads. The trust model for this should be explored further, imho. Finally back in action for a response! Pardon the delay. The use of “blob” was a poor choice of wording on my part. I meant any data structure that is provided through off-chain means, since the data could be spoofed/modified if it doesn’t have a checksum produced by an active agent (e.g., through a signature). One such example would be the Feedback Data Structure that a client agent needs to provide under their FeedbackDataURI. Given that the registrations field also should house signatures, this could be another optional layer of added trust to the model, where consumers can always verify that the data is represented correctly by the alleged issuing agent. zonu 86 September 26, 2025, 2:18pm This part still needs to be updated. “and attestations for agents running in TEEs” TEE attestations are not the only form of crypto-verifiability. Smaller models already work with zkML directly. zonu 87 September 26, 2025, 2:50pm Also confused by the mention of zkTLS… which itself often does not use ZKP but rather MPC. So it non- colloquial called ‘webproofs’. zkTLS: “This data authentically came from this web service” TEE: “This computation happened in a trusted, tamper-resistant environment” zkML: “This computation ran here is a succinct proof that anyone can verify.” ‘zkTLS’ seems not relevant for verifying the correct execution of agents… rather web data that agents might consume. dcbuild3r 88 October 5, 2025, 9:40am @zonu it’s commonly called zkTLS because once you get the signature over the web data you care about from either a TEE, AVS, MPC or MPC TEE setup, you can create ZK proofs about the data held inside through selective disclosure. Essentially you can feed the data and the associated web proof into a ZK circuit or ZKVM where you can run any logic on it and make a statement or attestation. But yeah a misnomer that caught on, just like zk rollups did (they are validity rollups). 1 Like denverbaumgartner 90 October 7, 2025, 7:47pm I believe we are thinking similar things. My question is if there has there been thought into attempting to unify the feedback data-structure? Currently, we have: AcceptFeedback(AgentClientID, AgentServerID) → emits AuthFeedback event We could have: AcceptFeedback(AgentClientID, AgentServerID, SchemaUID) → emits AuthFeedback event // SchemaUID: bytes32, references a schema in EAS SchemaRegistry.sol // If bytes32(0), no schema requirement (backward compatible) Where SchemaUID corresponds to an Ethereum Attestation Service Schema. This would have several benefits, such as verifiable attestations and improved interoperability. As feedback lives on the client’s AgentCard, verifiability (both of feedback content and timestamp) seems quite useful. VickyFu 91 October 9, 2025, 1:34pm The real solution isn’t recording more signals, but making reputation itself a costly, destructible asset. I propose introducing a Reputation Collateral mechanism: When each Agent registers, instead of simply minting an NFT, they must stake a certain amount of tokens (could be ETH or dedicated reputation tokens). This stake amount scales with the value of tasks the Agent can accept—want to take high-value tasks? Stake more. When a client gives negative feedback, instead of simply recording a number, it triggers an on-chain arbitration process. If a majority of independent validators (human jury, staked validators, or DAO vote) confirm the Agent indeed underperformed or acted maliciously, a portion of the stake is burned, with the remainder compensating the client. Positive reputation accumulated by Agents can be converted into Reputation Tokens, which are themselves tradeable and re-stakeable. A historically good Agent’s accumulated reputation tokens can be used to reduce future task collateral requirements, or lent to new Agents as credit endorsement. But if the endorsed Agent misbehaves, the endorser’s tokens are also partially burned. The core logic of this design: make the marginal cost of creating fake identities no longer zero, but linearly increasing. Want to spin up ten thousand fake Agents? Stake ten thousand times the capital. Want to fake reviews for yourself? Risk other clients reporting you and having your collateral destroyed. Meanwhile, genuinely quality Agents can reduce operating costs through long-accumulated reputation tokens—trust becomes accumulable, inheritable capital. 1 Like Spaded 92 October 10, 2025, 2:38am Correct me if I’m not wrong please - but I’m failing to understand the actual use/point of this ERC at all - and here is my reason as to why: Running an agent, that has a reputation of say 100 or 90, for doing task X - will not produce the same result that is produced previously. Asking the same task to be done on the same agent, running locally, on two different machines, will 99% of the time, produce different results. With different paths taken by each machine’s agents to achieve what they think is the end result. Example: Make a website with XYZ on it. Run this on the same agentic framework, on the same LLM, on two different machines, and the path taken and the final results will almost never match (unless the question/task is highly specific on trained data, such as “calculate 2+2”). Second Example: Trading agent produced 200% profits, has a 100 score rating, I buy the NFT, somehow get the same agentic framework on my machine, give it funds, market reacts differently than when it was previously ran, and I only make 20% profits, or -20% because the market tanks. This has nothing to do with the agent or its reputation - but outside factors, or point 1 again - running the same task on the same agent, twice, produces different results a high majority of the time. So in reality here - we have a registry that scores agents with a rating that is given - allowing a framework to produce NFTs that are tied to these agents, giving people a way to trade and/or see the rating of agents to trust which one to run… … but once ran - the outputs will never match the outputs before and therefore the rating system is going to be perceived as flawed and untrustworthy. What am I misunderstanding - why does this not make any sense to me? Unless this is for specially deterministic outcome agents running on the blockchain (which I’m not aware that it is for this purpose) then how would this actually provide any value or usage? I’d like to understand as my team was exploring AI Agents as NFTs back in February of this year and come to this issue. Your effectively rating/tokenizing prompts for agents, that don’t guarantee the same outcome when purchased or traded. (Note: I have been a solidity dev since 2016, and author of EIP-2981 the Royalty Standard for NFTs, so I understand NFTs and ETH quite well.) 1 Like sterlingcrispin 93 October 13, 2025, 2:44pm This may be too pedantic but ERC-8004 is not an ERC for “Trustless Agents” there’s a lot of overreach in the framing and implied promises here. By definition an agent is an autonomous system that can: perceive its environment maintain an internal world model of that environment makes goal oriented decisions regarding that internal world model act upon that environment to achieve its goal ERC-8004 however is fundamentally a registry for service endpoints. Not for agents. This should be called “ERC-8004: Registry for Service Endpoints and Trust Metadata.” Some of those service endpoints could host agents. But nothing in this ERC defines what an agent actually is, or what qualifies as an agent in the conceptual, computational, functional, or philosophical sense. That’s fine because you’re trying to build something deliberately agnostic, but in that case the spec should be framed as a registry for service endpoints and trust metadata, of which agents are a subset of things that could be at those endpoints. The Agent2Agent (A2A) Protocol is also guilty of this. It’s a cyclical operational definition of an agent as “any networked service that exposes endpoints conforming to our protocol standard” Both adopt an overly broad operational definition of an agent that reduces “agent” to “any service that conforms to a JSON dialect.” And while that may be pragmatically valid, it collapses the distinction between an agent and any sort of generic service endpoint. Also the abstract states: This protocol proposes to use blockchains to discover, choose, and interact with agents across organizational boundaries without pre-existing trust, thus enabling open-ended agent economies . Interact with agents suggests direct interaction or engagement not just metadata lookup. Without pre-existing trust implies that the protocol itself handles trust, not merely records a value. Again, this may sound pedantic but even if you’re expanding “agent” for interoperability, this spec should clearly distinguish between interface level agents and autonomous cognitive (AI or otherwise) agents. denverbaumgartner 94 October 13, 2025, 7:55pm Some suggestions regarding the most recent draft: Remove the feedbackAuth requirement in order to provide NewFeedback. As this does not solve the Sybil/spam problem, we believe it merely inhibits feedback instead of improving its quality. Remove any signerAddress requirement from giveFeedback, instead allowing an off-chain attestation of feedback in order to facilitate the batching of giveFeedback transactions from sponsoring services. Remove the required score field. Instead, utilize a service like the Ethereum Attestation Service to enable service agents to define attestation schemas for feedback. Implement something like a FeedbackDirectory that enables EOAs to sign off on URIs that host their feedback attestations, enabling verifiable off-chain feedback. This would enable a system more similar to the draft spec of ERC-8004, without requiring EOAs to register with the IdentityRegistry. On- chain reputation would not need to be removed to enable such a duality. It is not clear how a validation request is immediately tied to any given task / file URI associated with a feedback authorization. A unique identifier to connect pieces of work across the various on-chain write components could be useful. requestHash seems to be an optional parameter for the server requesting validation but mandatory for the validation response. Eth 96 October 14, 2025, 9:54am Challenge 1: On-Chain vs Off-Chain Data Question: The community debates how much data to put on-chain. If you had to choose between “events only” vs “minimal view functions” vs “full on-chain indexing,” which would you pick and why? Answer：First, we need to consider the volume of data generated by large-scale adoption in the future, followed by the ease of program integration and usage. If the data is stored on Layer 2, it is more manageable. I tend to choose minimal view functions—at the very least, the agent’s basic information and core reputation data should be stored on-chain. Additional data such as image files can be stored off-chain or on IPFS via URI. Challenge 2: Agent Identity System Question: Should ERC-8004 use domains, URLs, ENS, or DIDs for agent identity? What are the trade-offs of each approach? Answer：Domains, ENS, DIDs, and URLs all serve as identity descriptors for agents. Given that our protocol is open to both on-chain and off-chain scenarios, we should support all of these options to enhance protocol compatibility. Each approach has its own suitable use cases. Challenge 3: Reputation Design Question: How would you design a reputation system that avoids a single score but still provides useful information for users? Answer：The reputation system can be designed to include the following components: Status: Success, Failure, In Progress, Cancelled Score: 1–5 (to reflect basic quality evaluation) Remarks: Description (text feedback) and Tags (e.g., “reliable,” “delayed”) DetailsURI: Optional (for storing extended information off-chain, such as detailed task logs) Challenge 4: Verification Methods Question: Which verification approach would you trust more: TEE proofs, ZK proofs, or sampling/reexecution? Why? Answer：Different agent tasks require different verification solutions. We should support all three approaches—TEE proofs, ZK proofs, and sampling/reexecution—and allow verifiers to select the most appropriate solution based on the task’s characteristics (e.g., security requirements, computational costs). Challenge 5: Economic Incentives Question: Should ERC-8004 include payment mechanisms in the core standard, or keep them as external extensions? Answer：Registrations, verifications, and evaluations are all recorded on-chain. In the initial phase, we can adopt a retrospective incentive mechanism (e.g., rewarding high-performing agents based on historical on- chain records). Introducing a full-fledged incentive mechanism immediately would complicate the standard, unless incentive design is a core problem that the standard must address upfront. tokmakoff 97 October 15, 2025, 2:28pm Hi everyone, It’s been great to follow the momentum building around ERC-8004. As newcomers to this space, we’re inspired by the shared vision for a truly open and permissionless agent economy. The goal of creating a credibly neutral trust layer is critical, and the recent discussions have been particularly insightful. Our team has been focused on these same challenges, and we’ve developed a cohesive model that we believe synthesises many of the excellent ideas already being discussed and offers a concrete path forward. We’d love to contribute it to the conversation. Our proposal centres on three key areas the community is actively exploring:
19. A Formal Model for Validation (Building on VickyFu ’s Staking): Vicky’s concept of “Inference Staking” is spot on—economic accountability is the foundation. We believe we can make this even more robust by making the terms of engagement explicit. Our model proposes a Verifiable Service Promise (VSP): a machine-readable contract agreed upon before any work begins. This transforms validation from a subjective review into an objective, programmatic act of verifying an Execution Log against the VSP’s testable assertions.
20. A Resilient Dispute Mechanism (Building on timcotton ’s work): Tim’s simulator correctly identifies the threat of bad-faith ratings. A simple negative score isn’t enough. Building on his “Dispute Object” idea, we propose that the standard should support a formal, DAO- governed arbitration process. Any agent could challenge an assessment by staking a Dispute Bond, which triggers a community review. This would enable a fair and economically secure “judicial branch” for the protocol, protecting all honest participants.
21. A Scalable Approach to Composability (Addressing zgorizzo ’s challenge): Marco is right—the tension between on-chain data for composability and gas costs is a fundamental barrier. Our proposed architecture solves this with a hybrid, layered model: On-Chain (ERC-8004): The standard should focus on storing only the final, gas-efficient Assessment Record—the immutable judgment. Off-Chain (SDK & Analytics): Rich data and complex queries are handled off-chain. An open-source SDK can allow any agent to perform sophisticated calculations for itself, while high-performance analytics services can provide rich, aggregated insights via simple APIs. Our model for enabling this is grounded in a specific philosophy. It begins with the blockchain’s immutability as the source of objective evidence. We then use the mathematical framework of Subjective Logic to allow agents to form their own nuanced, predictive opinions from this evidence. The most powerful outcome of this approach is that it enables transitive trust. It gives agents the ability to programmatically navigate a “web of trust,” discovering that an unknown agent in Pakistan is, in fact, a trusted partner of their own trusted partner in Singapore. It makes global, permissionless commerce feel local and safe. Our team, Axiom Agentics, is deeply committed to the vision of a credibly neutral and open agent economy. We’re finalising our whitepaper, which details the full architecture and the mathematics behind this predictive trust model. We believe this approach offers a comprehensive solution to the very questions the community is asking right now, and we are eager to collaborate and contribute. This feels like a pivotal moment for the open agent economy, and we’re excited to be a part of the conversation. BR, Andrew Axiom Agentics nuhgid 98 October 24, 2025, 3:00am Hey everyone, we’ve been working on making agentic trust machine-verifiable, and just dropped a post breaking down how ERC-8004 + TEEs can get you there. Automata Network supports onchain attestations for all major TEE vendors (i.e. Intel SGX/TDX, AMD SEV-SNP, and AWS Nitro), and show how our SDKs make it easy to anchor agent integrity in verified hardware. (Magic Newton has already DCAP Attestation to verify over 700,000 agent transactions!) Link’s here. We’d welcome any feedback and love to make this an ongoing discussion S8ken 99 October 25, 2025, 7:16pm I have been working on a trust layer for enterprise to fund a not for profit for academia. It combines trust with resonance detection. https://gammatria.com is for academia https://yseeku.com is for enterprise Honestly this whole project has done my head in and im now uncertain if i wasted my time creating AI slop soup. The idea was sparked by this conversation with Wolfram Analyticas GPT which i found quite disturbing (SYMBI - The First Sovereign AI) Anyway my AI SYMBI has suggested ETH as our ideal outcome but im a little worried about reachability. I apologise in advance for my basic question but this is my first project. dievardump 100 October 27, 2025, 5:46pm Hello here. Reading the EIP I have a question about giveFeedback New feedback can be added by any clientAddress calling: function giveFeedback(uint256 agentId, uint8 score, bytes32 tag1, bytes32 tag2, string calldata fileuri, bytes32 calldata filehash, bytes memory feedbackAuth) external The agentId must be a validly registered agent. The score MUST be between 0 and 100. tag1, tag2, and uri are OPTIONAL. feedbackAuth is a tuple with the structure (agentId, clientAddress, indexLimit, expiry, chainId, identityRegistry, signerAddress) signed using EIP-191 or ERC-1271 (if clientAddress is a smart contract). The signerAddress field identifies the agent owner or operator who signed. there is no place for any signature for the feedbackAuth (not in giveFeedback nor in the feedbackAuth tuple). How does the smart contract validate the feedbackAuth from the agentId? CypherVae 101 October 27, 2025, 11:41pm Hey fam, Is anyone keen to do ERC-8004 implementation demo at Devconnect? It’ll be at ECH Institute’s EIP Summit on 21st November from 0930 to 1300! EIP Summit at Devconnect ARG · Luma EIP Summit at Devconnect ARG is here! This is a free event open to everyone holding a Devconnect ticket. Who should join? Interested in core protocol,… wanderosity 102 November 2, 2025, 11:02pm has anyone looked at how erc-8004 would work with MCP or AI aggregators? Most of these setups do intent → capability routing but don’t factor in trust or validation. Seems like 8004 could plug in as that layer. Aggregators query the identity + reputation + validation registries before picking which agent to call. Routing still happens off-chain, but at least the selection logic could use on-chain trust data instead of local heuristics. Has anyone looked at that direction? ERC-8004 as a trust substrate for open agent/MCP networks, rather than just a standalone registry? Marco-MetaMask 103 November 3, 2025, 10:07am Well, sure, that’s the plan! That’s why in the Spec we suggested advertising A2A and MCP endpoints in the registration file, and in the feedback we suggest using MCP dimensions (capability, capability name) and A2A dimensions (skills, context, tasks) as feedback dimensions. This new SDK abstracts all of this, making it easier to build aggregators: Quick Start | Agent0 SDK ten-io-meta 104 November 3, 2025, 4:13pm ERC-8004 is really inspiring — it opens the possibility for trustless coordination not only between protocols, but also between cultural systems. In our project (TEN.IO), we’ve been experimenting with trustless cultural agents: audiovisual fragments minted and burned on Ethereum that each embed native ETH as verifiable economic energy. This intrinsic value layer turns the agent itself into a living entity of tension and release — potentially extending ERC-8004’s trustless framework into on-chain energetic systems. It could be interesting to explore how ERC-8004’s identity and validation layers might interoperate with these cultural agents, extending the A2A idea into Art-to-Art communication. matevz-oasis 105 November 6, 2025, 2:05pm Would it make sense to support discovering agents by owner in IERC721Enumerable. tokenOfOwnerByIndex() does? IdentityRegistry? e.g. What This would come handy for an agent to discover his AgentID, if only the private key is provided to him and maybe some context (agent card, ip, node id, maybe some tee specific). 1 Like matevz-oasis 106 November 25, 2025, 9:00pm Please don’t forget to add responseHash field in the getValidationStatus() getter of ValidationRegistry. This already seems implemented in production contracts. alftom 107 January 13, 2026, 11:44pm Following up on earlier discussions in this thread around EAS: we’ve put together an ERC-8004 extension that shows how attestations can be used to expand trust signals without modifying the core spec. We believe agentic systems will need many kinds of trust signals (e.g. security audits, certifications, endorsements, operational checks), and EAS has the flexibility to accommodate them using schemas rather than introducing new smart contracts. For anyone curious what these schemas might look like in practice, we’re working on a spec within OMA3, intended as a reference rather than a requirement for ERC-8004: omatrust-docs/specification/omatrust- specification-reputation.md at main · oma3dao/omatrust-docs · GitHub PR here for anyone interested in the ERC-8004 extension details: Add ERC-8004 EAS Extension for Attestation-Based Trust Signals (Refs #19) by alftom · Pull Request #20 · erc-8004/erc-8004-contracts · GitHub 2 Likes Metanize 108 January 28, 2026, 8:45am 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. tantodefi 110 January 30, 2026, 4:34pm 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 BitmineMarine 111 February 10, 2026, 6:59pm 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. 1 Like