zeekay
6eb4c5d492
mpcd is the production threshold daemon. With this commit it embeds
the JSON-RPC dispatcher from luxfi/threshold/pkg/thresholdd on a new
--threshold-listen flag (default 127.0.0.1:7300, MPC_THRESHOLD_LISTEN
env var). The dispatcher exposes every supported scheme:
cggmp21 (secp256k1 ECDSA, CGGMP21 fork)
frost (secp256k1 Schnorr, RFC 9591)
bls (BLS12-381 Shamir/Lagrange)
sr25519 (Ristretto255, via mpc node's own session — separate path)
pulsar (M-LWE / FIPS 204 ML-DSA-65 threshold, via luxfi/corona/threshold)
corona (R-LWE / Ringtail, via luxfi/ringtail/threshold)
doerner (reserved; upstream protocol non-functional, returns explicit error)
Wire format matches teleport/mpc/src/signers/rpc.ts byte-for-byte:
POST / {"jsonrpc":"2.0","id":N,"method":"<scheme>.<op>","params":{...}}
Methods per scheme: keygen / sign / verify. Public-key handles are
returned by keygen and bound on sign/verify.
Decomplecting note: the dispatcher carries zero policy. Profile
gating, auth, audit, and rate-limiting live on mpcd's existing API
surface (and on the cluster ingress in front of it). The threshold
listener is loopback by default; production exposure happens via the
KMS-facing ZAP server or the gateway.
There is no separate thresholdd daemon to deploy. The luxfi/threshold
repo's cmd/thresholdd remains as a developer / CI binary that imports
the same package — one wire, one implementation, two startup paths.
Tests: TestEmbeddedDispatcher_BLSRoundTrip (full keygen → sign →
verify → forgery rejection) and TestEmbeddedDispatcher_UnknownScheme
(-32601 method-not-found contract) both pass. README updated with the
new protocol table; full surface documented in
luxfi/threshold/LLM.md "thresholdd — unified JSON-RPC dispatcher".
mpcd — MPC Daemon
mpcd is a threshold-signature daemon. It speaks ZAP wire protocol over
TLS 1.3 directly between peers — no NATS, no Consul, no PostgreSQL in the
critical path. The daemon is the same binary in every deployment shape;
the operating mode is selected entirely by flags.
Operating modes
There is exactly one start command (mpcd start) and the topology is
determined by the --peer and --threshold flags:
| Topology | Flags | Use |
|---|---|---|
| Standalone (1-of-1 self-loop) | --threshold 1 (no --peer) |
Smoke tests, dev sandbox |
| Networked t-of-n cluster | --threshold t --peer ... (n−1 peers) |
Production |
In all cases mpcd runs the consensus-embedded transport
(pkg/transport). The "consensus" here is local PoA membership over the
node's own Ed25519 identities — it is intentionally not the Lux mainnet
chain, because key shares must never leave the cluster.
Standalone (1-of-1)
mpcd start \
--node-id solo \
--listen :9999 \
--api :9800 \
--data /var/lib/mpcd \
--threshold 1
Starts mpcd with itself as the only quorum member. /healthz will report
signing_quorum: true immediately. Keygen and signing of fresh wallets
require ≥2 parties — CGGMP21 and FROST cannot produce shares with a
single party — so this mode exists only for boot-up smoke tests, e2e
harness fixtures, and verifying TLS / membership / API plumbing. For real
signing, run a multi-node cluster.
Networked (t-of-n)
# Node 0
mpcd start --node-id node0 --listen :9999 --api :9800 \
--data /data/node0 --threshold 2 \
--peer [email protected]:9999 --peer [email protected]:9999
# Node 1
mpcd start --node-id node1 --listen :9999 --api :9800 \
--data /data/node1 --threshold 2 \
--peer [email protected]:9999 --peer [email protected]:9999
# Node 2 — same pattern
The daemon expects the cluster size n = len(peers) + 1 and rejects start
when threshold > n. See pkg/transport/registry.go::HasSigningQuorum for
the quorum arithmetic.
Smoke test
go test -tags=integration ./cmd/mpcd/... -count=1 -timeout 90s
standalone_test.go builds mpcd, runs it with --threshold 1 on free
ports and a fresh data directory, polls /healthz until quorum holds,
and asserts the response shape. It does not exercise keygen — see e2e/
for that.