Validator Client Integration

Containment Chamber implements the Web3Signer signing API, so any validator client that supports Web3Signer works out of the box. Point your client at the signer URL and you’re done.

Signer URL

Configure your validator client with the signer URL. Auth tokens are created with containment-chamber operator auth token create (see Auth Policies & Tokens for details).

# Stateless mode only (requires static_auth with an anonymous binding)
http://signer:9000

Note

Validator clients send auth tokens via the Authorization: Bearer <token> header when configured with authentication. Refer to your validator client’s documentation for auth header configuration.

Client Configuration

Each validator client has its own CLI flag for the remote signer URL. Pick your client below.

Lighthouse

lighthouse vc \
  --beacon-node http://beacon:5052 \
  --web3-signer-url http://signer:9000

Teku

teku vc \
  --beacon-node-api-endpoint=http://beacon:5052 \
  --validators-external-signer-url=http://signer:9000

Prysm

validator \
  --beacon-rpc-provider=beacon:4000 \
  --web3signer-url=http://signer:9000

Note

Prysm’s flag is --web3signer-url (no hyphen between “web3” and “signer”), unlike most other clients.

Lodestar

lodestar validator \
  --beaconNodes http://beacon:5052 \
  --externalSigner.url http://signer:9000

Nimbus

nimbus_validator_client \
  --beacon-node=http://beacon:5052 \
  --web3-signer-url=http://signer:9000

Key Loading

Validator clients don’t need local keystores when using a remote signer. Containment Chamber loads keys from its own keystore directories and exposes them through the /api/v1/eth2/publicKeys endpoint. Your validator client fetches the key list automatically.

If you need to add or remove keys at runtime, see the Key Manager API documentation.

Multi-Tenant Setups

Running multiple validator clients against a single Containment Chamber instance? Configure auth policies to give each client its own token with per-key and per-operation restrictions. This prevents one client from signing with another client’s keys.

Each client uses its own auth token (created with containment-chamber operator auth token create) to access only its authorized keys. Configure each client’s token via its native authentication mechanism (consult your validator client’s documentation for auth configuration options).

See the Auth Policies & Tokens guide for full configuration details.

Next Steps

• Auth Policies & Tokens — create policies and tokens for each validator client
• API Concepts — understand how scopes, keys, and operations are evaluated
• Docker Deployment — run the signer and connect clients via Docker Compose