Skip to content
nklave GitHub

Who it's for

One firewall. Five kinds of operator.

nklave is the simplest correct thing between a validator client and its keys. That single design serves restaking and AVS operators facing more slashing surfaces, staking operators at scale, teams migrating off Web3Signer, multi-chain validators, and security teams — each for a different reason.

Restaking & AVS operators

Put a firewall in front of keys exposed to more slashing surfaces

Restaking and EigenLayer-style AVS opt the same staked capital — and increasingly the same keys — into multiple independent slashing regimes at once. Each is a new way to lose stake, defined by code you did not write. nklave is the control point in front of the keys: it enforces protocol-level slashing prevention before any signature is produced, resolves every request to an explicit allow or refuse, and is the first-class layer where operators express additional guardrails as the surface grows.

Why restaking changes the math →
  • Enforcement in front of the signing keys
  • Protocol-level EIP-3076 prevention today
  • First-class policy layer for added guardrails

Professional staking operators

Make slashing a class of bug, not a class of incident

Operators running validators at scale cannot rely on protection that lives inside the same process that signs. nklave moves enforcement to a separate trust boundary in front of the keys, so a compromised or buggy validator client cannot produce a slashable signature — the request is refused before the key is touched.

See the request lifecycle →
  • Enforce before the key is consulted
  • EIP-3076 double-vote / surround-vote
  • Monotonic safety state, tamper-resistant

Migrating from Web3Signer

Drop-in swap with your slashing history intact

Because nklave speaks the Web3Signer HTTP signing protocol, migrating is a signer-URL change plus an EIP-3076 interchange import. You keep your validator client, keep your HSM, and gain a first-class policy layer and a tamper-evident audit log.

nklave vs Web3Signer →
  • Web3Signer-compatible endpoints
  • EIP-3076 import/export
  • One small Rust binary, no JVM

Multi-chain validators

One signer for Ethereum and Cosmos

Teams validating on both Ethereum and Cosmos / CometBFT can run a single signer for both. nklave handles BLS for Ethereum and Ed25519 for CometBFT, applying slashing rules per (source, target) epoch, per slot, and per (height, round) as appropriate.

See all features →
  • BLS (ETH2) + Ed25519 (Cosmos)
  • Per-chain slashing semantics
  • Shared policy layer and audit log

Security & compliance teams

A verifiable record of every signing decision

When you need to prove what your infrastructure did — for an incident review, an audit, or your own peace of mind — nklave's append-only log gives you a Merkle-checkpointed, operator-signed record of every allow and refuse. Re-walk the chain and any tampering exits non-zero.

How the log works →
  • Append-only JSON decision log
  • Merkle-root checkpoints every 60s
  • CLI-verifiable, tamper-evident

Switch your signer URL.

nklave is MIT-licensed and built to be the simplest correct thing between your validator client and your keys.

GitHub See all features