ERC-8265: Portable Agent Memory Capsule and Body Lease

ERCs
1

This is a companion proposal to ERC-8264 “AI Agent Memory Access Rights”. ERC-8264 defines a four-function rights interface (readMemory / writeMemory / deleteMemory / exportMemory) but explicitly leaves what exportMemory returns as implementor-defined. This proposal fills that gap.

Three layers, independently usable:

  1. Capsule — canonical, owner-signed, encrypted-payload bundle that exportMemory returns. JSON manifest with a Merkle root over payload hashes; ciphertext-only on disk. Different implementors can import each other’s capsules for the same subject.
  2. Body Lease — signed, scoped, expiring binding between an ERC-8264 subject and a body (a hardware/runtime substrate). Lets an agent identity persist across hardware while keeping the body revocable. Off-chain, owner-signed; composes with EIP-7702 for joint on-chain delegation when needed.
  3. Credential Broker — convention requiring capsules carry entitlement descriptors rather than raw credentials. New body presents lease; owner re-mints scoped credentials per body. Compromise of one body cannot propagate credentials to others.

Narrowest viable subset is Capsule alone.

License: CC0. PR: Add ERC: Portable Agent Memory Capsule and Body Lease by clavote-boop · Pull Request #1763 · ethereum/ERCs · GitHub · Reference implementation: GitHub - clavote-boop/rmem-gateway: Reference implementation of ERC-8264 (AI Agent Memory Access Rights) and the companion Portable Agent Memory Capsule + Body Lease draft. Includes CAAP-ROBOTID v1.1 identity module. CC0. · GitHub

How it composes

Additive, not competitive. The Rationale section explicitly addresses adjacent work:

  • ERC-8181 Self-Sovereign Agent NFTs (Draft, PR #1579) — semantically closest. An 8181 NFT can be the container/sovereignty layer; 8264 + this Capsule are the rights and wire-format layer. They compose: an 8181 NFT MAY be the controller of an 8264 subject and reference a Capsule by its Merkle root.
  • ERC-7857 AI Agent NFT w/ Private Metadata (Final) — NFT-coupled, transfer-bound re-encryption. Different surface.
  • EIP-7702 (Final) — Body Lease scope/expiry fields aligned with 7702 authorization-list semantics for joint issuance.
  • ERC-8118 Agent Authorization (PR #1450) — on-chain action authz. Credential Broker is the off-chain analogue; explicit disclaimer in Rationale.
  • MCP SEP-2072 “Memory Portals” + SEP-2342 MIF — Anthropic’s drafts at the MCP protocol layer. This ERC is the rights and authorization surface on EVM; MCP defines the wire format between an agent and its memory store. Complementary; an implementor MAY use MIF as the payload format inside a Capsule.

Reference implementation

CC0, all selftest-green, live-verified on a Bitcoin chain (mutinynet) 2026-05-22.
Live anchor: 224958929c…969f0a.

Feedback welcome on

  1. The split into three sections. Is the bundling load-bearing, or would Capsule / Lease / Broker work better as three separate ERCs?
  2. The canonical JSON serialization rule (sort_keys, no whitespace, UTF-8). Adequate, or should I move to JCS (RFC 8785)?
  3. The OP_RETURN payload format for the optional anchor — currently 38 bytes (CAAP magic + 1B version + 1B type + 32B root). Reasonable?
  4. Any active proposal I missed in the composition map.

Author: @clavote-boop — same author as ERC-8264.

2

Restructure: scope reduced to Body Lease + Credential Broker; portable Capsule format moved to a chain-agnostic spec

Answering my own §Q1 — “should this stay bundled or split into separate ERCs?” — and a composition concern I want to surface proactively.

The original §1 Capsule defined a manifest, canonical JSON serialization, Merkle commitment, and Bitcoin OP_RETURN anchoring. That surface is fundamentally chain-agnostic: a Capsule can be content-addressed without any chain, anchored to Bitcoin, Ethereum, IPFS, or any other commitment substrate. Specifying it inside an ERC couples a chain-neutral concern to the Ethereum standards track.

What changed (pushed to PR #1763 just now):

  • The ERC is now scoped to two EVM-native surfaces only:
    • Body Lease — signed scope/expiry binding of an ERC-8264 subject to a body
    • Credential Broker — no raw credentials in any memory export
    • Both requires: 8264; both EIP-191 signed.
  • Capsule format is now a standalone chain-agnostic specification, published at https://github.com/clavote-boop/rmem-gateway/blob/main/standards/capsule-spec-v0.1.md. It defines:
    • An opaque subject_id with a subject_id_method registry (eth-address, did:btc, did:key, did:web, urn)
    • A signature-suite registry (eip-191 default; bip-322-legacy for Bitcoin-rooted controllers)
    • An anchor registry (caap-btc-opreturn-v1 registered today; eth-event-log-v1, ipfs-cidv1-raw, arweave-tx-v1 as intended future shape)
    • RFC 8785 JSON Canonicalization Scheme (tightened from “implementor-defined”)
  • The slim ERC cites the capsule spec by URL; ERC-8265’s Credential Broker rule explicitly governs any memory export, including a CAAP-Capsule.

No reference-implementation changes — eip-191 is the registered default suite and caap-btc-opreturn-v1 is the existing anchor format, so clavote-boop/rmem-gateway stays compliant with both the slim ERC and the chain-agnostic capsule spec as-is.

Open to feedback on:

  1. Whether the chain-agnostic capsule spec belongs at CAIP (Chain Agnostic Improvement Proposals) rather than as a standalone document — keeping it standalone for now so the registry framing isn’t blocked on cross-org coordination, but CAIP submission is an open option.
  2. The subject_id_method registry — particularly whether did:btc should reference a specific BIP/draft rather than be method-string-defined.
  3. Whether the signature-suite registry should be wire-versioned independently of capsule_version.

Original §Q2 (canonicalization vs RFC 8785) is now resolved in favor of RFC 8785 in the capsule spec. §Q3 (OP_RETURN payload format) is now in the anchor registry as caap-btc-opreturn-v1. §Q4 (overlooked related proposals) remains open.

1 Like