Skip to content
nklave GitHub

About

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

nklave is an open-source remote signer — a policy firewall that enforces slashing-prevention rules and configurable policies before any signature is produced. It exists because slashable signing is an entire category of preventable production incident, and there's no reason to keep treating it as a human-process problem. Restaking makes that case sharper: as EigenLayer-style AVS multiply the surfaces a single key can be slashed on, a control point in front of the keys becomes critical infrastructure.

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:

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

What nklave does not claim

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.

Why restaking raises the stakes

For most of proof-of-stake's history, a validator key faced exactly one slashing surface: the consensus layer of the chain it validated. Restaking changed that. EigenLayer-style restaking and Actively Validated Services (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. The more regimes a key is exposed to, the more valuable a single control point that governs what actually gets signed.

We are deliberate about scope here. nklave enforces protocol-level slashing prevention — EIP-3076 and equivalents — which covers the overwhelming majority of real-world slashing incidents. AVS-specific slashing conditions are per-service and are not built in. What nklave contributes is the enforcement model and the first-class policy layer where operators can express additional guardrails as the surface grows. See the roadmap for where restaking-aware policy work is headed.

Who builds nklave

nklave is built and maintained by Cryptuon Research. 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

Project status

nklave is under active development. The crates publish to crates.io as they stabilize; the Docker image at ghcr.io/cryptuon/nklave tracks the main branch. Production use today should be paired with monitoring of nklave_policy_refusals_total and the audit log's checkpoint age.