Skip to content

BLS Key Custody Models

The default model for external operators is bring-your-own-BLS:

  1. Operator generates their own BLS keypair (never shared with foundation)
  2. Operator submits pubkey + deposit data to the foundation
  3. Foundation deploys vault (binds withdrawal credentials to vault address)
  4. Foundation validates deposit data pubkey + WC match the seat and vault
  5. Foundation allowlists and deposits 32 CTN
  6. Operator loads their BLS key into their own Validator Client

Key custody: Operator holds the BLS signing key. Foundation never touches it.

Kill switch: Treasury can force-exit the validator via triggerValidatorExit() (EIP-7002) without the BLS key. The vault's withdrawal credentials address can request exits through the system contract.

Slashing responsibility: Operator's fault domain. Foundation is protected by principal-first settlement.

Internal Only: Managed Keys (Foundation Validators)

The "Generate Keys" flow (POST /v1/seats/generate) is for foundation-managed validators only:

  1. Foundation generates BLS keypair from its own mnemonic
  2. Encrypted keystore saved to SeatBlsMaterial in PostgreSQL
  3. Vault deployed, seat created atomically
  4. Keystore delivered to the validator client operator

This flow should NOT be used for external operators. It creates key custody obligations for the foundation.

Critical data in PostgreSQL

Always present (all seats)

  • Seat-to-vault mappings, operator assignments, deposit data, audit trail
  • These are NOT recoverable from chain alone — back up PostgreSQL

Only for managed keys (internal flow)

  • SeatBlsMaterial.keystoreJson — encrypted BLS validator private keys
  • Recovery: mnemonic + index can regenerate the same keypair via deposit-cli
  • Database loss = signing key loss unless mnemonic is preserved separately

BYO-BLS seats

  • No BLS private material is stored. Operator holds their own key.
  • deposit_data_signature and deposit_data_root store the operator's submitted deposit data

Financial protection

Regardless of key custody model: - Principal-first settlement: If a validator's lifetime inflows fall below 32 CTN (e.g., due to slashing), the treasury recovers all available inflows up to the principal target; the beneficiary receives only the excess, if any - Running-phase principal protection: when vault balance reaches 32 CTN, Running-phase beneficiary claim flow is blocked (PrincipalProtectionActive) until settlement - 24h claim delay: below 32 CTN, Running-phase claims are still time-delayed; treasury can cancel pending claims by starting settlement - Force exit: Treasury can trigger validator exit via EIP-7002 without BLS key access