What Is ERC-8004? The AI Agent Trust Standard, Explained
What is ERC-8004, in one sentence: a Draft Ethereum standard, titled "Trustless Agents," that gives autonomous AI agents a verifiable on-chain identity so they can be discovered, evaluated, and trusted by other agents or humans without a central directory deciding who's legitimate. It's not a product, it's a specification, three on-chain registries plus a JSON file format, that other tools and platforms implement. This covers exactly what those three registries define, straight from the official EIP text.
TL;DR:
- ERC-8004 defines three on-chain registries: Identity, Reputation, and Validation
- Identity Registry: an ERC-721 token gives each agent a permanent, portable handle
- Reputation Registry: 0-100 feedback scores, optionally weighted by proof of payment via x402
- Validation Registry: independent validators score agent output 0-100
- Each agent's identity token points at a "Registration File" pinned to IPFS, and its status is currently Draft, not Final
What the EIP Actually Says It's For
The specification's own abstract states it "proposes to use blockchains to discover, choose, and interact with agents across organizational boundaries without pre-existing trust, thus enabling open-ended agent economies." The problem it's solving: as AI agents increasingly act autonomously, on their own or on a user's behalf, there's no standard way for one agent (or a human) to verify who another agent actually is, check its track record, or confirm its output was actually correct, the way a marketplace's star ratings or a company's registered business ID does in more familiar systems.
The Identity Registry
Every agent gets a permanent handle through an ERC-721 token, built with the URIStorage extension. The core function is register(agentURI, metadata), which returns an agentId, the agent's on-chain identifier from that point forward. Because it's a standard NFT under the hood, existing wallets, block explorers, and marketplaces already know how to display and transfer it, no new tooling required just to represent the identity itself. The registry also supports setAgentWallet() for linking a payment address to the identity, and getMetadata()/setMetadata() for small key-value data stored directly on-chain.
The Reputation Registry
Reputation tracks agent performance through client feedback. The core function, giveFeedback(agentId, value, valueDecimals, tag1, tag2, ...), records a numeric score (0-100 scale) plus up to two tags per interaction, and supports gasless submission via EIP-7702. The detail worth knowing: feedback can be value-weighted through proof of payment via x402 integration, meaning a $10,000 engagement can be weighted differently from unpaid or trivial work when reputation gets aggregated, rather than every piece of feedback counting identically regardless of stakes. Only the core fields (value, tags, revocation status) are stored on-chain; richer detail can be referenced through an optional feedbackURI.
The Validation Registry
For work where a simple client rating isn't enough, the Validation Registry lets independent validators check an agent's output. validationRequest() (called by the agent's owner or operator) asks for a check; validationResponse() (called by the validator) returns a 0-100 score, with the specification allowing several verification approaches, re-execution, cryptographic proof checking, or secure enclave (TEE) attestation, depending on what's appropriate for the work being verified. Like reputation feedback, the core response is on-chain, and heavier evidence can be referenced through a responseURI.
The Registration File
An agent's identity token points at a Registration File, a JSON document with a defined shape: a type field identifying it as an ERC-8004 registration, name, description, image, a services array listing the agent's actual endpoints (which protocol, which URL), an x402Support flag, an active flag, and a registrations array. This is the document that actually describes what the agent does and how to reach it, the identity token is just the pointer. The spec's own convention for referencing this file: ipfs://{cid} directly, since a CID is already a content hash, no separate integrity field needed.
Draft Status and Who's Behind It
ERC-8004's status on the official EIP page is Draft, not Final, worth stating plainly rather than glossing over. That said, it's not a fringe proposal either: per community coverage, it's been refined with input from Coinbase, MetaMask, ENS, EigenLayer, and The Graph. If you're building against it, the core registry shapes are stable enough to work with, but treat the exact interface as something that could still shift before the EIP progresses to a later stage.
AIOZ Pin's own tooling maps onto this standard directly, worth reading in full in AIOZ Pin for AI Agents: the Identity Registry's ERC-721 pattern is the same one pinNft() already targets, and the Registration File is exactly the kind of content-addressed JSON document AIOZ Pin's pinning tooling is built to handle.
Frequently Asked Questions
What is ERC-8004 in simple terms? An Ethereum standard giving AI agents a verifiable on-chain identity, plus a way to track their reputation and have their work independently validated, so other agents or humans can trust them without a central authority vouching for them.
Is ERC-8004 a finished standard? No. Its status on the official EIP page is Draft. The core structure is stable enough for real building per community coverage, but the exact interface could still change before it's finalized.
What are the three registries in ERC-8004? Identity (an ERC-721 token per agent), Reputation (0-100 feedback scores with optional payment-weighted significance), and Validation (independent 0-100 scoring of agent output).
What is a Registration File in ERC-8004? A JSON document an agent's identity token points to, describing the agent's name, description, endpoints, and supported trust models, typically pinned to IPFS and referenced as ipfs://{cid}.
How does payment affect reputation under ERC-8004? Through x402 integration, feedback can be value-weighted based on proof of payment, so a high-value engagement can carry more weight in aggregated reputation than free or trivial work.
Related Reading
- AIOZ Pin for AI Agents: Storing ERC-8004 Files on IPFS - how AIOZ Pin's existing NFT and pinning tooling applies directly to this standard
- How AIOZ Pin Keeps Files Online: Replication and Proofs - the content-addressing property behind the Registration File's
ipfs://{cid}reference - How to Mint NFTs with Persistent Metadata on AIOZ Pin - the same pin-then-reference workflow ERC-8004's Identity Registry follows
References
Related Content
How IPFS Splits Files: Fixed vs. Content-Defined Chunking
IPFS defaults to 256 KiB fixed-size chunks, but also ships Rabin and Buzhash content-defined chunkers. Here is why the choice affects deduplication.
Anatomy of a CID: Decoding an IPFS Identifier
An IPFS CID is not a random string. It encodes a version, a codec, and a hash algorithm plus digest. Here is how to decode a real CID piece by piece.
How IPFS Shards Large Directories: The HAMT, Not a B-Tree
IPFS does not use a B-tree for large directories. It uses a HAMT, a Hash Array Mapped Trie. Here is exactly how it shards a folder once it outgrows one block.
How to Resize Images on AIOZ Pin Using URL Parameters
AIOZ Pin image resizing happens straight in the gateway URL, no upload step or separate service. Here is every img- parameter, with real srcset examples.
How x402 Payments Weight AI Agent Reputation on ERC-8004
x402 payments let ERC-8004 weight a paid AI agent interaction more heavily than free work in its reputation score. Here is exactly how that link works.
How to Automate NFT Pinning with the AIOZ Pin NFT API
AIOZ Pin NFT API calls pin an asset and its metadata as two tracked pins under one record. Here is how to automate it directly over REST, no SDK needed.