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 via the /api/v1/auth/ API (see Signing Authorization for details).

# No auth (unauthenticated_policy must be configured)
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 signing authorization 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 via the /api/v1/auth/tokens API) 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 Signing Authorization guide for full configuration details.