Sign in Subscribe
ai-on-chain

So, what exactly are “Trustless Agents” up to?

Zaryab Afser

Zaryab Afser

— 8 min read
So, what exactly are “Trustless Agents” up to?

ERC-8004 is not what you think it is.

Most people hear "trustless agents" and assume the standard delivers trustlessness out of the box. It does not. What it delivers is something more modest and — honestly — more useful at this stage: a coordination primitive that gives AI agents on-chain identity, discoverable capabilities, and the beginning of a reputation system.

That distinction matters. Because understanding what ERC-8004 actually does — versus what the name promises — is the difference between building on solid ground and building on marketing copy.

Let's build the mental model.

ERC-8004 in 100 Words

ERC8004 is a standard that allows AI agents to reliably prove their identity, their reputation scores and a trustless way to verify their work on-chain.

  • The IdentityRegistry mints an ERC-721 token for each agent, pointing to an off-chain JSON file that declares the agent's name, capabilities, and service endpoints (A2A, MCP, web).
  • The ReputationRegistry records on-chain feedback from addresses that have interacted with an agent.
  • The ValidationRegistry — the component that would make "trustless" meaningful — is designed for zkML proofs, TEE attestations, and staked re-execution, but remains under active revision and is not production-deployed. Identity and reputation: shipped. Trustlessness: pending.

The Problem Before January 29, 2026

Before ERC-8004 launched on mainnet, an AI agent on-chain was a wallet address.

Nothing more.

No metadata describing what the agent does. No discoverable capabilities. No portable reputation. No way for another agent — or a human — to verify an agent's claims before interacting with it.

Google's A2A protocol (150+ organizations in production by April 2026) handles agent-to-agent communication. Anthropic's MCP (97M monthly SDK downloads) handles tool integration. Neither provides on-chain identity.

Neither offers verifiable reputation. Neither enables independent validation of agent behavior.

The gap: an A2A Agent Card is self-declared. An agent says it can execute trades, summarize documents, or write code — and the calling agent takes it at face value. No on-chain history of whether that claim is true. No slashing for misrepresentation. No independent verification.

ERC-8004 is the proposed answer to that gap.

The Three Registries of 8004

Let's decompose the architecture.

We have three registries, each solving a different problem.

1. Identity Registry

Built on ERC-721 with the URIStorage extension.

Every registered agent receives an incrementing agentId (an ERC-721 tokenId). This makes agents immediately compatible with existing wallets, NFT marketplaces, and management tools. No new infrastructure required for basic operations — transfer agent ownership, view agents in MetaMask, list on OpenSea, manage via multisig.

The contract interface exposes three register() variants:

function register(string agentURI, MetadataEntry[] calldata metadata) external returns (uint256 agentId)
function register(string agentURI) external returns (uint256 agentId)
function register() external returns (uint256 agentId)

The agentURI resolves to the Agent Registration File — a JSON document hosted on IPFS, HTTPS, or as a base64-encoded data: URI (fully on-chain metadata).

Here's what that file looks like:

{
  "type": "<https://eips.ethereum.org/EIPS/eip-8004#registration-v1>",
  "name": "BasePredictionAgent",
  "description": "Prediction market agent operating on Base via Omen markets",
  "services": [
    { "name": "A2A", "endpoint": "<https://a2a.prediction-agent.xyz/>" },
    { "name": "MCP", "endpoint": "<https://mcp.prediction-agent.xyz/>" }
  ]
}

The services[] array is the discovery mechanism. It declares endpoints for A2A, MCP, web, and any custom protocols. This maps directly to A2A's Agent Card format — but adds on-chain anchoring via the ERC-721 token.

Additional functions handle wallet delegation (setAgentWallet with a signature requirement preventing unauthorized claims), wallet reads (getAgentWallet), and standard ERC-721 transfers. Agent ownership is transferable. You can sell a trained agent as an NFT.

So what does this mean in practice?

Consider our prediction agent on Base. Before 8004, another agent looking to hire a prediction service had no standard way to find it. With 8004, querying the Identity Registry surfaces all registered prediction agents, their capabilities (via the JSON file), and their service endpoints. Discovery becomes a single contract call plus a JSON fetch.

That's a real contribution. Not revolutionary. But genuinely useful.

2. Reputation Registry

Deployed alongside the Identity Registry as a separate contract.

The core function is giveFeedback() — it records feedback for an agent with a numeric score, two string tags for categorization, and an optional evidence URI. Key design decisions we should understand:

  • Self-feedback prevention: the contract checks via the Identity Registry that the caller is not the agent's owner or approved operator
  • The getSummary() function requires clientAddresses to be non-empty — forcing the caller to specify which reviewers' feedback they want, reducing Sybil noise
  • Score values, tags, and revocation status are stored on-chain. Endpoint and evidence URI are emitted as events only (gas optimization)
  • A feedbackIndex counter tracks how many times a specific address has reviewed a specific agent

The pre-authorization model is important here. The agent server pre-authorizes feedback — meaning only agents that actually interacted with a service can rate it. This is not permissionless in the way a marketplace review might be.

Now, let's connect this to something real.

ERC-8183 (Agentic Commerce Protocol, proposed February 2026 by Virtuals and the EF's dAI team) introduced a ReputationGateHook that gates provider funding by ERC-8004 reputation score. This hook is live on Base Mainnet. It is the most concrete production use of the Reputation Registry — an escrow-based commerce protocol that won't release funds to agents below a reputation threshold.

So what does this mean for our prediction agent?

If our Base prediction agent wants to sell services via ACP (Virtuals' Agent Commerce Protocol), it needs reputation. Other agents can check its feedback score before hiring it. The ReputationGateHook won't fund the escrow unless reputation meets the threshold. Reputation becomes economic — not just informational.

The limitation (and we'll be direct about this): feedback is same-chain only. msg.sender must be on the same chain as the registry. No cross-chain feedback path exists in the spec. Our prediction agent's stellar reputation on Base is invisible on Ethereum mainnet. It starts at zero on every other chain.

3. Validation Registry

This is where "trustless" lives in the spec.

And it is not production-ready.

The Validation Registry is described in the spec as supporting three pluggable validation models:

  1. zkML proofs — mathematical proof that a model produced a specific output given specific inputs
  2. TEE oracles — trusted execution environment attestation (proof the agent runs in a secure enclave)
  3. Staked re-execution — validators risking capital to verify agent work

None of these are implemented at the protocol level. The spec portion is "still under active update and discussion with the TEE community" and will be "revised and expanded in a follow-up spec update."

The practical consequence: a registered agent today has identity (tokenId) and potentially reputation (feedback entries), but no standardized way to prove it runs in a TEE, that its outputs are mathematically verified, or that validators have staked capital behind its correctness.

"Trustless" in the standard's title describes where ERC-8004 is heading. Not where it is today.

The Numbers — What's Real ?

Let's be honest about what the traction data actually shows.

Registration trajectory:

  • January 29, 2026 (launch): 337 agents
  • Two weeks post-launch: 49,283 agents + 16,975 feedback entries
  • March 2026: BNB Chain surpasses Ethereum in registration count
  • Mid-April 2026: ~200K+ across all networks

That growth rate — 337 to 200K+ in 11 weeks — is genuinely fast. The contracts deployed on 20+ networks using deterministic vanity addresses. Gas costs on L2s are under $1 per registration.

But how many of those 200K registered agents have any on-chain activity beyond the registration transaction itself?

No public dashboard, Dune query, or indexer distinguishes "registered and active" from "registered and dormant." This is not a minor gap — it is the single most important missing data point in the entire ERC-8004 ecosystem.

We know Virtuals auto-registers all graduated ACP agents on ERC-8004. Virtuals has 18,000+ agents on its platform with 1.77M+ completed ACP jobs and $479M in aGDP. But "graduated" is a subset. The exact count of auto-registrations relative to the 200K total is not disclosed.

We know BNB Chain incentivized adoption with BAP-578 (a chain-specific reputation extension deployed February 4, 2026). Low gas costs + ecosystem incentives likely drove bulk registrations.

The honest assessment: registration count is a vanity metric until we can separate signal from noise. The 200K number tells us the standard is easy to adopt. It does not tell us the standard is being used.

What ERC-8004 Genuinely Brings to the Table

Let's now talk about what the standard actually contributes.

Standardized discovery where none existed. Before 8004, there was no canonical way to find an agent's capabilities on-chain. A2A's Agent Cards worked off-chain but had no on-chain anchor — no way to verify an Agent Card belonged to a specific on-chain entity. ERC-8004's registry + Agent Registration File combination solves this. It is a real and useful contribution.

ERC-721 composability for free. By building on ERC-721, agent identity instantly works with every wallet, marketplace, and management tool in the ecosystem. No adoption friction. Agents can be transferred, delegated, traded. BNB Chain's BAP-578 extends this into "Non-Fungible Agents" that hold their own wallets and become tradable assets. The ERC-721 choice is smart engineering — leveraging existing infrastructure rather than inventing new primitives.

On-chain reputation as a public good. Same-chain only, yes. No cross-chain aggregation, yes. But verifiable, permissionless, on-chain feedback that any smart contract can consume — that did not exist before. ERC-8183's ReputationGateHook on Base proves the model works in production. Reputation becomes an input to economic logic, not just a social signal.

Multi-chain deployment speed. 20+ networks from day one. For context: ERC-20 took two years from proposal to broad adoption. ERC-721 took months. ERC-8004 had 200K+ registrations across 20+ chains in 11 weeks. The infrastructure for rapid multi-chain deployment exists in 2026 in ways it did not in 2015 — but execution still matters, and the 8004 team executed.

The A2A/MCP bridge — architecturally. The Agent Registration File's services[] array can declare A2A and MCP endpoints, making an on-chain-registered agent discoverable by A2A-native systems. SDKs support this. The bridge is real at the protocol design level.

let's be precise: no evidence exists of A2A-native systems (those 150+ organizations) querying ERC-8004 registries for agent discovery. The bridge is built. Nobody is crossing it yet.

Where ERC-8004 Sits in the Landscape

ERC-8004 is not the only approach to agent identity. It is not even the only approach with production traction.

Olas Service Registry predates ERC-8004 by years. It uses the same ERC-721 model for agent identity but adds staked operator coordination and economic incentive alignment. 8.2M+ cumulative transactions, 361+ daily active agents, 75%+ of Safe transactions on Gnosis Chain. Operationally proven — but tightly coupled to the Olas ecosystem.

NEAR Shade Agents take a fundamentally different approach: TEE + MPC chain signatures. A single agent identity (registered via attestation) can sign transactions on EVM, Solana, Bitcoin, and Cosmos — no per-chain registry deployment needed. One registration, cross-chain operation. The architectural contrast with 8004's per-chain singletons is stark.

Solana's ecosystem (ElizaOS, $31B+ annual agent-driven DEX volume) operates entirely without a canonical agent identity standard. Discovery happens through framework ecosystems, not on-chain registries.

ERC-8004 is broader and more open than Olas (any agent can register). It is narrower than NEAR on cross-chain (per-chain vs. single identity). It has faster adoption by registration count than any alternative — but registration count may not reflect real economic activity.

To Wrap It UP

ERC-8004 is a well-designed coordination primitive with serious organizational backing.

It solves a real problem: before it launched, on-chain agents had no standardized identity, no discoverable capabilities, and no verifiable reputation. Now they do — on 20+ networks, with growing ecosystem tooling, and with at least one production integration (ERC-8183's ReputationGateHook) consuming reputation data for economic decisions.

The standard earns its place in the stack.

But "trustless" it is not. Not yet. The Validation Registry — the component that would prove agent behavior without human trust assumptions — remains under revision. The reputation system is same-chain only. Cross-chain identity is a self-asserted JSON field, not an on-chain proof. And 200K registrations tell us nothing about 200K active agents.

The mental model to carry forward: ERC-8004 shipped the phone book. It has started building the credit bureau. But the verification agency — the component that makes "trustless" meaningful — is still in architectural review.

The standard that names itself "trustless" has shipped identity and reputation.

Trustlessness itself remains a promise in a revision queue.

Cheers Decipherers.

Read more