What you get
A hardened trust boundary, in one small Rust binary.
nklave is the simplest correct thing between your validator client and your keys. Every feature exists to make slashable signing impossible by construction — and to prove it after the fact.
Enforce before the key is touched
nklave sits between the validator client and the signing keys. The policy chain evaluates every request first; a refused request never reaches the keystore or HSM. Slashable signing is impossible by construction, even if the host is compromised.
EIP-3076 slashing protection
Built-in double-vote and surround-vote detection for attestations, and double-proposal detection for blocks (and (height, round) for Cosmos/CometBFT). Import and export the standard EIP-3076 interchange format.
First-class policy engine
Slashing rules live in a dedicated policy layer (nklave-core::policy) that resolves every request to an explicit Allow or Refuse(code) before the key is consulted. Alongside EIP-3076 protection, the fork-version allowlist and per-validator rate limit ship built in. As restaking pushes more signing constraints onto the same keys, this is the extension point that matters — enforcement, not a config afterthought.
Tamper-evident append-only log
Every allow/refuse decision lands in a newline-delimited JSON log, sealed into Merkle-root checkpoints every 60 seconds and signed by a separate operator key. nklave log verify re-walks the chain and exits non-zero if anything was edited.
Web3Signer-compatible
nklave implements the Web3Signer HTTP signing protocol, so any validator client that supports a remote signer URL — Lighthouse, Teku, Prysm, Lodestar — works with a single URL change.
Multi-chain, multi-custody
Ethereum (BLS) and Cosmos / CometBFT (Ed25519) from one signer. Keys live in a local keystore, YubiHSM 2, AWS CloudHSM, or GCP KMS — nklave only requests signatures for requests the policy chain allowed.
See how it fits into your stack.
Read the architecture, or see who runs nklave and why.