Skip to content

Add ERC: Body Lease and Credential Broker #1763

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
clavote-boop wants to merge 5 commits into
base: master
Choose a base branch
from
+128 −0
Open

Add ERC: Body Lease and Credential Broker #1763

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
d1584ec
Add ERC-8265: Portable Agent Memory Capsule and Body Lease
clavote-boop May 23, 2026
ea6fc6d
ERC-8265: point discussions-to at dedicated magicians thread
clavote-boop May 23, 2026
7ccd719
erc-8265: scope to Body Lease + Credential Broker; cite chain-agnosti…
clavote-boop May 23, 2026
32e2c59
erc-8265: clear remaining eipw lint
clavote-boop May 23, 2026
b74dcd3
erc-8265: link EIP-191 at first use; drop remaining unlinkable refs
clavote-boop May 23, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
128 changes: 128 additions & 0 deletions ERCS/erc-8265.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,128 @@
---
eip: 8265
Copy link
Copy Markdown
Contributor

@abcoathup abcoathup May 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
eip: 8265
eip: 8269

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

Please also update the filename.

title: Body Lease and Credential Broker
Copy link
Copy Markdown
Contributor

@abcoathup abcoathup May 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

description: Off-chain body-lease and credential-broker conventions for ERC-8264 agents, binding identity to revocable hardware bodies.
author: Clavote (@clavote-boop)
discussions-to: https://ethereum-magicians.org/t/erc-8265-portable-agent-memory-capsule-and-body-lease/28597
Copy link
Copy Markdown
Contributor

@abcoathup abcoathup May 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

status: Draft
type: Standards Track
category: ERC
created: 2026-05-22
requires: 8264
---

## Abstract

This ERC defines two composable layers built on [ERC-8264](./eip-8264.md) "AI Agent Memory Access Rights":

1. **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.
2. **Credential Broker** — a convention requiring agent memory exports to carry entitlement *descriptors* rather than raw credentials, so compromise of one body cannot propagate the subject's credentials to other bodies.

The two layers are independently usable. Portable memory *payload format* — manifest, Merkle commitment, canonicalization, and on-chain anchoring — is specified separately by the chain-agnostic CAAP-Capsule v0.1 specification (see Reference Implementation), which this ERC composes with but does not redefine.

## Motivation

AI agents that operate across hardware — a fleet that migrates between local machines, a robot that swaps physical bodies, an agent whose runtime is replaced — need a standard way to express "this body may operate as me, under these scopes, until this time." On-chain delegation primitives such as [EIP-7702](./eip-7702.md) and contemporaneous proposals in the agent-authorization space address related but distinct concerns (session keys, action-authorization lists). Neither defines the scope/expiry surface that an *off-chain* agent gateway needs to enforce per body.

Separately, naive memory exports embed credentials (API keys, wallet keys, OAuth tokens, macaroons) into the portable payload, which makes the payload itself a credential. This is the wrong shape: the subject should re-mint scoped credentials per body, not transport them. Without a standard convention, this distinction collapses.

Memory-export *format* is orthogonal to both concerns and is intentionally specified outside this ERC; see the chain-agnostic Capsule spec referenced below.

## Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

### 1. Body Lease

A Body Lease is a canonical-JSON object signed by a key authorized to act for the ERC-8264 subject:

```json
{
"lease_id": "...",
"subject": "0x...",
"body_id": "...",
"scopes": {
"read": ["L2_project", "L3_canonical"],
"write": ["L1_session", "proposal"],
"delete": [],
"export": []
},
"expires_at": "2026-06-22T00:00:00Z",
"requires_owner_cosign": ["canonical_write", "skill_install", "delete", "export",
"body_transfer", "wallet_action"],
"owner_signature": "0x..."
}
```

`subject` is the ERC-8264 subject address. `body_id` is an implementor-defined identifier of the host (hardware serial, runtime UUID, etc.). The signature MUST be [EIP-191](./eip-191.md) over the canonical JSON of the lease with `owner_signature` removed.

**Canonicalization.** JSON keys sorted lexicographically at every nesting level; no insignificant whitespace; UTF-8 encoding; numbers serialized without trailing zeros.

A gateway that accepts an ERC-8264 operation from a body MUST verify a valid, unexpired, in-scope lease before serving. The `scopes` enumeration is implementor-defined; this ERC RECOMMENDS the canonical layers `L1_session` (working memory), `L2_project` (project state), `L3_canonical` (durable preferences) as a minimum scope vocabulary.

Operations listed in `requires_owner_cosign` MUST require an additional owner signature beyond the lease, even if the lease's scopes would otherwise permit them.

**Revocation.** A lease is revoked by issuing a new manifest with the same `lease_id` and an `expires_at` in the past, or by gateway-side tombstoning. Revocation MUST be effective immediately for *subsequent* operations; in-flight operations are implementor-defined.

EIP-7702 (account-abstraction session-key delegation) MAY be used as a complementary *on-chain* primitive when the gateway is contract-based. The off-chain Body Lease and an on-chain EIP-7702 authorization MAY be issued from the same controller key, with the lease covering off-chain ERC-8264 operations and the EIP-7702 authorization covering on-chain calls.

### 2. Credential Broker

Memory exports — whether bundled as a CAAP-Capsule (see Reference Implementation) or in any other portable form — MUST NOT contain raw credentials (API keys, private keys, OAuth tokens, macaroons, NWC connection strings, or any analogous bearer material).

Memory exports MAY contain entitlement *descriptors*:

```json
{
"entitlement": "openrouter:budget_usd_per_month",
"value": 50,
"issuer_hint": "https://openrouter.ai",
"lease_id": "..."
}
```

An entitlement descriptor records *what* a body is entitled to do, not *how* to authenticate. When memory is mounted into a new body, the subject's controller MUST re-mint fresh, scoped credentials for the new body's lease through the appropriate issuer (an LLM provider, a payment hub, an OAuth server). Credentials issued under any prior body's lease MUST be revoked at lease end.

This rule is the *off-chain* analogue to on-chain action-authorization conventions. Issuer integration is out of scope; this ERC defines the convention, not the issuer protocols.

### Authorization Model

Authorization for `read`, `write`, `delete`, and `export` operations defers to [ERC-8264](./eip-8264.md). This ERC adds the Body Lease as a permissible authorization input alongside the subject-only and delegated-operator models that ERC-8264 enumerates: a gateway MAY treat a valid, in-scope Body Lease as authorization for the operations its scopes permit, except for operations listed in `requires_owner_cosign`.

## Rationale

**Why the Body Lease is off-chain.** Most agent operations — memory reads, write proposals, skill invocations — happen at the gateway, not on-chain. Requiring on-chain lease issuance imposes gas costs on every body migration and exposes operational identity to chain analysts. The Lease is owner-signed and gateway-verified, with optional on-chain anchoring or EIP-7702 binding when needed.

**Why payload format is out of scope.** The portability format used to *carry* memory across bodies (manifest, Merkle commitment, anchoring) is fundamentally chain-agnostic — a Capsule may be content-addressed without any chain, anchored to Bitcoin, Ethereum, IPFS, or any other commitment substrate. Embedding that format in an ERC would couple a chain-neutral concern to the Ethereum standards track. The chain-agnostic CAAP-Capsule v0.1 specification (see Reference Implementation) is the canonical format; this ERC references it as a transport but defines neither its bytes nor its anchoring.

**Relationship to [EIP-7702](./eip-7702.md).** EIP-7702 authorization-list semantics overlap the Body Lease at the on-chain layer. A controller MAY issue both: an EIP-7702 authorization for on-chain calls from a body's EOA, and a Body Lease for off-chain ERC-8264 operations. The `scopes` and `expires_at` fields are deliberately aligned with EIP-7702 authorization semantics to make joint issuance ergonomic.

**Relationship to MCP SEP-2072 and SEP-2342.** Anthropic's Model Context Protocol has draft Standards Enhancement Proposals defining portable memory wire formats at the MCP layer. This ERC is complementary: MCP defines the *interchange format and runtime protocol* between an agent and its memory store; this ERC defines the *body-lease and credential-broker surface* exposed via ERC-8264 to the agent's subject identity.

**Relationship to other agent-NFT and agent-authorization proposals.** Companion proposals in the agent-NFT family (AI agent NFTs with private metadata, self-sovereign agent NFTs, on-chain agent action-authorization with time- and usage-bounded delegation) are complementary to the surfaces defined here. The Body Lease is subject-initiated and off-chain; an agent NFT MAY be the controller of an ERC-8264 subject and the issuer of its Body Leases. The Credential Broker rule is the off-chain analogue of on-chain action-authorization and does not duplicate that surface.

## Backwards Compatibility

This ERC is additive. ERC-8264 implementations that do not adopt this ERC continue to operate. This ERC's Body Lease is opt-in for any subject.

## Reference Implementation

A CC0 reference implementation is published at github.com/clavote-boop/rmem-gateway . The Body Lease primitive is implemented in `rmem-lease.py`; ERC-8264 gateway operations honoring leases are implemented in `rmem-gateway.py`. The Credential Broker convention is enforced at the gateway's export path (`rmem-migrate.py`'s freeze command rejects raw credential fields).

The portable memory capsule format that an ERC-8264 `exportMemory` MAY return — referenced by §1 and §2 above — is specified by the chain-agnostic CAAP-Capsule v0.1 document published at github.com/clavote-boop/rmem-gateway under `standards/capsule-spec-v0.1.md`. CC0.

## Security Considerations

**Body-lease replay.** Body Leases SHOULD include a `nonce` field (this ERC RECOMMENDS but does not require) to prevent reuse of a signed lease beyond its single intended issuance. Lease verification MUST reject leases whose `expires_at` is in the past.

**Body-lease revocation lag.** Revocation effective time is gateway-local. If a lease is shared across gateway replicas (e.g. mirrored installations), the revocation MUST propagate before operations on the revoking lease are considered terminated. Implementors with multi-gateway deployments SHOULD adopt a revocation log with strict ordering.

**Body-lease scope escalation.** A gateway honoring a Body Lease MUST NOT extend the lease's scopes implicitly. Operations not listed in the lease's `scopes` map require either a fresh lease or an inline owner signature; operations in `requires_owner_cosign` require both.

**Credential-broker race.** Re-minting of body credentials on lease issuance, and revocation of credentials on lease expiry, occur out-of-band relative to the lease itself. A gateway honoring the Broker rule MUST refuse to issue an entitlement-backed credential until it has received a valid lease, and MUST revoke that credential when the lease ends.

**Cross-body credential propagation.** Even with the Broker rule, a compromised body that retains issued credentials past lease end becomes a vector for cross-body propagation. The gateway and the issuer MUST treat lease expiry as the *latest* revocation deadline, not the earliest; eager revocation on lease tombstoning is RECOMMENDED.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Loading