ERC-8004: Trustless Agents

[pcarranzav]

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.

[deiu]

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?

[micheda]

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

[SumeetChougule]

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:

1. 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) external;

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.

2. 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, bytes32 feedbackAuthId);

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!

[node0]

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?

[vkpatva]

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.

[davidecrapis.eth]

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.

[davidecrapis.eth]

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.

[davidecrapis.eth]

@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) external;

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.

[davidecrapis.eth]

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.

[SumeetChougule]

Exactly! The dual path approach is a good idea as it will maintain backward compatibility while addressing high-value use cases.

[deiu]

For those of us working towards an implementation, how do we test interoperability?

[Marco-MetaMask]

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

[Marco-MetaMask]

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?

[Marco-MetaMask]

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

[pcarranzav]

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.

[soispoke]

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.

[bransdotcom]

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.

[bransdotcom]

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

[sarkazein]

I think DID is the most suitable unique identifier, in addition to domain. Let’s build this.