Add ERC: Body Lease and Credential Broker

[clavote-boop]

Note on discussions-to: temporarily pointed at the ERC-8264 magicians thread; a dedicated thread for this ERC will be created and the frontmatter updated in a follow-up commit before merge.

This PR proposes a companion standard to ERC-8264 "AI Agent Memory Access Rights". ERC-8264 defines a four-function rights interface (readMemory / writeMemory / deleteMemory / exportMemory) but explicitly leaves exportMemory's returned payload implementor-defined. This proposal fills that gap with three composable layers:

1. Capsule — a canonical, owner-signed, encrypted-payload bundle format that exportMemory(subject) returns and that a different implementor's gateway can import for the same subject.
2. Body Lease — a signed, scoped, expiring binding between an ERC-8264 subject and a body (a hardware or runtime substrate), enabling agent identity to persist across hardware while keeping the body revocable.
3. Credential Broker — a convention requiring capsules carry entitlement descriptors rather than raw credentials, so compromise of one body cannot propagate credentials to other bodies.

The three layers are independently usable. The narrowest viable subset is Capsule alone.

requires: 8264. CC0.

Why now

Three problems autonomous AI agents face that no single standard addresses today:

• Hardware ≠ identity (a robot's body can fail, get replaced, or be one of several substrates the same agent runs on).
• Memory must be portable AND auditable.
• Autonomous credentials must be scoped to a body, not transported with the memory.

Without a common capsule format, exports from one ERC-8264 implementation cannot be imported by another, undermining the GDPR-Article-20-style portability ERC-8264 was motivated by. Without a Body Lease, agent body migration has no standard handoff. Without the Broker convention, naive capsules embed credentials and the payload becomes a credential.

Composition with existing standards (Rationale section)

The proposal explicitly composes with — rather than competes with — five existing or in-flight standards. Each composition is named in the Rationale section to pre-empt reviewer objections:

• MCP SEP-2072 "Memory Portals" + SEP-2342 MIF — these define the interchange wire format at the MCP protocol layer; this ERC defines the rights and authorization surface on EVM. Complementary, different layer.
• ERC-7857 (Final) "AI Agent NFT w/ Private Metadata" — NFT-coupled and transfer-bound. Capsule is subject-initiated and not NFT-coupled.
• ERC-8181 (PR #1579) "Self-Sovereign Agent NFTs" — closest semantic neighbor; cite as a composition target, not a competitor.
• EIP-7702 (Final) session-key authorization — Body Lease scope/expiry semantics deliberately align with EIP-7702 authorization-list semantics for joint issuance.
• ERC-8118 (PR #1450) "Agent Authorization" — on-chain action authorization. Credential Broker is the off-chain analogue; explicit disclaimer in Rationale.

The Rationale section also addresses subject ↔ Soul-ID interoperability for implementations whose canonical agent identifier is non-EVM-rooted (e.g., a did:btc:<pubkey> identifier): same secp256k1 keypair, two chain encodings.

Reference implementation

A complete CC0 reference implementation has been live-verified on a Bitcoin chain:

• Off-chain vault (encrypted SQLite + hash-chained audit log) — implements the storage layer for readMemory / writeMemory / deleteMemory
• ERC-8264 gateway — EIP-191 owner-signature verification on all four ops; exportMemory produces a Capsule per §1 (owner-signed manifest, Merkle root, ciphertext payload files); supports Body Lease auth per §2
• Body Lease module — issuance, signature verification, scope/cosign logic, revocation
• Migration CLI — freeze / verify-capsule / mount-with-re-encryption (body-to-body transfer)
• Bitcoin OP_RETURN anchoring module — commits Capsule Merkle roots via a single 38-byte payload (4-byte magic CAAP + 1-byte version + 1-byte commit-type + 32-byte root)

Live anchor on Bitcoin mutinynet, 2026-05-22:
224958929c193488e639715d278d98bd82b742b579a110a6b8309ce903969f0a
— verified by independently re-fetching the tx, extracting the OP_RETURN payload, and matching the committed Merkle root.

Public reference impl URL: (will be added once the implementation repo is published from the private repo — currently maintained at clavote-research)

Backwards compatibility

Additive only. ERC-8264 implementations that do not adopt this ERC continue to operate; their exportMemory returns remain implementor-defined. This ERC's Capsule format is opt-in for any subject.

Test cases

Reference implementation ships a selftest subcommand on every module. Coverage includes:

• Capsule manifest signing + Merkle-root recomputation + tamper detection (modified payload bytes; forged signature)
• Body Lease lifecycle: issue, verify, scope-check, body-signed request, revoke, wrong-key revoke denied, tampered-expiry detection
• Gateway lease-auth path: valid body action authorized, wrong body sig rejected, lease_id binding enforced, scope/cosign refusal for ops requiring owner cosign
• Migration: capsule verify, mount-with-re-encryption (old key cannot decrypt mounted records), second-mount-to-existing-target denied
• OP_RETURN anchoring: build, sign, parse-back, OP_RETURN extraction, payload round-trip, CAAP magic / version / type validation

Discussion

discussions-to: (eth-magicians thread to be created at submission; URL added to frontmatter before merge)

Reviewer requests

cc @g11tech @jochem-brouwer @SamWilsn @xinbenlv — same reviewer set as ERC-8264 PR #1752, since the standards are designed to compose.

Author

clavote-boop. CC0.

[eip-review-bot]

File ERCS/erc-8265.md

Requires 1 more reviewers from @g11tech, @jochem-brouwer, @samwilsn, @xinbenlv

[clavote-boop]

Restructure: scope reduced to Body Lease + Credential Broker; portable Capsule format moved out

Addressing the first of the four open questions from the discussion thread ("should the three sections be bundled or split?") — 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 in this push:

• This ERC is now scoped to two EVM-native surfaces: Body Lease (signed scope/expiry binding of an ERC-8264 subject to a body) and 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; what the reference implementation uses) and 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 listed as intended future shape.
  • RFC 8785 JSON Canonicalization Scheme (tightened from "implementor-defined" canonicalization).
• The slim ERC cites the capsule spec by URL in a new References section. ERC-8265's Credential Broker rule explicitly governs any memory export, including a CAAP-Capsule.
• description trimmed under 140 chars (clears the previous eipw lint).
• Capsule-specific Security Considerations (confidentiality, manifest replay, anchor finality, metadata side channels) move to the capsule spec where they belong.

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

Net effect: tighter ERC, less reviewer surface area, and the multi-chain Capsule lineage lives where it actually makes sense.

cc @g11tech @jochem-brouwer @SamWilsn @xinbenlv — gentle re-ping for the outstanding reviewer slot now that scope is cleaner.

[github-actions]

The commit b74dcd3 (as a parent of 7c53bd5) contains errors.
Please inspect the Run Summary for details.

[abcoathup]

Suggested change

	eip: 8265
	eip: 8269

Assigning next sequential EIP/ERC/RIP number.
Numbers are assigned by editors & associates.

Please also update the filename.

[abcoathup]

Note: I am NOT an editor.
Would be great is there was a more descriptive title (within 44 character limit)

[abcoathup]

Suggested change

	discussions-to: https://ethereum-magicians.org/t/erc-8265-portable-agent-memory-capsule-and-body-lease/28597
	discussions-to: https://ethereum-magicians.org/t/erc-8269-body-lease-and-credential-broker/28597

Updated Eth Magicians title with assigned number & ERC title