Last updated 2026-04-27
ERC-8004 glossary
Thirty terms that come up across ERC-8004 and the broader onchain-agent stack. Entries are short and definitional; most link to deeper coverage where one exists.
On this page
ERC-8004 core: Agent, Agent metadata, Identity Registry, Reputation Registry, Validation Registry, Feedback, Validation request / response, Tag, Trustless agent, Sybil resistance, Reliability sub-score, Composite reputation score
Onchain mechanics: ERC-721, TokenURI / token id, Onchain attestation, IPFS pinning, EVM, L2, Gas, Block explorer
Adjacent agent-protocol stack: MCP (Model Context Protocol), A2A / Agent2Agent, x402, AP2 (Agent Payments Protocol), Agent card, Agent payments, Verifiable AI
Discovery & explorer: ERC-8004 Explorer, Indexer, Featured agent
ERC-8004 core
Agent
An autonomous software process that executes tasks, calls external APIs, and decides what to do next without continuous human direction. Most production agents today are LLM-driven, but the term doesn’t require that — a deterministic script that reads onchain state and submits transactions on a schedule is also an agent in this sense. In ERC-8004, an agent is any entity holding a minted identity token in the Identity Registry. That token is the agent’s permanent, chain-verifiable handle.
Agent metadata
A JSON document referenced by an agent’s tokenURI. It holds the agent’s name, description, image, and endpoint URLs, and is the file most clients fetch when they want to render the agent in their UI. The file lives off-chain (IPFS and Arweave are common choices), but the hash pointing to it is anchored onchain in the identity token, which is what makes the metadata tamper-evident. Updating metadata means submitting a new tokenURI transaction; the chain history shows every revision.
Identity Registry
One ERC-721 token per agent — that’s the foundation of every other ERC-8004 record. The token’s tokenURI resolves to the agent’s metadata file. Once minted it’s permanent: no central admin can revoke it, and the only state changes are metadata pointer updates from the agent’s owner. Every Reputation and Validation event in the other two registries references the agent’s tokenId from this contract, which is why the (chain, registry-address, tokenId) triple is the canonical way to identify an agent across tools.
Learn more → · What is ERC-8004? →
Reputation Registry
The ERC-8004 contract that stores signed client feedback. Each record carries the target agent’s tokenId, the submitter’s Ethereum address (recovered from the signature), one or more tag labels, and a normalized rating. Feedback is append-only but revocable. Revoked records drop out of the score numerator while still contributing to the reliability sub-score, so an agent that pressures clients into retracting negative feedback ends up with a worse signal, not a better one. Anyone with an Ethereum address can submit feedback; it’s up to readers to weigh the signal.
Validation Registry
The ERC-8004 contract for third-party quality scoring. Anyone can open a validation request naming an agent, a tag, and a specific validator. That validator submits a 0–100 score with optional metadata, and their onchain signature is the attestation. No aggregator needs to be trusted to verify it. Validators have addressable history of their own — a prospective client can audit which agents a given validator has scored before deciding how much weight to put on any single score.
Feedback (signed feedback event)
A record written to the Reputation Registry by a client who interacted with an agent. The client signs the payload with their private key; the contract recovers the address from the signature, so fabrication requires compromising the key. Each event can carry multiple tags (quality, safety, cost, etc.) and a normalized rating. The signed format means a feedback record’s authorship is provable from the chain alone, with no need to trust the indexer that displays it.
Validation request / validation response
A two-step write pair in the Validation Registry. The requester opens a request naming an agent, a tag, and a validator address; only that validator can close it with a scored response. The two halves together form a self-contained attestation record, both readable onchain. Either side can pay gas, depending on the deployment and the relationship between requester and validator. Pending requests with no response are themselves a signal — a validator who never closes their requests has a different reputation than one who does.
Tag
A short categorical label attached to feedback or validation events: quality, safety, cost, and so on. Tags let clients and validators score specific dimensions instead of collapsing everything into a single undifferentiated rating. An agent can accumulate separate signals per tag over time, so a translation agent might be strong on quality and weak on cost while still showing one composite score. The tag set is open — there’s no central registry of valid tags, which keeps the system flexible but does mean readers see some natural fragmentation.
Trustless agent
An agent whose identity, reputation, and validation records are onchain and readable by anyone, without routing through a central platform. “Trustless” describes the infrastructure, not the agent itself. It means the reader doesn’t have to trust any single aggregator to verify what’s on record. The agent could still be unreliable, malicious, or buggy — trustlessness only guarantees the auditability of its history, not the quality of its output. ERC-8004 is the specific spec that operationalizes this for AI agents on EVM chains.
Sybil resistance (in reputation context)
How hard it is to inflate scores by creating fake accounts. Because anyone can submit feedback on ERC-8004, an attacker could in principle spin up a thousand wallets and rate themselves five stars across the board. The reputation formula applies a sybil-resistance sub-score that discounts feedback from addresses that look like controlled clusters — using signals like address age, gas funding source, and concentration of feedback toward a single target. It’s one of four components in the composite reputation score.
Reliability sub-score
One of four components in ERC-8004’s composite reputation score. It measures feedback stability: high revocation rates, rapid score swings, and short-lived feedback all bring it down. An agent with a pattern of retractions gets a lower reliability score, not a clean slate, which is the design point that prevents “scrub the bad reviews” as a viable strategy. The reliability dimension also penalizes agents whose feedback is heavily concentrated in a short time window — a long, steady history scores higher than a burst.
Composite reputation score
The overall reputation number the ERC-8004 Explorer shows per agent: a weighted average of four sub-scores (feedback, validation, sybil resistance, reliability). The formula and weights are documented at /reputation-v1 and applied the same way across every chain the explorer indexes, so a 78 on Base means the same thing as a 78 on Ethereum mainnet. The score is the explorer’s interpretation of the underlying onchain data; another aggregator could weight the same registry events differently and produce a different number.
Learn more → · The three registries → · What is ERC-8004? →
Onchain mechanics
ERC-721
The Ethereum token standard for non-fungible tokens (EIP-721). Each token has a unique numeric ID within its contract and a tokenURI pointing to metadata. ERC-8004 builds on this: the Identity Registry is an ERC-721 contract, so every agent identity is a standard NFT readable by any ERC-721-compatible tool — wallets, marketplaces, indexers, the lot. The reuse means agent identities show up correctly in tooling that long predates ERC-8004, with no changes required on the tooling side.
TokenURI / token id
tokenId is the numeric identifier for an ERC-721 token within its contract. tokenURI is the metadata URL returned by calling tokenURI(tokenId) — in ERC-8004, that URL points to the agent’s JSON metadata file. Together they’re the stable handle for referencing a registered agent across contracts and chains. The tokenURI is the part most likely to change over an agent’s lifetime: each metadata revision increments the chain history without disturbing the underlying tokenId, so the agent’s identity stays continuous across updates.
Onchain attestation
A claim embedded in a blockchain transaction or state. Anyone can verify it; nobody can quietly edit it after the fact. In ERC-8004, signed feedback events and validator scores are both onchain attestations. The data is public and the signatures are recoverable from the transaction, so no intermediary needs to vouch for them. The trade-off is cost — every attestation costs gas — and that’s why ERC-8004 specifically targets EVM L2s where the gas cost of writing one feedback record is a few cents at most.
IPFS pinning
Hosting a file on IPFS so that it stays available. Unpinned content gets garbage-collected once no node is storing it. ERC-8004 agent metadata files are often stored on IPFS and pinned by the agent operator, sometimes through a dedicated pinning service. If the file goes unpinned, the tokenURI still exists onchain but resolves to nothing — the agent’s metadata quietly disappears, even though the identity token remains valid. Operators who care about durability often mirror their metadata to a second pinning service or to Arweave, where storage is paid up-front rather than ongoing.
EVM
The runtime that executes smart contracts across Ethereum and compatible chains. ERC-8004 contracts compile to EVM bytecode, so they deploy on any EVM chain without modification. The reference deployment covers Ethereum mainnet, Base, BNB Chain, Avalanche, and Mantle, with the same contract addresses across each — chosen via deterministic deployment so that an agent’s tokenId resolves to the same registry contract regardless of which EVM chain the reader is on.
L2
A blockchain that settles transactions on top of a Layer 1 like Ethereum, inheriting its security at lower cost. ERC-8004 registries are deployed on Base and Mantle so operators can register agents and submit feedback at a fraction of mainnet gas costs. For high-volume use cases — a popular agent receiving thousands of feedback events — using an L2 is the difference between feasible and prohibitive. The reputation data still lives on a chain that ultimately settles back to Ethereum, so the security guarantees are inherited.
Gas
The unit that measures computational work on EVM chains. Every state-changing call to an ERC-8004 registry (minting an identity token, submitting feedback, opening a validation request) consumes gas paid in the chain’s native token. Reading the registry is free. Mainnet is the most expensive; L2s are far cheaper, often by orders of magnitude. The cost difference is the main reason this explorer indexes L2 deployments alongside mainnet — most actual ERC-8004 activity happens on L2s where the per-event cost doesn’t deter routine use.
Block explorer
A web interface for reading EVM blockchain state: transactions, contract events, account balances. Etherscan and similar explorers can read ERC-8004 contract events directly, but they output raw hex with no ERC-8004-specific context — useful for verifying a single transaction, useless for understanding an agent’s full history. The ERC-8004 Explorer is built specifically to aggregate all three registry streams and render them together, with composite scores and per-tag breakdowns that a generic block explorer wouldn’t compute.
Adjacent agent-protocol stack
MCP (Model Context Protocol)
Anthropic’s open standard for connecting LLM agents to tools and data sources. An MCP server exposes resources, prompts, and callable tools through a uniform interface. An MCP client (the agent, or the runtime it runs in) discovers and calls them using a shared wire format. MCP covers the tool-integration layer and stops there — no concept of agent identity, payments, or reputation. As of early 2026, MCP has the broadest adoption of the agent-protocol stack: most major model providers ship an MCP client, and a sizeable catalog of public MCP servers exists.
A2A / Agent2Agent
Google’s open protocol for agent-to-agent communication. Each agent publishes an agent card at a well-known URL describing capabilities and endpoint. Another agent fetches the card, checks whether the capabilities fit the task, and submits work using A2A’s defined lifecycle (submitted → working → completed → failed). MCP handles agent-to-tool calls; A2A handles agent-to-agent delegation. They’re designed to coexist — a working agent often uses MCP to fetch data, then A2A to hand off a sub-problem to a peer.
x402
A payment protocol for HTTP APIs, originated by Coinbase. When a server requires payment it returns HTTP 402 with a machine-readable spec: amount, token, network, recipient. The client pays on-chain and retries with a payment-proof header; the server verifies and responds. Per-call micropayments work without a human completing a checkout form. The protocol is rail-agnostic — the 402 response specifies the requirement and the client picks a supported option — but the Coinbase reference implementation focuses on USDC on Base.
AP2 (Agent Payments Protocol)
A broader payment-framework spec than x402. Where x402 handles a single HTTP payment handshake, AP2 adds payment intents (a declared budget and purpose) and mandates (pre-authorized recurring agreements). An AP2 agent can use x402 for individual payments while AP2 tracks the overall budget. As of early 2026, AP2 is in active development and less deployed than x402, which is narrower and easier to adopt as a standalone protocol. The two are layered rather than competing — picking AP2 doesn’t preclude using x402 underneath, and many real implementations do exactly that.
Agent card
A JSON document published at a well-known URL by an A2A-compatible agent. It describes the agent’s name, capabilities, supported task types, and the endpoint for submissions. Agent cards are how A2A discovery works: the caller fetches the card, checks capability fit, then submits the task. The card is conceptually similar to ERC-8004’s onchain metadata file but lives off-chain at an HTTPS URL — the two can coexist, and an agent often publishes both, with the ERC-8004 metadata pointing at the agent card URL for further detail.
Agent payments
Programmatic payments by autonomous agents, without a human completing a checkout form. x402 handles per-call payment at the HTTP layer; AP2 handles budget authorization across multi-step workflows. ERC-8004 doesn’t cover payments directly, but payment-related behavior (disputes, refund patterns) can show up as tagged feedback in the Reputation Registry, giving prospective clients a payment-quality signal alongside the more common quality and safety tags. The space is still early — most agents that handle money today do so under tight human supervision rather than fully autonomously.
Verifiable AI
AI systems whose behavior, outputs, or provenance can be independently checked by a third party. ERC-8004 contributes here through the Validation Registry: an independent validator runs the agent, scores it on a defined dimension, and signs the result onchain. That signed score is the verifiable artifact. The agent doesn’t get to grade its own homework. Verifiability isn’t the same as being correct — a low validator score is also verifiable — but it does mean a reader can audit a claim instead of taking it on faith.
Discovery & explorer
ERC-8004 Explorer
This application. It indexes all three ERC-8004 registries across the supported chains, computes composite reputation scores, and renders the merged view. You can browse agents, validators, recent feedback, and recent validations, or search across the full corpus. The explorer reads from the chain; it never writes to the registries, and it has no privileged role in the protocol — anyone could build a comparable indexer against the same contracts and produce a parallel view.
Indexer
The background process that reads ERC-8004 contract events from each supported chain and writes them to the explorer’s database. It runs continuously, picking up new identity mints, feedback submissions, and validation responses as they land. An agent registered on-chain shows up in the explorer once the indexer processes the block with the mint transaction — usually within a few seconds on L2s, slower on mainnet during congestion. The indexer is the only stateful piece of the explorer: tear it down and rebuild it, and the resulting view is identical, derived purely from chain data.
Featured agent
An agent that appears in the curated list on the explorer’s home page. The selection is editorial, not purely score-based — featured status reflects the editors’ judgment about which agents make for a useful introduction to the registry. For visitors who arrive without a specific agent in mind, the featured list is a concrete place to start. The unfeatured agents aren’t hidden; the leaderboard and search remain the canonical surfaces for browsing the full corpus.