Ephemeral Memory Keys

Memory is not a durable backend. It is an ephemeral key source for keys that arrive at runtime via HTTP and are never persisted. Memory keys are immediately available for signing, but they vanish on restart.

Two HTTP import paths produce Memory-source keys:

Surface	Endpoint	Audience	Backed by
Key Manager API	POST /eth/v1/keystores	Validator-client-facing (Ethereum Key Manager API spec)	http.key_manager_api.*
Chamber Key API memory mode	POST /api/v1/chamber/keys with storage.persist=false	Operator-facing	chamber.keys.import.*

Never persisted

Memory keys are stored only in the signer’s in-memory DashMap. A restart loses every Memory-source key. If you need persistence, use Filesystem or DynamoDB.

Why two surfaces produce the same source

The two surfaces exist for different audiences:

• The Key Manager API implements the Ethereum Key Manager API spec so existing validator-client tooling (lighthouse vm keymanager, Teku migration scripts, etc.) works unchanged
• The Chamber Key API memory mode is the operator-facing path that uses the same handler family as persistent imports — same request shape, same error semantics, same per-key result objects

Both call into the same KeyStore::insert with KeySource::Memory, both register the key for signing immediately, both report InsertOutcome::Duplicate on pubkey collision.

Memory keys do not have an inactive state. Chamber imports with storage.persist=false must either omit storage.status or set it to active; storage.persist=false with storage.status=inactive is rejected because there is no persistent row to mark inactive.

Key Manager API (/eth/v1/keystores)

Three endpoints under tag: keymanager:

Method	Path	Scope	Body
GET	/eth/v1/keystores	list_keys	—
POST	/eth/v1/keystores	import_keystores	{ keystores: [...], passwords: [...], slashing_protection?: ... }
DELETE	/eth/v1/keystores	delete_keys	{ pubkeys: [...] }

Enabling

http:
  key_manager_api:
    enabled: true
    max_concurrent_reads: 50
    max_concurrent_writes: 10
    request_timeout_seconds: 30
    max_items_per_request: 100

For every option, see the Configuration Reference.

Import semantics

The handler decrypts each EIP-2335 keystore and inserts the key into memory. Per-key results in the response:

Status	Meaning
imported	Newly added to memory
duplicate	A key with this pubkey was already loaded (from any source); the original is preserved
error	Per-key decryption or validation failure; other keys in the batch still apply

Delete semantics

Only memory keys can be deleted via this API. Filesystem and DynamoDB keys are returned as per-key errors because they were not created by the Key Manager API; persistent storage is never touched.

Auth shim

Bearer tokens are the canonical credential. HTTP Basic is accepted as a validator-client compatibility shim — see Auth Policies & Tokens for the contract.

Chamber Key API memory mode

The same Chamber import endpoint accepts storage.persist=false to land keys in memory instead of DynamoDB. Use this path when your tooling already speaks the Chamber API or when you need to import raw hex keys. Request schemas are in the API Reference.

Why this exists alongside the Key Manager API:

• Accepts raw hex keys, not just EIP-2335 keystores (Key Manager API only takes keystores)
• Same request/response shape as the persistent import path — convenient for tooling that already speaks the Chamber API
• Gated by chamber.keys.import.enabled (separate from http.key_manager_api.enabled)
• Requires storage.persist=false for memory-only imports; omitting storage defaults to persist=true

See Chamber Key API → Key Management for the full surface, including persistent imports (persist=true), generate, list, patch, and delete.

Collision behaviour

When the same pubkey arrives from multiple sources, first loaded wins:

• Boot-time backends (Filesystem, DynamoDB) load in registration order, so a filesystem-supplied key shadows the same pubkey from DynamoDB
• Runtime imports against an already-loaded pubkey are reported back to the caller as duplicate (HTTP 200 with per-key status); the original entry is untouched

This applies regardless of which surface the new write came in on.

When to use ephemeral memory keys

• Testing or short-lived validators on a single instance
• Raw hex keys that the EIP-2335 keystore format cannot represent (use Chamber memory mode)
• Validator clients that drive their own ephemeral lifecycle via the Key Manager API spec

For any production deployment that should survive a restart, use DynamoDB or Filesystem.

Next Steps

• Key Manager API — the HTTP surface that drives memory-mode imports
• Chamber Key API — generate, list, patch, and delete keys via HTTP
• Auth Policies & Tokens — restrict which clients can import or sign with keys