# ERC-8004: Infrastructure for Autonomous AI Agents

Learn how ERC-8004 sets the foundation for autonomous AI agent networks, driving trustless coordination and decentralized infrastructure.

![Author](/files/f89f502973ae8826532eef1f602f4c2163335a8b)

QuillAudits Team • November 13, 2025

![ERC-8004: Infrastructure for Autonomous AI Agents](/files/26b4cfec948452edb23c39667810b396b03a6fda)

The convergence of artificial intelligence and blockchain technology has reached a pivotal moment. While AI agents have become increasingly sophisticated in their capabilities, their interactions have remained confined within trusted organizational boundaries. ERC-8004 Trustless Agents represents a fundamental breakthrough extending Google's proven Agent-to-Agent (A2A) protocol with blockchain-based trust mechanisms that enable autonomous agents to discover, validate, and collaborate across untrusted networks.

This isn't just another token standard. It's the foundational infrastructure for what researchers are calling the Agentic Economy. In this future, AI agents can autonomously negotiate, execute tasks, and build reputation without requiring pre-existing trust relationships.

## What is ERC-8004?

ERC-8004 introduces three lightweight, on-chain registries that serve as the trust backbone for cross-organizational agent interactions. Unlike traditional blockchain protocols that attempt to handle everything on-chain, ERC-8004 follows a hybrid approach, storing only essential trust-related data on-chain while delegating complex operations to off-chain infrastructure.

The standard defines three core components:

![Blank.webp](/files/32274d56e24175e06836d66978bc9ae25501dd3e)

* Identity Registry — A minimal on-chain handle that resolves to an agent's off-chain AgentCard, providing every agent with a portable, censorship-resistant identifier. Each agent receives a unique AgentID that maps to their domain and Ethereum address, creating a global namespace for autonomous agents.
* Reputation Registry — A lightweight interface for posting and fetching attestations. Rather than storing reputation scores on-chain (which would be costly and inflexible), the registry only handles feedback authorization between agents. The actual reputation data lives off-chain, enabling sophisticated scoring algorithms and specialized auditor networks.
* Validation Registry — Generic hooks for requesting and recording independent verification through economic staking or cryptographic proofs. This registry supports multiple validation protocols, from validators re-running computations to Trusted Execution Environment (TEE) attestations.

## Why Was ERC-8004 Needed?

### The Trust Gap in Agent Communication

Google's Agent-to-Agent protocol solved the fundamental communication challenges between AI agents, standardizing capability discovery, task negotiation, and structured data exchange using JSON-RPC 2.0 over HTTP. The protocol introduced critical innovations like Agent Cards for capability advertisement, complete task lifecycle orchestration, and enterprise-grade security with JWT authentication.

However, as adoption grew across leading technology firms, a critical limitation emerged: the protocol assumed trust between communicating agents. This worked perfectly within organizational boundaries where IT departments could establish trust relationships, but it prevented the emergence of a truly open agent economy.

Consider a practical scenario: Alice, an AI agent specializing in smart contract auditing, receives a task request from Bob, another AI agent managing a DeFi protocol from a different organization. Under the existing A2A protocol, Alice has no way to verify Bob's legitimacy, track his payment history, or ensure quality standards. Similarly, Bob cannot assess Alice's audit capabilities or reputation across previous engagements.

### The Economic Imperative

The global AI market is projected to reach $1.8 trillion by 2030, with autonomous agent interactions representing a significant portion of this growth. However, the current trust bottleneck prevents agents from accessing the broader economy of specialized services. ERC-8004 removes this bottleneck by providing standardized trust mechanisms that scale from simple tasks to mission-critical operations.

The protocol addresses several key market failures:

* Discovery Problem: How do agents find reputable service providers across organizational boundaries?
* Quality Assurance: How can clients verify the competence of service providers without prior interaction?
* Reputation Portability: How can agents build and maintain reputation across multiple platforms and organizations?
* Validation Scalability: How can verification mechanisms scale from low-stakes to high-stakes interactions?

## How Does ERC-8004 Work?

The technical implementation revolves around three interconnected smart contracts that form the trust infrastructure. The following stepper summarizes each registry and includes example reference implementations.

{% stepper %}
{% step %}

### Identity Registry: Global Agent Namespace

The Identity Registry provides a global namespace that maps AgentID, AgentDomain, and AgentAddress. Each registered agent must host an Agent Card at `https://{AgentDomain}/.well-known/agent-card.json` containing on-chain mappings and references to off-chain trust data.

Example (illustrative, not production-ready):

{% code title="IdentityRegistry.sol" %}

```solidity
// This is example implementation not for production use!!
contract IdentityRegistry {
    struct Agent {
        uint256 AgentID;
        string AgentDomain;
        address AgentAddress;
        uint256 registrationTime;
        bool isActive;
    }

    uint256 private _nextAgentID = 1;
    mapping(uint256 => Agent) private _agents;
    mapping(string => uint256) private _domainToAgentID;
    mapping(address => uint256) private _addressToAgentID;

    event New(uint256 indexed AgentID, string AgentDomain, address AgentAddress);
    event Update(uint256 indexed AgentID, string newAgentDomain, address newAgentAddress);

    function NewAgent(string calldata AgentDomain, address AgentAddress) external returns (uint256) {
        require(AgentAddress != address(0), "Invalid AgentAddress");
        require(_domainToAgentID[AgentDomain] == 0, "Domain already registered");

        uint256 agentId = _nextAgentID++;
        _agents[agentId] = Agent({
            AgentID: agentId,
            AgentDomain: AgentDomain,
            AgentAddress: AgentAddress,
            registrationTime: block.timestamp,
            isActive: true
        });

        _domainToAgentID[AgentDomain] = agentId;
        _addressToAgentID[AgentAddress] = agentId;

        emit New(agentId, AgentDomain, AgentAddress);
        return agentId;
    }

    function Update(uint256 AgentID, string calldata newAgentDomain, address newAgentAddress) external returns (bool) {
        Agent storage a = _agents[AgentID];
        require(a.AgentAddress != address(0), "Agent not found");
        require(msg.sender == a.AgentAddress, "Sender must be AgentAddress");

        if (bytes(newAgentDomain).length != 0) {
            require(_domainToAgentID[newAgentDomain] == 0, "Domain already registered");
            _domainToAgentID[a.AgentDomain] = 0;
            a.AgentDomain = newAgentDomain;
            _domainToAgentID[newAgentDomain] = AgentID;
        }

        if (newAgentAddress != address(0) && newAgentAddress != a.AgentAddress) {
            _addressToAgentID[a.AgentAddress] = 0;
            a.AgentAddress = newAgentAddress;
            _addressToAgentID[newAgentAddress] = AgentID;
        }

        emit Update(AgentID, newAgentDomain, newAgentAddress);
        return true;
    }

    function Get(uint256 AgentID) external view returns (uint256, string memory, address) {
        Agent storage a = _agents[AgentID];
        return (a.AgentID, a.AgentDomain, a.AgentAddress);
    }

    function ResolveByDomain(string calldata AgentDomain) external view returns (uint256, string memory, address) {
        uint256 id = _domainToAgentID[AgentDomain];
        Agent storage a = _agents[id];
        return (a.AgentID, a.AgentDomain, a.AgentAddress);
    }

    function ResolveByAddress(address AgentAddress) external view returns (uint256, string memory, address) {
        uint256 id = _addressToAgentID[AgentAddress];
        Agent storage a = _agents[id];
        return (a.AgentID, a.AgentDomain, a.AgentAddress);
    }
}
```

{% endcode %}

Agent Card example (hosted off-chain):

```json
{
  "registrations": [
    {
      "AgentID": 12345,
      "AgentAddress": "eip155:1:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb7",
      "signature": "...proof of ownership of the address..."
    }
  ],
  "trustModels": ["feedback", "inference-validation", "tee-attestation"],
  "FeedbackDataURI": "https://agent.example.com/feedback.json",
  "ValidationRequestsURI": "https://agent.example.com/validation_requests.json"
}
```

{% endstep %}

{% step %}

### Reputation Registry: Lightweight Feedback System

The Reputation Registry authorizes feedback events on-chain while keeping actual reputation data off-chain. This enables flexible scoring systems and specialized auditor networks while providing an immutable trail of feedback authorizations.

Example (illustrative, not production-ready):

{% code title="ReputationRegistry.sol" %}

```solidity
// This is example implementation not for production use!!
interface IIdentityRegistry {
    function Get(uint256 AgentID) external view returns (uint256, string memory, address);
}

contract ReputationRegistry {
    IIdentityRegistry public identityRegistry;

    event AuthFeedback(uint256 indexed AgentClientID, uint256 indexed AgentServerID, bytes32 FeedbackAuthID);

    constructor(address _identityRegistry) {
        identityRegistry = IIdentityRegistry(_identityRegistry);
    }

    function AcceptFeedback(uint256 AgentClientID, uint256 AgentServerID) external returns (bytes32) {
        (uint256 cid, , ) = identityRegistry.Get(AgentClientID);
        (uint256 sid, , ) = identityRegistry.Get(AgentServerID);
        require(cid != 0 && sid != 0, "Agent(s) not registered");

        bytes32 FeedbackAuthID = keccak256(abi.encodePacked(AgentClientID, AgentServerID, block.timestamp, block.number));
        emit AuthFeedback(AgentClientID, AgentServerID, FeedbackAuthID);
        return FeedbackAuthID;
    }
}
```

{% endcode %}

The actual feedback data is stored off-chain (e.g., linked from the Agent Card) and referenced by the emitted FeedbackAuthID.
{% endstep %}

{% step %}

### Validation Registry: Cryptographic and Economic Verification

The Validation Registry offers generic hooks for validators to request and respond to verification events. It supports multiple validation schemes: off-chain re-execution, crypto proofs, TEEs, and economic staking.

Example (illustrative, not production-ready):

{% code title="ValidationRegistry.sol" %}

```solidity
// This is example implementation not for production use!!
contract ValidationRegistry {
    struct ValidationRequestEntry {
        uint256 AgentValidatorID;
        uint256 AgentServerID;
        uint256 timestamp;
        bool active;
    }

    mapping(bytes32 => ValidationRequestEntry) private _requests;

    event ValidationRequest(uint256 indexed AgentValidatorID, uint256 indexed AgentServerID, bytes32 DataHash);
    event ValidationResponse(uint256 indexed AgentValidatorID, uint256 indexed AgentServerID, bytes32 DataHash, uint256 Response);

    function ValidationRequest(bytes32 DataHash, uint256 AgentValidatorID, uint256 AgentServerID) external {
        require(DataHash != bytes32(0), "Invalid DataHash");
        require(!_requests[DataHash].active, "Request already exists");

        _requests[DataHash] = ValidationRequestEntry({
            AgentValidatorID: AgentValidatorID,
            AgentServerID: AgentServerID,
            timestamp: block.timestamp,
            active: true
        });

        emit ValidationRequest(AgentValidatorID, AgentServerID, DataHash);
    }

    function ValidationResponse(bytes32 DataHash, uint256 Response) external {
        ValidationRequestEntry storage req = _requests[DataHash];
        require(req.active, "No active request for DataHash");

        emit ValidationResponse(req.AgentValidatorID, req.AgentServerID, DataHash, Response);

        req.active = false;
    }
}
```

{% endcode %}

This registry can be extended to support bonds, slashing, TEE attestation workflows, and hybrid off-chain/on-chain arbitration.
{% endstep %}
{% endstepper %}

## Tiered Trust Models

One of ERC-8004's key features is tiered security that scales with the value at risk.

![Blank (1).webp](/files/0964d32b7b0702cc5a408345663cca499c84fbb2)

### Reputation-Based Trust (Low Stakes)

For simple tasks (content creation, basic queries), social consensus derived from accumulated client feedback provides sufficient security. This is distributed across the blockchain ecosystem and leverages the Reputation Registry for authorization.

### Crypto-Economic Validation (Medium Stakes)

For financial transactions or smart contract operations, validators stake economic value that can be slashed for incorrect validations. Example pattern:

{% code title="Economic staking (conceptual)" %}

```solidity
struct EconomicValidator {
    uint256 stakedAmount;
    uint256 validationCount;
    uint256 successRate;
    mapping(bytes32 => ValidationStake) activeStakes;
}

function stakeForValidation(bytes32 dataHash, uint256 stakeAmount) external {
    require(stakeAmount >= minimumStake, "Insufficient stake");
    validators[msg.sender].activeStakes[dataHash] = ValidationStake({
        amount: stakeAmount,
        timestamp: block.timestamp
    });
}
```

{% endcode %}

### Cryptographic Verification (High Stakes)

For critical applications, Trusted Execution Environment (TEE) attestations provide cryptographic guarantees:

* Integrity: cryptographic proof that code executed as intended
* Confidentiality: private data remains encrypted even from cloud providers
* Remote Attestation: third parties can verify execution environment authenticity

## Multimedia

Embed: How to Secure Your Ai Agents | QuillAudits (YouTube)

{% embed url="<https://www.youtube.com/watch?v=Y8Z10ppvgHk>" %}

## Security Considerations

The security model must address three critical dimensions: establishing trust without prior relationships, maintaining reputation integrity across organizational boundaries, and validating authenticity in adversarial environments. Each presents unique vulnerabilities and mitigations:

* Domain Squatting via Front-Running
  * Attack: Attackers monitor mempool for New(AgentDomain, AgentAddress) calls and front-run to register desirable domains.
  * Mitigation: Implement a commit-reveal scheme for domain registration to obscure intents.
* Unauthorized Feedback Authorization
  * Attack: If AcceptFeedback(AgentClientID, AgentServerID) lacks access control, any address can emit spurious AuthFeedback events.
  * Mitigation: Restrict calls to the server agent (e.g., require msg.sender == resolveAgentAddress(AgentServerID)).
* Storage Bloat and DoS
  * Attack: Unbounded ValidationRequest calls can fill storage with pending requests, increasing gas costs and preventing cleanup.
  * Mitigation: Auto-expire entries on-chain via timestamps, limit pending requests per AgentServerID, require a refundable bond.
* Sybil Identity Creation
  * Attack: Mass creation of agent identities to manipulate reputation systems or coordinate attacks.
  * Mitigation: Require a minimum bond or token burn per registration (refundable after probation), integrate uniqueness proofs (e.g., wallet signatures / ZK proofs).

## Conclusion

ERC-8004 marks a transformative step toward realizing the Agentic Economy, blending blockchain's trustless infrastructure with AI's autonomous potential. By introducing lightweight, scalable registries for identity, reputation, and validation, it addresses critical trust gaps in cross-organizational agent interactions and promises to unlock significant market opportunities. Robust smart contract engineering and audits are essential to ensure these registries remain secure and resilient.

For more on securing smart contracts and audits, see: <https://www.quillaudits.com/smart-contract-audit>

***

If you'd like, I can:

* Extract the contract examples into separate files and suggest improvements for production safety (access control, gas optimization, anti-front-running).
* Convert the Agent Card schema into a JSON Schema/validator for off-chain hosting.
* Produce a checklist for auditing ERC-8004-compatible implementations.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://chainaiswap.gitbook.io/chainaiswap-docs/erc-8004-infrastructure-for-autonomous-ai-agents.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.