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!