Skip to content
nklave GitHub

← Back home · Compare

nklave vs Web3Signer

Consensys · Reference remote signer for Ethereum staking

Web3Signer defined the HTTP signing protocol that every modern validator client speaks. nklave is explicitly Web3Signer-compatible — it implements the same endpoints, so anywhere you use Web3Signer today, nklave can replace it. The differences are in how the signer treats policy, audit, and the trust boundary itself.

Feature nklave Web3Signer Best fit
API surface Web3Signer HTTP signing protocol — drop-in compatible Defines the protocol Comparable
Slashing protection format EIP-3076 import/export EIP-3076 import/export Comparable
Slashing-protection backend RocksDB (default) or Postgres for HA Postgres / sqlite, depending on mode Comparable
Implementation language Rust — small static binary Java / JVM nklave
Multi-chain Ethereum (BLS) + Cosmos/CometBFT (Ed25519) Ethereum + Filecoin + others Web3Signer
Policy engine First-class chain; custom policies via Rust trait Slashing-protection + fork-version checks nklave
Audit log Append-only with Merkle-root checkpoints, operator-signed, CLI-verifiable Standard slf4j logs nklave
Key custody backends Local keystore, YubiHSM 2, AWS CloudHSM, GCP KMS Local, HashiCorp Vault, Azure, AWS, YubiHSM Web3Signer
License MIT Apache 2.0 Comparable
Embedded UI Vue.js dashboard on the API No first-party UI nklave

Pick nklave when

  • You want a single small Rust binary instead of a JVM service
  • You want the policy chain (fork-allowlist, rate-limit, custom rules) as a first-class API, not bolted on
  • You want a tamper-evident append-only audit log with checkpoint chain verification out of the box
  • You operate Cosmos / CometBFT validators alongside Ethereum and want the same signer for both

Pick Web3Signer when

  • You need the broadest possible vendor adoption and ecosystem familiarity today
  • You already run JVM infrastructure and operational tooling around it
  • You need Filecoin or other chains that nklave does not yet support

Still deciding?

Both are valid choices for a remote signer. If you want to see what nklave looks like in your stack, run the import against a testnet validator's slashing-protection export and watch the audit log fill.