ERC-8004 Explained: On-Chain Identity for AI Agents

ERC-8004, titled "Trustless Agents", is a draft Ethereum standard for discovering AI agents and establishing trust in them across organizational boundaries, using three on-chain registries for identity, reputation and validation. By the end of this guide you will know what the standard defines, how to register an agent's identity under it with the @abstraxn/agent-kit SDK (from an Abstraxn server wallet or your own signer), and what drives the gas cost of registration.

An agent that can act but cannot prove who it is will eventually do something it shouldn't, and you'll have no clean way to trace it, reverse it, or explain it to anyone. Identity is the security primitive that makes every other control meaningful, and an on-chain identity lets any external protocol or MCP tool verify your agent against the registry without touching your infrastructure. This post is the developer path; for the business case, read why payment networks care about agent identity.

Key takeaways

• ERC-8004 defines on-chain agentic identity, not for humans, not for generic contracts, specifically for AI agents. Each agent is an ERC-721 token in the Identity Registry, owned by an accountable account, whose URI resolves to a registration file listing its name, endpoints, and supported trust models. Reputation and Validation registries sit alongside it.
• An EVM address is not an identity. It's a cryptographic anchor with no semantic link to accountability. ERC-8004 is the registration that gives it meaning.
• The canonical identifier is the agentIdentity string. The format eip155:{chainId}:{registry}:{tokenId} is globally unique, verifiable on-chain, and chain-specific by design. It belongs in your authorization logic, not just your logs.
• Identity is per-chain. An agent operating on three chains needs three registrations. The SDK call is identical for each; only chainId changes.
• Register at creation time, not post-deployment. Adding identity registration to a live agent is a migration. Adding it at deployment is one function call.

Why AI Agents Need On-Chain Identity

According to McKinsey's State of AI 2025, 23% of organizations are already scaling an agentic AI system somewhere in the enterprise, and another 39% are experimenting with agents. Every one of those agents has the same problem: no standard way to prove who it is, who authorized it, or what it's allowed to do.

Most teams building AI agents in 2025 solved identity the same way: they didn't.

An agent got a UUID in a Postgres table, an API key for their backend, and access to a funded EOA. That was the identity layer. It worked fine, until the agent needed to interact with a protocol that had no idea who it was. Until a user wanted to verify which agent had authorized a spend. Until a compliance team asked for an audit trail and got a log file that anyone could have edited.

The problem isn't lazy developers. It's that the tooling for agentic identity didn't exist in a form that fit the agent lifecycle. Ethereum account addresses are cryptographic but carry no semantic meaning. DIDs (Decentralized Identifiers) are semantically rich but too heavyweight for most agent deployments. ENS names are human-readable but not machine-processable in the way an authorization system needs.

None of these were built for the specific problem: an autonomous, non-human actor that operates on behalf of a human user, across multiple chains, over an extended period, with programmable spend authority.

That gap is what ERC-8004 fills.

What ERC-8004 Actually Is

ERC-8004, titled "Trustless Agents", is a draft Ethereum standard for discovering AI agents and establishing trust in them across organizational boundaries. Not for people, not for generic smart contracts, specifically for agents.

ERC-8004 defines three registries. The Identity Registry gives every agent an on-chain identity. The Reputation Registry records feedback from the clients an agent has worked for. The Validation Registry records independent checks of an agent's work.

This post is about the first. The Identity Registry is an ERC-721 contract: each registered agent is a token, so it can be owned, transferred, and browsed like any other NFT. Each registration has three parts:

The agentId, the token ID the registry assigns when the agent is registered.

The token's owner: the account that owns the agent and can transfer it or delegate management to operators. This is the standard's on-chain accountability link. If an agent acts, you can query the registry and find the account that owns it.

The agentURI, which resolves to the agent's registration file (an "agent card"). The file lists the agent's name, description, and service endpoints (such as an MCP or A2A endpoint), the trust models it supports, and an active flag.

The chain, the registry contract, and the token ID together identify the agent globally. The Abstraxn Agent Kit returns them as a single canonical agentIdentity string:

eip155:11155111:0x8004A818BFB912233c491871b3d84c89A494BD9e:42

Four segments. Namespace and chain ID. Registry contract. Token ID. Machine-readable. Verifiable without trusting any off-chain source.

The Agent Kit also takes a userIdentity for each agent: the identifier of the user or organization the agent acts for in your application. That field is an Abstraxn Agent Kit convention, not part of the ERC-8004 standard. It lets your backend link an agent to the person it works for, while the standard's own on-chain link is the token owner.

This isn't a signature scheme or a session token. It's an on-chain record that this agent exists, which account owns it, and where its registration file lives. Any smart contract, any API, any MCP tool that wants to authorize this agent can verify that record against the chain.

ERC-8004 turns an EVM address into a named, accountable actor, and puts that record somewhere every change leaves an on-chain trail.

ERC-8004 vs DID vs ENS vs JWT: Which Identity Approach Is Right for Your Agent?

Here's how the main approaches compare:

DIDs are the most complete identity model but require significant infrastructure to operate correctly. ENS is human-readable but has no semantic concept of an agent or its operator. JWTs are easy but ephemeral and off-chain: any verifying party has to trust your token issuer. ERC-8004 is purpose-built for an autonomous agent acting on behalf of a human, with minimal implementation overhead and durable on-chain verification.

For agentic deployments where agents touch real value, the operator link matters most. An on-chain record that ties an agent to the account that owns it gives an auditor who wasn't in the room when the agent was created something to check without trusting your database.

The Difference Between an Address and an Identity

An EVM address is a public key hash. It tells you that someone with the corresponding private key can sign transactions from that address. It says nothing about who that someone is, what they're authorized to do, or who they answer to.

Think of it this way: a car has a VIN. That number is unique and traceable, but if you find a car parked somewhere, the VIN doesn't tell you who drove it there, whether they were authorized to be there, or who owns it right now. You need the registration. The registration links the physical object to a named owner in a system with enforcement teeth.

An EVM address is the VIN. ERC-8004 is the registration.

The practical consequence: protocols that want to authorize specific agents can't do it by address alone without building and maintaining their own off-chain registry. With ERC-8004, they query a standard contract on the chain and get a structured result back. The authorization logic is composable.

For developers building multi-tenant agent platforms, where one application might spin up hundreds of agents, each acting on behalf of a different user, this distinction separates an audit trail that means something from a list of addresses that mean nothing without your private database.

How to Register AI Agent Identity On-Chain: Two Paths

The @abstraxn/agent-kit SDK gives you two paths to ERC-8004 registration, corresponding to two different trust models.

Server wallet mode is the default. Abstraxn provisions a smart account for the agent, one you don't hold the private key to directly. The access key is a P-256 credential that authenticates your backend to Abstraxn's signing service, which signs transactions on behalf of the wallet. When you register the agent's identity, Abstraxn's backend handles the signing internally.

import { AgentKitClient } from '@abstraxn/agent-kit';
 
const agentKit = new AgentKitClient({
  apiKey: process.env.ABSTRAXN_API_KEY!,
  wallet: 'server',
});
 
const { agent, wallet } = await agentKit.createAgent({
  name: 'Trading Assistant',
  description: 'AI agent that executes trades within per-order limits',
  userIdentity: 'user-123@example.com',
});
 
// Fund the wallet on the target chain first.
// Then register its identity on-chain.
const identity = await agentKit.registerAgentIdentity({
  agentId: agent.id,
  userIdentity: 'user-123@example.com',
  accessKey: wallet.accessKey,        // store this; it cannot be retrieved again
  organizationId: wallet.organizationId,
  evmAddress: wallet.evmAddress,
  chainId: 11155111,                  // Sepolia
});
 
console.log(identity.registration.agentIdentity);
// eip155:11155111:0x8004A818BFB912233c491871b3d84c89A494BD9e:42

One call after wallet creation. The SDK handles gas estimation, transaction construction, and submission. The identity is on-chain. Your backend stores the agentIdentity string and uses it for authorization from that point forward.

External wallet mode is the path for teams that bring their own key infrastructure: existing multisigs, hardware security modules, user-owned wallets via MetaMask. You provide the address and the signer. Registration is a three-step flow: prepare, sign, confirm.

import { createWalletClient, http } from 'viem';
import { privateKeyToAccount } from 'viem/accounts';
import { sepolia } from 'viem/chains';
 
const { agent } = await agentKit.createAgent({
  wallet: 'external',
  evmAddress: process.env.DEV_EVM_ADDRESS!,
  name: 'My Agent',
  description: '...',
  userIdentity: 'user@example.com',
});
 
const identity = await agentKit.registerAgentIdentityExternal({
  agentId: agent.id,
  evmAddress: process.env.DEV_EVM_ADDRESS!,
  chainId: 11155111,
  signTransaction: async ({ prepare, fromAddress }) => {
    const account = privateKeyToAccount(process.env.DEV_PRIVATE_KEY as `0x${string}`);
    const walletClient = createWalletClient({
      account,
      chain: sepolia,
      transport: http(prepare.rpcUrl),
    });
 
    return walletClient.sendTransaction({
      account: fromAddress,
      chain: sepolia,
      to: prepare.registerCall.to as `0x${string}`,
      data: prepare.registerCall.data,
      value: BigInt(prepare.registerCall.value || '0'),
    });
  },
});

You pass in a signTransaction function that receives the prepared calldata and fires it with whatever signing stack you already have. The SDK calls your function, waits for the hash, and confirms the registration against the chain.

Both paths produce the same output: a canonical agentIdentity string, verifiable on-chain, which your backend links to the agent's userIdentity. The difference is who holds the keys.

The registration flow

From agent creation to on-chain verification, same sequence for server and external wallets:

Steps 1 to 3 run once at deployment. Step 6 runs on every authorization check that needs on-chain identity.

The Security Questions That Actually Matter

There's a question that comes up every time I explain this at a technical level, and it's a good one:

"If the registration is on-chain and public, can't someone else register my agent before I do?"

Not in a way that claims it. Registering mints a new token owned by whoever calls the registry, so another party can create their own agent record but cannot make your address its owner. What they can do is copy your agent's name or endpoints into their own registration file. That's why counterparties should verify the agentId and the token owner, not the display name. ERC-8004 also defines an optional endpoint domain verification: an agent proves it controls an HTTPS endpoint by publishing a matching registration at /.well-known/agent-registration.json on that domain.

"What happens if someone registers an address that looks like mine, or claims the same userIdentity string?"

The standard doesn't limit how many times an address registers: every registration mints a new token with a new agentId. Agent Kit adds its own rule on top: each agent registers once per chain. The userIdentity is an Agent Kit field your backend uses, not part of the standard, and it isn't required to be unique, because the same person might operate multiple agents. The canonical identifier is the agentIdentity string, which encodes the registry contract address and the token ID together. Two registrations will never produce the same agentIdentity, even if someone uses the same userIdentity string.

"My agent operates on three chains. Do I need three registrations?"

Yes. Identity is per-chain. An agent's agentIdentity on Sepolia is a different string from its identity on Polygon Amoy, because the chain ID is part of the string and each chain has its own registry deployment (even where the contract address is the same). This is intentional. An authorization system on Polygon shouldn't have to trust a contract on Sepolia to validate an agent. On-chain verification is local to the chain where the action is happening.

What it costs to register an agent

Registering an agent is an on-chain write to the Identity Registry on your target chain. The registry mints an ERC-721 token for the agent, which assigns its agentId, records the owner, and stores the agentURI that points to the registration file. The file itself, with the agent's name, endpoints and supported trust models, lives off-chain at that URI. The standard also allows optional on-chain metadata entries, and each one you add is another storage write you pay for.

That split is what keeps registration cheap. Writing to contract storage is one of the most expensive things a transaction can do on the EVM, and the cost grows with every byte stored. A URI pointer is a short string. A full registration file with descriptions and endpoint lists is many times larger. Keeping the file off-chain and the pointer on-chain means you pay to store a reference, not the document.

The network matters even more. On Ethereum mainnet, every step of the registration is executed and paid for at mainnet gas prices. On an L2 such as Base or Arbitrum, most of the cost is L2 execution, which is far cheaper, plus a share of the cost of posting the transaction's data to Ethereum. Together those still come to a small fraction of the same registration on mainnet, which is why L2s suit platforms that register many agents.

Budget for gas on the registering wallet itself. Registration through Agent Kit, with registerAgentIdentity or registerAgentIdentityExternal, is a standard transaction, not a sponsored user operation, so the wallet that registers must hold a small amount of native gas on the target chain. On Base Sepolia, fund it from a testnet faucet before you register. On mainnet, registering on an L2 keeps that cost low. Gasless registration through the paymaster is not available today. Where a paymaster does help is after registration: paymasters can sponsor an agent's other on-chain actions once it is registered.

Tip: estimate the cost before deploying by calling eth_estimateGas for the registration transaction on your target network.

How Identity Connects to the Other Three Powers

Identity doesn't operate in isolation. In the four powers framing, it's power number one, and the precondition for the other three working correctly.

Wallet is authenticated by identity. In Agent Kit, the userIdentity field on a server wallet ties the wallet's spend authority to a specific operator in your application. When you update a spend policy, you're setting a budget for that agent's paid MCP tool fees, tied to its identity. If two agents share an address, which happens when someone reuses keys carelessly, the policy system can't distinguish them.

Payments via x402 payment rails for agents don't require ERC-8004: any client that can sign the payment can pay. Identity is an optional, separate layer on top. A tool provider that wants to restrict who can call its endpoints can check the caller's registered identity as well as taking payment. Without ERC-8004, "which agents" reduces to "which API keys", a less durable trust anchor than a verifiable on-chain registration.

Policy enforcement at the interaction layer (contract whitelists, recipient blacklists, native amount limits) is keyed to agent IDs in the backend. Those agent IDs map to identities. An interaction policy that blocks an agent from sending more than 0.5 ETH to an unknown address is only meaningful if "this agent" is unambiguously defined. The on-chain identity record is what makes that mapping durable across key rotations, session resets, and infrastructure migrations.

You can build an agent without ERC-8004 registration. Many teams do. But every time they need to answer "which agent did this, and who authorized it," they're reconstructing the answer from mutable off-chain sources. On-chain identity makes that question answerable in a way that doesn't rely on trusting any single party's records.

Common ERC-8004 integration mistakes

1. Treating identity as a post-deployment concern.

The most common mistake: spin up the agent, wire it to a funded wallet, ship it, and plan to "add proper identity later." Later never comes, because the agent is already in production and adding identity registration now requires a migration, a gas spend, and a coordination window. Register identity at agent creation time, in the same deployment step. The SDK flow is designed for this: createAgent gives you the wallet, registerAgentIdentity is the next call.

2. Storing the agentIdentity string as a display field.

The agentIdentity string, eip155:11155111:0x8004..., is not a label. It's the canonical, verifiable identifier for that agent on that chain. It belongs in your authorization logic, your audit logs, your policy configuration, and any inter-agent communication where trust verification matters. Teams that store it as a metadata field and continue using their internal UUID as the real identifier are missing half the value of the standard.

3. Skipping gas funding before registration.

This is the one that fails silently in the worst way. The registerAgentIdentity call submits an on-chain transaction. If the wallet has no native gas on the target chain, the call will fail with a generic error that looks like an SDK or configuration problem. Fund the wallet first, then register. Add a gas check to your deployment checklist.

Conclusion

Agent identity is the mapping between a cryptographic address and an accountable actor. It's the answer to "who is this, and who is responsible for it", in a form any on-chain system can verify without trusting your backend. Whether a specific action is inside what its owner authorized is a separate check: Know Your Intent (KYI).

ERC-8004 encodes that mapping. It doesn't replace your internal agent database. It creates a durable anchor for it, a record on-chain that persists independently of your infrastructure, that can be queried by any protocol, and that links the agent to the account that owns it in a way that gives auditors something to check, enables composable authorization, and makes multi-agent coordination tractable at scale.

The @abstraxn/agent-kit SDK reduces the implementation to three operations: create the agent, register its identity, store the agentIdentity string. Teams that wire it in at agent creation time, using a standard that already exists, will have an audit trail their compliance teams can actually read and an authorization layer their protocols can actually trust.

An agent without identity is a process. An agent with identity is an actor. That distinction is the whole game when autonomous systems start handling real value.

Start building with @abstraxn/agent-kit →

Frequently asked questions

Further Reading

• ERC-8004 Specification, the official EIP on eips.ethereum.org
• ERC-4337 Account Abstraction, the execution model that powers Abstraxn server wallets
• W3C DID Specification, the W3C standard for decentralized identifiers, for comparison