magnetar/PATENTS.md

PATENTS --- Magnetar SLH-DSA Signature

v1.0 framing. This document is a v0.x archival snapshot. The v1.0 patent grant covers the THBS-SE construction (thbsse.go + thbsse_field.go) under the same terms as the v0.x reveal-and-aggregate path described below; the construction details have changed but the IP posture is unchanged.

Statement of Intellectual Property and Royalty-Free Patent Grant for the Magnetar threshold-signing construction submitted to the NIST Multi-Party Threshold Cryptography (MPTC) project.

TL;DR

Lux Industries, Inc. ("Lux") grants a worldwide, royalty-free, non-exclusive, irrevocable patent license for any implementation of the Magnetar threshold signature construction that is either (a) licensed under BSD-3-Clause or a compatible OSI-approved license, OR (b) is part of a NIST MPTC / PQC / ACVP submission, validation, or interoperability test.

The grant terminates automatically and prospectively against any party that asserts a patent claim against Magnetar, FIPS 205 SLH-DSA, FIPS 204 ML-DSA, or any other NIST-standardized post-quantum signature scheme. Defensive termination mirrors Apache-2.0 §3.

The full text of the grant is in §3 Patent Grant below.

§1 Scope of the IP statement

This document covers patent rights and patent posture for:

• The Magnetar threshold-signing construction as implemented at github.com/luxfi/magnetar (DKG → Round-1 commit → Round-2 reveal → Combine).
• The reference implementation in ref/go/pkg/magnetar/.
• The test-vector format in ref/go/cmd/genkat and vectors/.

It does NOT cover, and explicitly DISCLAIMS, the following prior art:

Component	Status
FIPS 205 SLH-DSA (Stateless Hash-Based Digital Signature Standard, NIST 2024)	NIST standard. Magnetar implements the single-party FIPS 205 layer unchanged in its math via cloudflare/circl's audited Go reference. Lux asserts no patents on FIPS 205 itself.
WOTS+, HORS, FORS, hypertree constructions underlying SLH-DSA (Buchmann-Dahmen-Hülsing 2011 and follow-up academic literature)	Academic / public domain.
Shamir secret sharing (Shamir 1979)	Public domain.
Lagrange polynomial interpolation	Classical mathematics.
SHAKE128 / SHAKE256 / Keccak / cSHAKE / KMAC / TupleHash (FIPS 202 + SP 800-185)	Public domain — NIST standards.
Pedersen verifiable secret sharing (Pedersen 1991)	Academic prior art. Magnetar v0.1 does NOT use Pedersen VSS (v0.1 ships plain byte-wise Shamir); v0.4 may adopt for envelope-wrapping authenticity.
HJKY97 proactive secret sharing (Herzberg, Jakobsson, Jarecki, Krawczyk, Yung. CRYPTO 1995/1997)	Academic prior art. Will be the basis of Magnetar's Refresh primitive when it lands at v0.4.
Reveal-and-aggregate threshold-signing pattern (used by Pulsar v0.1 and other production threshold systems)	Industry / academic prior art. The general pattern is not asserted by Magnetar; only the SLH-DSA-specific lifecycle additions below are candidate claims.

§2 What Lux considers patentable (high level)

Subject to attorney review, Lux considers the following Magnetar contributions to be candidates for patent protection. Note: this list is intentionally narrow because the underlying FIPS 205 SLH-DSA primitive is a NIST standard (public domain) and the byte-wise Shamir VSS pattern over a NIST-standard scheme seed follows directly from Pulsar's v0.1 reveal-and-aggregate template applied to the SLH-DSA seed instead of the ML-DSA seed. Magnetar's novel contributions are the SLH-DSA-specific protocol shape and binding.

§2.1 Byte-wise Shamir VSS of the FIPS 205 SLH-DSA scheme seed over GF(257)

The specific adaptation of byte-wise Shamir secret sharing to the FIPS 205 SLH-DSA scheme seed (96 bytes for SHAKE-192s/192f, 128 bytes for SHAKE-256s), where:

• Each byte position of the seed is shared independently over GF(257) (smallest prime > 255, admits every byte value as a distinct field element).
• Shares are encoded as one big-endian uint16 per byte position (the 9-bit GF(257) element packed in a 16-bit lane).
• Reconstruction at x=0 recovers the master byte-sum, which is then mixed with the committee root via cSHAKE256 to produce the reconstructed master seed.
• The cSHAKE256 mix uses customisation tag MAGNETAR-SEED-SHARE-V1 with function-name "Magnetar" per SP 800-185.

Detailed in SPEC.md §3 (DKG protocol) and §4 (threshold signing Combine step); implementation in ref/go/pkg/magnetar/shamir.go, dkg.go, combine.go.

§2.2 Three-round DKG with transcript-digest equivocation detection

The specific DKG protocol shape:

• Round-1: dealer broadcasts one envelope per recipient carrying the recipient's Shamir share and the dealer's full contribution to the joint seed. Each envelope is (share || contribution) where share is 2 × seed_size bytes (big-endian uint16 per byte position) and contribution is seed_size bytes.
• Round-2: each party computes a 32-byte transcript digest D = cSHAKE256(tau_dkg || for_each_dealer(for_each_recipient(env)), N="Magnetar", S="MAGNETAR-DKG-TRANSCRIPT-V1") binding the entire ordered envelope set; broadcasts D.
• Round-3: parties verify every received digest equals their local D. A mismatch produces an AbortEvidence{Kind: ComplaintEquivocation} carrying the conflicting digest pair — identifiable abort with attributable evidence suitable for slashing.

The transcript binding tau_dkg = (mode || threshold || committee_size || committee_in_order) and the dealer/recipient ordering convention are domain-separated under lux-magnetar-v0.1.

Detailed in SPEC.md §3; implementation in dkg.go.

§2.3 Two-round commit-bind threshold sign with masked-share reveal

The specific threshold-sign protocol shape:

• Round-1: each signer derives r_i = cSHAKE256(rngBytes || sid || attempt || NodeID, N="Magnetar", S="MAGNETAR-SIGN-MASK-V1") — the per-attempt mask is derived deterministically from raw entropy plus the session/attempt/NodeID tuple, so a deterministic RNG that produces the same output across two attempts still yields DISTINCT masks. Compute masked_i = share_i XOR r_i; commit D_i = cSHAKE256(r_i || masked_i || tau_1, N="Magnetar", S="MAGNETAR-SIGN-R1-V1") where tau_1 = (sid, attempt, quorum, NodeID, pk, msg).
• Round-2: reveal (r_i, masked_i) so peers can re-derive D_i and the aggregator can XOR them to recover share_i.
• Combine: for each Round-2 reveal, re-derive D'_i and gate on ctEqual32(D'_i, D_i). Recover share_i = masked_i XOR r_i. Collect t distinct shares with their EvalPoints; Lagrange- interpolate the master byte-sum at x=0; mix with the committee root via cSHAKE256 (identical to DKG Round-3 step 6); derive the FIPS 205 SLH-DSA secret key via slhdsa.Scheme(ID).DeriveKey(S); sign via slhdsa.SignDeterministic. Result is byte-identical to centralized FIPS 205 SLH-DSA.

Detailed in SPEC.md §4; implementation in threshold.go and combine.go.

§2.4 Identifiable abort with attributable evidence

The specific use of ComplaintEquivocation carrying the conflicting digest pair (my_digest, accused_digest) as the slashing-suitable evidence blob; the typed AbortEvidence struct with Kind, Accuser, Accused, Evidence, Signature fields. Detailed in SPEC.md §8; implementation in dkg.go Round-3.

§2.5 Constant-time commit-bind gate in Combine

The specific implementation pattern in combine.go where every Round-2 reveal's recomputed D'_i is compared to the matching Round-1 D_i via ctEqual32 (constant-time 32-byte equality scan) before the share is included in the Lagrange reconstruction. This prevents a malicious aggregator from selectively admitting shares based on timing of the per-share commit verification.

§3 Patent grant (the load-bearing text)

MAGNETAR PATENT GRANT — v1.0

Lux Industries, Inc. ("Lux"), a Delaware corporation, hereby grants to any person or entity ("You") a worldwide, royalty-free, non-exclusive, no-charge, fully-paid-up, irrevocable (except as stated in §3.2 below) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer any implementation of the Magnetar threshold-signing construction described in SPEC.md (the "Construction"), provided that such implementation:

(a) Implements the Construction (signing, DKG, or — when v0.4 lands — proactive resharing) in a manner consistent with the algorithmic specification (the "Construction-Conformance Condition"); AND

(b) Is licensed to the public under (i) the BSD-3-Clause License, (ii) the Apache License, Version 2.0, or (iii) any other Open-Source-Initiative-approved license compatible with BSD-3-Clause or Apache-2.0, OR (c) is part of a submission to, validation under, or interoperability test for the NIST Multi-Party Threshold Cryptography (MPTC) project, the NIST Post-Quantum Cryptography (PQC) standardization process, or any successor program administered by NIST.

The license granted in this §3 covers all "Necessary Claims" owned or controllable by Lux that would, in absence of this license, necessarily be infringed by an implementation meeting (a) and (b). "Necessary Claims" means claims of any patent or patent application that are essential for compliance with the Magnetar specification, that Lux has the right at the time of execution to grant a license under.

§3.1 Documentation and reference-implementation grant

The Magnetar specification (SPEC.md), the reference implementation (ref/go/pkg/magnetar/), and the test vectors (under vectors/ with deterministic regeneration via ref/go/cmd/genkat) are released under the BSD-3-Clause license. The patent grant in this document operates in addition to (not in lieu of) any patent provisions in the BSD-3-Clause license; BSD-3-Clause's silence on patents is supplemented by the explicit grant here.

§3.2 Defensive termination

The patent license granted in this §3 terminates automatically and prospectively, without notice, with respect to any party (the "Asserting Party") if the Asserting Party initiates patent litigation (including a cross-claim or counter-claim in a lawsuit) alleging that:

(i) The Magnetar construction; or (ii) FIPS 205 SLH-DSA, FIPS 204 ML-DSA, FIPS 203 ML-KEM, or any other NIST-standardized post-quantum signature or key- encapsulation scheme; or (iii) Any implementation of (i) or (ii) — including without limitation the reference implementation in this repository, independent third-party implementations, NIST ACVP/CAVP reference vectors, or any FIPS 140-3 validated module containing such an implementation,

infringes any patent owned or controllable by the Asserting Party. Termination is prospective only; it does not undo the validity of any implementation distributed prior to the date the Asserting Party initiated the litigation.

Defensive termination mirrors the patent-termination clause of the Apache License, Version 2.0, §3, generalized to also cover FIPS 205 SLH-DSA, FIPS 204 ML-DSA, FIPS 203 ML-KEM, and successor NIST-standardized post-quantum signature schemes. The purpose is to deter patent assertion against the broader post-quantum signature ecosystem, not only against Magnetar itself.

§3.3 No trademark license

This grant does not authorize the use of Lux's trademarks (including "Magnetar", "Pulsar", "Corona", "Quasar", "Lux", "Lux Industries", and their respective logos) except as required for reasonable and customary use in describing the origin of the Construction and reproducing the content of any NOTICE file.

§3.4 Disclaimer

THE CONSTRUCTION AND ALL ASSOCIATED MATERIALS ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. Lux shall not be liable for any damages resulting from the use of the patent license granted in this §3.

§4 Filing strategy (informational)

This section is for transparency; it does not modify the grant in §3.

Lux intends to pursue patent protection on the Magnetar production- lifecycle additions as follows:

1. US provisional application within 12 months of public disclosure (the NIST MPTC submission counts as public disclosure for §102 purposes; filing before submission preserves priority).

2. PCT international application within 12 months of the provisional, designating jurisdictions where threshold SLH-DSA deployment is anticipated (EU, JP, CN, KR, IN, AU, CA, UK, BR).

3. EPO and major-jurisdiction national-phase entries at the PCT 30-month deadline, prioritized by anticipated deployment markets.

4. Continuation / divisional applications to cover incremental refinements (e.g., the v0.4 ML-KEM-768 envelope-wrapping pattern for DKG Round-1 envelopes, the v0.4 reshare protocol, future hash-suite profile additions, the v0.2 full-MPC construction when it matures).

The royalty-free grant in §3 applies to ALL such filings, present and future, that are owned or controllable by Lux.

§5 Why the grant is structured this way

§5.1 Defensive patent ownership protects the ecosystem

Without Lux holding the patents on the Magnetar production-lifecycle additions, a third party could observe the public NIST submission, file blocking patents on (e.g.) the byte-wise Shamir VSS over the SLH-DSA seed pattern, and assert them against open-source implementations. Lux holding the patents (with a royalty-free grant) removes that attack surface.

This is the same logic that protects FRAND ecosystems and that underlies Apache-2.0's patent grant + retaliation clause.

§5.2 Compatibility with NIST MPTC submission terms

The NIST Multi-Party Threshold Cryptography project's submission guidelines require submitters to provide a patent statement specifying the IP terms under which the submitted construction may be used. The grant in §3 satisfies that requirement and goes beyond NIST's baseline by extending defensive termination to FIPS 205 SLH-DSA, FIPS 204 ML-DSA, FIPS 203 ML-KEM, and successors (not just Magnetar's own construction).

§5.3 Compatibility with the FIPS 205 standard

The underlying FIPS 205 SLH-DSA primitive is a NIST standard (public domain). Lux asserts no patents on FIPS 205 itself; Magnetar's claims are limited to the threshold lifecycle additions. Any third-party implementation of FIPS 205 SLH-DSA single-party signing is free of Magnetar patent assertions whether or not it adopts Magnetar's threshold layer.

§5.4 Defensive termination for the broader PQ ecosystem

Extending defensive termination to FIPS 205 SLH-DSA, FIPS 204 ML-DSA, FIPS 203 ML-KEM, and successors — not just Magnetar itself — converts Lux's patent portfolio into a small deterrent against PQ-signature patent trolls. It costs Lux nothing (Lux does not intend to assert offensively) and benefits the ecosystem.

§6 What this document does NOT do

• It does not assign any Lux patent rights to NIST, IETF, or any third party. Lux retains ownership; the grant in §3 is a license.
• It does not commit Lux to maintain or prosecute any specific patent application. Lux may abandon applications for business reasons; the grant in §3 covers issued patents in proportion to what is actually granted.
• It does not waive Lux's right to update the grant text (subject to §6.1 below).
• It does not modify the BSD-3-Clause license covering the reference implementation, specification, and vectors.
• It does not claim patent rights on FIPS 205 SLH-DSA itself (NIST standard, public domain).

§6.1 Modifications to this grant

Lux may issue future versions of this PATENTS document with clarifications or extensions of the grant. Future versions will apply to implementations published under the future version's identifier. The grant in §3 of this v1.0 document is irrevocable for implementations relying on it, subject only to the defensive-termination clause in §3.2.

§7 Contact

Purpose	Contact
Patent / IP inquiries	legal@lux.network
Licensing for non-conforming implementations	legal@lux.network
NIST submission coordination	mptc@lux.network
Security disclosure	magnetar@lux.network

---

Document metadata

• Document name: PATENTS.md
• Document version: v1.0
• Document date: 2026-05-18
• Construction version: Magnetar v0.3.0 (Tier A documentation shape complete)
• Construction repository: https://github.com/luxfi/magnetar
• License of this document: Creative Commons CC-BY-4.0 (so it can be freely reproduced in NIST submission packages and audit reports without modification).