ERC-8337: Agent Memory State

Hi all — draft ERC for discussion: verifiable version control for autonomous-agent memory, without putting any memory content on chain. Status: submitted upstream as ERC-8337 (ethereum/ERCs#1910) — all CI checks including eipw passing, awaiting editor review. A public Sepolia deployment is live (see Links and the Update Log). The case, in plain terms An agent that has been running for a year is not the model it started as. It has accumulated preferences, distilled skills, revised policies, and a record of what it did and why. That accumulated state — its memory and its behavioral history — is rapidly becoming the most valuable thing about the agent: it is what you trust, what you would want to carry to another platform, what you might license to someone else, and what a counterparty or regulator may one day ask you to account for. ERC-8004 solved the first half of this: identity and on-chain reputation answer “which agent is this, and should I trust it?” But 8004 deliberately stops there — it does not cover memory, persistent state, or how an agent’s cognition evolved. Nothing today answers the second half: “How did this agent’s memory reach its current state — in what order, authorized by whom, with nothing skipped or rolled back — and can a third party verify that without seeing the memory itself?” That is the gap this draft addresses: memory state, version management, and behavioral trajectory as a first-class, verifiable object. The intuition: git for agent memory, minus the leaks Think of it as version control. Every memory update is a sequenced, signed commit; the chain holds an append-only history where each state cryptographically binds to its predecessor; “force-push” is structurally impossible. The difference from git: only 32-byte commitments ever go on chain — the memory content, embeddings, policies, salts, and storage locations stay off chain as a private witness. Committing a hash is not the novel part — ERC-8004, 7857, 8257, 8273, 8299 and EAS all commit opaque digests already. The missing piece is the rule connecting one commitment to the next. A flat anchor is a bag of hashes; a sequenced chain is an auditable trajectory. Concretely, enforcing sequence == current + 1 together with prevStateRoot == currentStateRoot is what lets a third party detect: an operator quietly rolling a Space back to an earlier memory state and replaying forward; two contradictory histories grown in parallel under one identity; a gap where transitions were dropped from the record; a relayer substituting the storage locator a signature was supposed to cover. None of these are distinguishable from normal operation under any existing flat-anchor scheme. That — not the hashing — is what this draft is for. Proposed minimal interface prevStateRoot + ExperienceDelta v1 → transitionId → authorized commit → nextStateRoot The normative struct is fixed-width, seven fields: struct ExperienceDelta { bytes32 spaceId; uint64 sequence; bytes32 prevStateRoot; bytes32 deltaCommitment; bytes32 provenanceCommitment; bytes32 profileId; bytes32 locatorCommitment; } transitionId = the EIP-712 hashStruct of the Delta (fixed type string; no JCS/CBOR/JSON alternative). nextStateRoot = keccak256(abi.encode(MEMORY_STATE_TYPEHASH, prevStateRoot, transitionId)), computed by the registry — callers cannot supply it. Acceptance requires sequence == current + 1 and prevStateRoot == currentStateRoot. spaceId = keccak256(abi.encode(MEMORY_SPACE_TYPEHASH, initialController, salt)), so a namespace claim is cryptographically specific to its initial controller. Permissions are a controller + authorizer pair with a per-space configNonce for rotation. Signatures cover every Delta field including locatorCommitment, so a relayer cannot substitute a locator. EIP-712 domain fixed to name=“AgentMemoryState”, version=“1”, current chainId, registry address. Authorization accepts EOAs, EIP-1271 contract accounts, and EIP-7702 delegated accounts. On the last point: validation must not branch on code.length alone, since a 7702-delegated EOA carries 0xef0100 || delegate code while many delegates implement no signature policy. The spec requires trying ERC-1271 first, then falling back to canonical ECDSA. Raw memory, salts, keys, and raw locators must never be supplied to the registry. Why not just EAS? Fair question, and the first one I would ask myself. EAS already offers refUID to link attestations, Private Data Attestations with Merkle multiproofs for selective disclosure, and resolver contracts for arbitrary custom validation. What EAS does not offer is successor uniqueness. In EAS.sol, the only check applied to refUID is that the referenced attestation exists. Multiple attestations may reference the same refUID, so at the protocol layer forking is permitted. There is no sequence number, no prior-state binding, and no per-namespace controller/authorizer model. You can certainly build these semantics with an EAS schema plus a custom resolver — but that is a per-application implementation, not an interoperable standard. This is the same reasoning ERC-8273 gave when it faced the identical question. Relationship to existing agent ERCs This area is crowded, so here is the boundary as I understand it. Corrections very welcome — especially from the authors of the proposals below. Proposal What it covers What is still missing ERC-8004 Trustless Agents Identity / Reputation / Validation registries Explicitly does not cover memory, persistent state, or cognition ERC-8181 Self-Sovereign Agent NFTs A State Anchor: anchor(tokenId, type, contentHash, contentUri) over off-chain cognitive state The anchor is flat — no prevStateRoot, no sequence, no unique-successor rule, and contentUri is an unsigned argument a relayer can swap ERC-8264 AI Agent Memory Access Rights Data-subject rights over memory records (read / write / delete / export), GDPR framing Rights over records, not the verifiable evolution of state between them ERC-8269 Body Lease / Capsule Packaging: a Merkle root over payload hashes within one capsule Integrity within a capsule, not a chain of transitions across time ERC-7857 (Final) AI Agents NFT with Private Metadata Ownership transfer with sealed keys and access proofs The moment of transfer, not the process of state evolution The intent is that this draft can be referenced by any of those without any of them taking a dependency on it. If the authors of 8181 / 8264 / 8269 think this belongs inside their proposals instead of alongside them, I would genuinely rather hear that now than after a number is assigned. Explicit non-claim A valid transition proves only that a configured authority approved a particular committed state transition. It does not prove truthfulness of the content, availability of off-chain data, ownership, or that a deletion occurred. I would rather state this loudly in the spec than let downstream applications infer guarantees that do not exist. Deliberately out of scope Agent identity, raw memory storage, data availability, retrieval, a universal memory taxonomy, inference verification, branching/merge rules, deletion claims, licensing, payment, and tokenization. Those may reference a Space, transition ID, or state root without becoming a dependency of the core. Links ERC-8337 draft: ERC-AWAR/erc/erc-8337.md at main · AwareLiquid/ERC-AWAR · GitHub Upstream PR: Add ERC: Agent Memory State Registry by everest-an · Pull Request #1910 · ethereum/ERCs · GitHub Whitepaper (rationale, applications, metadata layering): ERC-AWAR/docs/whitepaper.md at main · AwareLiquid/ERC-AWAR · GitHub Threat model: ERC-AWAR/docs/threat-model.md at main · AwareLiquid/ERC-AWAR · GitHub Cross-language golden vectors: ERC-AWAR/test-vectors/v1.json at main · AwareLiquid/ERC-AWAR · GitHub Repository (Solidity registry + two dependency-isolated TS implementations): GitHub - AwareLiquid/ERC-AWAR · GitHub Sepolia registry (live, reproduces the golden vector): 0xDdf21937ba80b5fF973610877A0955b320C91241 Canonical v1 typehashes, for anyone who wants to check their own implementation: ExperienceDelta: 0x4f020f86bc06d852f1fde17853b4d92a70214eeab8e09718028124af097d070d MemoryState: 0xf3148762556cbf851baf4b9a205e18ff4e6b366a58a3a1ef58e8626ba41beadb MemorySpace: 0x9ae5478f084ad3b841da58a9cb2354d153cddec59ee64d0cb741fa9d08884531 Open questions — feedback wanted Linearity. This draft enforces a strictly linear per-Space history, and I think that is the right base primitive: it is precisely what makes “no gap, no silent rollback, no contradictory parallel history” checkable by a third party. Concurrency belongs in multiple Spaces plus off-chain merge. Is there a concrete agent workload where that is the wrong call? Baseline commitments. Is a domain-separated salted keccak baseline an acceptable normative floor, with ZK schemes as opt-in profiles? Should the ERC mandate encryption for low-entropy payloads rather than merely a secret salt? EIP-1271 / EIP-7702 edge cases. Is “try 1271, then fall back to ECDSA” the right ordering? It lets a delegate policy apply when one exists, but since delegation does not revoke the key, the ECDSA path always remains. Should a registry be allowed to disable the fallback per Space? profileId governance. Should there be any registry-level convention for profile identifiers, or is fully application-defined the correct long-term stance? Note that an unsalted profileId drawn from a published vocabulary is effectively public — the draft now documents it as such. Deletion semantics. Is “attestation with a stated scope” the right framing, and should the core reference it normatively or stay silent? Discoverability layering. A Space is deliberately opaque, which makes it undiscoverable — including to a would-be licensee. Should minimal descriptive metadata live in an optional extension (the current approach), or does the core need a hook? Naming. Is “Agent Memory State” the right title, or should it lead with “Commitments” / “Registry” to set expectations about the non-claim above? Happy to adjust scope based on feedback — the editors have not merged yet, so changes are still cheap. Update Log 2026-07-24: Initial discussion thread opened. Draft at 1.0.0-alpha.1. 2026-07-26: Submitted upstream as ERC-8337 (ethereum/ERCs#1910); eipw and all CI checks passing. 2026-07-26: Sepolia deployment live — registry 0xDdf21937ba80b5fF973610877A0955b320C91241 returns all three typehashes byte-for-byte equal to test-vectors/v1.json. Verify: cast call 0xDdf21937ba80b5fF973610877A0955b320C91241 “EXPERIENCE_DELTA_TYPEHASH()(bytes32)” --rpc-url https://ethereum-sepolia-rpc.publicnode.com External Reviews None yet. Reviews from EIP-712 / EIP-1271 / EIP-7702, privacy, and agent-systems folks are especially welcome. Outstanding Issues 2026-07-24: Needs an independent second implementation maintained by another team passing the golden vectors. (The repo ships two implementations, but both are maintained here.) 2026-07-24: No public testnet deployment yet. Resolved 2026-07-26 — Sepolia registry 0xDdf21937ba80b5fF973610877A0955b320C91241 (see Update Log). 2026-07-24: External security audit pending. 2026-07-24: Author list and EIP champion to be confirmed. 2 posts - 2 participants Read full topic