Memory Runtime Keys

Memory is not a durable backend. It is a transient bucket 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.*`

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.

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 reported as not active for this delete path; persistent storage is never touched.

Auth shim

Bearer tokens are the canonical credential. HTTP Basic is accepted as a validator-client compatibility shim — see Access Control 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)

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 Memory

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.