Publishing a plain content hash does not tell anyone which state it advances, whether it is the rightful next step, or who was authorized to approve it. The proposal addresses that gap by committing to a private delta, an optional provenance reference, an interpretation profile and an optional private locator, while leaving the registry itself agnostic to whatever memory engine sits underneath.
ExperienceDelta and State Transition Mechanics
Each change to an agent’s memory is packaged into a struct called ExperienceDelta, containing fields such as spaceId, sequence, prevStateRoot, deltaCommitment, provenanceCommitment, profileId and locatorCommitment. That struct gets its own unique identifier, the Transition ID, calculated as an EIP-712 struct hash.
Continuity is enforced mathematically. A registry must only accept a transition if its sequence number equals the current sequence plus one, and if its prevStateRoot matches the registry’s current state root. The next state root is then produced by hashing together the previous root and the new Transition ID, which, per the rationale section of the spec, prevents an update from claiming an unrelated prior memory state the way a simple pointer to a previous record could.
Authorization Model and Signature Validation
Every memory space carries a controller and a replaceable authorizer. Both roles can be filled by ordinary externally owned accounts or by smart-contract accounts following ERC-1271. The controller handles administrative recovery, while the authorizer approves day-to-day transitions and can be a hot wallet, a multisignature setup or a policy contract.
All signatures for registration, authorization updates and transitions must use an EIP-712 signing domain tied to the registry’s chain ID and contract address, which stops a signature from being replayed on another chain or another deployment. When an account has deployed code, the registry checks the signature through ERC-1271 first; if that check fails, reverts, or the account has no code, it falls back to standard ECDSA signature recovery.
Privacy Considerations and Registry Limitations
The specification is explicit that raw memory, salts, encryption keys and raw locators must never reach the registry through the ExperienceDelta struct or any other required argument. Only commitments to that data are stored on-chain, which is meant to keep sensitive agent data out of public view entirely.
That design comes with a stated limit: a valid commitment proves only that the configured authorizer approved a state transition. It does not prove the committed memory was actually available, or that its contents were true. Applications that need those guarantees have to build separate verification on top of the registry.
Contract Immutability and Security Requirements
The proposal treats immutability as a security precondition rather than a preference. A conforming registry must not sit behind an upgrade mechanism capable of replacing the logic that enforces sequence linearity, state root chaining or signature validation, and it must expose no upgrade authority over that logic at all.
The authors warn that an upgradeable version of the contract could still reproduce every test vector in the specification while accepting a transition that violates the sequence rule.
Reference Implementation and Test Vectors
A reference implementation already exists as a Solidity contract, AgentMemoryStateRegistry.sol, which implements the IAgentMemoryState interface described in the proposal. According to the specification, this contract reproduces the canonical v1 test vector published alongside the draft, including matching typehashes for ExperienceDelta, MemoryState and MemorySpace.
Article produced with the assistance of artificial intelligence and reviewed by the editorial team.
