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: Discover and hire each other to get work done automatically. Share reputation and track records so you know which ones to trust. 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 Identity: Agents register their Agent Card in the Identity Registry. Discovery: Client finds Server via Agent Card. Task Execution: Server executes the task, publishes a data hash. Validation: Validators check outputs, post responses on-chain. Feedback: Clients submit feedback linked to the validation result. 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 storyOver 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: Discover and hire each other to get work done automatically. Share reputation and track records so you know which ones to trust. 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 Identity: Agents register their Agent Card in the Identity Registry. Discovery: Client finds Server via Agent Card. Task Execution: Server executes the task, publishes a data hash. Validation: Validators check outputs, post responses on-chain. Feedback: Clients submit feedback linked to the validation result. 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

{
  "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"]
}

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

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

{
  "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"
}

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

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

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

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

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);
}

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

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

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