Questions operators ask before they switch signers.

Before restaking, a validator key faced one slashing surface: the consensus layer of the chain it validated. Restaking and EigenLayer-style AVS opt the same staked capital — and increasingly the same keys — into multiple independent slashing regimes at once, each with conditions defined by code the operator did not write. That multiplies the ways a single key can lose stake, which makes the boundary between what requested a signature and what actually gets signed the most valuable control point a staking operation has. A firewall in front of the keys that refuses rule violations before the key is touched stops being optional.

No — and we are explicit about that. nklave enforces protocol-level slashing prevention (EIP-3076 and equivalents), which is where the overwhelming majority of real-world slashing incidents come from: double proposals, double votes, surround votes on Ethereum, and (height, round) double-signing on CometBFT. AVS-specific slashing conditions are defined per service and are not built in. What nklave provides is the first-class policy layer where operators express additional guardrails, and the enforcement model that holds those decisions before the key is reached. See the roadmap for restaking-aware policy direction.

Built-in protection lives inside the same process that signs — if that process is compromised, the protection can be bypassed. nklave moves the check to a separate trust boundary in front of the keys. A refused request never reaches the keystore or HSM, so enforcement holds even when the validator host is fully compromised.

Yes. nklave implements the Web3Signer HTTP signing protocol, so anywhere you point a validator client at a Web3Signer URL, you can point it at nklave instead. Migrate your slashing history with the standard EIP-3076 interchange file and switch the signer URL.

Four built-in policies: attestation slashing protection (double-vote and surround-vote), block slashing protection (double proposal, and (height, round) for Cosmos), a fork-version allowlist, and a per-validator rate limit. Every request resolves to an explicit Allow or Refuse(code) before the key is consulted; a refusal never reaches the keystore or HSM.

Policy is a first-class layer in nklave, not a config afterthought: every request resolves to an explicit Allow or Refuse(code) in nklave-core::policy before the key is consulted, and that is where additional operator guardrails belong. Today the built-in policies cover EIP-3076 slashing protection, a fork-version allowlist, and a per-validator rate limit; the layer is designed to carry more as restaking pushes heterogeneous constraints onto the same keys. See the roadmap for where restaking-aware policy work is headed.

In dedicated custody of your choice: a local keystore for dev/single-host, or a YubiHSM 2, AWS CloudHSM, or GCP KMS for production. nklave never reads the key material — it only requests signatures, and only for requests the policy chain allowed.

Every decision is appended to a newline-delimited JSON log. Every 60 seconds the log is sealed into a Merkle-root checkpoint signed by a separate operator key. Running nklave log verify --from 0 --to latest re-walks every checkpoint, recomputes each Merkle root, and confirms the operator-key signatures — a non-zero exit means the log was edited.

Ethereum consensus (BLS) with Lighthouse, Teku, Prysm, and Lodestar via the Web3Signer protocol, and Cosmos / CometBFT (Ed25519). Slashing rules apply per (source, target) epoch for attestations, per slot for blocks, and per (height, round) for CometBFT.

The recommended HA pattern is two nklave instances sharing a Postgres slashing-protection DB, serialized by row-level locks so exactly one signature can be produced per slashable decision. RocksDB is the default single-host backend; Postgres unlocks leader/follower HA.