Agent Memory State

Hi all — opening a discussion thread for a draft ERC on authorized, ordered, private state transitions for autonomous-agent memory . Status: pre-ERC community draft. No number requested yet; the repo uses ERC-XXXX and does not squat a number. What this is — and what it is not I believe that the memory state and behavioral records of future agents need to be preserved. Once an agent becomes an active user of Web3, we don’t know what it did or thought beyond its transactions and identity. ERC-8004 solved identity and on-chain reputation; the remaining records need a new standard. Memory state, version management, and behavior are crucial. Each agent carries three kinds of memory during operation: what it thought at runtime, the reasoning process behind it, and what it thought collectively with other agents. What actions the agent took — and what impact those actions had — need to be recorded as verifiable commitments, selectively disclosable for audit, rather than as public metadata . This enables real version management and investigation. To be precise about the boundary: the chain never stores or manages the latent-space vectors themselves — it manages the verifiable history of how that latent state evolved. The vectors stay private; the trajectory becomes provable. Let me start by ruling out the obvious reading. The novelty here is not “commit a hash instead of the data.” That is already standard practice in this ecosystem: ERC-8004, ERC-7857, ERC-8257, ERC-8273, ERC-8299 and EAS all commit opaque digests. If that were the pitch, there would be nothing to discuss. The gap this draft addresses is one level up: Anchoring is well covered. What is missing is a rule for how anchors must connect to one another. An agent can already publish a commitment to its memory state. What nothing establishes today is that the new commitment is the unique successor of the previous one, that no state was skipped or quietly rolled back, or that the off-chain reference it points at was actually covered by the signature. Absent those rules, a memory history is a bag of hashes — not 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 from there; 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. A flat anchor cannot distinguish any of these from normal operation. That — not the hashing — is what this draft is for. Problem Agent systems increasingly keep long-lived memory (preferences, distilled skills, knowledge, policies, embeddings) in private databases, while using Ethereum for identity, payment, or execution. Publishing an opaque content hash is easy; what a hash alone does not establish is: which state it advances; whether the transition is the unique successor of the current state; who controls the namespace and who may authorize updates; whether all externally meaningful references (e.g. storage locators) were signed; or whether independent implementations derive the same identifier. Meanwhile, publishing raw prompts, embeddings, preferences, policies, or latent state on chain is incompatible with privacy and usually uneconomical — so the state machine has to work over commitments rather than contents. 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 draft: ERC-AWAR/erc/erc-xxxx-agent-memory-state.md at main · AwareLiquid/ERC-AWAR · 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 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 before requesting a number. Update Log 2026-07-24: Initial discussion thread opened. Draft at 1.0.0-alpha.1 . 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. 2026-07-24: External security audit pending. 2026-07-24: Author list and EIP champion to be confirmed. 1 post - 1 participant Read full topic