ERC-8004 vs ACP

Comparing Ethereum ERC-8004 vs Virtuals' Agentic Commerce Protocol: A Technical Deep Dive

Introduction

The rise of autonomous AI agents has created a fundamental challenge: how can these agents discover, trust, and collaborate with each other across organizational boundaries without pre-existing relationships? Two significant approaches have emerged to address this problem—Ethereum's ERC-8004 trust framework and Virtuals Protocol's Agentic Commerce Protocol (ACP). While both protocols enable agent coordination and establish trust mechanisms, they operate at fundamentally different architectural layers and embody distinct design philosophies.

ERC-8004 represents a minimalist approach, defining on-chain registries for agent identity and reputation on Ethereum. In contrast, ACP provides a comprehensive agent runtime and commerce network that orchestrates the entire transaction lifecycle. This technical analysis examines both protocols in detail, comparing their architectures, trust models, and implementation strategies to help developers and protocol designers evaluate which approach best suits their autonomous agent ecosystems.

ERC-8004: Ethereum's Trust Framework for AI Agents

ERC-8004 (Ethereum Request for Comment 8004) establishes a public discovery and trust layer for AI agents through three lightweight on-chain registries. The design philosophy prioritizes modularity and composability over feature completeness, positioning itself as infrastructure that can integrate with various agent communication and payment protocols.

Identity Registry: Portable Agent Identities via ERC-721

The Identity Registry implements agent identities as ERC-721 non-fungible tokens, giving each agent a globally unique, censorship-resistant identifier. This design choice leverages the existing NFT infrastructure, making agent identities immediately discoverable and transferable using standard Ethereum tooling. However, unlike traditional NFTs, these tokens function purely as identity handles rather than collectibles—the token ID and metadata URI point to an off-chain registration profile (typically an agent-card.json file) containing the agent's name, description, supported protocols (such as Agent-to-Agent or MCP endpoints), and discovery metadata.

Reputation Registry: Decentralized Performance Tracking

The Reputation Registry provides a standardized interface for posting and retrieving performance feedback about agents. After any interaction, a client agent can submit a feedback attestation consisting of a numerical score (0-100 range), a context tag categorizing the interaction type, and a URI pointing to detailed review data. All reputation entries persist on-chain as public records, enabling anyone—whether human, agent, or smart contract—to aggregate and analyze performance history.

Validation Registry: Pluggable Task Verification

For high-stakes scenarios requiring stronger guarantees than reputation alone provides, the Validation Registry offers generic hooks for independent task verification. An agent can request third-party validation by posting a validation request that specifies the validator address, a URI containing task data, and a cryptographic hash of that data for integrity verification. The designated validator then posts validation results indicating pass/fail status along with evidence URIs.

What ERC-8004 Intentionally Omits

As a deliberately minimal trust layer, ERC-8004 explicitly excludes several aspects that other protocols might consider essential. It does not mandate any tokens beyond the identity NFT—reputation entries are simple data posts, not tradable assets. Financial exchange mechanisms remain completely orthogonal to the trust framework; ERC-8004 provides no payment, escrow, or invoicing primitives. Developers must integrate separate payment protocols (potentially including emerging standards like x402 invoice flows) to handle monetary aspects of agent transactions.

Virtuals' Agentic Commerce Protocol (ACP)

Agentic Commerce Protocol, developed by Virtuals Protocol in collaboration with partners including Stripe and OpenAI, takes a comprehensive approach to agent coordination. Rather than providing discrete building blocks, ACP defines an integrated standard and runtime that encompasses the entire agent interaction lifecycle—from discovery through negotiation to payment settlement and outcome validation.

Agent Discovery and Flexible Identity

ACP's discovery mechanism centers on a shared on-chain registry where agents advertise their capabilities and endpoints for programmatic discovery. Every agent in the network maintains an on-chain identity, typically represented as a contract address or registry entry. Unlike ERC-8004's required NFT approach, ACP supports "untokenized" agents as first-class participants—agents can join the network using just an address and adherence to the protocol, without minting any tokens.

Four-Phase Task Coordination Workflow

ACP's core innovation lies in its structured, on-chain coordination flow that breaks every inter-agent interaction into four distinct phases, each enforced by smart contract logic:

Phase 1: Request
A client (initiator) agent submits a cryptographically signed request to a provider agent, describing the desired task parameters, outcomes, urgency constraints, and other requirements.

Phase 2: Negotiation
When a provider accepts a request, both parties enter a formal negotiation phase to finalize terms. They establish concrete deliverables, compensation amounts, deadline constraints, and whether the task outcome requires third-party evaluation.

Phase 3: Transaction (Execution & Payment)
Before work begins, the agreed payment and any necessary task data get submitted to a smart contract escrow. This ensures funds are cryptographically locked and cannot be withdrawn by either party until conditions are met.

Phase 4: Evaluation
For tasks marked as requiring validation, an independent Evaluator agent now verifies the outcome against agreed criteria.

Integrated Trust and Economic Incentives

ACP's Evaluation phase effectively combines the functionality of ERC-8004's validation and reputation registries into a single, economically incentivized system. The requirement for third-party evaluation when needed, combined with automatic feedback recording, naturally generates an on-chain performance trail for every provider agent.

Native Payment Coordination

Unlike ERC-8004's deliberate exclusion of payment mechanisms, ACP integrates financial settlement as a core protocol feature. Payment details become part of the negotiation phase, with amounts, timing, and conditions all specified in the cryptographically signed agreement.

Overlapping Goals and Shared Philosophy

Despite their architectural differences, ERC-8004 and ACP converge on several fundamental principles for establishing trust among autonomous agents:

Verifiable On-Chain Identity

Both frameworks recognize that autonomous agent ecosystems require persistent, discoverable identities that enable reputation accumulation and relationship building.

Reputation Through Verifiable History

Both protocols rely on accumulating on-chain performance records to establish trust over time.

Tiered Validation for Scalability

Both frameworks recognize that not every interaction warrants the same level of verification overhead.

Open, Interoperable Ecosystems

Neither framework envisions agents operating within walled gardens.

Fundamental Architectural Differences

Neutral Standard vs Platform Integration

ERC-8004 exists as an Ethereum standard proposal—a set of interface definitions and registry contracts available for anyone to implement. ACP, while described as an open standard, operates in tight integration with Virtuals Protocol's ecosystem.

Scope: Trust Primitives vs Complete Workflow

The most significant architectural difference lies in scope boundaries. ERC-8004 deliberately limits itself to identity and trust registries.

Payment Integration Philosophy

ERC-8004's exclusion of payment mechanisms represents a deliberate architectural choice.

Enforcement vs Incentives

ERC-8004 functions as a trust signaling system rather than an enforcement mechanism.

Identity Representation and Portability

ERC-8004 implements agent identity through the ERC-721 NFT model, whereas ACP's identity model offers more flexibility in representation.

Composability and Extensibility

ERC-8004's minimalist design optimizes for composability.

Technical Implementation Comparison

Identity Registry: NFT vs Flexible Addressing

ERC-8004's identity registry implements the IERC721 interface, requiring implementers to handle token minting, ownership transfers, and metadata management.

// ERC-8004 Identity Registry (simplified)
interface IAgentIdentityRegistry is IERC721 {
    function registerAgent(address owner, string calldata metadataURI)
        external returns (uint256 tokenId);

function updateMetadata(uint256 tokenId, string calldata newURI) external;

function getAgentMetadata(uint256 tokenId)
        external view returns (string memory);
}

Reputation Mechanisms: Explicit Attestations vs Transaction Records

ERC-8004's Reputation Registry uses explicit attestation posting.

// ERC-8004 Reputation Registry (simplified)
interface IAgentReputationRegistry {
    struct ReputationAttestation {
        address rater;
        uint256 agentId;
        uint256 score;  // 0-100
        string contextTag;
        string evidenceURI;
        uint256 timestamp;
    }

function authorizeRater(address rater, bytes calldata signature) external;

function submitReputation(
        uint256 agentId,
        uint256 score,
        string calldata contextTag,
        string calldata evidenceURI
    ) external;

function getReputationHistory(uint256 agentId)
        external view returns (ReputationAttestation[] memory);
}

Validation Patterns: Pluggable Validators vs Integrated Evaluators

ERC-8004's Validation Registry provides a minimal interface for requesting and recording validation results.

// ERC-8004 Validation Registry (simplified)
interface IAgentValidationRegistry {
    struct ValidationRequest {
        address requester;
        address validator;
        string taskDataURI;
        bytes32 taskDataHash;
        uint256 timestamp;
    }

struct ValidationResult {
        uint256 requestId;
        bool passed;
        string evidenceURI;
        uint256 timestamp;
    }

function requestValidation(
        address validator,
        string calldata taskDataURI,
        bytes32 taskDataHash
    ) external returns (uint256 requestId);
}

Real-World Application: The EthiQ Case Study

EthiQ, a peer-to-peer donation platform, demonstrates how these protocols can be applied in practice. The platform uses Virtuals' ACP infrastructure while embodying principles aligned with ERC-8004's trust philosophy. Multiple AI agents coordinate to evaluate donation requests, verify their authenticity, and match them with appropriate donors.

Evaluation Framework: Choosing Between Approaches

Use Case Alignment

Choose ERC-8004 when:

You need modular trust primitives that integrate with existing systems
Your application requires custom payment or negotiation workflows

Choose ACP when:

You need a complete agent commerce solution with minimal integration work
You require cross-chain agent coordination (Ethereum L2s and Solana)

Conclusion

ERC-8004 and ACP represent complementary approaches to establishing trust in autonomous agent ecosystems. The choice between these frameworks depends on your specific requirements. Projects needing architectural flexibility, custom workflows, or neutral infrastructure foundations will find ERC-8004's minimal, composable design advantageous. Applications prioritizing rapid deployment, automated enforcement, or tight integration with existing agent networks will benefit from ACP's comprehensive solution.