submission: SUBMISSION + NIST-SUBMISSION + PATENTS

Tier A documentation shape, first cluster. Mirrors Pulsar's Tier A template adapted to Magnetar specifics: - SUBMISSION.md: NIST MPTC cover sheet. Headline N1 claim: Magnetar threshold signatures are byte-identical to single-party FIPS 205 slhdsa.SignDeterministic on the reconstructed master seed. Honest delta vs Pulsar (no EC/Lean/Jasmin yet for the threshold overlay). - NIST-SUBMISSION.md: one-page executive summary mapped to NIST IR 8214C requirements. - PATENTS.md: royalty-free grant + defensive termination. Defensive scope extends to FIPS 205, FIPS 204, FIPS 203, successors. Claims limited to Magnetar-novel lifecycle additions (byte-wise Shamir VSS over SLH-DSA seed, three-round DKG transcript binding, two-round commit-bind threshold sign).
2026-07-27 02:53:47 +00:00 · 2026-05-19 07:51:12 -07:00
parent 5ae075e14f
commit fc8667a8a2
3 changed files with 927 additions and 0 deletions
@@ -0,0 +1,213 @@
+# NIST MPTC Submission — Magnetar (one-page executive summary)
+
+> **Executive summary** of the Magnetar package for the NIST Multi-Party
+> Threshold Cryptography (MPTC) project. The full cover sheet is in
+> `SUBMISSION.md`; the package contents map is below.
+
+## Submission metadata
+
+| Field | Value |
+|---|---|
+| Submission name | **Magnetar** |
+| Submitting organisation | Lux Industries, Inc. |
+| Algorithm | Threshold SLH-DSA (FIPS 205) — reveal-and-aggregate over the SLH-DSA scheme seed |
+| MPTC classes | **N1** (threshold signing, byte-identical to single-party FIPS 205 SLH-DSA on the reconstructed master seed). N4-analog (reshare with public-key preservation) is on the v0.4 roadmap. |
+| Underlying construction | FIPS 205 SLH-DSA (single-party layer); v0.1 reveal-and-aggregate Shamir VSS of the SLH-DSA scheme seed over GF(257) (threshold overlay) |
+| Hash family | FIPS 202 SHA-3 / SHAKE; SP 800-185 cSHAKE256 / KMAC256 for Magnetar-specific transcript hashes |
+| Parameter sets | SLH-DSA-SHAKE-192s (NIST PQ Cat 3, recommended), SLH-DSA-SHAKE-192f (Cat 3 fast), SLH-DSA-SHAKE-256s (Cat 5) |
+| Round count | DKG = 3 rounds; threshold sign = 2 rounds (commit + reveal) |
+| Repository | <https://github.com/luxfi/magnetar> |
+| Submission tag | `submission-2026-11-16` (planned) |
+| Latest tagged release | `v0.2.0` (this revision targets `v0.3.0`) |
+| License | BSD-3-Clause (code) + CC-BY-4.0 (PATENTS.md) |
+
+## Headline claim
+
+> Every signature produced by a Magnetar threshold ceremony (DKG →
+> Round-1 commit → Round-2 reveal → Combine) is **byte-identical**
+> to single-party FIPS 205 `slhdsa.SignDeterministic` on the
+> reconstructed master seed. Verification under unmodified FIPS 205
+> accepts Magnetar signatures with no code change.
+
+**Theorem framing**: byte-equality to a NIST-standardized
+single-party primitive. Magnetar implements FIPS 205 SLH-DSA
+**unchanged in its math** (via `cloudflare/circl` audited Go
+reference) for the single-party layer; Magnetar's contribution
+beyond FIPS 205 is the threshold lifecycle (byte-wise Shamir VSS
+over GF(257) of the SLH-DSA scheme seed, three-round DKG,
+two-round commit-bind threshold sign, identifiable abort,
+KAT-deterministic Magnetar-SHA3 hash suite).
+
+**Verifier-side reality.** FIPS 205 SLH-DSA IS a NIST standard.
+Magnetar's `Verify` is a thin dispatch over circl's FIPS 205 §10.3
+verifier; a reviewer can cross-check Magnetar threshold-emitted
+bytes against any FIPS 205-conformant verifier. The Magnetar test
+suite's `TestN1_ByteEquality_*` realizes this property empirically.
+This is the strong N1 framing distinction from Corona (which has
+no FIPS standard target to anchor against); it is the same N1
+framing Pulsar uses against FIPS 204.
+
+## Package contents (mapped to NIST IR 8214C requirements)
+
+| NIST requirement | Magnetar artifact |
+|---|---|
+| Technical specification | `SPEC.md` |
+| Open-source reference implementation | `ref/go/pkg/magnetar/` (BSD-3-Clause) |
+| KAT vectors | `vectors/{keygen,sign,verify,threshold-sign,dkg}.json`; deterministic regeneration via `ref/go/cmd/genkat` |
+| Security analysis | `SPEC.md` §6 (Class-N1-analog byte-equality claim) + `SPEC.md` §7 (trust model) + FIPS 205 (NIST standard) for the single-party layer |
+| Patent / IP statement | `PATENTS.md` (royalty-free grant) |
+| Known limitations | `SUBMISSION.md` §"Does NOT claim" + `BLOCKERS.md` |
+| Trust model | `DEPLOYMENT-RUNBOOK.md` (operator-facing); `TRUSTED-COMPUTING-BASE.md` (implementation TCB); `PROOF-CLAIMS.md` (proof scope) |
+| Axiom inventory | `AXIOM-INVENTORY.md` |
+| FIPS traceability | `FIPS-TRACEABILITY.md` (FIPS 205 § → code mapping) |
+| Cryptographer review | `CRYPTOGRAPHER-SIGN-OFF.md` (internal review) |
+| Contact / maintainers | `SUBMISSION.md` §Contact |
+
+## What makes this submission different
+
+1. **Cross-family PQ diversity** — Magnetar is the hash-based PQ
+   threshold leg of the Lux cross-family cert profile. While Pulsar
+   (M-LWE) and Corona (R-LWE) provide lattice-based PQ threshold
+   signing, Magnetar's hash-based foundation means a complete break
+   of the lattice family (M-LWE and R-LWE together) would leave the
+   Magnetar leg sound. The hardness assumption is collision/preimage
+   resistance of the underlying hash (SHAKE for the Magnetar
+   parameter sets), with no lattice dependence.
+
+2. **FIPS-anchored byte equality** — Unlike Corona (which targets a
+   2024 academic R-LWE construction with no NIST standard), Magnetar
+   anchors byte-equality against FIPS 205 SLH-DSA — a published NIST
+   standard. The strong N1 claim form is therefore available;
+   verification against any FIPS 205-conformant verifier is a
+   property the submission asserts and the test suite empirically
+   realizes.
+
+3. **KAT-deterministic Magnetar-SHA3 profile** — Every transcript
+   hash routes through cSHAKE256 / KMAC256 per FIPS 202 + SP 800-185.
+   Customisation tags are pinned (`MAGNETAR-DKG-COMMIT-V1`,
+   `MAGNETAR-DKG-TRANSCRIPT-V1`, `MAGNETAR-SIGN-R1-V1`,
+   `MAGNETAR-SIGN-MASK-V1`, `MAGNETAR-SEED-SHARE-V1`). Re-running
+   `ref/go/cmd/genkat` on a clean checkout produces byte-identical
+   vectors.
+
+4. **Reveal-and-aggregate construction (honest trust caveat)** —
+   Magnetar v0.1 reconstructs the master SLH-DSA seed in
+   aggregator-process memory during each Combine call. This is the
+   same trust model as Pulsar v0.1; documented in
+   `DEPLOYMENT-RUNBOOK.md` with the TEE / mlock / ptrace-off
+   hardening matrix. A v0.2 full-MPC construction is on the research
+   path; the v0.1 byte-equality property is preserved across that
+   migration (the math is unchanged; only the trust placement
+   differs).
+
+5. **Reproducibility-first** — `scripts/cut-submission.sh` and
+   `ref/go/cmd/genkat` are deterministic. KAT regeneration is
+   byte-equal across runs; CI enforces drift = build bug.
+
+6. **Honest gap disclosure** — Magnetar does NOT ship a mechanized
+   refinement proof for the threshold overlay layer. See
+   `PROOF-CLAIMS.md` for the narrow claim and the roadmap. The
+   honest framing: production-hardened FIPS-anchored single-party
+   primitive with a novel reveal-and-aggregate threshold overlay,
+   NOT machine-checked refinement of the threshold overlay against
+   FIPS 205.
+
+## Trust footprint (one-screen summary)
+
+After Magnetar v0.3.0:
+
+| Category | Count / Status |
+|---|---|
+| EasyCrypt files (threshold overlay) | **0** (no mechanized refinement of the overlay layer — see `PROOF-CLAIMS.md` §3.1) |
+| Lean ↔ EC bridge files | **0** specific to Magnetar (Shamir / Lagrange algebraically identical to Pulsar's; cross-citation closure on roadmap) |
+| Jasmin source files (threshold overlay) | **0** (libjade covers FIPS 205 single-party; threshold overlay is pure Go) |
+| Go reference test coverage | single-party + DKG + threshold + Combine + KAT replay; `TestN1_ByteEquality_*` across three configurations |
+| KAT determinism | enforced by deterministic `ref/go/cmd/genkat` regeneration |
+| Constant-time discipline | `ctEqualSlice` / `ctEqual32` on every commit comparison and public-key equality; secret-dependent branches absent from `verify.go`, `sign.go`, and the Combine commit-verify gate. Statistical CT validation (dudect) is roadmap. |
+
+The trust base for Magnetar at submission time reduces to:
+
+- The FIPS 205 SLH-DSA standard (NIST 2024) and its security analysis.
+- The `cloudflare/circl/sign/slhdsa` Go reference implementation
+  (community-audited; standard library-style).
+- The Go reference implementation correctness of the Magnetar
+  threshold overlay (reviewed by code + KATs +
+  `TestN1_ByteEquality_*`).
+- The `crypto/subtle` standard library constant-time helpers.
+- The Go toolchain.
+
+## What this submission does NOT claim
+
+| Out-of-scope claim | Why |
+|---|---|
+| Mechanized refinement of the threshold overlay | Multi-month research project. See `PROOF-CLAIMS.md`, `AXIOM-INVENTORY.md`. |
+| Threshold secrecy without aggregator trust | v0.1 is reveal-and-aggregate; aggregator process is TCB for the seed-reconstruction window. v0.2 (full-MPC) is research. |
+| Statistical constant-time validation (dudect) | Roadmap v0.4+. |
+| ML-KEM-768 envelope wrapping of DKG envelopes | v0.1 envelopes are plaintext (KAT-deterministic); v0.4 closes this. See `BLOCKERS.md` BLK-4. |
+| Reshare protocol (N4-analog) | v0.4 roadmap. See `BLOCKERS.md` BLK-4. |
+| Post-quantum hardness of SLH-DSA itself | Assumed from FIPS 205 + the SHAKE-family analysis. |
+| ACVP/CAVP algorithm validation for the threshold overlay | Not applicable — NIST has no ACVP test vector set for threshold SLH-DSA. |
+| FIPS 140-3 module validation | Downstream — applies to packaged modules. |
+| Asynchronous identifiable abort | Synchronous only. |
+| External cryptographic audit | Internal sign-off only at v0.3.0. See `BLOCKERS.md` BLK-9. |
+
+## Reproducibility commitment
+
+```bash
+git clone --branch submission-2026-11-16 https://github.com/luxfi/magnetar
+cd magnetar
+GOWORK=off go build ./...
+GOWORK=off go test -count=1 -short -timeout 240s ./ref/go/pkg/magnetar/
+GOWORK=off go run ./ref/go/cmd/genkat -out=vectors/  # regenerate KAT vectors
+```
+
+Drift between submission tarball and reproduced output is a build
+bug — please file at the GitHub issues link above. NIST reviewers
+should obtain byte-identical artifacts on reproduction.
+
+## Patent / IP posture (TL;DR)
+
+- **Code**: BSD-3-Clause.
+- **Patents**: Royalty-free grant to any implementation of the
+  Magnetar construction released under BSD-3-Clause or compatible
+  OSI license, OR any NIST MPTC / PQC / ACVP submission /
+  validation / interoperability test.
+- **Defensive termination**: license terminates against any party
+  asserting patents against Magnetar, FIPS 205 SLH-DSA, or any
+  other NIST-standardized PQ signature scheme.
+- **Full text**: `PATENTS.md` §3.
+
+## Contact
+
+| Purpose | Contact |
+|---|---|
+| Submission coordination | `mptc@lux.network` |
+| Patent / IP inquiries | `legal@lux.network` |
+| Security disclosure | `magnetar@lux.network` |
+| Public discussion | <https://github.com/luxfi/magnetar/discussions> |
+| Primary maintainer | `z@lux.network` (Lux Industries, Inc.) |
+
+## Roadmap (v0.4 and beyond)
+
+| Milestone | Target |
+|---|---|
+| Tier A documentation shape complete (this revision) | v0.3.0 |
+| ML-KEM-768 envelope wrapping of DKG Round-1 envelopes (closes passive-network-observer channel) | v0.4.0 |
+| Reshare protocol (Refresh + ReshareToNewSet) — Class N4-analog evidence | v0.4.0 |
+| EasyCrypt theory shells for the threshold overlay (refinement of byte-equality to FIPS 205) | v0.5.0 (research; multi-month) |
+| Lean ↔ EC bridge (cross-citation to Pulsar's Shamir / Lagrange bridges; or Magnetar-specific entries if needed) | v0.5.0 |
+| dudect-style statistical CT validation harness for the threshold overlay | v0.6.0 |
+| External cryptographic audit (engaged lab) | v0.6.0 |
+| v0.2 full-MPC construction (aggregator never sees the master seed) | research, no committed target |
+
+The roadmap is published at `SUBMISSION.md` "What this submission
+does NOT claim" + tracked at the GitHub issues link above.
+
+---
+
+**Document metadata**
+
+- Name: `NIST-SUBMISSION.md`
+- Version: v0.1 (initial Tier A submission-package scaffolding)
+- Date: 2026-05-18
+- Submission package version: Magnetar v0.3.0
@@ -0,0 +1,351 @@
+# PATENTS — Magnetar Threshold SLH-DSA Signature
+
+> **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 `EvalPoint`s; 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).
@@ -0,0 +1,363 @@
+# NIST MPTC Submission — Magnetar
+
+This document is the cover sheet for the **Magnetar** submission to the
+NIST Multi-Party Threshold Cryptography (MPTC) project. It is written
+for NIST reviewers and points at every artifact a reviewer needs.
+
+The `magnetar` repository is the **single canonical home** for the
+submission: it carries the Go reference implementation under
+`ref/go/pkg/magnetar/`, the cover sheet, the construction
+specification, the deterministic KAT generator, the deployment runbook,
+and the high-assurance gate orchestration. A NIST reviewer gets a
+self-contained checkout that does not require network access.
+
+The repository is **active** (not frozen). The submission tarball is
+cut from a tag on `main` at NIST's deadline via
+`scripts/cut-submission.sh`; reviewer feedback and post-submission
+patches land in this same repository so the artifact chain stays
+auditable.
+
+**Date stamp (this revision): 2026-05-18.**
+
+**Maturity stamp**: Tier A documentation shape complete at v0.3.0.
+This submission is **not** NIST-ratified, **not** FIPS 140-3
+validated, **not** ACVP-validated. It IS FIPS-anchored at the
+single-party layer (FIPS 205 SLH-DSA). The threshold-overlay layer
+is novel; the byte-equality property to single-party FIPS 205 is the
+load-bearing N1 claim.
+
+## At a glance
+
+| Field | Value |
+|---|---|
+| Submission name | **Magnetar** |
+| Submitting organisation | Lux Industries, Inc. |
+| Algorithm | Threshold SLH-DSA (FIPS 205) — reveal-and-aggregate over the SLH-DSA scheme seed |
+| Target NIST MPTC classes | **N1** (threshold signing, byte-identical to single-party FIPS 205 SLH-DSA on the reconstructed master seed) + **N4-analog** (multi-party key generation; public-key preservation across resharing is on the v0.4 roadmap) |
+| Underlying construction | FIPS 205 SLH-DSA (single-party layer); v0.1 reveal-and-aggregate Shamir VSS of the SLH-DSA scheme seed over GF(257) (threshold overlay) |
+| Hash family | SHA-3 / SHAKE (FIPS 202) and cSHAKE256 / KMAC256 (SP 800-185) for every Magnetar-specific transcript hash |
+| Parameter sets | SLH-DSA-SHAKE-192s (recommended; NIST PQ Cat 3), SLH-DSA-SHAKE-192f (Cat 3 "fast"), SLH-DSA-SHAKE-256s (Cat 5) |
+| Round count | DKG = 3 rounds (Round-1 deal; Round-2 transcript digest; Round-3 share assembly). Threshold sign = 2 rounds (commit + reveal). |
+| Signature output | **Byte-identical to single-party FIPS 205 `slhdsa.SignDeterministic`** on the reconstructed master seed (the headline N1 claim) |
+| Repository | <https://github.com/luxfi/magnetar> (single canonical home: code, spec, KAT, runbook, cut tool) |
+| Algorithm source | This repository, `ref/go/pkg/magnetar/`. Latest tagged release at this revision: `v0.2.0` (Tier B); this revision targets `v0.3.0` (Tier A documentation shape complete). |
+| Tarball cut tool | `scripts/cut-submission.sh` (tags from `main`, regenerates KATs deterministically, runs the test suite, tars) |
+| Submission tag | `submission-YYYY-MM-DD` (cut from `main` at deadline) |
+| Spec | `SPEC.md` (in-tree construction specification) |
+| License | BSD-3-Clause (code) — see `LICENSE` |
+| Patent posture | **Royalty-free grant** — see `PATENTS.md`. Lux Industries grants a worldwide, royalty-free, irrevocable patent license to any implementation conformant to the Magnetar construction released under BSD-3-Clause or compatible OSI license, OR any NIST MPTC / PQC / ACVP submission, validation, or interoperability test. Defensive termination mirrors Apache-2.0 §3. |
+| Sibling submissions | **Pulsar** ([`luxfi/pulsar`](https://github.com/luxfi/pulsar)) — M-LWE threshold ML-DSA with FIPS 204 byte-equality (Tier A, sister submission). **Corona** ([`luxfi/corona`](https://github.com/luxfi/corona)) — R-LWE threshold (Tier A documentation shape; no FIPS standard target). Independent submissions; reviewable separately. |
+
+## Headline claim
+
+> Every signature produced by a Magnetar threshold ceremony (DKG →
+> Round-1 commit → Round-2 reveal → Combine) is **byte-identical**
+> to the signature single-party FIPS 205
+> `slhdsa.SignDeterministic(slhdsa.Scheme(ID).DeriveKey(S), m, ctx)`
+> would produce on the same reconstructed master seed `S`, message
+> `m`, and context `ctx`. Verification under unmodified FIPS 205
+> `slhdsa.Verify` therefore accepts Magnetar signatures with **no
+> code change**.
+
+This is the Class-N1 byte-equality claim, anchored against FIPS 205
+SLH-DSA (NIST PQ category 3 / 5 stateless hash-based signature
+standard, 2024).
+
+**Verifier-side story (load-bearing for N1 framing).** Because
+FIPS 205 SLH-DSA IS a NIST standard, Magnetar's N1 claim has the
+strong form: a Magnetar threshold signature must verify under any
+FIPS 205-conformant verifier. The Magnetar `verify.go` is a thin
+dispatch over `circl/slhdsa.Verify`, which is the FIPS 205 §10.3
+verifier verbatim. A reviewer can — and the test suite does —
+cross-check Magnetar threshold-emitted bytes against
+`cloudflare/circl`'s FIPS 205 verifier; the byte-identity invariant
+is empirically realized by `TestN1_ByteEquality_*` over
+(committee, threshold) configurations (3,2), (5,3), (7,4).
+
+## Algorithm scope
+
+The algorithm being submitted is the Magnetar implementation at
+`luxfi/magnetar` v0.3.0. The single-party signing primitive is
+FIPS 205 SLH-DSA, **unchanged in its math** (via `cloudflare/circl`'s
+audited Go reference), plus the following production threshold
+lifecycle layers that FIPS 205 does not specify (these are
+Magnetar's contribution to the submission package):
+
+1. **Byte-wise Shamir VSS of the SLH-DSA scheme seed over GF(257)** —
+   `ref/go/pkg/magnetar/shamir.go`. Distributes the 96-byte (192s/192f)
+   or 128-byte (256s) FIPS 205 scheme seed across `n` committee
+   members at reconstruction threshold `t`. The choice of GF(257) is
+   the smallest prime > 255 (so every byte fits as a distinct field
+   element); shares are encoded as one big-endian uint16 per byte
+   position, matching the byte-equal property byte-wise.
+
+2. **Three-round DKG over the scheme seed** — `ref/go/pkg/magnetar/dkg.go`.
+   Round-1 dealers broadcast per-recipient envelopes carrying that
+   recipient's Shamir share plus the dealer's full contribution to
+   the joint seed. Round-2 broadcasts a transcript digest binding
+   the entire ordered envelope set. Round-3 reconciles digests
+   (identifiable abort on equivocation) and computes each party's
+   share of the master byte-sum + the group public key. v0.1 ships
+   plaintext envelopes for KAT determinism; v0.4 wraps them under
+   ML-KEM-768 to recipient identity keys (BLOCKERS.md BLK-4 path,
+   matching Pulsar's CR-8 closure).
+
+3. **Two-round threshold sign with commit-bind reveal** —
+   `ref/go/pkg/magnetar/threshold.go` + `combine.go`. Round-1 each
+   signer commits to `D_i = cSHAKE256(mask || masked_share || tau_1)`
+   where `tau_1 = (sid, attempt, quorum, pk, msg)`. Round-2 reveals
+   `(mask, masked_share)`. Combine re-derives every `D_i` from the
+   reveals, gates each share on `ctEqual32(D'_i, D_i)`, recovers
+   each share via `masked XOR mask`, Lagrange-reconstructs the
+   master byte-sum, applies the cSHAKE256 mix bit-for-bit identical
+   to DKG Round-3, and calls FIPS 205 `SignDeterministic` on the
+   reconstructed seed-derived key.
+
+4. **Identifiable abort with attributable evidence** — `dkg.go`
+   complaint emission (`ComplaintEquivocation` on DKG Round-3 digest
+   mismatch; conflicting digest pair is the evidence blob).
+   `ComplaintBadDelivery` on malformed envelopes. `ComplaintMACFailure`
+   reserved for v0.2 (per-pair MAC layer, currently omitted —
+   reveal-and-aggregate trust model already places the aggregator
+   in the TCB; MACs close a session-bind hole that doesn't matter
+   under v0.1 trust caveat).
+
+5. **Domain-separated hash suite** — `ref/go/pkg/magnetar/transcript.go`
+   centralises every Magnetar cSHAKE256 / KMAC256 call. All cSHAKE
+   function-name `"Magnetar"`; customisation tags
+   `MAGNETAR-DKG-COMMIT-V1`, `MAGNETAR-DKG-TRANSCRIPT-V1`,
+   `MAGNETAR-SIGN-R1-V1`, `MAGNETAR-SIGN-MASK-V1`,
+   `MAGNETAR-SEED-SHARE-V1`. Protocol-wide domain-separation context
+   `lux-magnetar-v0.1`.
+
+## What to read first
+
+A reviewer with limited time should read in this order:
+
+1. **`SUBMISSION.md`** (this file) — submission metadata and headline
+2. **`NIST-SUBMISSION.md`** — one-page executive summary
+3. **`SPEC.md`** — standalone construction specification
+4. **`PROOF-CLAIMS.md`** — what is claimed vs not (HONEST framing — no
+   machine-checked refinement proof at this submission; FIPS-anchored
+   byte-equality empirical at the test-vector level)
+5. **`TRUSTED-COMPUTING-BASE.md`** — implementation TCB (Go +
+   `cloudflare/circl` SLH-DSA + crypto/subtle)
+6. **`FIPS-TRACEABILITY.md`** — FIPS 205 § → code mapping
+7. **`AXIOM-INVENTORY.md`** — construction-level + implementation-level
+   axioms; closure plans for the proof-tier roadmap
+8. **`PATENTS.md`** — royalty-free patent grant text
+9. **`DEPLOYMENT-RUNBOOK.md`** — operator-facing trust-model disclosure
+   (v0.1 reveal-and-aggregate aggregator-as-TCB)
+10. **`BLOCKERS.md`** — Tier B → A path; outstanding gates
+11. **`CRYPTOGRAPHER-SIGN-OFF.md`** — internal review verdict
+12. **`README.md`** — repository layout and how to reproduce
+
+## What to run
+
+The reproducibility gate is `scripts/cut-submission.sh` against the
+tarball extract — the entire submission is self-contained, so no
+network access is required:
+
+```bash
+tar xzf submission-YYYY-MM-DD.tar.gz
+cd magnetar
+GOWORK=off go build ./...
+GOWORK=off go test -count=1 -short -timeout 240s ./ref/go/pkg/magnetar/
+GOWORK=off go run ./ref/go/cmd/genkat -out=vectors/   # regenerate KATs deterministically
+```
+
+The test suite includes `TestN1_ByteEquality_ThresholdMatchesCentralized`
+(across (3,2), (5,3), (7,4) configurations) and
+`TestN1_ByteEquality_DifferentQuorumsSameSignature` (the same DKG
+output under two distinct signing quorums yields byte-identical
+signatures). Both are the load-bearing N1 evidence.
+
+To cut a fresh tarball (maintainer-side):
+
+```bash
+scripts/cut-submission.sh                       # dry-run, no tarball
+scripts/cut-submission.sh submission-2026-11-16 # production cut + tag
+```
+
+The cut script verifies a clean tree, regenerates KATs from the
+in-tree canonical implementation, re-runs the test suite (including
+N1 byte-equality), tars the entire submission checkout, and prints
+the SHA-256.
+
+## Class N1 — Byte-equal to single-party FIPS 205
+
+The N1 claim is asserted at **three** levels of evidence (one fewer
+than Pulsar at full Tier A; the missing level is the machine-checked
+refinement chain — EC theory shells for the threshold overlay layer
+remain a roadmap item, multi-month research):
+
+| Evidence | Where |
+|---|---|
+| Algorithmic argument | `SPEC.md` §6 (Class-N1-analog byte-equality claim) + the construction-equivalence proof sketch |
+| Test harness | `ref/go/pkg/magnetar/n1_byte_equality_test.go` — three (committee, threshold) configurations; byte-identity asserted via `bytes.Equal` |
+| KAT determinism | `vectors/{keygen,sign,verify,threshold-sign,dkg}.json` regenerated deterministically by `ref/go/cmd/genkat` |
+| Cross-implementation verifier | Magnetar's `Verify` is a thin dispatch over `cloudflare/circl/sign/slhdsa.Verify`, which is the FIPS 205 §10.3 verifier verbatim. Any FIPS 205-conformant verifier accepts Magnetar threshold-emitted bytes. |
+
+**What Magnetar DOES NOT yet provide vs Pulsar Tier A**:
+
+- No EasyCrypt refinement chain for the threshold overlay layer.
+  (FIPS 205 SLH-DSA itself has the libjade formal artifacts available
+  for the single-party layer; the threshold overlay is novel and
+  not yet mechanized. See `AXIOM-INVENTORY.md` §2 closure plan.)
+- No Lean ↔ EC algebraic bridge files specific to Magnetar. (Magnetar's
+  Shamir / Lagrange operations are algebraically identical to
+  Pulsar's GF(257) variant; cross-citation to Pulsar's
+  `proofs/lean-easycrypt-bridge.md` is the closure target, see
+  `AXIOM-INVENTORY.md` §2.)
+- No Jasmin high-assurance implementation of the threshold overlay.
+  (libjade covers SLH-DSA single-party; the threshold overlay is
+  pure Go.)
+- No machine-checked `Class N1 byte-equality` theorem for the
+  threshold overlay layer.
+
+The honest framing for Magnetar is: **production-hardened
+implementation of a FIPS-anchored single-party primitive with a
+novel reveal-and-aggregate threshold overlay**, NOT
+**machine-checked refinement against FIPS 205**. The mechanized
+proof tier for the threshold overlay remains a roadmap item; see
+`PROOF-CLAIMS.md` for the narrow stated claim and the closure path.
+
+## Class N4-analog — Public-key preservation across resharing
+
+Multi-party reshare with public-key preservation is on the v0.4
+roadmap (see `BLOCKERS.md` BLK-4 "Reshare protocol"). The v0.1
+construction supports DKG → threshold-sign → Combine but does NOT
+ship a `Refresh` or `ReshareToNewSet` primitive. Class N4 framing
+is therefore "**N4-analog**" at v0.3.0: the construction admits a
+reshare protocol with the same byte-equality property to FIPS 205
+under the reconstructed seed, but the protocol itself is not yet
+implemented.
+
+The N4-equivalent claim, when v0.4 lands, will state: any DKG share
+set can be `Refresh`-rotated (same committee, fresh shares) or
+`ReshareToNewSet`-rotated (committee rotation) such that any
+post-reshare threshold-sign produces signatures verifiable under
+the byte-identical unchanged group public key.
+
+## High-assurance track — HONEST DELTA vs Pulsar
+
+Pulsar ships an EasyCrypt + Lean + Jasmin high-assurance track that
+mechanically refines its Class N1 byte-equality claim against a
+formal model of FIPS 204. **Magnetar does NOT ship that.** The
+honest delta:
+
+| Pulsar artifact | Magnetar equivalent | Status |
+|---|---|---|
+| 13/13 EasyCrypt files compile, 0/0 admits (refinement chain) | none | NOT PRESENT — threshold-overlay EC theory shells are roadmap v0.4+, multi-month research project, see `AXIOM-INVENTORY.md` §2 |
+| 5/5 Lean ↔ EC algebraic-bridge files | none specific to Magnetar | NOT PRESENT — Shamir / Lagrange algebraically identical to Pulsar's GF(257) variant; cross-citation closure on roadmap, see `AXIOM-INVENTORY.md` §2 |
+| 3/3 jasmin-ct blocking on threshold layer | none for the threshold overlay | NOT PRESENT — libjade covers FIPS 205 SLH-DSA single-party; threshold overlay is pure Go |
+| Class N1 byte-equality theorem (mechanized) | empirical byte-equality at the test-vector level only | NOT MECHANIZED — see `PROOF-CLAIMS.md` §3 |
+| `cloudflare/circl` FIPS 205 cross-validation | `Verify` dispatches to circl's FIPS 205 verifier; `TestN1_ByteEquality_*` is the load-bearing harness | PRESENT — circl is the canonical Go FIPS 205 implementation |
+
+What Magnetar DOES offer at this submission-time:
+
+1. **Production-hardened reference implementation** in Go
+   (`ref/go/pkg/magnetar/`, ~2200 LOC). Single-party + DKG +
+   threshold sign + Combine. Three FIPS 205 parameter sets.
+2. **KAT-deterministic outputs** under the Magnetar hash suite
+   (cSHAKE256 / KMAC256 per FIPS 202 + SP 800-185). Vectors at
+   five profiles: keygen, sign, verify, threshold-sign, dkg.
+   Deterministic regeneration via `ref/go/cmd/genkat`.
+3. **Byte-identity N1 evidence**:
+   `TestN1_ByteEquality_ThresholdMatchesCentralized` proves at three
+   configurations that threshold-Combine output is byte-equal to
+   single-party `slhdsa.SignDeterministic` on the same seed.
+4. **Identifiable-abort evidence pipeline** at the DKG layer
+   (`ComplaintEquivocation` carries the conflicting digest pair).
+5. **Honest gap disclosure** — `PROOF-CLAIMS.md` §3 enumerates every
+   property NOT proved; `BLOCKERS.md` enumerates the Tier B → A gates.
+6. **Reproducibility commitment** — `scripts/cut-submission.sh` is
+   deterministic from fixed seeds; the KAT generator's output is
+   byte-stable across runs.
+
+## What this submission does NOT claim
+
+- **No formal mechanized refinement** of the threshold overlay layer
+  against FIPS 205. EasyCrypt / Lean / Jasmin theories for the
+  Magnetar threshold layer are roadmap items, multi-month research.
+  See `PROOF-CLAIMS.md` §3.1 and `AXIOM-INVENTORY.md` §2.
+- **No threshold secrecy without aggregator trust.** Magnetar v0.1 is
+  reveal-and-aggregate: the aggregator process holds the reconstructed
+  master seed in memory for the duration of one Combine call. This is
+  the same trust caveat Pulsar v0.1 carries; documented in
+  `DEPLOYMENT-RUNBOOK.md` with the TEE / mlock / ptrace-off hardening
+  matrix. A v0.2 full-MPC construction (aggregator never sees the seed)
+  is on the research path; see `BLOCKERS.md`.
+- **No statistical constant-time validation (dudect)** of the threshold
+  layer. The Magnetar threshold-layer code paths use constant-time
+  primitives (`ctEqual32` / `ctEqualSlice`) for every commit verification
+  and key equality check, but no statistical timing harness ships at
+  v0.3.0. Roadmap v0.4+. See `PROOF-CLAIMS.md` §3.4.
+- **No ML-KEM-768 envelope wrapping** of DKG Round-1 envelopes in
+  v0.1 — envelopes are plaintext. A passive network observer can see
+  the per-recipient share + dealer contribution. v0.4 closes this
+  channel by wrapping envelopes under recipient identity keys (matching
+  Pulsar's CR-8 closure). See `BLOCKERS.md` BLK-4.
+- **No reshare protocol** in v0.1. Class N4-analog will be claimed at
+  v0.4 when `Refresh` and `ReshareToNewSet` primitives land. See
+  `BLOCKERS.md` BLK-4.
+- **No external cryptographic audit.** Internal cryptographer
+  sign-off (`CRYPTOGRAPHER-SIGN-OFF.md`) is the v0.3.0 review; an
+  external lab engagement is roadmap, see `BLOCKERS.md` BLK-9.
+- **No FIPS 140-3 module validation** — applies to packaged
+  cryptographic modules, not this reference implementation. Downstream
+  of this submission.
+- **No ACVP / CAVP algorithm validation certificate** for the
+  threshold layer — no NIST ACVP test vector set exists for
+  threshold SLH-DSA. The single-party FIPS 205 layer in `cloudflare/circl`
+  is independently ACVP-testable; the threshold overlay is not.
+- **No identifiable abort under network partition** — synchronous
+  network assumption only; asynchronous identifiable abort is a
+  separate problem.
+- **No post-quantum hardness claim beyond FIPS 205's analysis.**
+  SLH-DSA's security rests on collision/preimage resistance of the
+  underlying hash (SHAKE for the Magnetar parameter sets); NIST's
+  FIPS 205 analysis is the substrate.
+
+## Comparison to sibling and related submissions
+
+| Submission | Hardness basis | Round count | Output story | NIST class |
+|---|---|---|---|---|
+| **Magnetar** (this) | Hash-based (FIPS 205 SLH-DSA collision/preimage resistance) | DKG=3 + sign=2 | **Byte-equal to single-party FIPS 205 SLH-DSA on reconstructed seed** | N1 (+ N4-analog at v0.4) |
+| **Pulsar** ([`luxfi/pulsar`](https://github.com/luxfi/pulsar)) | Module-LWE (FIPS 204 ML-DSA) | 2 | Byte-equal to FIPS 204 ML-DSA-65 | N1 + N4 |
+| **Corona** ([`luxfi/corona`](https://github.com/luxfi/corona)) | Ring-LWE (Boschini et al. ePrint 2024/1113) | 2 | Construction-level interchangeable; no NIST standard target | N1 + N4 |
+| FROST (academic upstream) | Discrete log / Schnorr | 2 | EdDSA-compatible | not MPTC |
+
+The hash-based / M-LWE / R-LWE triple is intentional. Lux's Polaris
+cert profile MAY combine Magnetar (hash-based) and Pulsar (M-LWE)
+and Corona (R-LWE) as a **cross-family** layered defence so a break
+in any single family (lattice or hash) does not break finality.
+That layered combination is the consumer's design choice and is
+not part of this submission. Magnetar stands alone as an MPTC
+Class N1 candidate (with N4-analog roadmap).
+
+## Contact
+
+- Primary: <z@lux.network> (Lux Industries, Inc.)
+- Submission coordination: <mptc@lux.network>
+- Security disclosure: see `SECURITY.md` (when present) or
+  `magnetar@lux.network`
+- Public discussion: <https://github.com/luxfi/magnetar/discussions>
+
+## Reproducibility commitment
+
+The build, test, and vector-generation scripts are deterministic
+from fixed seeds. A reviewer reproducing the submission tarball
+from `submission-YYYY-MM-DD` should obtain byte-identical artifacts.
+Drift is a build bug; please open an issue.
+
+---
+
+**Document metadata**
+
+- Name: `SUBMISSION.md`
+- Version: v0.1 (initial Tier A submission-package scaffolding)
+- Date: 2026-05-18
+- Submission package version: Magnetar v0.3.0 (Tier A documentation
+  shape complete)
+- Underlying library version at this revision: `luxfi/magnetar v0.3.0`