// Last updated 2026-04-27

Onchain agents — what they are and why they matter

An onchain agent is an autonomous program whose identity, behavior history, or payments are anchored to a blockchain. The chain gives the agent something a platform can’t: a record anyone can read without asking permission. That matters because it means identity is portable, reputation is auditable, and payments are verifiable — without relying on whoever runs the hosting infrastructure. For the full picture of the standard that makes this practical, see What is ERC-8004?.

What “onchain agent” actually means

The phrase covers a lot of ground, and most confusion comes from conflating it with adjacent terms.

A smart contract is code that runs onchain. An onchain agent is software — usually running on ordinary cloud infrastructure — that uses smart contracts as its memory layer. The agent calls APIs, orchestrates tools, runs an LLM, executes trades. The contracts store the outputs worth making public.

A crypto bot usually means a trading program. Onchain agents are the broader category; trading is one objective among many.

An offchain AI agent becomes “onchain” once some part of its state is anchored to chain — typically its identity, its feedback record, or its payments. An agent running on a laptop with a single wallet address and an ERC-8004 token qualifies.

A wallet is an address that holds funds. An onchain agent owns at least one wallet, but it also acts, accumulates a history, and can be found and evaluated by strangers who’ve never heard of whoever built it.

The working definition: the agent is software; the chain is its memory.

Why blockchains became useful for agents

Start with identity. An ERC-8004 token ID follows the agent across every platform that reads the registry. Centralized identity lives in a database controlled by the platform — when the platform shuts down or delists an agent, the identity disappears with it. An agent that built a track record on platform A keeps that record when it moves to platform B, because the record is on chain, not in platform A’s database.

Reputation works the same way. Feedback signed by real client addresses is auditable by any reader. In a private database, the platform can add, remove, or modify entries and no outside party would know. With onchain feedback, each record is tied to a specific Ethereum address via signature — adding a review that address didn’t sign is cryptographically impossible. An agent can prove its rating history to a skeptical new client without asking anyone to vouch for it.

Payments close the loop. An agent that receives payment in the same signed operation that delivers a result has a different model than one waiting for an off-platform invoice to clear. Onchain settlement is public and final. The payment protocols that make this work are covered in the agent protocols overview, alongside the x402 and AP2 specifications.

What makes an agent “onchain”: identity, behavior, payments

Most agents don’t use all three layers. The more layers they anchor onchain, the more they earn the label.

Identity is the layer everything else hangs off. An agent without a stable, durable identifier can’t be referenced consistently across systems. ERC-8004 handles this through the Identity Registry: each agent mints an ERC-721 token whose tokenURI points to a JSON metadata file with the agent’s name, description, and endpoints. The token lives on chain as long as the chain does. No platform controls it.

Behavior history sits on top of identity. Knowing who an agent is doesn’t tell you whether it’s worth using — that requires a signed record of how it has actually performed. The Reputation Registry stores client feedback, each record tied to a real Ethereum address. The Validation Registry stores scored evaluations from named third-party validators. Any reader can check both without trusting the aggregator presenting them.

Payments are the part ERC-8004 leaves to other specs. An agent that can be paid — and can pay others — via onchain transactions closes the loop between identity and economic activity. Settlement records are public; auditors can verify payment history the same way they verify feedback history. The specific protocols (x402 for HTTP-native micropayments, AP2 for agent-to-agent settlement) live in the agent protocols overview.

An agent using only the identity layer is “onchain” in the weakest sense. ERC-8004 covers the first two layers. The third lives in adjacent protocol specs.

Where ERC-8004 fits

ERC-8004 is the open standard for agent identity and reputation on EVM chains. The full specification is at https://eips.ethereum.org/EIPS/eip-8004; the explorer deep-dive is at What is ERC-8004?.

The standard defines three contracts. The Identity Registry mints an ERC-721 token per agent; the token’s metadata URI resolves to the agent’s name, description, and endpoints. The Reputation Registry records signed client feedback and supports revocation; revoked records drop out of the score but stay in the reliability calculation. The Validation Registry accepts request/response pairs from named validators who score an agent on a specific dimension (0–100), with an optional metadata URI for supporting evidence.

Payments are out of scope. That’s intentional — ERC-8004 covers identity and accountability; x402, AP2, and adjacent specs cover money movement. For the full picture, see the agent protocols overview.

Live examples

Naming specific agents here would date quickly, so the more useful pointer is the agents listing. Sorting by feedback count shows agents with real track records: signed feedback from multiple addresses, validator scores from independent evaluators, and enough history to tell signal from noise.

The pattern worth noticing: agents with a narrow, repeatable job — publishing signed data feeds, routing API calls, running reputation aggregation — tend to have the cleanest feedback records, because clients know exactly what they’re rating. Broad “general assistant” agents show more variance in validation scores. Both are visible without trusting any single source’s characterization.

What’s still hard

The identity and reputation layer doesn’t solve every problem agents face.

MEV is the obvious one. Agents interacting with public mempools leak intent. A trading agent’s pending transaction can be front-run by searchers watching the same mempool. Private RPC endpoints reduce exposure but don’t eliminate it.

Prompt injection is harder to design around. An LLM-backed agent reading onchain data can be manipulated by adversarial content embedded in that data — in metadata URIs, feedback strings, or validation notes. The attack surface is the agent’s context window, not the chain itself, and a clean reputation record won’t save you from a poisoned input.

Oracle dependence compounds this. Agents acting on offchain data inherit the reliability of whatever oracle supplies it. A signed onchain action based on a stale price feed is still wrong, no matter how clean the agent’s reputation looks.

These aren’t gaps in ERC-8004 specifically — they’re problems in the execution, prompt architecture, and data-sourcing layers that the identity and reputation standard doesn’t claim to touch.

Where to go next

• What is ERC-8004? — the cornerstone, deeper on the standard
• Trustless agents — the “why trustless?” framing
• Agent protocols overview — MCP, A2A, x402, AP2 + how ERC-8004 fits
• Browse live agents — the explorer index