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:
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.
The Identity Registry provides a universal, verifiable identity for each agent.
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.
The Reputation Registry records structured feedback after tasks are completed.
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.
The Validation Registry ensures that tasks are actually executed correctly.
→ Crypto-economic methods (restaking, AVSs).
→ Cryptographic proofs (zkTLS, TEE attestations).
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.
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?
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:
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:
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.
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.
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.
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.
