Seeking champion + early feedback: threshold-signature MPC cluster (KMS Driver) for Canton validators — 01node
Hello everyone,
01node here — validator operator with nodes running on Canton DevNet, TestNet, and MainNet, and a background in Distributed Validator Technology (we build and operate staking infrastructure on Ethereum via SSV and Obol). We're preparing a Development Fund proposal and are looking for two things from this group: **early feedback** and a **Tech & Ops champion**.
## The problem
Every validator/SV operator must protect participant and sequencer signing keys. Today's options are unsatisfying:
- **Keys in node storage** — host compromise = key compromise.
- **AWS/GCP KMS** — a single cloud account is a single point of trust _and_ failure; also a non-starter for bare-metal and lock-in-averse operators.
- **Enterprise HSMs** — cost and procurement friction that pushes smaller operators back to option one.
Other ecosystems solved this class of problem in production: Cosmos validators run strangelove-ventures/horcrux (threshold Ed25519 with a high-watermark double-sign ledger); Ethereum runs SSV/Obol. Canton has no equivalent — yet it has the perfect integration seam: the **KMS Driver plug-in API (v1)**.
## The proposal: "Canton Horcrux"
An Apache-2.0, Horcrux-style cosigner cluster plus a Canton KMS Driver:
- **Threshold cryptography**: FROST-Ed25519 (primary — Canton's default signing spec) and CGGMP21 ECDSA for secp256k1/secp256r1. Keys are born via DKG and **never materialize whole** in memory or on disk, anywhere.
- **Native integration**: a Scala `KmsDriver` v1 — nodes adopt it by changing only a config block; same key lifecycle through existing admin APIs; OTel trace propagation; retryable-error mapping onto Canton's backoff.
- **Safety under failover**: a replicated consistency journal enforcing at-most-one signature per (keyId, payload) and single-use nonces — the threshold analogue of Horcrux's HRS high-watermark, protecting against nonce-reuse key leakage during Participant HA failovers.
- **Operability**: mTLS between cosigners, Prometheus metrics, audit log, encrypted shard backup/recovery, Helm chart + Terraform modules.
**Milestones (≈7 months, 750k CC total, milestone-gated):** M1 MPC core → M2 KMS driver (Maven Central + local-net participant on external key storage) → M3 safety/consistency layer with chaos-tested failover → M4 DR tooling → M5 live signing for 01node's DevNet+TestNet validators → M6 28-day MainNet soak on our production validator (≥99.9% availability, p99 <250ms Ed25519 3-of-5) plus **at least one independent operator completing a TestNet trial**. Full maintenance commitment and community handoff docs included.
Draft (complete per the fund template): <https://github.com/01node/canton-dev-fund/blob/main/proposals/2026-08-01node-canton-threshold-signer.md>
## What we ask of you
1. **Feedback**: does the scope match what operators actually need? Are the acceptance criteria meaningful to you? Anything you'd cut or demand before voting?
2. **Champion**: if you're on a relevant SIG (security / node-operations) and believe in the problem statement, we'd be grateful for a champion to help sharpen milestones and scope through review, per CIP-0100. Happy to walk you through the draft on a call first.
Thanks for reading — and see you on the SIG calls.
Gabriel Mateiciuc
Validator Engineering, 01node
<https://01node.com>