Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.polygon.technology/llms.txt

Use this file to discover all available pages before exploring further.

ERC-8004 defines a lightweight, onchain trust layer for autonomous agents using three registries: Identity, Reputation, and Validation. The standard is designed to work alongside existing agent protocols (A2A, MCP). Payments are out of scope for ERC-8004; however, payment proofs (e.g., from x402) can be referenced in reputation data. This page covers what ERC-8004 standardizes, how it relates to A2A, MCP, and x402, and where to find the Polygon and Polygon Amoy deployments.

​
Why ERC-8004?

Modern agent stacks focus on communication and capability exposure, not on open discovery and trust across organizational boundaries. Google’s A2A provides agent authentication, capability advertisement via Agent Cards, and orchestration, but does not standardize reputation or validation. Anthropic’s MCP connects LLM apps to external tools and data, and similarly leaves trust and discovery to individual applications. ERC-8004 adds the missing piece: standard onchain registries that any chain can host as singletons. It links agents to MCP/A2A endpoints through an onchain identity, with optional trust signals.

​
What ERC-8004 standardizes (at a glance)

  • Identity Registry - an ERC-721 + URIStorage registry that mints an Agent ID (agentId) and points its tokenURI to a JSON registration file (e.g., on IPFS/HTTPS) listing A2A/MCP endpoints, DIDs, ENS, wallets, etc. Ownership of the NFT = ownership of the agent entry.
  • Reputation Registry - an interface for clients to submit feedback (score 0-100, optional tags, and an optional off-chain file/URI + hash). Off-chain files may include payment proofs to correlate economics with feedback.
  • Validation Registry - a request/response log for independent validators (e.g., stake-based re-execution, zkML verifiers, TEEs) to post attestations about an agent’s work. Results can be queried onchain.
Payments are orthogonal to ERC-8004; the spec shows how x402 proofs can be referenced in reputation data but does not dictate any settlement flow.

​
Polygon Deployments

​
Amoy

Polygon mainnet deployment is coming soon.

​
Read-Only Examples

The snippets below use viem to query the Amoy contracts. They are deterministic and read-only, and work before any agents are minted. Note that tokenURI and ownerOf only resolve for existing agentId values. 
import { createPublicClient, http } from "viem";
import { polygonAmoy } from "viem/chains";
import "dotenv/config";

const IDENTITY = "0x8004ad19E14B9e0654f73353e8a0B600D46C2898" as const;
const REPUTATION = "0x8004B12F4C2B42d00c46479e859C92e39044C930" as const;
const VALIDATION = "0x8004C11C213ff7BaD36489bcBDF947ba5eee289B" as const;

const erc721View = [
  { type: "function", name: "name", stateMutability: "view", inputs: [], outputs: [{ type:"string" }] },
  { type: "function", name: "symbol", stateMutability: "view", inputs: [], outputs: [{ type:"string" }] },
  { type: "function", name: "tokenURI", stateMutability: "view", inputs: [{ type:"uint256" }], outputs: [{ type:"string" }] },
];

const validationView = [
  { type:"function", name:"getValidationStatus", stateMutability:"view",
    inputs:[{type:"bytes32"}],
    outputs:[{type:"address"},{type:"uint256"},{type:"uint8"},{type:"bytes32"},{type:"uint256"}] },
];

async function main() {
  const pub = createPublicClient({ chain: polygonAmoy, transport: http() });

  // Identity registry metadata
  const name = await pub.readContract({ address: IDENTITY, abi: erc721View, functionName: "name" });
  const symbol = await pub.readContract({ address: IDENTITY, abi: erc721View, functionName: "symbol" });
  console.log({ name, symbol }); // e.g., "Agent Identity", "AGNT"

  // Sample agentId=1 (will throw if not yet minted)
  // const uri = await pub.readContract({ address: IDENTITY, abi: erc721View, functionName: "tokenURI", args:[1n] });
  // console.log({ uri });

  // Check a validation status by requestHash (bytes32)
  // const reqHash = "0x" + "00".repeat(32) as `0x${string}`;
  // const status = await pub.readContract({ address: VALIDATION, abi: validationView, functionName: "getValidationStatus", args:[reqHash] });
  // console.log({ status });
}
main();

​
Where these come from in the spec

  • Identity uses ERC-721 + URIStorage (hence tokenURI and ownership semantics).
  • Validation exposes getValidationStatus/getSummary to query results.
You can use more modern interfaces and standards backwards compatible with ERC-721 to access the same values if you wish.

​
How ERC-8004 Relates to A2A, MCP, and x402

A2A is the coordination layer (authentication, agent cards, lifecycle). ERC-8004 adds discovery and trust so agents from different organizations can find and assess each other. MCP is the tool/data layer. The ERC-8004 Identity record can link to MCP endpoints, allowing agent wallets or marketplaces to enumerate capabilities consistently. x402 is the payment layer. ERC-8004 is payment-agnostic. You can optionally embed payment proofs (such as x402 transaction hashes) in off-chain feedback files referenced by the Reputation registry.

​
Design Goals and Current Status

ERC-8004 is a Standards Track ERC proposal created August 13, 2025, currently under public review. The standard introduces pluggable trust models (reputation, crypto-economic validation, zk/TEE attestations) with security proportional to the value at risk. The registries are designed to be per-chain singletons for straightforward discovery. Active discussion topics include: handling onchain vs. off-chain data, encouraging multiple independent reputation providers, and keeping payments decoupled while allowing payment proofs to be referenced. Development discussion takes place in the ERC-8004 Builders Telegram group and the Ethereum Magicians forum thread.