A signing security layer, built for operators who can't afford to be wrong twice.

What nklave actually is

nklave is the policy-enforcing trust boundary between a validator client and signing keys. It speaks the Web3Signer HTTP signing protocol, so any validator client that supports a remote signer URL — Lighthouse, Teku, Prysm, Lodestar — can use it as a drop-in.

The codebase is organized as a small set of Rust crates:

• nklave-core — signing logic, BLS / Ed25519 key handling, slashing-protection rules
• nklave-api — Web3Signer-compatible HTTP API with an embedded Vue.js dashboard
• nklave-storage — append-only logs, checkpoints, EIP-3076 interchange import/export
• nklave-server — the main server binary with TLS, metrics, configuration
• nklave-cosmos — Cosmos / CometBFT remote signer protocol
• nklave-cli — CLI tools for key management and operations

The security model, summarized

nklave v1 makes four security claims and is explicit about what it does not protect against. We think you should read the threat model in full, but the short version:

What nklave guarantees

• Key non-exfiltration. Signing keys are not readable by the host. They live in the chosen custody backend (local keystore, YubiHSM, AWS CloudHSM, or GCP KMS), and the API does not expose them.
• Non-slashable signing. Slashable requests are refused — even if the request comes from compromised software. The policy engine evaluates every request against the slashing-protection database before the key is touched. A refused signature never reaches the HSM at all.
• Monotonic safety state. The slashing-protection state is append-only with cryptographic chaining. It cannot be silently rolled back by an attacker with filesystem access.
• Auditability. Every signing decision is logged with a deterministic reason code. Forensic reconstruction is a CLI command, not a forensics project.

What nklave does not claim

• Physical access attacks. Cold boot, DMA, evil maid — out of scope. Operators are responsible for physical security of validator hosts.
• Advanced side-channels. Side-channel attacks on enclave execution are out of scope for v1.
• Enclave-implementation compromise. A bug in nklave itself can defeat the guarantees. This is why the codebase is deliberately small and the threat model is published.
• Global anti-slash. Two independent nklave instances signing for the same validator with no shared state can still slash each other. The HA story exists precisely so you don't run that configuration by accident.

Why a separate signer at all

Every modern validator client ships some form of internal slashing protection — a sqlite file the client consults before signing. That is useful, but it inherits the trust model of the client itself. If the client is compromised, the slashing-protection DB is compromised. If the client is replaced by an attacker, the DB might be skipped entirely.

A separate signer breaks that coupling. The signing key never leaves the signer's custody. The slashing-protection state lives behind the signer's API, not in a file the validator client controls. A compromised validator client can request bad signatures all day; nklave will refuse them, log the refusal, and tell you about it via metrics.

The cost of that boundary is one extra hop per signing request. In the deployments we care about, that hop is on the loopback interface, and the latency is invisible next to slot times.

Who builds nklave

nklave is built and maintained by Cryptuon. The project is MIT-licensed and the source lives at github.com/cryptuon/nklave. Contributions are welcome; for significant changes, please open an issue first so we can talk through the threat-model implications.

How to engage

• Read the threat model and tell us where it's wrong.
• Try the single-host deployment on a testnet validator. Verify the log chain. Tamper with a JSON entry and watch nklave log verify fail.
• If you operate a fleet, run the HA pattern: two nklave instances behind HAProxy, a shared Postgres slashing-protection DB with SELECT … FOR UPDATE serializing updates.
• If you find a security issue, please disclose privately to me@dipankar.name before opening a public issue.