Introduction
Ethereum’s AI agent stack split into two unrelated pieces this year, and most coverage still treats them as one. ERC-8004 gives an autonomous agent a portable on-chain identity and a place to accumulate reputation. ERC-6551 gives a non-fungible token an actual wallet, one that can hold assets and sign transactions on its own. Neither standard was built to do the other’s job. The ERC-8004 specification says so directly: payment and custody are explicitly out of scope.
That separation matters now because agent frameworks are already combining identity NFTs with token-bound wallets in production, and the reputation layer has no mechanism to see what happens inside the custody layer once a signing session is compromised. This piece breaks down what each standard controls, where they connect on-chain, and why that connection point is the part existing coverage of either standard has not priced in yet.
What ERC-8004 Actually Registers
ERC-8004, titled “Trustless Agents,” entered Draft status on Ethereum’s standards track on August 13, 2025, authored by Marco De Rossi, Davide Crapis, Jordan Ellis, and Erik Reppel. It builds on ERC-721, ERC-712, ERC-1271, and EIP-155. Agent identities are represented using ERC-721 with the URIStorage extension. Calling register(agentURI) returns an agentId, and that ID is nothing more exotic than the ERC-721 tokenId the registry assigns incrementally.
The standard splits into three registries, laid out in detail in the Ethereum Magicians discussion thread. Identity handles registration and discovery. Reputation accumulates feedback, most of it recorded off-chain with events anchored on-chain. Validation records independent verification responses submitted by third parties.
None of the three touch money. The specification is explicit on this point: “Payments are orthogonal to this protocol and not covered here.” An agent can carry a spotless ERC-8004 reputation and an entirely uncontrolled wallet at the same moment, because the standard was never designed to know that wallet exists.
For a deeper look at how registration numbers compare to actual operational use, our earlier analysis covers the gap directly: ERC-8004 Adoption: What the Agent Numbers Actually Show.
What ERC-6551 Actually Controls
ERC-6551, Non-fungible Token Bound Accounts, has been live far longer. It entered the standards track in February 2023. Its registry is a single, ownerless, immutable contract deployed at the identical address on every chain that supports it: 0x000000006551c19487814612e58FE06813775758.
The registry does one job. Given an implementation address, a salt, a chain ID, a token contract, and a token ID, it computes a deterministic account address using CREATE2 and can deploy a minimal proxy at that address on demand. The account itself holds no private key of its own. Every execution call routes through an isValidSigner check, which asks one question: does ownerOf(tokenId) on the bound NFT contract return this caller’s address? A match authorizes the caller to move whatever the account holds.
That check is the entire security model. Whoever controls the NFT controls the wallet, full stop. The specification’s own security considerations section names two failure modes worth remembering. An NFT transferred into its own bound account locks both permanently, and a malicious owner can drain an account’s assets before selling the now-empty NFT to a buyer who assumes the assets are still inside. Neither failure has anything to do with reputation. Both are pure custody problems.
Where the Two Standards Actually Connect
Here is the detail most coverage skips entirely. ERC-8004 identities are ERC-721 tokens. ERC-6551 accounts attach to any ERC-721 token. Nothing in either specification stops an agent’s ERC-8004 identity NFT from being the exact token an ERC-6551 account binds to. One tokenId would then anchor both the agent’s reputation history and its wallet.
This is not a hypothetical pairing. Virtuals Protocol already runs the identical pattern using a plain ERC-721 instead of an ERC-8004 identity token. Documentation describes it plainly: “Each VIRTUAL agent is minted and represented as an ERC-6551 NFT, which also serves as a unique wallet address.” Revenue accrues directly to the bound account and distributes back to whoever holds the NFT. Swap that plain ERC-721 for an ERC-8004 identity token and the architecture does not change. An agent’s reputation and its funds would sit behind the same tokenId, both controlled by whoever can produce a valid signature for that token’s current owner.
No confirmed production deployment currently pairs ERC-8004 specifically with ERC-6551. The compatibility is structural, not yet operational at scale. That gap between what is technically possible and what has actually shipped is exactly why the risk covered later in this piece has not been priced into existing coverage of either standard.
What’s Actually Shipped vs. Still Early
| Component | Status |
| ERC-6551 registry | Live since February 2023, canonical address, deployed across every supporting chain |
| ERC-6551 in agent production | Live: Virtuals Protocol assigns every agent an ERC-6551 wallet |
| ERC-8004 identity registry | Draft standards track since August 2025, reference contracts published, active public discussion |
| ERC-8004 reputation and validation at scale | Early. Registration activity is running ahead of operational, endpoint-serving agents |
| ERC-8004 identity paired with ERC-6551 custody | Not confirmed in production. Structurally compatible only |
The mismatch in maturity is the whole story here. Developers reaching for ERC-6551 today are building on a battle-tested, three-year-old primitive. Developers reaching for ERC-8004 are building on a specification whose own authors have acknowledged, in the public discussion thread, that types and precision still need work: “In the ERC we have function names, inputs and (with one exception) outputs. But yes, we will specify types and be more precise in a future version.”
Why Reputation Can’t See a Custody Compromise
Reputation Tracks the Token, Not the Signer
ERC-8004’s reputation and validation registries record feedback and validation events keyed to an agentId, which is a tokenId. Neither registry records which key, process, or AI session was actually authorized to act as that token’s owner at the moment a given transaction executed. The registry answers “how has this agent behaved historically.” It has no field for “who is actually in control right now.”
Custody Compromise Leaves No Registry Trace
A prompt-injected agent tricked into authorizing a malicious transaction, the kind of attack our wallet exploits analysis documents with real incidents, never touches the ERC-8004 registries. The reputation score written the day before the compromise stays exactly where it was the day after. Nothing in either specification requires, or even permits, the registries to detect that an account’s effective controller changed mid-session. Confirming this required reading both specifications directly: neither one provisions a signal for it, because neither one was designed to watch for it.
The Result Is a False Signal for Counterparties
Any agent or service that checks ERC-8004’s validation registry before transacting with a given agentId is reading a record of past behavior, not a statement about present-moment control. Treating a clean reputation score as evidence that the associated wallet is safe to interact with confuses two systems that were never wired together.
Real Use Cases, Categorized Honestly
Mature. Virtuals Protocol’s agent wallets are the clearest production example of an NFT-as-identity, token-bound-account-as-custody pattern operating at scale, though it predates ERC-8004 and uses a plain ERC-721 rather than an ERC-8004 identity.
Emerging. Independent, smaller-scale open-source projects have started wiring token-bound accounts directly into agent payment stacks, including implementations built around the x402 payment rail on Base. These are early, developer-driven efforts rather than audited production infrastructure, and should be evaluated as such.
Early-stage. Pairing an ERC-8004 identity token directly with an ERC-6551 custody account for the same agent is technically straightforward and, as far as public repositories and the Ethereum Magicians discussion show, not yet confirmed as deployed. This is the combination the rest of this article is built around, and it remains a design pattern rather than a shipped product.
The Risks
The Reputation-Custody Blind Spot
This is the risk the rest of the industry has not priced in. An agent’s ERC-8004 reputation can be pristine while its ERC-6551 signing session is actively compromised, and no mechanism in either standard closes that gap. A counterparty protocol that gates interactions on validation-registry status is gating on a signal that says nothing about current custody integrity. This is not a theoretical edge case. It is the direct, provable consequence of reading what each registry actually records versus what a custody compromise actually changes.
Ownership-Cycle Lockout Destroys Both Layers at Once
ERC-6551’s own specification flags a scenario where an NFT gets transferred into the very account it is bound to. Both the token and its account become permanently inaccessible. If that token happens to be an agent’s ERC-8004 identity, the agent loses its reputation history and its wallet in the same transaction, with no recovery path built into either standard.
Marketplace Drain-Then-Sell
The ERC-6551 specification documents a known fraud pattern directly: an owner can strip an account’s assets and then sell the now-empty NFT to a buyer who has no on-chain way to confirm the account is empty before the sale finalizes. Applied to an ERC-8004 identity token, a buyer could acquire an agent’s entire reputation history attached to a wallet that has already been drained.
Draft-Standard Interface Risk
ERC-8004 is still Draft status, and its authors have publicly acknowledged that interface types are not fully specified. Anything built today that hardcodes assumptions about agentId behavior or registry interfaces carries real re-architecture risk if the standard’s interfaces change before finalization. For related reputation-gaming risks already documented on ERC-8004 specifically, see our earlier adoption analysis.
What This Means for Different Readers
For developers building agent wallets: treat ERC-8004 reputation and ERC-6551 custody as two independent systems that require independent validation. A clean reputation score is not evidence of an uncompromised signing session, and code that conflates the two is building on a false assumption.
For security and audit teams: scope reviews around the boundary between identity and custody, not just each standard in isolation. The failure mode described here happens precisely because nothing sits at that boundary today. Session-level signer verification, of the kind covered in our prompt injection analysis, remains the actual control here, not registry status.
For wallet and agent operators: do not present ERC-8004 reputation to end users as a custody safety indicator. It measures something real, but not the thing a user checking “is this agent safe to send funds through” actually needs to know.
What to Watch
ERC-8004’s progression toward Review or Last Call status. The standard has sat in Draft since August 2025. Movement to the next stage would signal the community considers the specification stable enough to build against long-term.
Interface type finalization. The authors have publicly committed to specifying types more precisely in a future revision. Track the Ethereum Magicians thread and the EIP repository directly for that update.
Whether any team confirms a production pairing of ERC-8004 identity with ERC-6551 custody. As of this writing, none has been publicly documented. The first confirmed deployment will be a meaningful signal that the architecture described in this piece has moved from structural possibility to shipped infrastructure.
Formal alignment with the Linux Foundation and the A2A ecosystem. ERC-8004’s authors have referenced ongoing coordination with these stakeholders. Any published joint specification work is worth tracking for how it treats the custody boundary this piece describes.
Conclusion
ERC-6551 is real, live, and already carrying production value through deployments like Virtuals Protocol’s agent wallets. It has run essentially unchanged since 2023 and its security model, while narrow, is well understood. ERC-8004 is also real, but it remains a Draft standard with acknowledged gaps in its own interface specification, and it was built, by its authors’ own words, without touching custody at all.
What remains unresolved is the connective tissue between them. No confirmed deployment currently pairs the two, no mechanism in either standard lets a reputation check reveal a custody compromise, and the interfaces on the newer standard are still subject to change. Anyone treating ERC-8004 as a signal of wallet safety is reading a system for something it was never built to measure.
The two standards will likely get paired formally at some point, because the technical fit is close to seamless at the ERC-721 layer. Until reputation systems account for signer-session integrity rather than token ownership history alone, ERC-8004 status should not be read by any counterparty, protocol team, or end user as a statement about whether an agent’s funds are currently safe.
FAQs.
What is the difference between ERC-8004 and ERC-6551?
ERC-8004 gives an AI agent an on-chain identity built as an ERC-721 token, plus registries for reputation and third-party validation. ERC-6551 gives any ERC-721 token an actual smart contract wallet capable of holding assets and executing transactions on its own. ERC-8004 handles identity and trust signaling. ERC-6551 handles custody and execution. They address separate layers of an agent’s on-chain footprint, built by different authors on different timelines, and neither one substitutes for or supersedes the other in practice.
Does ERC-8004 make an AI agent’s wallet more secure?
No, and the specification itself says so. ERC-8004 explicitly states that payments are outside its scope, and its registries record reputation and validation history, not custody status or signer authorization. An agent can hold a strong, verified ERC-8004 reputation while its associated wallet, if built on ERC-6551, has an actively compromised signing session at the same time. The two systems are not connected by design, and treating one as a proxy for the other is a mistake worth avoiding.
How can a compromised custody session be detected if ERC-8004 reputation can’t reveal it?
Detection has to happen at the wallet layer, not the identity layer, since neither registry was built to watch for it. That means monitoring signer sessions directly: hardware-isolated key storage, programmable spending limits, and transaction-level policy checks of the kind covered in our prompt injection analysis of agent wallet exploits. ERC-8004’s registries were not designed to surface a live custody compromise, so relying on reputation status for that kind of monitoring leaves the actual attack surface completely uncovered.
How does an ERC-6551 account verify that a transaction is authorized?
The account calls
ownerOf(tokenId)on the NFT contract it is bound to and checks whether the address returned matches the caller attempting the transaction, through anisValidSignerfunction defined in the reference implementation. If the two addresses match, the call is authorized and executes. This check runs fresh on every transaction and carries no awareness of reputation, validation history, or any state recorded in an ERC-8004 registry.What does this mean for teams building on ERC-8004 today?
Build ERC-8004 integrations assuming the interfaces may still change, since the standard remains in Draft status and its own authors have publicly acknowledged incomplete type specifications in the discussion thread. Do not present reputation or validation status to users as a proxy for custody safety under any circumstance. Keep signer-session verification as a separate, explicit check in any wallet architecture, rather than something inferred indirectly from an agent’s ERC-8004 standing or history.
ERC-8004 reputation and ERC-6551 custody can live on the same tokenId, but nothing keeps them in sync. Subscribe below for no-hype AI crypto analysis before the market catches up.
Editorial & Disclaimer Note: Content on CryptoAIAnalysis is independently researched and written using publicly available documentation, technical resources, and observable network data. The aim is to explain AI-powered crypto and blockchain systems clearly, highlight real-world use cases, and discuss limitations alongside potential. This content is provided for informational and educational purposes only and does not constitute financial, investment, or legal advice. Cryptocurrency and AI-related investments involve risk, and readers should always conduct their own research before making decisions.
