Quick Start

Get signing in under 5 minutes. This guide walks you through creating a minimal configuration, loading keys, and connecting to a validator client.

This quick start uses stateless Web3Signer-compatible mode: no signer_state, filesystem-loaded keys, and direct compatibility with validator clients that already support Web3Signer.

Step 1 — Create a config file

Create a config.yaml with the minimal stateless settings needed to run:

server:
  listen_address: "0.0.0.0"
  listen_port: 9000

key_sources:
  filesystem:
    paths:
      - ./keystores

anti_slashing:
  backend: sqlite
  path: ./slashing_protection.sqlite

static_auth:
  policies:
    - name: anonymous
      rules:
        # Allow signing and key discovery, but never voluntary exits.
        - effect: allow
          scopes: [sign, public_keys]
        - effect: deny
          operations: [VOLUNTARY_EXIT]
  anonymous:
    policies: [anonymous]

Tip

SQLite is perfect for development and single-instance deployments. For production with multiple signer instances, use PostgreSQL — see the Anti-Slashing guide for details.

Caution

This config has an anti-slashing database and a fixed anonymous policy, but it does not have a signer state backend. Runtime auth policies/tokens and /api/v1/chamber/keys/generate are state-backed features; add signer_state before using the Auth API, and add key_sources.dynamodb before using chamber key generation. The EIP-3076 Key Manager API can still hot-load keys in memory, but those memory keys are lost on restart.

Step 2 — Add a keystore

Create the keystores directory and add your validator keys:

mkdir -p ./keystores

Place your key files in this directory. Containment Chamber supports multiple formats:

• Raw hex — plain private key files
• EIP-2335 keystores — PBKDF2 or Scrypt encrypted JSON keystores

See Filesystem Keystores for the descriptor format, directory structure, and password-file convention.

Step 3 — Start the signer

Launch Containment Chamber with your config file:

containment-chamber server -c config.yaml

You should see startup logs indicating the server is listening on port 9000 and your keys have been loaded.

Step 4 — Verify it’s running

Check the health endpoint and list loaded keys:

# Health check
curl http://localhost:9000/upcheck
# Expected: 200 OK

# List loaded validator public keys
curl http://localhost:9000/api/v1/eth2/publicKeys
# Expected: JSON array of loaded keys

Step 5 — Connect to Lighthouse

Point your validator client at the signer. Here’s an example with Lighthouse:

lighthouse vc \
  --beacon-node http://localhost:5052 \
  --validators-dir ./validators \
  --web3-signer-url http://localhost:9000

Tip

Containment Chamber is a drop-in replacement for Web3Signer. Any validator client that supports Web3Signer works the same way — including Teku, Prysm, Lodestar, and Nimbus.

Next steps

• Docker deployment — run with Docker or Docker Compose
• Anti-Slashing — configure PostgreSQL for multi-instance protection
• Signer State Backend — enable state-backed auth policies, tokens, and chamber control-plane state
• Auth Policies & Tokens — set up per-key, per-operation access control after configuring signer_state
• Chamber Key Management — generate or persist keys with a DynamoDB key source
• API Concepts — understand how requests flow and how scopes work
• Configuration reference — full list of options, env vars, and CLI flags