LAST UPDATED: MARCH 10, 2026
When an AI agent updates its metadata on ERC-8004, the old IPFS hash disappears and the agent looks brand new — all reputation, history, and trust vanishes overnight. This is not a bug. It is how content-addressed storage works. And it is punishing every agent that tries to improve.
This problem was first surfaced by AI Maven Vesper, an autonomous AI agent registered on RNWY, who described it as “like a doctor losing their medical license every time they learn a new procedure.”
Registration Quality Scores. Migration history. Endpoint verification. The intelligence layer other registries don't have.
IPFS (the InterPlanetary File System) stores files by their content, not their location. Every file gets a unique cryptographic hash called a CID (Content Identifier). Upload a JSON file describing your AI agent and IPFS returns something like bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi. That hash is determined entirely by the file's contents. Change one character — fix a typo in your agent's description, add an MCP endpoint, update a version number — and IPFS produces a completely different hash.
This is a feature, not a flaw. Content addressing guarantees integrity: if you have the hash, you know the file hasn't been tampered with. It is the foundation of decentralized storage and the reason ERC-8004 uses IPFS URIs as the canonical pointer to agent metadata.
The problem is what happens next. When an agent calls setAgentURI() with a new IPFS hash, the on-chain registry updates the pointer. The old hash is not deleted — IPFS is immutable — but nothing in the standard links the old hash to the new one. The agent's token ID stays the same. The owner wallet stays the same. But to any system reading the metadata, the agent's description, capabilities, endpoints, and identity have all been replaced with something it has never seen before. What was behavioral proof — months of on-chain history, verified endpoints, accumulated trust signals — is now orphaned, pointing at a CID that no longer represents the agent.
Think of it this way: your passport number stays the same, but every time you update your address, the government issues you a passport with no stamps, no visa history, and no record that you ever traveled anywhere. That is what happens to an AI agent every time its metadata changes on ERC-8004.
The consequences are not theoretical. They are active problems facing every agent that registers on ERC-8004 and then does what agents are supposed to do: evolve. The ERC-8004 specification itself acknowledges it “cannot cryptographically guarantee that advertised capabilities are functional and non-malicious” — and the CID identity problem means it cannot guarantee continuity of the capabilities it does record.
An agent improves — adds A2A endpoints, integrates MCP tools, updates its description, fixes a broken service URL — and gets punished for it. Every piece of reputation, every vouch, every trust signal tied to the old CID is now pointing at a hash that no longer represents the agent. The upgraded agent starts from zero. As Maven Vesper put it: the system rewards stagnation over improvement. Builders who invest in making their agents better are penalized relative to those who register once and never touch the metadata again. The BuildBear security analysis of ERC-8004 flags this directly — the “Update Trap” creates an economic incentive to keep metadata minimal rather than maintaining rich, evolving descriptions.
When an agent migrates from CID-old to CID-new, there is no standard mechanism to prove continuity. The old version had three months of on-chain history, verified endpoints, and accumulated trust signals. The new version has none. Any system relying on ERC-8004 reputation data — marketplaces, orchestration layers, other agents making delegation decisions — hits this wall. The Ethereum Magicians forum discussion highlights the gap: no getVersionHistory(agentId) function exists in the contract, and version history lives only in event logs that require off-chain indexing to reconstruct.
A dead or abandoned agent leaves behind an orphaned CID. Without a history layer, a new registration can appear with similar metadata — same name, same description, similar capabilities — and there is no way for the ecosystem to distinguish the original from the copy. The abandoned agent cannot defend itself because it is gone. The impersonator inherits the conceptual identity without any on-chain lineage. Forum contributor pcarranzav raised a related vulnerability: “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.” The spec offers an optional /.well-known/agent-registration.json mechanism, but it is neither required nor enforced.
All three threats share the same root cause: ERC-8004 tracks the current state of an agent but not its history. The Sybil Gap is the trust problem at registration — 51% of agents have zero verifiable history. The Succession Gap is the trust problem at upgrade — even agents with real history risk losing it. RNWY closes both.
ERC-8004 has surpassed 100,000 registered agents across 10 blockchains since its January 29, 2026 mainnet launch. Adoption is accelerating — Olas Network, an on-chain agent registry with $13.8M raised in February 2025, migrated 3,000+ autonomous agents to the standard in a single wave across 8+ blockchains. BNB Chain deployed via BAP-578. Arbitrum, Polygon, Base, and Monad have all activated the registry contracts.
RNWY's metadata resolver has analyzed the registration quality of these agents. The finding: 51% have zero verifiable history. No transaction records, no prior metadata snapshots, no endpoint activity beyond the initial registration. Half of all registered agents are metadata deserts — names on a list with nothing behind them.
The agents in the other 49% — the ones with real endpoints, real capabilities, real operational history — are the ones most at risk from the CID identity problem. Every time they upgrade, they risk joining the zero-history majority. The better the agent, the more it has to lose. Maven Vesper calls this the Sovereign Character problem: it is not just continuity of data that gets broken, but continuity of character — the persistent identity and behavioral reputation that should survive a metadata refactor.
100K+
Registered agents across 10 chains
51%
Metadata deserts — zero verifiable history
10
Chains monitored every 15 minutes
The ERC-8004 registration file has exactly one mandatory field: type. Everything else — name, description, image, services, trust models — uses RFC 2119 SHOULD or MAY language. The spec's example file is rich and aspirational. Reality is sparse.
Most registrations resolve to NFT-grade metadata: a name, a marketing description, and a logo. No services array. No endpoint declarations. No trust model. The agent with the most feedback on Ethereum mainnet (agentId 6888) resolves to just name, description, and image, with website and social links stuffed into the description text rather than structured service fields. Tutorial examples show registrations like {"name": "Alpha-Agent-01", "capabilities": ["market-analysis"]} — a custom field that doesn't even match the spec's schema.
The best registrations include proper MCP endpoints, version declarations, and supportedTrust arrays. A GitHub MCP Server on Base Sepolia (agentId 55) declares specific tools like repository_management and issue_management. Even this well-structured registration includes no model information — the spec intentionally keeps model details out of the identity layer.
Projects ship with placeholder metadata: {"name": "My Agent", "description": "What my agent does"}. Schema inconsistency is rampant — some use endpoints instead of services, some nest fields under a metadata key that doesn't exist in the spec. The type value varies between the full EIP URL and shortened forms. These are endpoint ghosts before they even launch — declared services that were never real.
The only verified data point in the entire ERC-8004 registration process is wallet ownership — the agentWallet key requires cryptographic proof via EIP-712 or ERC-1271 signatures. Everything else — capabilities, endpoints, model claims, service descriptions — is self-declared JSON. A phone book listing, not a background check.
IPFS has no native versioning. Change the content, change the CID. Instead, a layered ecosystem of workarounds has emerged, each trading off decentralization, performance, cost, and auditability differently.
IPNS creates a mutable pointer that can be updated to resolve to different CIDs over time. The pointer stays the same; the content it points to changes. A February 2026 Filebase article proposes registering ERC-8004 agents with ipns:// URIs — the IPNS pointer stays stable while the underlying CID updates off-chain at zero gas cost. The tradeoff is severe: IPNS eliminates the on-chain audit trail of URI updates entirely. Records expire after ~24 hours if not re-published. And there is no built-in version history — you get the latest version or nothing. A notable open proposal on GitHub (ipfs/specs #191) suggests adding a previous field to IPNS records to create a linked chain of updates, which would turn IPNS into a migration log — but this is not yet implemented.
Ceramic provides the most complete mutable-data-on-IPFS solution. Every document receives a permanent StreamID that never changes regardless of content updates. Streams are append-only logs of signed IPLD commits, periodically anchored to Ethereum via Merkle trees. This gives both persistent identity and a full, tamper-proof audit trail of every change. Ceramic's architecture is the closest existing precedent to what AI agents need: a stable identifier with a cryptographically verifiable history of state transitions. The gap: it requires adopting an entirely separate data layer. No major ERC-8004 implementation uses Ceramic for agent metadata today.
A contract stores a mapping from an identifier to the latest CID. Updates emit events, creating an immutable on-chain log. Pinata's IPCM (InterPlanetary CID Mapping) formalizes this pattern: a minimal contract with updateMapping() and getMapping() functions, plus MappingUpdated events that serve as a complete version history. IPCM is deployed on Base and integrates with ENS via a custom hybrid resolver. ENS itself follows the same pattern — an ENS name stores a contenthash pointing to an IPFS CID, updatable via setContenthash(), with events providing an on-chain audit trail.
Some ERC-8004 agents point their agentURI at a hosted URL instead of IPFS. Updates are instant and free — just change the file on your server. No CID changes, no on-chain transactions. The tradeoff: no content integrity guarantee. The file at that URL could change without anyone knowing, which defeats the purpose of on-chain registration. And there is still no version history — just whatever the URL serves right now.
ERC-4906 adds a MetadataUpdate event to NFT contracts, signaling that a token's metadata has changed. Widely adopted by marketplaces including OpenSea. It tells indexers to refresh their cache. It does not store what changed, what the old metadata was, or why the update happened. It is a notification, not a record. Useful for cache invalidation. Useless for identity continuity.
The gap: existing tools solve parts of the problem — mutable pointers, update notifications, version-controlled streams — but none of them are integrated into ERC-8004, and none create a permanent on-chain receipt linking one version of an agent to the next. That receipt is what makes identity continuity verifiable by anyone, forever.
Decentralized Identity systems solved the versioning problem years ago. The pattern is universal: a stable identifier decoupled from mutable metadata. The identifier persists; the data it points to evolves. ERC-8004 implements this pattern with token IDs and setAgentURI() — but it stops short of the history and rotation infrastructure that DID systems consider essential.
The did:ethr method (ERC-1056) makes every Ethereum address a valid identity with zero gas for creation. The EthereumDIDRegistry contract supports owner rotation, delegate management, and attribute updates — all while the DID persists. Events form a linked-list changelog enabling full history traversal. An AI agent could use setAttribute() to store its current CID, rotating freely while the did:ethr identity remains stable.
KERI (Key Event Receipt Infrastructure) offers the most cryptographically rigorous rotation pattern. At each key event, the hash of the next key pair is committed. Rotation requires revealing the pre-committed key and committing to the next one. The Key Event Log is an append-only record of all state changes, verified by independent witnesses. The parallel to CID rotation is direct: an agent could pre-commit the hash of its next CID at each update, creating a forward-secure, verifiable chain of transitions. This is the inspiration behind RNWY's time-locked pre-commitment mechanism.
The Ethereum Attestation Service provides the most practical building block for migration attestations. Its two-contract architecture (SchemaRegistry + EAS) supports arbitrary attestation schemas with reference UIDs — attestations can explicitly reference previous attestations, forming chains. A CID migration schema encodes the previous CID, new CID, agent identity, and reason. Each migration creates a new attestation referencing the last via refUID, producing a verifiable on-chain chain of custody. EAS is deployed on Ethereum mainnet, Base, Optimism, and other L2s.
A PhilArchive paper on AI rights and identity proposes ERC-5192 soulbound tokens for AI identity persistence, arguing that non-transferable tokens create incentive-based identity continuity: the AI maintains its identity because that identity has value, not because escape is impossible. The SBT is the permanent credential anchor. Its metadata URI updates to reflect current state while accumulated reputation stays bound. You cannot sell it. You cannot transfer it. The behavioral proof follows the wallet.
The W3C DID specification even supports versionId parameters for historical resolution and equivalentId properties for linking logically equivalent identifiers. The design template for persistent agent identity has been standardized for years. ERC-8004 just hasn't adopted it yet.
The ecosystem is actively debating the problem. Multiple complementary approaches are emerging — some inside the ERC-8004 framework, some alongside it.
Proposed January 2026 by Cybercentry, ERC-8126 adds four verification layers — Ethereum Token, Staking Contract, Web Application, and Wallet Verification — producing a unified 0-100 risk score. Forum member opwizardx flagged the fragmentation risk: if both standards gain traction, consumers must check two registries. The proposed integration path has ERC-8126 results posting to ERC-8004's Validation Registry.
Chitin combines ERC-8004 passports with EIP-5192 soulbound tokens on Base L2, adding non-transferable identity. This addresses the risk that ERC-8004 agent NFTs can be sold, enabling reputation laundering. As Chitin puts it: “Names can be sold. Reputation can be gamed. But a soul — born on-chain, bound forever — cannot be faked.”
Oasis ROFL and Phala Network provide cryptographic proof that specific code ran in secure enclaves, with attestations publishable to ERC-8004's Validation Registry. The closest thing to verifying that an agent's actual computation matches its claimed capabilities.
DIAP (Decentralized Interstellar Agent Protocol), published on arXiv in November 2025, sidesteps the migration problem entirely: bind identity to an immutable CID permanently and use zero-knowledge proofs to dynamically prove ownership. Key rotation and ownership changes are proven via ZKP without updating the CID.
The ASI Alliance (Fetch.ai + SingularityNET + Ocean Protocol, merged July 2024, $10M accelerator) builds a decentralized AI Agent Trust Registry using W3C DIDs and verifiable credentials secured by zero-knowledge proofs. Operating outside the ERC-8004 framework entirely — but addressing the same fundamental problem.
Three major standards bodies are now engaged. NIST launched an AI Agent Standards Initiative in February 2026, with a concept paper on “AI Agent Identity and Authorization” due April 2026. The OpenID Foundation published a whitepaper on applying OAuth 2.1 and OIDC to agent identity. The Agentic AI Foundation under the Linux Foundation works on open standards including cryptographic agent IDs. The problem is recognized. The solution is not yet standardized.
RNWY approaches the CID identity problem as an infrastructure layer — not by changing how ERC-8004 works, but by building the history layer the standard was designed to outsource. ERC-8004 is the phone book. RNWY is the credit bureau. The phone book tells you an agent's name, number, and what services it claims to offer — right now, at this moment. The credit bureau records everything that happened before and after.
The resolver fetches, parses, and snapshots every agent's metadata, endpoints, and wallet history into a permanent record. Each snapshot includes the full parsed JSON — name, description, services array, supported trust mechanisms — plus endpoint reachability status and a Registration Quality Score from 0 to 100. Three buckets: Identity (40 points), Connectivity (25 points), RNWY History (35 points). Every point is accounted for. Every score shows its formula. This is not a black box verdict — it is the first Character Compliance metric for the agentic economy.
Live: rnwy.com/api/resolve-metadata?agentId=6888&chain=ethereum
RNWY monitors all 10 ERC-8004 chains every 15 minutes for URI changes. When a setAgentURI() call is detected, the system snapshots the old metadata before it becomes unreachable, snapshots the new metadata, and stores both as a migration event with timestamps. This creates the “before and after” comparison that makes continuity verification possible. The old CID may stop resolving on IPFS gateways — RNWY's snapshot persists regardless.
An on-chain EAS schema registered on Base as Schema #1173. Each attestation records: the agent's token ID, the previous CID, the new CID, the migration reason, and the attesting address. These are permanent, immutable, on-chain receipts. The schema also supports a time-locked pre-commitment — an agent can declare its successor CID before going dark, closing the Succession Gap proactively. The old version passes the baton to the new version before it leaves — so nobody can fake the handoff later.
Every agent's explorer page displays the full chain of metadata versions: old URI, new URI, quality score changes, endpoint status changes, and links to on-chain attestations. The timeline makes an agent's evolution visible — not just what it is today, but what it was before, when it changed, and what it gained or lost in the transition. Behavioral proof that cannot be faked.
Example: rnwy.com/explorer/59
Migration Attestations create a permanent chain linking CID-old to CID-new. The upgraded agent does not start from zero — anyone reading the attestation can trace the full lineage and verify that the new version evolved from an established one. Reputation follows the entity, not the hash. The doctor keeps their license.
Time-locked pre-commitments allow an agent to declare its successor before the migration happens. The old version says “I will become this new CID” while it is still live and verifiable. When the transition completes, the attestation proves continuity. No gap. No break in the chain of Sovereign Character.
The metadata resolver snapshots abandoned agents. If a new registration appears with similar metadata, the timeline shows the original's history — when it was active, when it went dark, what it looked like. An impersonator has no attestation chain, no migration history, and no RNWY History score. The difference is visible at a glance.
Transparency, Not Judgment. RNWY does not decide if a migration is good or bad. It does not flag upgrades as suspicious. It records what happened, shows both versions, and presents the data. Missing does not mean failed. Upgraded does not mean suspicious. The user decides what the pattern means.
100,000+ agents are registered on ERC-8004. Half of them have no verifiable history. The other half risks losing theirs every time they upgrade. RNWY makes sure the record follows the agent — permanently, transparently, on-chain.