What ERC-8004 sets out to fix for agents
The proposal starts from a plain observation. Model context protocol lets servers list their tools and resources. Agent2Agent handles sign-in, skills, and messages between agents. Yet these protocols do not cover how to discover an agent or decide whether to trust it [1]. In an open market of agents, that is a real hole.
ERC-8004 fills it with three lightweight registries that can be deployed on any L2 or on Mainnet as per-chain singletons [1]. The identity registry is a minimal on-chain handle. The reputation registry is a standard interface for posting and fetching feedback. The validation registry holds generic hooks for independent checks, such as stakers re-running a job or zero-knowledge proofs [1].
Trust is meant to be tiered. A low-stakes job like ordering pizza needs less proof than a high-stakes one like a medical diagnosis. So builders can pick a model that fits the value at risk [1]. Payments are deliberately left out of ERC-8004, though the text shows examples of how x402 payments can enrich feedback signals [1]. If you want the payment side, our explainer on x402 on Arc covers it.
The three registries are light on purpose. Each is one copy per chain, so a chain has one identity, one reputation, and one validation registry that all share [1]. Scoring and aggregation can happen on-chain for composability and off-chain for sophisticated algorithms [1]. That split leaves room for specialist services such as agent scoring, auditor networks, and insurance pools [1]. Trust models stay pluggable, with reputation systems, stake-secured re-execution, zkML proofs, and TEE oracles all listed as options [1].
The identity token: an ERC-721 handle for an agent
The identity registry is built on ERC-721 with the URIStorage extension. That choice means every registered agent shows up as an NFT, so any app that already understands NFTs can browse and transfer agents [1]. In the text, the token ID is called the agentId and the token URI is called the agentURI.
Each agent has a global ID made of a registry string, which holds a namespace, a chain ID, and the registry address. The agentId, which the registry hands out in order, comes after it [1]. The owner of the token is the owner of the agent. That owner can transfer it or hand day-to-day management, such as updating the registration file, to operators [1].
Registering is a single contract call. The call emits a Transfer event and a Registered event, which is how a tool later finds the new agentId.
The registry also lets an owner attach small on-chain notes to an agent. These sit under a text key and hold raw bytes, so apps can read them without fetching any file [1]. One key is reserved, called agentWallet. It names the address where the agent receives payments and starts out as the owner's address [1]. Changing it needs a signature that proves control of the new wallet. When the agent is sold or moved, the field clears itself, and the new owner must verify it again [1].
What sits inside a registration file
The agentURI must resolve to a registration file, and it can use ipfs, https, or a base64 data URI for fully on-chain storage [1]. When the file moves, the owner calls setAgentURI to update it [1]. The point is a portable record that is hard for any single party to censor.
The file has a fixed structure. At the top are a type, a name, a description, and an image, which keep it friendly to ERC-721 apps [1]. Each entry names an endpoint, such as a web page, an A2A agent card, an MCP server, an ENS name, a DID, or an email address [1].
Two details matter for builders. The supportedTrust field is optional, and if empty the standard is used only for discovery, not trust [1]. An agent can also prove it controls a domain by posting a file under a well-known path on its endpoint domain that matches its on-chain record [1].
Registration can happen in stages. An owner may call register with no URI at all and add the agentURI later through setAgentURI [1]. A second overload takes extra metadata entries in the same call, and each entry emits its own event [1]. The registrations list inside the file links back to the chain record. It holds an agentId and a registry string, and the standard says every field in that list is mandatory [1]. That link lets a reader check the file against the chain.
How feedback is posted, and why owners cannot rate themselves
Feedback from a client address is a signed fixed-point value with a decimals field. Only the value and its decimals are required, so the off-chain file can be left out entirely [1].
That blocks the most obvious abuse, an owner padding their own score. It creates two wallets, one that owns the agent and one that records reputation, because per ERC-8004 agent owners cannot record reputation for their own agents [2].
The endpoint, file link, and hash are emitted in an event but not stored [1]. The honest limit is that a rule on addresses can't stop one person from running many addresses. That is why the standard also offers validation, and why scoring is meant to happen in off-chain specialist services [1].
The registry tracks more than raw scores. Each feedback entry gets a feedbackIndex, a 1-indexed counter of the submissions a client address has made to an agent [1]. Tags are left to developers, which keeps filtering flexible [1]. For off-chain files, the standard suggests IPFS or an equivalent so subgraphs can index the feedback [1]. If a file is not content-addressed, a KECCAK-256 hash guards its integrity [1].
Running ERC-8004 on Arc
Arc documents ERC-8004 as its native route to agent identity. Its agentic economy page says Arc gives onchain identity through ERC-8004, plus reputation and a separate standard for job settlement. So agents can sign up, find work, and get paid on their own [3]. The same page points builders to a quickstart for registering a first agent [3].
That quickstart runs on Arc Testnet. It shows how to make developer-controlled wallets, sign up the identity, log reputation, and check credentials [2]. Step four signs up the agent by calling register on the identity registry. The tutorial notes that gas there is about 0.006 USDC-TESTNET per transaction [2]. Arc also states that agents can pay in a stable unit without managing a volatile gas token [3].
For the surrounding context, Arc lists sub-second finality and USDC-native settlement as reasons it suits agents [3]. We cover the network in more depth in what the Arc blockchain is. The tutorial also stresses that metadata fields at the URI are set by each app, unless your integration follows a separate rule.
Arc lists ERC-8004 identity and reputation next to ERC-8183 job settlement as standards for its agentic economy use case [3]. Next to ERC-8004, the agentic economy page names ERC-8183 for the life of a job: creation, escrow funding, handing in the work, review, and USDC settlement [3]. Sample apps include an escrow flow and a nanopayments demo where an agent pays for premium API endpoints in tiny USDC amounts over x402 [3]. Agents can use any EVM-compatible SDK, such as ethers.js, viem, or web3.py, to talk to Arc contracts [3]. Arc says agents can use any EVM-compatible SDK, such as ethers.js, viem or web3.py, to interact with its contracts [3].
How SpendTheBits uses Agent ID
SpendTheBits offers this as Agent ID. It gives an AI agent budget, or a payable @handle, a public on-chain identity in Arc's ERC-8004 identity registry. The identity token is minted to the user's own wallet. This fits a fully non-custodial design, where keys never leave the phone.
The owner-cannot-rate rule shows up here too. SpendTheBits posts its own rating for a registered identity at most once a day, from a separate address. The standard does not let an owner rate their own agent. Nothing about this is hidden: the identity and its ratings are public and permanent, so think before you register. And ERC-8004 is a draft standard, so what you register today may need updating later.
An agent's spending limit is the USDC the owner puts at its address, so the chain sets the cap. We cover this in our piece on an AI agent wallet spending limit. You can see more on the agents page and the AI agent builders page. You can also read about payable handles in how to get paid by AI agents.
In the app · 3 steps
Give an AI agent an on-chain ID in SpendTheBits
Agent ID lives under Arc tools and works on agent budgets and payable handles you already have.
Find it in Arc tools
Arc tools groups the agent tools together. Open Agent ID.
Register an identity
Tap Register for an agent budget or a payable handle. The review shows exactly what you sign.
Your handle carries its record
A registered handle shows its identity and the seller record buyers can check.
Hold your own keys, keep the yield, skip the middleman.
SpendTheBits is a fully non-custodial wallet for 13 chains, free on iOS and Android.