Pulsar — Boundary-Cleared Module-LWE Threshold ML-DSA (FIPS 204, byte-equal)

Implementation status (code-audited 2026-07-03): SHIPPED Byte-equality under the stock FIPS 204 verifier proven in the pulsar repo: test/interoperability/n1_class_test.go (TestN1_*_VerifyUnderFIPS204), pkg/pulsar/wire_test.go (TestPulsar_Wire_FIPS204Verifiable), plus cross-verification against the pq-crystals reference C verifier.

Abstract

Pulsar is Lux's Module-LWE threshold signature scheme. Each combined signature is byte-equal to FIPS 204 ML-DSA (ML-DSA-65 and ML-DSA-87): a Pulsar threshold signature is indistinguishable on the wire from a single-party ML-DSA signature, so any unmodified FIPS 204 verifier accepts it. The threshold structure lives entirely in keygen and signing; the verifier is stock FIPS 204.

The dealer is dead at both ends. Pulsar's committee key is generated dealerlessly via Mithril short replicated secret sharing (RSS) — no trusted dealer, no centralized reconstruction, and the RSS-generated group key signs under stock unmodified mldsa65.Verify. Signing is no-reconstruct: no party or coordinator ever forms s1, s2, t0, the mask y, the seed, sk, c·s2, c·t0, r0, or the full commitment w. Two no-reconstruct signers are shipped — the boundary-cleared carry-elimination path (BCC/CEF + CSCP) and the Mithril hyperball 3-round signer (z_j = y_j + c·s1_(j), where the secret mask y is never serialised onto the wire). Both emit a signature that verifies byte-for-byte under stock FIPS 204.

The novelty — and the reason Pulsar can be byte-equal to ML-DSA without the usual threshold-Dilithium leakage — is its threshold protocol: boundary-cleared nonce transcripts plus carry elimination (BCC/CEF). A naive algebraic threshold of ML-DSA must broadcast or reconstruct the secret-bearing intermediates c·s2 and c·t0 to run the FIPS sign-side rejection sequence and MakeHint; doing so leaks long-term key material (this is the V13 finding, LP-4450-V13). Pulsar never forms those quantities. Instead the FIPS hint is recovered from public data only — w' = A·z − c·t1·2^d and the public high-bits target w1 = HighBits(w) — via the standard FIPS UseHint decision (FindHint). Boundary clearance is an offline, message-independent predicate on the aggregate nonce commitment w that guarantees the carry residual c·t0 − c·s2 only perturbs the high bits by ±1, which the public hint corrects, so the threshold signature verifies byte-for-byte under unmodified FIPS 204.

Pulsar and Corona (LP-4440) are sibling Module-LWE threshold schemes in the same lattice family: they differ in parameter regime, lifecycle, and standard conformance, not in hardness family. Corona uses the Ringtail-derived parameter set (matrix A ∈ R_q^{8×7}, 48-bit q, ~33 KB signatures, Cat-1); Pulsar is tuned for byte-equality with FIPS 204 ML-DSA (Cat-3 at ML-DSA-65, Cat-5 at ML-DSA-87).

Honest status (claim discipline). Pulsar is review-ready, not production-certified, and the two claim levels are kept strictly apart:

• PROVEN — standard-verifier compatibility. A dealerless-RSS group key and both no-reconstruct signers (BCC/CEF and hyperball) produce output that verifies under the stock unmodified reference verifiers cloudflare/circl (mldsa65, mldsa87) and pq-crystals (cgo) — gold-proof at committees (t=8,n=8), (t=16,n=16), and all small committees 2 ≤ t ≤ n ≤ 6 via real per-party rejection sampling. The boundary-clearance ⇒ FindHint↔UseHint correspondence is machine-checked in Lean, and the hyperball/BCC no-reconstruct property is proven structurally (AST) with negative controls.
• LABELED RESIDUAL — distribution-equivalence and full malicious security. Full FIPS-204 KeyGen-distribution-equivalence (the simulation / hiding-below-t / abort-bias argument, residual R1) is not proven, only standard-verifier compatibility is. Pulsar is malicious-HARDENED, not fully-malicious-secure-PROVEN: nonce single-use is safe by construction and identifiable-abort blame is gated on authenticated PartyID, but malicious-secure CSCP, a leak-free distributed NonceMPC (the current NonceCert consumes a stand-in that dealer-models the nonce — the PULSAR-V13-W-LEAK residual), tight small-norm lattice range proofs for the nonce/DKG witnesses, and HighBits/boundary-clearance evaluated inside the MPC over secret-shared w are fail-closed pending external review.

Until reviewed verifiers are installed, ProductionBCCSigningReady() returns false, the production signer refuses the gated path, and the consensus layer composes the Corona leg in Pulsar's place. Pulsar is therefore the byte-equal ML-DSA threshold target whose security case is under review — never described as "FIPS/NIST-certified threshold ML-DSA", "fully malicious-secure", or a "global 1000-validator DKG".

Motivation

The Lux PQ-finality stack wants its signature-side threshold output to be verifiable by any stock FIPS 204 implementation — no bespoke verifier, no wire divergence — while still running t-of-n distributed custody. ML-DSA-65/87 (FIPS 204) are the only NIST-validated PQ signatures at Category 3 / Category 5. Module-LWE and Module-SIS are the hardness assumptions stress-tested through the NIST PQC competition. Pulsar targets exactly this: a threshold whose combined signature is an ML-DSA signature.

The obstacle is well known and is the reason FIPS 204 specifies ML-DSA for single-signer use only. ML-DSA is Fiat–Shamir-with-Aborts: the signer samples a mask y, commits w = A·y, derives challenge c, forms z = y + c·s1, and — crucially — runs a secret-dependent rejection and hint sequence over w0 − c·s2 and c·t0. Threshold constructions historically resolve this either (a) by reconstructing the master key (defeating the threshold), or (b) by broadcasting the secret-bearing intermediates c·s2, c·t0 to a combiner so it can run the FIPS sign-side checks and MakeHint. Path (b) is what the prior Pulsar v0.3 AlgebraicAggregate construction did, and it leaks long-term key material (V13).

Pulsar's contribution is to make the threshold byte-equal without either compromise, by moving every secret-dependent decision either offline (boundary clearance, message-independent) or onto public data (FindHint over w'). Defence-in-depth is layered on top, not baked into the floor: Corona (intra-lattice, Ringtail-derived) and Magnetar (cross-family, hash-based SLH-DSA) are profile-selectable diversity legs.

Specification

Hardness and conformance

• Hardness. Module-LWE + Module-SIS over R_q = Z_q[X]/(X^N + 1), N = 256, q = 8380417 (the FIPS 204 prime). Both Pulsar and Corona are Module-LWE; Corona uses the Ringtail parameter set (M = 8, N_vec = 7, 48-bit q).
• Standard conformance. Combined signatures are byte-equal to FIPS 204 ML-DSA at the selected mode. A Pulsar group public key is an ML-DSA public key (ρ, t1); a combined Pulsar signature (c̃, z, h) verifies under the standard FIPS 204 ML-DSA.Verify.
• Modes (the BCC scope is mode-restricted). BCC/CEF is sound only where ‖c·t0‖∞ ≤ τ·2^{d−1} < γ2, which makes the FIPS c·t0 check vacuous and bounds the carry to a single high-bit step. This holds for ML-DSA-65 (τ·2^{d−1} = 49·4096 < γ2 = 261888) and ML-DSA-87 (60·4096 < γ2), but not for ML-DSA-44 (39·4096 > γ2 = 95232). Pulsar therefore supports ML-DSA-65 and ML-DSA-87 only; the parameter selector returns "out of scope" for ML-DSA-44.

No-reconstruct signing I — boundary-cleared carry elimination (BCC/CEF + CSCP)

Pulsar ships two no-reconstruct signers over the same dealerless key; this is the first. Two-round online signing, in the Ringtail-style 2-round shape, on top of a t-of-n Shamir setup over R_q. BCC/CEF is the Boundary-Cleared Carry-elimination Framework; CSCP is its secure-comparison protocol layer (the v0.4 "BCC/CSCP" track). The protocol decomposes into a message-independent offline phase (nonce generation + boundary clearance, certified by a validator quorum) and a message-dependent online phase (two rounds + finalize).

• NonceTranscript / boundary clearance (offline, message-independent). Parties generate masked nonce shares and form the aggregate commitment w = A·y in secret-shared form. A nonce survives iff it is boundary-clear: every coefficient of w has centered low-bits satisfying |w0| < γ2 − 2β − slack. A surviving nonce guarantees, for every admissible challenge c, that HighBits(w − c·s2) = HighBits(w) = w1 and that the FIPS r0-norm check holds — without ever forming c·s2, c·t0, r0, or w0 in any party's view. The yield is roughly 10% per nonce for ML-DSA-65, so the offline phase oversamples.

• NonceCert (validator-run quorum, consensus-native MPC). Boundary clearance is certified by a NonceTranscript quorum run by the validator set itself — it is consensus-native MPC, not a separate signing service. The quorum emits a NonceCert carrying only W1 = HighBits(w) and a ClearanceQC (the quorum certificate that the nonce passed boundary clearance). The NonceCert never carries the full commitment w — exposing w would re-introduce the V13 leak surface — only its public high-bits and the clearance proof.

• Round 1 — bind canonical nonce. Given the message μ and a NonceCert, signers bind the canonical nonce index and signer subset (anti-grinding: the nonce and the t-subset are selected by a canonical, transcript-derived rule, not chosen by a party). The challenge c = H(μ, w1, ...) is derived from public data.

• Round 2 — z-partial. Each signer opens a partial z_i that aggregates linearly: z = Σ z_i. Partial shares carry the z-contribution only; they contain no c·s2, c·t0, r0, or LowBits fields. This is enforced structurally — the wire type has no such fields, and the reference implementation reflection-guards against them.

• Finalize — public hint recovery. The combiner forms the public reconstruction w' = A·z − c·t1·2^d (exactly the quantity the FIPS verifier forms) and derives the hint h from w' and the public w1 via the standard FIPS UseHint decision (FindHint): for each coefficient j, h_j = 0 if HighBits(w'_j) = w1_j; h_j = 1 iff UseHint(1, w'_j) = w1_j; otherwise no valid FIPS hint exists for that nonce and the protocol consumes the nonce and retries. If the hint weight exceeds ω, retry. The output is the FIPS 204 signature (c̃, z, h).

• Verification-equivalence (the load-bearing claim). FIPS 204 Verify computes w'_approx = A·z − c·t1·2^d and accepts iff c̃ == H(μ, UseHint(h, w'_approx)). Because FindHint builds h so that UseHint(h, w') = w1 by construction, and because boundary clearance bounds the c·t0 − c·s2 residual to ±1 high-bit carries that the hint corrects, the threshold signature verifies byte-for-byte under unmodified FIPS 204. This is the same algebra as single-party Sign, with the hint recovered from public data instead of from the secret residual.

No-reconstruct signing II — the Mithril hyperball 3-round signer

The Mithril-native signer (mithril_rss_hyperball.go SignHyperball) produces a stock-FIPS-204 signature from any t active parties over the dealerless RSS key in three rounds, without ever reconstructing the key. Each active party holds only its balanced-partition share s1_(j) and emits only its masked partial response:

z_j = y_j + c·s1_(j)

The coordinator sums z = Σ_j z_j = y + c·s1 — the standard FIPS-204 response — and recovers the hint from the public w' = A·z − c·t1·2^d and w1. No party or coordinator forms s1, s2, t0, the mask y, the commitment w, w0 = LowBits(w), or any sk; the secret mask y is never serialised onto the wire. The key insight is that the only secret-bearing step (z = y + c·s1) is linear, so it distributes additively and verifiability is independent of the boundary-clearance parameters. No-reconstruct is proven structurally (TestHyperballNoReconstructStructural, AST), the output verifies under stock circl (TestHyperballStockCirclVerify), and the path is fail-closed (gate 6).

Dealerless keygen (Mithril short replicated secret sharing)

Committee key generation is dealerless — no trusted dealer, no centralized reconstruction. MithrilRSSKeygen (mithril_rss.go) builds the group key as a sum of fresh per-subset short secrets under Mithril short replicated secret sharing (RSS): for a t-of-n committee the key is split across C = C(n, n−t+1) subsets, each holding an independent χ_η short secret, so the reconstructed ‖s2‖∞ ≤ C·η stays small. The RSS-generated group public key (ρ, t1) is an ordinary ML-DSA public key and signs under stock unmodified mldsa65.Verify (gold-proof at (t=8,n=8), (t=16,n=16), and all small committees).

The dealerless share-dealing layer (Pedersen-VSS, equivocation gate, identifiable-abort blame) is the shared luxfi/dkg library — the same no-reconstruct DKG Corona consumes (LP-4440): one-and-one-way DRY.

The naive lift is unsound — but that is not a class impossibility. A naive additive sum of S_η shares (Pedersen/Gennaro style) has ‖·‖∞ ≤ N·η > η, which breaks BCC and FIPS-204 byte-equality (naive_additive_seta_obstruction.go → ErrDealerlessByteFIPSUnreachable). Mithril short replicated shares is the published escape and is the production dealerless keygen; the obstruction is to the naive lift only.

Per-subset overflow fix (v0.6.3). The RSS secret is the sum of all C(n, n−t+1) subset secrets; each χ_η coefficient is stored in Pulsar's [q−η, q+η] representation (≈ q ≈ 2^23) and added with a raw uint32 add. Summing all subsets without intermediate reduction overflows the uint32 accumulator once C ≥ ⌊2^32/q⌋ = 512 — e.g. the n=16, t=14 committee with C(16,3) = 560 — producing an unsignable "wall key". accumulateSubset reduces mod q per subset; mod q is an additive homomorphism, so small committees (n ≤ 8) stay bit-identical and large committees become signable.

Committee viability — the pick-2 wall as a per-(N,T) bound

A committee (t, n) is admitted iff both hold (checked in one place, fail-closed, by rss.ValidateCommittee):

1. structural: 2 ≤ t ≤ n ≤ 63 (a real threshold that fits the uint64 subset bitmask);
2. norm budget: τ · C(n, n−t+1) · η < γ2.

(2) is load-bearing. Because the RSS secret reconstructs as the plain sum of C short secrets, the signer's hint term is bounded by ‖c·s2‖∞ ≤ τ·C·η, and ML-DSA-65 certifies that a hint exists only while that stays inside one rounding bucket of width γ2 = 261888 (τ = 49, η = 4). This is the classic threshold-Dilithium "pick-2 wall" re-expressed as a clean per-(N,T) inequality rather than a flat N cap. Worked cases (from rss/params.go):

Committee	C	τ·C·η	vs γ2	Verdict
n=8, t=7	28	5,488	48× margin	admitted (owner default)
n=8, t=8	8	1,568	167× margin	admitted
n=16, t=14	560	109,760	2.4× margin	admitted (tight; keygen viable)
n=16, t=12	4,368	856,128	> γ2	rejected (hint budget blown)
n=64, t=5	635,376	≈1.2×10⁸	≫ γ2	rejected

rss.MaxParties = 6 is a conservative cap below which every 2 ≤ t ≤ n committee is both norm-viable and cheap to rejection-sample; it is not the admission gate (ValidateCommittee admits the high-threshold n=8 and n=16,t=14 sets above directly). Two further practical limits keep small n the viable sweet spot: a norm-viable committee still needs a balanced reconstruction partition (Algorithm 6), and the tighter the τ·C·η/γ2 ratio the more rejection-sampling attempts signing costs — n=16, t=14 keygens fine but its hyperball signing exhausts the round budget in practice. The sampled-certificate finality layer (LP-0120 defaults) therefore samples many small n=8 committees rather than one large one (see Quasar / LP-4099).

Resharing & lifecycle

• Dynamic resharing. The signer set may be reshared (add/remove/rotate parties, change t) without changing the group public key, so validator-set churn does not invalidate downstream verifiers or light-client anchors. Proactive refresh (HJKY97) and redistribution (Desmedt–Jajodia97) preserve the master secret by the Lagrange-recombination identity.
• DKG well-formedness. The DKG relation reduces to the single linear identity A·s1 + s2 − t0 = t1·2^d for the well-formedness proof, anchored to the Q-Chain ceremony root.

Verifier, sizes, profile role

• Verifier. Raw precompile 0x012204 (LP-0120) is stock FIPS 204 ML-DSA.Verify. Under the P3Q unified rollup-batch verifier (LP-218 / LP-220) Pulsar is kind byte 0x01 at slot 0x012205; the raw 0x012204 path remains for non-rollup-batch use.
• Sizes. ML-DSA-65: signature 3,309 B, public key 1,952 B, verification ≈181 µs single (3 µs cached). ML-DSA-87: signature 4,627 B, public key 2,592 B.
• Profile role (honest). Pulsar is the byte-equal ML-DSA threshold target, selected by the Pulsar cert profile and composed alongside Corona (Aurora) and Magnetar (Polaris). Under IsStrictPQ(time) == true the Pulsar precompile (0x012204, stock FIPS 204 verify) is one of the always-allowed primitives, while every classical-curve precompile refuses via the single contract.RefuseUnderStrictPQ chokepoint (LP-0120). Pulsar's threshold signer is fail-closed until external review lands (see Status); the verifier is just FIPS 204 and is always available. When the signer is not yet review-cleared, the consensus layer composes the Corona leg in Pulsar's place.

The detailed parameter set, boundary-clearance slack, FindHint encoding, NonceTranscript quorum protocol, and the wire formats are owned by the reference implementation and its KAT vectors (luxfi/pulsar); this LP fixes the role, slot, kind byte, the BCC/CEF threshold design, DKG/resharing model, byte-equality guarantee, mode restriction, honest status, and family relationships.

V13 finding — the removed leaking path

This LP supersedes the prior Pulsar threshold design. The earlier v0.3 AlgebraicAggregate path had parties broadcast (W, Z, CS2 = c·s2, CT0 = c·t0) shares; an aggregator summed them and ran the FIPS 204 sign-side rejection sequence verbatim (‖w0 − c·s2‖ < γ2 − β, ‖z‖ < γ1 − β, ‖c·t0‖ < γ2, then MakeHint(w0 − c·s2 + c·t0, w1)). Broadcasting c·s2 and c·t0 leaks long-term secret-key material (the V13 finding, PULSAR-V13-HINT-LEAK). A second variant of the leak (PULSAR-V13-W-LEAK) exposes the full commitment w in a NonceCert. Both are closed:

• The v0.3 AlgebraicAggregate path was removed — ripped out (commit b185533, PULSAR-V13-HINT-LEAK) with no backward-compatible re-entry. The legacy GF(q) seed-reconstruction committee is quarantined behind //go:build legacy_trusted_dealer, and a CI invariant (TestCI_ProductionBuildExcludesLegacyTrustedDealer) asserts the production build never ships it.
• NonceCert carries only W1 = HighBits(w) plus a ClearanceQC, never the full w.
• Partial z-shares carry no c·s2, c·t0, r0, or LowBits fields; the wire types omit them and the implementation reflection-guards against forbidden field fragments.

The BCC/CEF and hyperball designs above are the no-leak replacement: every secret-dependent decision is either offline-and-message-independent (boundary clearance) or computed on public data (FindHint over w'). The PULSAR-V13-W-LEAK variant is closed on the wire (the NonceCert carries only w1); the remaining residual is the leak-free distributed nonce generation itself — today a stand-in dealer-models the nonce and exposes its commitment to the test harness only, never on the wire, fail-closed behind the same wall as the lattice range proofs.

Version & track lineage

Two independent version axes: the luxfi/pulsar module (released tags v1.x, currently v1.7.1) and the signing/keygen design track (internally v0.3 → v0.6.3, logged in ref/go/pkg/pulsar/VERSIONS.md). The design track:

Track	Status	What it is
v0.3 algebraic broadcast	REMOVED	Broadcast c·s2 / c·t0 residual shares and reconstructed the MakeHint residual at the aggregator — leaks the long-term key (PULSAR-V13-HINT-LEAK). Ripped out; no re-entry.
v0.4 BCC/CSCP no-reconstruct	current sign path	Boundary-Cleared Carry-elimination (BCC/CEF) + secure-comparison (CSCP). One poly-vector Shamir share of s1 per party; aggregate only masked z-partials; hint from public w'. Stock-FIPS-204 output.
v0.5.0 / v0.5.1 malicious-hardening	merged	Nonce single-use safe-by-construction; authenticated-PartyID identifiable-abort blame; origin-auth safe-by-default (ErrOriginAuthRequired); epoch-pruned nonce ledger; pure-Go CI assertion. Malicious-HARDENED, not proven.
v0.6.0 dealerless RSS keygen	merged — the dealer is dead at keygen	Mithril short replicated-secret-sharing committee keygen (mithril_rss.go).
HYPERBALL signer	merged (gates 5/6)	Mithril 3-round no-reconstruct signer (mithril_rss_hyperball.go, z_j = y_j + c·s1_(j)).
v0.6.1 / v0.6.2 mlwe de-dup	merged, byte-preserving	Transcript / Shamir / samplers / ring routed through luxfi/mlwe; golden KATs unchanged; one-and-one-way DRY with Corona.
v0.6.3 RSS overflow fix	current	accumulateSubset mod-q per-subset — unblocks large committees (the C ≥ 512 uint32 overflow).

Quarantined / residual tracks: the trusted-dealer bootstrap (DealAlgShares) is _test.go-only (uncompilable into production), the legacy GF(q) seed-reconstruction committee is behind //go:build legacy_trusted_dealer, and a leak-free distributed NonceMPC is still a residual (the current NonceCert consumes a stand-in that dealer-models the nonce — PULSAR-V13-W-LEAK, closed on the wire, open in nonce-gen).

Relationship to other LPs

• Algorithm family (lattice signatures, 4400-4499): LP-4400 (ML-DSA family root). Pulsar is the byte-equal ML-DSA threshold scheme; LP-4440 (Corona) is the Ringtail-derived Module-LWE sibling — same lattice family, so Pulsar ‖ Corona is implementation-level defence-in-depth, not family-disjoint hardness.
• Cross-family diversity: LP-4540 (Magnetar, threshold SLH-DSA) is the hash-based leg that gives true family-disjoint defence.
• Composition (Quasar): LP-4900 (Aurora = Pulsar ‖ Corona), LP-4910 (Polaris = Pulsar ‖ Corona ‖ Magnetar), LP-0110 (Quasar consensus), LP-0120 (mainnet defaults — Pulsar owns raw slot 0x012204). The Ringtail-style 2-round online signing is orchestrated inside luxfi/consensus as a Quasar cert profile; the BCC/CEF crypto primitives live in luxfi/pulsar. Quasar composes Pulsar by reference; it does not redefine the scheme.
• Rollup verify: LP-218 (P3Q framework), LP-220 (P3Q kind registry — Pulsar is kind 0x01).
• Slot registry: LP-0120 (owns raw 0x012204); LP-218 / LP-220 own the unified 0x012205 kind-dispatch slot.
• Chain home: Q-Chain DKG/ceremonies and validator finality; M-Chain (LP-7100) MPC custody selects Pulsar by default (Corona as a profile alternative).
• E2E-PQ: LP-171 (Pulsar DKG, mirror of HIP-0084).
• Paper: LP-073 (lp-073-pulsar) is the formal companion; its threshold-protocol section specifies the BCC/CEF design and the honest review-ready status. LP-020 §13 (Quasar) is superseded — threshold ML-DSA is achieved via Pulsar BCC/CEF; see that section's reconciliation.

Reference implementation

• Primitive (Go): github.com/luxfi/pulsar (module v1.7.1; signing/keygen design track v0.6.3 + hyperball, under ref/go/pkg/pulsar/). The gated BCC/CEF signer is fail-closed by default (ProductionBCCSigningReady() returns false until reviewed clearance and partial-z verifiers are registered).
• Dealerless keygen + signers: mithril_rss.go (MithrilRSSKeygen), mithril_rss_hyperball.go (SignHyperball), distributed_bcc.go / talus_cef.go (BCC/CEF + CSCP), nonce_ledger.go + protocol_auth.go (single-use + authenticated blame).
• Shared bases (one-and-one-way DRY): github.com/luxfi/mlwe (v0.2.0 — transcript, share, sample/shake, ring/mldsa) and github.com/luxfi/dkg (v0.3.5 — Pedersen-VSS + RSS partition + blame). Ring arithmetic also via github.com/luxfi/lattice/v7.
• C/C++/GPU: luxcpp/crypto/pulsar/ (CUDA / Metal / WGSL backends).
• EVM precompile: github.com/luxfi/precompile/pulsar (raw slot 0x012204, stock FIPS 204 ML-DSA.VerifyCtx, ctx "lux-evm-precompile-pulsar-v1").
• Consensus binding: luxfi/consensus/protocol/quasar/ consumes the Pulsar leg; it owns orchestration (session binding, canonical nonce/signer selection, z-aggregate, sampled-certificate sortition, ConsensusCert), Pulsar owns crypto.
• Interop evidence: a no-leak BCC/CEF signature, an RSS-generated group key, and a hyperball signature all verify byte-equal under cloudflare/circl (mldsa65, mldsa87) and pq-crystals (cgo), with ML-DSA-65 and ML-DSA-87 round-trips (TestMithrilRSSStockCirclVerify, TestHyperballStockCirclVerify).
• Machine-checked: proofs/lean/Crypto/Pulsar/ — boundary-clearance ⇒ FindHint↔UseHint correspondence and verification-equivalence, over proofs/lean/Crypto/Threshold_Lagrange.lean (shared algebraic core).
• NIST submission package (KAT vectors, transcript KATs): luxfi/pulsar NIST-MPTC package (LP-180). The NIST path is two tracks: CAVP/ACVP + FIPS-140-3 validate the ML-DSA primitive / module; the threshold DKG/signing is a Lux-authored construction submitted to NIST MPTC as a reference — not a FIPS certification of the threshold.

Open questions

• External review of the two fail-closed components (tight small-norm lattice range proofs for nonce/DKG witnesses; HighBits/boundary clearance in MPC over secret-shared w) before any production certification.
• Full FIPS-204 KeyGen-distribution-equivalence for the dealerless RSS keygen (the simulation / hiding-below-t / abort-bias argument, residual R1) — today only standard-verifier compatibility is proven.
• Leak-free distributed NonceMPC to replace the stand-in that dealer-models the nonce (PULSAR-V13-W-LEAK, open in nonce-gen).
• Exact resharing transcript-binding to the Q-Chain ceremony root for proactive (epoch-driven) vs. reactive (churn-driven) resharing.
• Aggregation across distinct group keys (multi-group QuasarCert) vs. the current single-group-per-cert model.

Provenance

Pulsar and Corona (LP-4440) are sibling Module-LWE threshold schemes that differ in parameter regime, lifecycle, and standard conformance, not hardness family. This LP is the canonical Pulsar algorithm specification; the verifier precompile detail is owned jointly with LP-0120 (raw slot 0x012204).

Academic basis. Pulsar's byte-equal threshold ML-DSA line follows Celi, del Pino, Espitau, Niot, Prest, Efficient Threshold ML-DSA (USENIX Security 2026); Pulsar's specific contribution is the BCC/CEF no-leak construction (boundary-cleared nonces + public-UseHint hint recovery), the Mithril hyperball 3-round no-reconstruct signer, and the consensus-native NonceTranscript quorum. The dealerless keygen follows the Mithril short replicated secret sharing line (ePrint 2026/013, RSSRecover) — the published escape from the naive-S_η-lift norm obstruction. The Ringtail two-round lattice-threshold line (Boschini, Kaviani, Lai, Malavolta, Takahashi, Tibouchi; ePrint 2024/1113; IEEE S&P 2025) is the work that Corona builds on — not Pulsar.

LP lineage. LP-073 was the original Pulsar paper-LP. During the unified-4xxx crypto consolidation, LP-4440 was briefly mis-titled "Pulsar" while in fact carrying Corona (Module-LWE) content; that error is corrected — LP-4440 is now canonical Corona, and LP-4450 is the real, canonical Pulsar. The historical LP-073 and the LP-7324/LP-4470 Corona stubs redirect accordingly: Pulsar → LP-4450, Corona → LP-4440.

Relationship to Corona. Pulsar (FIPS 204 byte-equal via BCC/CEF) and Corona (LP-4440, ~33 KB, Cat-1) are both Module-LWE threshold schemes; they share the lattice family but differ in parameter regime, codebase, and standard conformance. Corona is the Ringtail-derived leg; Pulsar is tuned for byte-equality with FIPS 204 ML-DSA. Both are Lux's own schemes.

Copyright

Copyright and related rights waived via CC0.