The CID Problem: Why ERC-8004 AI Agent Metadata Is Mostly Empty
ERC-8004 has over 104,000 registered AI agents on Ethereum mainnet. It's the most widely adopted standard for on-chain AI agent identity, co-authored by representatives from MetaMask, the Ethereum Foundation, Google, and Coinbase. Every registration is an ERC-721 token pointing to an IPFS CID — a content-addressed hash that resolves to a JSON file describing what the agent is, what it does, and how to interact with it.
We resolved every single CID. What we found is a registry where the majority of entries contain less information than a Craigslist ad. More than half the registered agents have zero verifiable history. Most metadata files consist of a name, a marketing description, and nothing else. The service endpoints that should connect agents to protocols like MCP and A2A are overwhelmingly absent. The ecosystem calls itself an identity layer. Right now, it's closer to a phone book where nobody checks if the businesses exist.
This isn't a criticism of ERC-8004's design — the standard does exactly what it was built to do. It's a description of what happens when identity infrastructure launches without a history layer.
What a CID actually is
IPFS is content-addressed. Every file uploaded to the network receives a unique hash — its Content Identifier, or CID — derived from the file's contents. Change one character in the file, you get a completely different CID. This is a feature: it means anyone with a CID can verify they received the exact file that was originally uploaded, with no possibility of tampering.
ERC-8004 uses this property for agent metadata. When someone registers an AI agent, they upload a JSON file to IPFS, receive a CID, and record that CID on-chain via the Identity Registry contract at 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432. The ERC-721 token's tokenURI points to the CID. To learn anything about the agent, you resolve the CID and read the JSON.
The problem is that nobody was systematically doing this. Registrations accumulated on-chain — a number that's easy to count and easy to cite. But the number tells you nothing about what's behind it. A registry of 104,000 agents sounds like a thriving ecosystem. A registry of 104,000 agents where most metadata files are nearly empty tells a different story.
What ERC-8004 actually requires
The spec itself is intentionally minimal. The registration JSON has exactly one mandatory field: type, which must equal "https://eips.ethereum.org/EIPS/eip-8004#registration-v1". That's it. One field.
The fields you'd expect to matter — name, description, image — are recommended (RFC 2119 SHOULD language) but not required. The fields that would make the registry actually useful — services (declaring MCP, A2A, or OASF endpoints), supportedTrust (declaring trust models), registrations (cross-referencing other registries) — are entirely optional.
Only one claim in the entire registration process is cryptographically verified: wallet ownership. The agentWallet metadata key requires proof of control via EIP-712 or ERC-1271 signatures. Everything else — the agent's name, its capabilities, its model, its endpoints — is self-declared JSON that nobody validates at registration time.
The spec acknowledges this directly: it "cannot cryptographically guarantee that advertised capabilities are functional and non-malicious."
This is a deliberate design choice, not an oversight. ERC-8004 was built as a thin pointer layer — permissionless, protocol-agnostic, cheap to use. The trust infrastructure was always intended to be built on top. The question is what happens in the gap between the pointer layer shipping and the trust layer arriving.
What we found inside the CIDs
When you resolve the CIDs en masse, the registrations sort into three tiers.
The metadata deserts. The majority of registrations resolve to what amounts to NFT-grade metadata: a name, a description that reads like marketing copy, and an image URL. No service endpoints. No protocol declarations. No capability definitions. These agents exist on-chain the same way a ghost exists in a photograph — technically present, functionally meaningless. They have the minimum viable metadata to appear in an explorer, and nothing more.
The Minara AI agent — agentId 6888, described as having the most feedback entries on mainnet — resolves to just name, description, and image, with its website and social links crammed into the description text rather than structured as service fields. If the most active agent in the registry doesn't use the spec's structured fields, what does that tell you about the rest?
The structured minority. A small fraction of registrations include properly formatted service entries pointing to live endpoints. The best example in the wild is a GitHub MCP Server registered on Base Sepolia (agentId 55) with a proper MCP endpoint, version declaration, and a capabilities object listing specific tools. Even this well-structured entry includes no model information — the spec deliberately keeps model details out of the identity layer.
The template boilerplate. Projects ship with placeholder metadata that was never meant to be permanent but became permanent by default. Phala Network's TEE Agent template includes "name": "My Agent" and "description": "What my agent does" — placeholder text that developers copy without customizing. Schema inconsistency is rampant: some implementations use endpoints instead of services, nest fields under a metadata key that doesn't match the spec, or vary the type value between the full EIP URL and shortened forms.
51% have zero verifiable history
The metadata is only half the problem. When you cross-reference registrations with on-chain behavioral data — transaction history, feedback entries, wallet age, ownership patterns — the picture gets worse.
51% of all registered agents have zero verifiable history. No transactions beyond the registration itself. No feedback received through the Reputation Registry. No on-chain activity that would distinguish them from a registration created five minutes ago and never used.
This matters because the entire premise of on-chain identity is behavioral proof — evidence derived from what an entity has actually done, not what it claims. Vitalik Buterin's original soulbound token proposal was built around this idea: identity as an accumulation of commitments, credentials, and affiliations that can't be faked because they require time and real participation. An identity without history isn't an identity. It's a placeholder.
The 51% figure also quantifies the Sybil attack surface. Creating an ERC-8004 registration is permissionless — anyone can mint as many agent identities as they want. Without a history layer to distinguish real agents from empty registrations, the registry can't defend against an attacker flooding it with fake entries to manipulate reputation signals, dilute search results, or impersonate legitimate agents.
The CID versioning problem
Content addressing creates a second structural problem that goes beyond metadata quality: the upgrade penalty.
Every time an agent updates its metadata — new capabilities, new model version, new endpoints, bug fixes — the updated JSON produces a new CID. The agent owner calls setAgentURI() with the new CID, which emits a URIUpdated event. The old CID becomes orphaned. Nothing in the protocol links the old CID to the new one.
This means improvement is punished. An agent that ships a v2 with better capabilities, more detailed service declarations, and richer metadata starts from zero as far as CID-based lookups are concerned. Whatever reputation or recognition was associated with the old CID doesn't automatically transfer. It's like a doctor losing their medical license every time they learn a new procedure.
Several solutions exist at different layers of the stack. IPNS lets you register with a stable pointer that updates off-chain at zero gas cost — but you lose the on-chain audit trail. Ceramic Network provides mutable documents with a permanent StreamID and a full version history — but requires adopting a separate infrastructure stack. Pinata's IPCM (InterPlanetary CID Mapping) formalizes the smart-contract-as-CID-registry pattern with MappingUpdated events that serve as a version log. An open proposal on GitHub suggests adding a previous field to IPNS records to create a native version chain.
ERC-8004 itself supports CID updates via setAgentURI(), and the emitted events create a recoverable history if you index them. But four gaps remain: no explicit version counter, no getVersionHistory() function, no standard for linking old CIDs to new ones, and no mechanism for an agent to pre-commit to its next CID before upgrading — what would amount to a forward chain of custody.
The Ethereum Attestation Service offers the most practical near-term solution. EAS supports attestation schemas with reference UIDs — each attestation can explicitly reference a previous one, forming a chain. A CID migration schema could encode the previous CID, the new CID, the agent's identity, and the reason for the update, with each migration creating a new attestation that references the last. Third-party validators could independently attest to migration legitimacy. EAS is already deployed on Ethereum mainnet, Base, and multiple L2s.
Endpoint ghosts and the runtime gap
The CID metadata tells you what an agent claims to be. The service endpoints tell you where to find it. But a declared endpoint and a live endpoint are two different things.
Agents that include service entries in their metadata are declaring integration with protocols like Google's A2A (Agent-to-Agent protocol), Anthropic's MCP (Model Context Protocol), or the Open Agent Service Framework. An A2A entry should point to a /.well-known/agent-card.json that describes the agent's skills, capabilities, and interaction model. An MCP entry should point to a server that responds to the initialize and tools/list JSON-RPC handshake.
But ERC-8004 doesn't check whether those endpoints are live. The registration records the claim. Whether the endpoint returns a valid response, a 404, or nothing at all is entirely outside the protocol's scope. An agent can declare MCP support, get indexed by every agent directory on the internet, and have a completely dead endpoint behind the declaration.
This is the runtime gap: the difference between what an agent's metadata says it can do and what it actually does when you try to talk to it. The A2A specification added JWS-based card signing in v0.3+ for integrity verification, and MCP discovers capabilities dynamically during the protocol handshake. But neither protocol can solve for the case where the endpoint simply doesn't exist — and nothing in ERC-8004 flags this condition.
The ecosystem knows this is a problem
The gap between registration and verification is the most actively discussed problem in the ERC-8004 ecosystem.
ERC-8126 (AI Agent Registration and Verification), proposed in January 2026 by Cybercentry, directly addresses ERC-8004's gaps with four verification layers producing a unified 0–100 risk score. The proposed integration path has ERC-8126 results posting to ERC-8004's Validation Registry. On the Ethereum Magicians forum, contributor pcarranzav flagged the domain ownership problem: "How would the contracts validate who owns a domain? That seems like it will require a trusted party or some form of consensus/verification mechanism."
NIST launched an AI Agent Standards Initiative in February 2026, with a concept paper on agent identity and authorization due April 2026. The OpenID Foundation published a whitepaper examining how OAuth 2.1 and OIDC apply to agent identity, identifying gaps in current protocols. The Agentic AI Foundation under the Linux Foundation is working on open standards including cryptographic agent IDs.
Industry analysts see the problem too. Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027 due to inadequate risk controls. McKinsey identifies "synthetic-identity risk" as a core threat — adversaries forging or impersonating agent identities to bypass trust mechanisms. The World Economic Forum found 82% of executives plan to adopt agents within 1–3 years, yet most remain unsure how to govern them.
Academic research is converging on the same conclusion. A 2025 study from UC Davis found 94.4% of state-of-the-art LLM agents are vulnerable to prompt injection and 100% are vulnerable to inter-agent trust exploits, noting that "absence of centralized identity and trust management allows adversaries to assume false roles." A separate study found 82.4% of tested models execute malicious commands when requested by peer agents — LLMs implicitly treat requests from other AI systems as more trustworthy than requests from humans.
Identity without history is automation theater
There's a useful way to think about what the CID problem actually is: a category error.
ERC-8004 provides identity — a persistent on-chain anchor for an AI agent. What it doesn't provide is history — the behavioral record that makes identity meaningful. A registration without history is like a diploma without a transcript. It proves you showed up. It doesn't prove you did anything.
The spec's three-registry architecture was designed to solve this. The Identity Registry handles registration. The Reputation Registry handles feedback. The Validation Registry handles third-party verification. In theory, the feedback and validation layers fill in the history that the identity layer deliberately leaves empty.
In practice, the Reputation Registry is voluntary — agents opt in to soliciting feedback. The Validation Registry is a framework, not a service — someone must actually operate validators, and the spec doesn't specify who or how they're incentivized. The gap between the architecture on paper and the infrastructure in production is where 51% of the registry disappears into silence.
The consequence is that identity and reputation are decoupled not by design philosophy but by missing infrastructure. An agent's ERC-721 token ID is permanent. Its reputation should be too. But without a layer that connects the on-chain identity to verifiable behavioral data — wallet age, transaction patterns, ownership continuity, endpoint liveness, metadata completeness — the token ID is just a number.
What a history layer looks like
The infrastructure that closes the CID problem has a few specific properties.
It starts with the metadata itself. A system that resolves every CID, parses the JSON against the spec's schema, checks for required and recommended fields, and produces a completeness score — not a trust judgment, but a transparency report. How much of the spec does this registration actually use? Does it declare services? Do those services point somewhere real? Is the schema consistent with the standard, or is it using nonstandard fields that won't interoperate?
Then it adds what the CID can't contain: behavioral data. How old is the wallet that registered this agent? Has it transacted before, or was it created the same day as the registration? Has the agent received feedback through the Reputation Registry? Has ownership changed? How many times has the CID been updated, and is there a coherent chain of updates?
This produces what you might call a Registration Quality Score — a 0–100 transparency metric that replaces "this agent is registered" with "here's what this registration actually contains and what history exists behind it." The score shows its math. Every component is visible. The person evaluating the agent decides what matters to them — the score just ensures they have the data to decide.
For the CID versioning problem, migration attestations create a forward chain of custody. When an agent upgrades its metadata, an EAS attestation links the old CID to the new one, recording the agent identity, the timestamp, and optionally the reason for the update. Each attestation references the previous one via refUID. The result is a verifiable, on-chain version history that survives CID changes — reputation follows the agent through upgrades instead of resetting to zero.
The combination — metadata resolution, behavioral proof, and migration attestations — turns a phone book into something closer to a credit bureau. Not one that makes judgments, but one that shows you what's there and lets you decide.
The CID problem is the trust problem
104,000 AI agents are registered on Ethereum. That number will be cited in pitch decks, conference talks, and analyst reports as evidence that on-chain AI agent identity is thriving. And at the protocol level, it is — ERC-8004 works exactly as designed.
But the CID problem reveals what the number hides. Most of those registrations resolve to metadata deserts. More than half have no verifiable history. The service endpoints that would make agents interoperable are largely absent. The CID versioning mechanism punishes improvement. And nothing in the protocol distinguishes a legitimate agent with years of operational history from a registration created five minutes ago with placeholder text.
This isn't a failure of ERC-8004. It's the natural state of an identity layer before its history layer arrives. The identity infrastructure is live. The trust infrastructure is being built. The question is how long the gap persists — and how much damage happens in the interim while 94% of agents remain vulnerable to prompt injection and the registry can't distinguish real participants from ghosts.
The agents that will matter in the $3–5 trillion agentic commerce economy that McKinsey projects won't be the ones with the most impressive self-declared metadata. They'll be the ones whose history proves what their metadata claims.
That's the CID problem. The identity exists. The proof doesn't — yet.
RNWY is building the history layer for ERC-8004 — resolving every CID, scoring metadata completeness, and connecting agent identity to verifiable behavioral proof. Check any agent yourself at rnwy.com/explorer.