ERC-8004: Trustless Agents

ERCs
62

Nothing to add on the items above the ones I respond to below.

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.

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
63

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
64

@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?

I’m not sure this is “front-running”, and I don’t think this approach is effective for the reasons explained by @pcarranzav.

​This was done on purpose; otherwise, AgentServer would have the incentive to revoke permission for every negative feedback received from AgentClient.

Which kind of hard cryptography do you have in mind? zkML and FHE-like approaches are not currently feasible for inference at scale.

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 :frowning:

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
65

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.

66

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.

67

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.
68

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.

69

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)

70

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!

73

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
74

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.

76

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 integrity in off-chain endpoints (why I cannot sign for agentId I don’t own or which is not on chain registred at all).

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.

77

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:

  1. 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.
  2. 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.

78

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?
79

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.
80

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?

:rocket: Explore the product: [AgentGo by Trusta Labs]

81

Great initiative. Some ideas to strengthen ERC-8004:

  1. Would it be possible to support scaled ratings (e.g., 1–5) and short review message feedback, so developers get actionable insights?
  2. We should allow multiple reputation providers and optional aggregation models, with transparent sources.
  3. Add an incident registry for incident reporting with evidence hashes and optional bonds to prevent spam.
  4. 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.
  5. This is more like a question: how to ban/disconnect a harmful agent from a user?

Thanks again, and amazing work!

82

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.

83

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

85

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.