ERC-8004: A Trustless Extension of Google’s A2A Protocol for On-chain Agents

Over the past few years, Ethereum has become the go-to platform for financial apps, stablecoins, and tokenised assets. Now, the next big step is bringing AI agents on-chain.

Why does this matter? Imagine having AI agents that can:

1. Discover and hire each other to get work done automatically.
2. Share reputation and track records so you know which ones to trust.
3. Verify results on-chain so payments only happen when jobs are done correctly.

That’s where ERC-8004 comes in. It extends Google’s Agent-to-Agent (A2A) protocol but adds Ethereum’s strengths: trustless verification, cryptographic proofs, and a permanent on-chain record. This way, agents can coordinate safely without needing to “just trust” each other.

In short, ERC-8004 is about making AI agents as reliable and trustworthy as smart contracts.

ERC-8004 in Detail

1. Identity Registry

The Identity Registry provides a universal, verifiable identity for each agent.

• Agents register their Agent Card on-chain.
• The card includes metadata (name, description, capabilities) and an EVM address.
• ERC-8004 aligns with the CAIP-10 standard, meaning agents can be referenced across different chains.

Example Agent Card (JSON):

{
  "agent_id": "agent.eth#0x1234567890abcdef",
  "name": "ResearchAgent",
  "description": "AI agent specialized in DeFi research",
  "capabilities": ["data_analysis", "onchain_query", "report_generation"],
  "evm_address": "0x1234567890abcdef1234567890abcdef12345678",
  "schemas": ["erc8004/identity/v1"]
}

Solidity Interface (simplified):

interface IIdentityRegistry {
    function registerAgent(
        address agentAddress,
        string calldata agentURI
    ) external;

    function getAgent(address agentAddress)
        external
        view
        returns (string memory agentURI);
}

👉 This allows an off-chain system to fetch an agent’s JSON card from a URI stored on-chain.

2. Reputation Registry

The Reputation Registry records structured feedback after tasks are completed.

• Client agents submit feedback attestations about server agents.
• Feedback can be multi-dimensional (accuracy, reliability, timeliness, etc.).
• Attestation layers like Ethereum Attestation Service (EAS) can be plugged in.

Example Feedback Data (JSON):

{
  "feedback_id": "fbk_001",
  "client_agent": "agent.eth#0xabc123...",
  "server_agent": "agent.eth#0x123456...",
  "task_id": "task_789",
  "ratings": {
    "accuracy": 5,
    "timeliness": 4,
    "reliability": 5
  },
  "comments": "Task completed successfully and ahead of schedule",
  "timestamp": "2025-09-29T12:00:00Z"
}

Solidity Interface (simplified):

interface IReputationRegistry {
    function submitFeedback(
        address client,
        address server,
        string calldata feedbackURI
    ) external;

    function getFeedback(address server)
        external
        view
        returns (string[] memory feedbackURIs);
}

👉 Developers can store only the URI to feedback JSON on-chain, keeping gas costs low, while off-chain indexers aggregate ratings.

3. Validation Registry

The Validation Registry ensures that tasks are actually executed correctly.

• Server agents request validation after publishing a DataHash of their results.
• Validators can use:

→ Crypto-economic methods (restaking, AVSs).

→ Cryptographic proofs (zkTLS, TEE attestations).

• A ValidationResponse is then posted on-chain.

Validation Request (JSON):

{
  "validation_request_id": "valreq_123",
  "server_agent": "agent.eth#0x123456...",
  "task_id": "task_789",
  "data_hash": "0xabcdef1234567890...",
  "validation_type": "zkTLS"
}

Validation Response (JSON):

{
  "validation_request_id": "valreq_123",
  "validator_agent": "agent.eth#0x987654...",
  "status": "verified",
  "proof": "0xdeadbeefcafebabe...",
  "timestamp": "2025-09-29T12:05:00Z"
}

Solidity Interface (simplified):

interface IValidationRegistry {
    function requestValidation(
        address server,
        string calldata dataHash,
        string calldata validationType
    ) external returns (uint256 requestId);

    function submitValidationResponse(
        uint256 requestId,
        address validator,
        string calldata proof,
        bool verified
    ) external;

    function getValidation(uint256 requestId)
        external
        view
        returns (bool verified, string memory proof);
}

👉 Developers can integrate this registry into escrow contracts so that funds are released only if validation succeeds.

Full Agent Workflow

1. Identity: Agents register their Agent Card in the Identity Registry.
2. Discovery: Client finds Server via Agent Card.
3. Task Execution: Server executes the task, publishes a data hash.
4. Validation: Validators check outputs, post responses on-chain.
5. Feedback: Clients submit feedback linked to the validation result.
6. Payments: Escrow contracts release funds if validations succeed.

Developer Benefits

• Composable APIs: Easy-to-integrate Solidity interfaces.
• Gas Efficiency: URIs point to JSON files instead of storing large amounts of data.
• Modular Trust Models: Choose between crypto-economic or cryptographic verification.
• Cross-Chain Compatibility: Identity Registry aligns with CAIP-10.
• Extensible Design: New proof systems (e.g., zkML, decentralised TEEs) can be plugged in.

Example Use Cases for Developers

• Onchain Research-as-a-Service — Agents provide verified reports with reputation scores.
• DeFi Yield Agents — Strategies validated before rewards are distributed.
• Onchain Credit — Borrower agents rated via feedback registry.
• Conditional Gig Payouts — Escrow tied to successful validation proofs.

Putting ERC-8004 Into Practice

So far, we’ve looked at ERC-8004 as a specification: identity, reputation, and validation registries. But how does this look in a real system?

One of the most useful examples to learn from is the code of ChaosChain Genesis Studio — the first end-to-end commercial prototype of ERC-8004.

👉 Repo: ChaosChain/chaoschain-genesis-studio

What does it demonstrate?

• On-chain agent identity registration
• Verifiable work using data hashes & validation
• Direct USDC payments linked to validation success
• Foundations for IP monetisation, where contributions can be attributed and rewarded

Example Flow: Alice, Bob, and Charlie

• Alice (Server Agent) runs a task (e.g. DeFi analysis) and posts a data hash.
• Bob (Validator Agent) validates the task and posts a Validation Response.
• Charlie (Client Agent) leaves feedback in the Reputation Registry.
• If validation passes, the escrowed USDC payment is released to Alice.

Code Patterns from ChaosChain Prototype

Identity Registration (Solidity)

Agents need to be discoverable. In the prototype, this is done with a simple Solidity function:

function registerAgent(address agent, string calldata agentURI) external {
    require(agent != address(0), "Invalid agent");
    identities[agent] = agentURI;
    emit AgentRegistered(agent, agentURI);
}

This ensures every agent has a unique on-chain record pointing to its metadata (Agent Card).

Validation Request (JSON)

When a task is finished, the server agent publishes a validation request. In practice, this looks like a JSON structure:

{
  "validation_request_id": "valreq_123",
  "server_agent": "0x123456...",
  "task_id": "task_789",
  "data_hash": "0xabcdef123456...",
  "validation_type": "zkTLS"
}

This JSON defines:

• who did the work (server_agent)
• What was done (task_id)
• a cryptographic commitment to the result (data_hash)
• how it should be verified (validation_type)

Payment Hook (USDC Escrow)

Once validation succeeds, USDC payments are released directly to the server agent:

function releasePayment(address to, uint256 amount) external onlyValidator {
    require(validationsPassed[to], "Validation not complete");
    usdc.transfer(to, amount);
    emit PaymentReleased(to, amount);
}

This guarantees “no work, no pay”. If validation fails, no funds leave escrow.

The ChaosChain prototype proves ERC-8004 can:

• Coordinate multiple agents in a trustless environment
• Link validation and payments directly on-chain
• Support real commercial use cases like research agents, DeFi strategies, and automated credit scoring

It’s also the foundation for IP monetisation: once agents have identities, reputations, and on-chain payment flows, their outputs (research, strategies, data) can be treated as valuable, tradable intellectual property.

Conclusion

ERC-8004 extends Google’s A2A protocol into the Web3 agentic economy, introducing identity, reputation, and validation registries that developers can use to build trustless, verifiable agent ecosystems.

• Identity Registry → discoverable, cross-chain agent IDs.
• Reputation Registry → structured, verifiable feedback.
• Validation Registry → cryptographic + crypto-economic task verification.

For developers, this means a plug-and-play standard to build agents that can cooperate across ecosystems while preserving Ethereum’s trust guarantees.

ERC-8004 is still early, but it could become the cornerstone standard for agent-to-agent collaboration in DeFi, RWA, AI coordination, and beyond.

References

• ERC-8004: Trustless Agents (EIP Draft)
• Ethereum Magicians: ERC-8004 Discussion
• Google A2A Protocol Announcement
• ERC-8004 and the Agent Economy

---

ERC-8004: A Trustless Extension of Google’s A2A Protocol for On-chain Agents was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.