docs: graduate from Tier C → Tier B

v0.2.0 reaches Tier B: production library + submission scaffold
landed (v0.1 reveal-and-aggregate construction shipped in
ref/go/pkg/magnetar/ with KAT vectors). Mechanized refinement +
independent audit remain on the roadmap to Tier A.

Changes:

- README.md: flip status to Tier B. Document the v0.1 reveal-and-
  aggregate construction, the Class-N1-analog byte-equality claim,
  and the v0.1 trust caveat. List what v0.2.0 ships and what does
  NOT ship (formal proofs, ct analysis, KEM-wrapped envelopes,
  independent review, full 16-doc submission package).

- SUBMISSION-STATUS.md: flip to Tier B. Phase 1 (construction
  selection) + Phase 2 (reference implementation) marked DONE.
  Phase 3 (proof artifacts, BLK-7), Phase 4 (16-doc submission
  package, BLK-8), Phase 5 (independent review, BLK-9) remain
  open. NIST MPTC v0.3 target window held (2027 Q3 internal).

- BLOCKERS.md: BLK-1 (construction selection), BLK-2 (academic
  basis), BLK-3 (spec definition) marked CLOSED with the
  reveal-and-aggregate selection documented and the citation gap
  honestly acknowledged. BLK-4 (ref impl) marked PARTIAL — v0.1
  shipped, missing pieces (KEM-wrapped envelopes, reshare, MACs,
  large-committee path) called out. BLK-5 (KAT vectors) CLOSED.
  BLK-6/7/8/9 (interop, proofs, package, review) remain OPEN with
  updated status.

- SPEC.md (NEW): construction specification for v0.1 reveal-and-
  aggregate. Covers notation, hash domain separation, DKG protocol
  (Round 1/2/3), threshold signing (Round 1/2/Combine), Class-N1-
  analog byte-equality claim with proof sketch, trust model
  disclosure, identifiable abort taxonomy, parameter sets,
  honest non-claims.

- DEPLOYMENT-RUNBOOK.md (NEW): operator-facing trust-model
  disclosure mirroring Pulsar's runbook. The v0.1 reveal-and-
  aggregate aggregator-as-TCB caveat is identical to Pulsar's;
  same hardening matrix (TEE / mlock / ptrace-off / short-lived
  aggregator process). Lists what the caveat does NOT cover
  (Byzantine committee members, Byzantine aggregator forging
  unsigned messages, passive network observers). Honest
  non-warranties section: no independent review, no formal
  proofs, no production Lux deployment yet.

DESIGN.md left untouched — it represents the original research-
direction sketch and is preserved as a historical record.

BLOCKERS.md

@@ -1,104 +1,171 @@
 # Magnetar — Blockers to NIST MPTC submission
 
-> Honest enumeration of what blocks Magnetar from moving Tier C →
-> Tier B → Tier A on the submission-readiness ladder. This is the
-> path-to-production register; see `SUBMISSION-STATUS.md` for the
-> tier definitions and phased plan.
+> Honest enumeration of what blocks Magnetar from moving Tier B →
+> Tier A on the submission-readiness ladder.
+>
+> **As of v0.2.0**: Tier C → Tier B blockers (BLK-1, BLK-2, BLK-3)
+> are **CLOSED**. Tier B → A blockers (BLK-4 through BLK-9) are
+> partially or fully open; see status below. See `SPEC.md` for the
+> selected construction, `SUBMISSION-STATUS.md` for tier definitions
+> and the phased plan.
 
-## Tier C → Tier B blockers (construction-level)
+## Tier C → Tier B blockers (construction-level) — CLOSED v0.2.0
 
-### BLK-1 — Construction not selected
+### BLK-1 — Construction not selected → **CLOSED**
 
-No fixed threshold-SLH-DSA protocol. Multiple candidates exist
-in the literature:
+**Resolution**: v0.1 reveal-and-aggregate construction selected
+(see `SPEC.md` §3-§4). Among the three candidates surveyed:
 
-- **Komlo/Goldberg-style FROST-of-SLH-DSA** — would mirror Pulsar's
-  protocol shape but SLH-DSA's hash-tree traversal has no linear-
-  aggregation identity. Cannot produce byte-equal FIPS 205
-  signatures from threshold inputs.
-- **Full-MPC hash-computation** — run every SHAKE / SHA-2 inside
-  MPC. Slow (per-signature MPC ceremony dominates) but correct.
-- **Threshold seed-DKG + batched per-signature ceremony** —
-  hybrid: distribute seed via VSS, batch per-signature
-  reconstruction.
+- ~~Komlo/Goldberg-style FROST-of-SLH-DSA~~ — rejected. SLH-DSA's
+  hash-tree traversal has no linear-aggregation identity at the
+  signature level, so byte-equal FIPS 205 output from threshold
+  Lagrange-of-z is not possible. The Pulsar protocol shape does
+  NOT transfer.
+- ~~Full-MPC hash-computation~~ — deferred. Per-signature MPC
+  ceremony cost dominates deployment economics for the v0.1
+  timeline; deferred to v0.2 research.
+- ✅ **Threshold seed-DKG + reveal-and-aggregate** — selected.
+  Distribute SLH-DSA scheme seed via byte-wise Shamir VSS over
+  GF(257). Each Combine reconstructs the seed in aggregator memory,
+  calls single-party `slhdsa.SignDeterministic`, zeroizes. Signature
+  is byte-identical to centralized FIPS 205.
 
-Each has different security models, performance, and proof
-obligations. Selection requires research, not engineering.
+The honest trust caveat: aggregator process is TCB for the brief
+seed-reconstruction window. Same caveat as Pulsar v0.1; documented
+in `DEPLOYMENT-RUNBOOK.md`.
 
-### BLK-2 — Reference paper / academic basis
+### BLK-2 — Reference paper / academic basis → **CLOSED (with caveat)**
 
-The threshold-SLH-DSA literature is sparse compared to threshold-
-Schnorr / threshold-Lattice. Magnetar's construction MUST cite a
-peer-reviewed paper as its academic basis (analogous to Pulsar's
-ePrint 2024/1113 for the Corona-family). Without this, the
-construction risks being unreviewed work.
+**Resolution**: the construction-equivalence argument is inherited
+from Pulsar's v0.1 reveal-and-aggregate pattern, which itself
+adapts the standard byte-wise Shamir VSS literature (Shamir 1979,
+Pedersen VSS, Feldman VSS) to a FIPS 204 / FIPS 205 seed.
 
-### BLK-3 — Spec definition
+**Open citation gap**: there is no peer-reviewed paper specifically
+targeting threshold-SLH-DSA reveal-and-aggregate. Magnetar inherits
+the security argument from the equivalence to a centralized signer
+(aggregator with the master seed). When the v0.2 full-MPC
+construction matures, a new peer-reviewed paper SHOULD be authored.
 
-No `SPEC.md` exists. Spec authoring is blocked on BLK-1
-(construction selection).
+### BLK-3 — Spec definition → **CLOSED**
 
-## Tier B → Tier A blockers (engineering-level)
+**Resolution**: `SPEC.md` ships in v0.2.0. Covers notation,
+hash domain separation, DKG protocol, threshold signing,
+Class-N1-analog byte-equality claim, trust model, identifiable
+abort, parameter sets, and honest non-claims.
 
-These activate once BLK-1, BLK-2, BLK-3 close.
+## Tier B → Tier A blockers (engineering- and formal-methods-level)
 
-### BLK-4 — Reference implementation
+### BLK-4 — Reference implementation → **PARTIAL: shipped v0.2.0**
 
-No Go implementation. Layout: `ref/go/pkg/magnetar/` mirroring
-Pulsar. Estimated 4-8 weeks once construction frozen.
+**Status**: `ref/go/pkg/magnetar/` ships in v0.2.0:
 
-### BLK-5 — KAT vectors
+- ✅ params.go, types.go, transcript.go, zeroize.go, shamir.go
+- ✅ keygen.go, sign.go, verify.go
+- ✅ dkg.go (DKG protocol)
+- ✅ threshold.go, combine.go (threshold-sign + Combine)
+- ✅ Three parameter sets: SHAKE-192s, SHAKE-192f, SHAKE-256s
 
-Deterministic KAT generator + replay tests. Cannot exist without
-implementation.
+**What's not yet in v0.2.0** (for v0.3+):
 
-### BLK-6 — Cross-validation harness
+- ML-KEM-768 wrapping of DKG envelopes (closes passive-network
+  channel; v0.1 envelopes are plaintext).
+- Reshare protocol (zero-secret-refresh rotation of shares).
+- Per-pair MACs for the threshold-sign rounds (Pulsar CR-7 analog).
+- Large-committee path (n > 256; v0.1 caps at GF(257) party-count
+  limit).
 
-Third-party FIPS 205 verifier integration (cloudflare/circl, pq-
-crystals reference) for the threshold-output-verifies-under-
-unmodified-FIPS-205 claim (analog of Pulsar's Class N1 evidence).
+### BLK-5 — KAT vectors → **CLOSED**
 
-### BLK-7 — Proof artifacts
+**Resolution**: `vectors/{keygen,sign,verify,threshold-sign,dkg}.json`
+ship in v0.2.0. Deterministic regeneration via `cmd/genkat`.
+Re-running on a clean checkout produces byte-identical output.
 
-- EasyCrypt theories for threshold-SLH-DSA correctness
-- Lean bridges for the algebraic identities (TBD — SLH-DSA is hash-
-  based, the bridge story is different from lattice schemes)
-- Jasmin constant-time analysis of the per-signature MPC ceremony
+The KAT replay tests in `kat_test.go` validate that the package
+implementation reproduces every KAT entry verbatim. This is the
+analog of Pulsar's KAT-determinism gate.
 
-Hash-based constructions have well-developed CT analysis pipelines
-(libjade SLH-DSA exists), so the single-party CT side is upstream-
-ready. The threshold MPC overlay is novel work.
+### BLK-6 — Cross-validation harness → **OPEN**
 
-### BLK-8 — Submission package documentation
+**Status**: the package's `Verify` function dispatches to
+`circl/slhdsa.Verify`, which IS the FIPS 205 reference verifier
+(cloudflare/circl is the only mainstream Go FIPS 205 implementation).
+Threshold-produced signatures verify under unmodified circl
+slhdsa.Verify — see `n1_byte_equality_test.go`.
 
-16-doc mirror of Pulsar's structure adapted to Magnetar specifics.
-Blocked on BLK-1 + BLK-4.
+**What remains**:
 
-### BLK-9 — Independent cryptographer review
+- A cross-implementation harness that verifies Magnetar-produced
+  signatures under an independent FIPS 205 implementation (e.g.,
+  the pq-crystals reference C code, or BoringSSL's SLH-DSA when
+  available). Pure interop testing with no code shared.
+- IETF / NIST ACVP integration would slot here.
 
-Independent reviewer must attest construction + impl + proofs +
-tests. Blocked on BLK-1 through BLK-8.
+### BLK-7 — Proof artifacts → **OPEN (multi-month)**
+
+**Status**: none ship in v0.2.0.
+
+**What's needed**:
+
+- **EasyCrypt theories**: correctness of byte-wise Shamir
+  reconstruction over GF(257); equivalence of threshold Combine to
+  centralized `KeyFromSeed(reconstructed_seed) → SignDeterministic`.
+- **Lean bridges**: TBD. SLH-DSA is hash-based; the bridge story
+  differs from lattice schemes. May reuse libjade's SLH-DSA
+  formal artifacts for the single-party layer; the threshold
+  overlay is novel work.
+- **Jasmin constant-time analysis**: of `dkg.go`, `threshold.go`,
+  `combine.go`, `shamir.go`. The single-party SLH-DSA CT side is
+  upstream-ready via libjade.
+
+Multi-month research. Tier A submission depends on at least the
+EasyCrypt correctness theorem.
+
+### BLK-8 — Submission package documentation → **OPEN (depends on BLK-7)**
+
+**Status**: `SPEC.md` + `DEPLOYMENT-RUNBOOK.md` + `BLOCKERS.md` +
+`SUBMISSION-STATUS.md` ship in v0.2.0. The remaining 12 documents
+in the Pulsar template (NIST-SUBMISSION.md, PATENTS.md,
+PROOF-CLAIMS.md, AXIOM-INVENTORY.md, FIPS-TRACEABILITY.md,
+TRUSTED-COMPUTING-BASE.md, CHANGELOG.md, docs/* mirror) are
+deferred to the Tier A submission package. Several depend on
+BLK-7 outputs.
+
+### BLK-9 — Independent cryptographer review → **OPEN**
+
+**Status**: no independent review of v0.2.0 has occurred.
+
+**What's needed**: same model as Pulsar's
+`CRYPTOGRAPHER-SIGN-OFF.md` — independent reviewer attests
+construction + impl + proofs + tests. Output:
+`CRYPTOGRAPHER-SIGN-OFF.md` matching Pulsar's structure.
+
+Blocked on BLK-7 and BLK-8 being complete enough for the reviewer
+to evaluate the formal correctness + the submission package.
 
 ## Non-blockers
 
 These are NOT blockers — they are deliberate non-claims that
-Magnetar will continue to make even at Tier A:
+Magnetar will continue to make at Tier A:
 
-- **Byte-equal to single-party FIPS 205**: SLH-DSA's hash-tree
-  traversal precludes this. Magnetar will instead claim
-  "verifies under unmodified FIPS 205 given seed-DKG soundness"
-  (a strictly weaker but still well-defined claim).
-- **Sub-second per-signature**: per-signature MPC ceremony is
-  hash-dominated; production deployment will batch / amortize but
-  Magnetar will not pretend to match Pulsar's signing throughput.
+- **Byte-equal across full-MPC and reveal-and-aggregate**:
+  Magnetar v0.1 reveal-and-aggregate IS byte-equal to centralized
+  FIPS 205. A future v0.2 full-MPC would also be byte-equal IF the
+  hash-tree computations under MPC are deterministic, but
+  Magnetar will not pretend the two constructions share the same
+  security model — the trust caveat differs.
+- **Sub-second per-signature**: SLH-DSA single-party signing on
+  SHAKE-192s is ~50-100ms on commodity hardware; the threshold
+  Combine layer adds ~10-20ms of Shamir reconstruction. Magnetar
+  will not pretend to match Pulsar's signing throughput.
 - **Production-ready before 2027**: see `SUBMISSION-STATUS.md`
   target window.
 
 ## Cross-references
 
-- `README.md` — repo purpose + status
-- `DESIGN.md` — research direction
+- `README.md` — repo purpose + status (v0.2.0 = Tier B)
+- `SPEC.md` — construction specification (v0.2.0 landed)
+- `DEPLOYMENT-RUNBOOK.md` — operator-facing trust-model disclosure (v0.2.0 landed)
 - `SUBMISSION-STATUS.md` — tier definitions + phased plan
 - [`luxfi/pulsar`](https://github.com/luxfi/pulsar) — Tier A template
-- [`luxfi/quasar`](https://github.com/luxfi/quasar) — Polaris profile
-  cannot deploy until Magnetar matures to Tier A
+- [`luxfi/quasar`](https://github.com/luxfi/quasar) — Polaris profile cannot deploy until Magnetar matures to Tier A

DEPLOYMENT-RUNBOOK.md

@@ -0,0 +1,112 @@
+# Magnetar v0.1 — Deployment runbook
+
+> Operator-facing trust-model disclosure and hardening guidance for
+> Magnetar v0.1. **READ THIS BEFORE DEPLOYING.**
+
+## 1. v0.1 reveal-and-aggregate trust caveat — single biggest disclosure
+
+**The Magnetar v0.1 aggregator process holds the reconstructed master SLH-DSA seed in memory for the duration of one `Combine` call.**
+
+This is the v0.1 reveal-and-aggregate trust model. It is identical to Pulsar's v0.1 reveal-and-aggregate trust model. The construction is **honest** about this: the security properties below are precisely what v0.1 delivers, and the path to v0.2 (true MPC, aggregator never sees the seed) is in `BLOCKERS.md`.
+
+### What this means operationally
+
+During a `Combine` call (typically ≤100 ms for SHAKE-192s on commodity hardware), the following secret material is live in the aggregator process's address space:
+
+| Buffer | Lifetime | Wiped by |
+|---|---|---|
+| `master_seed` (96 / 128 bytes) | ~ duration of one `slhdsa.SignDeterministic` call | `zeroizeBytes` at every return path in `combine.go` |
+| `sk_rec` (96 / 128 bytes) | ~ duration of one `slhdsa.SignDeterministic` call | `zeroizePrivateKey` |
+| `byteSum_bytes` (2×seed_size bytes) | from share Lagrange reconstruction to mix completion | `zeroizeBytes` |
+| `mixInput` (2×seed_size + 32 bytes) | from mix construction to cSHAKE output | `zeroizeBytes` |
+
+During this window, an adversary with one of the capabilities below can extract `master_seed` (and therefore forge arbitrary future signatures under the group key):
+
+- arbitrary-code-execution on the aggregator host
+- `/proc/<pid>/mem` read of the aggregator process
+- a coredump triggered during a Sign call
+- a swap-file or hibernation image written to disk
+- `ptrace` attached to the aggregator process
+- a malicious kernel or hypervisor
+
+### Hardening matrix
+
+| Mitigation | What it protects against | How to enable |
+|---|---|---|
+| **TEE (SGX / SEV-SNP / TDX)** | malicious kernel/hypervisor, /proc/<pid>/mem from outside the enclave | run aggregator inside a confidential VM or enclave |
+| `mlock` the secret buffers | swap / hibernation | the Go runtime does not expose `mlock`; deploy with `vm.swappiness=0` + `swapoff` |
+| `prctl(PR_SET_DUMPABLE, 0)` | coredumps | set ulimit core 0 (`ulimit -c 0`), set `/proc/sys/kernel/core_pattern` to disable cores, or run inside a container with `--security-opt no-new-privileges` |
+| ptrace-off (Yama LSM `kernel.yama.ptrace_scope=3`) | local ptrace attach | sysctl on the aggregator host |
+| Aggregator is a **short-lived process** (one Sign per process invocation, then exit) | post-mortem analysis of the long-lived process | wrap aggregator behind a per-Sign exec spawn |
+| Hardware HSM-backed aggregator | host compromise | offload `slhdsa.SignDeterministic` to an HSM — note: most commodity HSMs do not yet ship SLH-DSA |
+
+The Pulsar v0.1 deployment runbook mandates **TEE + mlock + ptrace-off** as the baseline; Magnetar v0.1 inherits the same requirement.
+
+### What this caveat does NOT cover (safe by construction)
+
+- A **single Byzantine committee member** cannot forge a signature. Forging requires `t` valid Round-2 reveals, which requires `t` honest signers to participate.
+- A **single Byzantine aggregator** cannot forge a signature for a message that did not receive `t` Round-2 reveals. `Combine`'s commit-bind check (re-derives each `D'_i` from the reveal and compares to the Round-1 broadcast `D_i`) rejects tampered reveals at constant-time check.
+- A **passive network observer** does NOT see the reconstructed seed. v0.1 envelopes are plaintext, so a passive observer can collect Shamir shares (one per committee member, but at most one share value per dealer-recipient pair); reconstructing the seed requires the EvalPoint directory + at least `t` distinct envelopes from a single dealer. v0.2 closes this with ML-KEM-768 envelope wrapping.
+- The **wire signature** is byte-equal to single-party FIPS 205. Any unmodified FIPS 205 verifier (including stock SLH-DSA validators in standard libraries) accepts Magnetar signatures with no code change.
+
+## 2. Aggregator role assignment
+
+Any party in the quorum (or an external third-party aggregator) can call `Combine`. The protocol does not assume a specific aggregator; the aggregator's identity is not bound into the signature.
+
+**Recommendation:** rotate aggregator role across signing requests to minimise the seed-exposure window on any single host. A leader-rotation pattern over committee members (round-robin keyed by `session_id`) is a reasonable v0.1 default.
+
+## 3. DKG ceremony procedure
+
+1. **Committee membership freeze.** All `n` committee members must agree on the committee NodeID set BEFORE Round 1. Committee membership is bound into the transcript digest at DKG Round 2; mid-ceremony additions are rejected.
+2. **Per-party entropy.** Each party MUST use a cryptographically secure RNG for `NewDKGSession.rng`. Reusing entropy across DKG ceremonies leaks contributions.
+3. **Round-1 envelope authenticity.** v0.1 envelopes are NOT KEM-wrapped — the network layer MUST authenticate dealers (TLS, sigs, gossip auth) to prevent forged envelopes. v0.2 adds ML-KEM-768 wrapping.
+4. **Round-2 digest agreement.** Honest parties detect dealer equivocation when their Round-3 local digest disagrees with any received Round-2 digest. The `ComplaintEquivocation` AbortEvidence is produced; protocol-layer drivers MUST broadcast this for slashing.
+
+## 4. Threshold-sign ceremony procedure
+
+1. **Quorum freeze.** All `t` quorum members must agree on the quorum NodeID set BEFORE Round 1. Quorum is bound into the `τ_1` transcript; mid-ceremony quorum changes are rejected.
+2. **Per-attempt RNG.** Each `ThresholdSigner` MUST use a fresh RNG state per (session_id, attempt) pair. Reusing RNG across attempts gives the same mask, which leaks the share to anyone observing the Round-2 reveal.
+3. **Round-2 timing.** Round-2 messages SHOULD be released only after every quorum member's Round-1 commit is in hand. This is a protocol invariant; if Round-2 is released early, an attacker can fork the session at Round 1 and extract two distinct shares from the same party (a forgery vector).
+4. **Aggregator hardening.** The aggregator host MUST follow §1 hardening (TEE + mlock + ptrace-off baseline).
+
+## 5. Key-share storage
+
+`KeyShare` is a long-lived secret. Storage requirements:
+
+- Encrypt-at-rest with a host-bound key (TPM-sealed, or KMS-wrapped under the host's identity attestation).
+- NEVER write `KeyShare.Share` to disk in plaintext.
+- Recommended: hold `KeyShare` in a TEE that performs the Round-1/Round-2 computation; the host process never touches the share bytes.
+
+## 6. Quorum rotation / resharing
+
+Magnetar v0.1 does NOT ship resharing. Once a committee is bootstrapped via DKG, the only way to rotate is to run a fresh DKG (producing a new group public key).
+
+v0.2 will ship zero-secret-refresh resharing matching Pulsar's resharing pattern.
+
+## 7. Honest non-warranties
+
+Magnetar v0.1 is shipped under the BSD-3-Clause license with NO WARRANTY. In particular:
+
+- **No independent cryptographic review** of the v0.1 protocol has occurred. See `BLOCKERS.md` BLK-9.
+- **No EasyCrypt / Lean / Jasmin proofs** ship in v0.1. See `BLOCKERS.md` BLK-7.
+- **No constant-time analysis** of the threshold layer has been conducted under `dudect` or formal tooling.
+- **No NIST MPTC submission** has been made.
+- **No production Lux deployment** uses Magnetar v0.1. The Polaris profile in `luxfi/quasar` references Magnetar at Tier A; v0.1 reaches Tier B only.
+
+Operators deploying Magnetar v0.1 do so at their own risk and SHOULD layer it with Pulsar (Tier A production primitive) under a cross-family cert profile rather than as the sole signing scheme.
+
+## 8. Cross-references
+
+- `SPEC.md` — full protocol specification
+- `BLOCKERS.md` — Tier B → A path
+- `SUBMISSION-STATUS.md` — NIST MPTC submission status
+- [`luxfi/pulsar/DEPLOYMENT-RUNBOOK.md`](https://github.com/luxfi/pulsar/blob/main/DEPLOYMENT-RUNBOOK.md) — sibling runbook for the threshold M-LWE primitive
+
+---
+
+**Document metadata**
+
+- File: `DEPLOYMENT-RUNBOOK.md`
+- Version: v0.1
+- Date: 2026-05-18
+- Status: operator-facing trust-model disclosure

README.md

@@ -1,19 +1,44 @@
 # Magnetar — Threshold SLH-DSA (FIPS 205)
 
-> **Research-stage construction.** Threshold hash-based PQ signature
-> primitive over FIPS 205 SLH-DSA. Not production-ready. Not part of
-> any current NIST submission. See `DESIGN.md` for the research
-> direction and `SUBMISSION-STATUS.md` for the path to NIST MPTC v0.3.
+> **Tier B: production library + submission scaffold landed v0.2.0.**
+> Threshold hash-based PQ signature primitive over FIPS 205 SLH-DSA
+> implementing the **v0.1 reveal-and-aggregate** construction.
+> Mechanized refinement + independent audit on the roadmap to Tier A.
+>
+> See `SPEC.md` for the construction specification,
+> `DEPLOYMENT-RUNBOOK.md` for the v0.1 trust-model disclosure,
+> `BLOCKERS.md` for the remaining Tier B → A path, and
+> `SUBMISSION-STATUS.md` for the NIST MPTC roadmap.
 
 ## Status
 
 | Field | Value |
 |---|---|
-| Standard | FIPS 205 SLH-DSA (single-party) |
-| Threshold construction | Open research — no fixed protocol |
-| Implementation | None |
-| Submission package | Roadmap: NIST MPTC v0.3 target |
+| Standard | FIPS 205 SLH-DSA (single-party + reveal-and-aggregate threshold) |
+| Construction | v0.1 reveal-and-aggregate (Shamir VSS over the SLH-DSA scheme seed) |
+| Reference implementation | `ref/go/pkg/magnetar/` — pure Go, depends on `cloudflare/circl/sign/slhdsa` |
+| KAT vectors | `vectors/{keygen,sign,verify,threshold-sign,dkg}.json` (deterministic regeneration) |
+| Class-N1-analog claim | threshold signature is byte-equal to single-party `slhdsa.SignDeterministic` on the same reconstructed seed |
+| Submission package | NIST MPTC roadmap — see `SUBMISSION-STATUS.md` for the v0.3 target window |
 | Cert-profile role | Polaris profile in `luxfi/quasar` (cross-family PQ diversity) |
+| Proof artifacts | None yet — see `BLOCKERS.md` BLK-7 |
+| Independent review | None yet — see `BLOCKERS.md` BLK-9 |
+
+## What v0.2.0 ships
+
+- **Reference implementation** (`ref/go/pkg/magnetar/`): single-party + DKG + threshold-sign + Combine over the SLH-DSA scheme seed.
+- **Parameter sets**: SHAKE-192s (recommended), SHAKE-192f, SHAKE-256s.
+- **KAT generator** (`ref/go/cmd/genkat`): deterministic vectors at five profiles (keygen, sign, verify, threshold-sign, dkg). Re-running on a clean checkout produces byte-identical output.
+- **Headline test** (`n1_byte_equality_test.go`): threshold-produced signatures are byte-identical to single-party FIPS 205 `SignDeterministic` on the reconstructed master seed.
+- **Honest trust-model disclosure**: `DEPLOYMENT-RUNBOOK.md` documents the v0.1 reveal-and-aggregate aggregator-as-TCB caveat with the same rigor as Pulsar's.
+
+## What v0.2.0 does NOT yet ship
+
+- Formal proofs (EasyCrypt theories, Lean bridges, Jasmin sources) — see `BLOCKERS.md` BLK-7.
+- Constant-time analysis under `dudect` of the threshold layer — see `BLOCKERS.md` BLK-7.
+- ML-KEM-768 wrapping of DKG Round-1 envelopes (closes passive-network-observer channel) — planned for v0.3 / Pulsar parity.
+- Independent cryptographer sign-off — see `BLOCKERS.md` BLK-9.
+- Full 16-document submission package — see `BLOCKERS.md` BLK-8.
 
 ## Where this is used
 
@@ -22,11 +47,11 @@ The `Magnetar` leg of the **Polaris** cert profile in
 maximum-assurance cross-family profile that pairs lattice PQ
 (Pulsar M-LWE + Corona R-LWE) with hash-based PQ (Magnetar
 SLH-DSA). Polaris is the production migration target for when
-Magnetar matures.
+Magnetar matures to Tier A.
 
-Until Magnetar exists in production form, the Polaris profile is
-reserved but not deployable; production chains run the **Pulsar**
-or **Aurora** profile.
+At v0.2.0 Tier B, Magnetar is **available as a library** but not
+yet the production cert-profile target. Production chains run
+the **Pulsar** profile; Polaris remains reserved.
 
 ## Why hash-based threshold matters
 
@@ -37,20 +62,46 @@ even if a future cryptanalytic break hits the entire lattice family
 (both M-LWE and R-LWE), Magnetar's hash-based threshold leg keeps
 the cert sound.
 
-## Why it's hard
+## The v0.1 trust caveat (READ THIS)
 
-See `DESIGN.md` for the construction-level challenges. Summary:
-SLH-DSA does not decompose into a linear-aggregation identity the
-way ML-DSA does, so the FROST-style aggregation pattern that powers
-Pulsar/Corona doesn't transfer. Threshold SLH-DSA in the literature
-requires MPC over hash computations + per-signature MPC ceremony,
-which dominates deployment economics.
+The v0.1 reveal-and-aggregate construction reconstructs the master
+SLH-DSA seed in **aggregator-process memory** during each `Combine`
+call. The aggregator process is in the trusted computing base for
+this brief window. This is the same trust model as Pulsar's v0.1
+reveal-and-aggregate.
+
+**Mitigations** (see `DEPLOYMENT-RUNBOOK.md` for the full matrix):
+- TEE (SGX / SEV-SNP / TDX) is the recommended deployment posture.
+- `mlock`, ptrace-off (`kernel.yama.ptrace_scope=3`), `ulimit -c 0` are mandatory.
+- Aggregator role SHOULD rotate per signing request.
+
+A v0.2 instantiation that gives true threshold secrecy (aggregator
+never sees the seed) is on the research path — full MPC over
+SLH-DSA's hash tree is the candidate construction; see
+`BLOCKERS.md` BLK-1 follow-on work.
+
+## Quick start
+
+```go
+import (
+    "github.com/luxfi/magnetar/ref/go/pkg/magnetar"
+)
+
+// Single-party usage (single-instance signer).
+params := magnetar.MustParamsFor(magnetar.ModeM192s)
+sk, _ := magnetar.GenerateKey(params, nil) // crypto/rand
+sig, _ := magnetar.Sign(params, sk, msg, ctx, false /* deterministic */, nil)
+err := magnetar.Verify(params, sk.Pub, msg, sig)
+```
+
+For DKG + threshold signing, see the `n1_byte_equality_test.go`
+end-to-end example.
 
 ## Cross-references
 
 - [`luxfi/quasar`](https://github.com/luxfi/quasar) — umbrella spec; Magnetar is `PRIMITIVES.md` row
-- [`luxfi/pulsar`](https://github.com/luxfi/pulsar) — sibling threshold M-LWE primitive (production)
-- [`luxfi/corona`](https://github.com/luxfi/corona) — sibling threshold R-LWE primitive (production)
+- [`luxfi/pulsar`](https://github.com/luxfi/pulsar) — sibling threshold M-LWE primitive (Tier A production)
+- [`luxfi/corona`](https://github.com/luxfi/corona) — sibling threshold R-LWE primitive (Tier A submission)
 
 ## License
 

SPEC.md

@@ -0,0 +1,259 @@
+# Magnetar v0.1 — Construction specification
+
+> Threshold FIPS 205 SLH-DSA via reveal-and-aggregate. Mirrors
+> Pulsar's v0.1 reveal-and-aggregate pattern, ported to SLH-DSA's
+> scheme-seed-as-secret model.
+>
+> Status: v0.1 implementation specification. **NOT yet
+> independently reviewed.** See `BLOCKERS.md` BLK-7 and BLK-9 for
+> the proof-and-review path to Tier A.
+
+## 1. Notation
+
+| Symbol | Meaning |
+|---|---|
+| `n` | committee size |
+| `t` | reconstruction threshold (1 ≤ t ≤ n ≤ 256) |
+| `q` | Shamir prime, fixed at 257 (smallest prime > 255) |
+| `seed_size` | SLH-DSA scheme-seed length: 96 bytes for SHAKE-192s/192f, 128 bytes for SHAKE-256s |
+| `P_i` | party `i`, `1 ≤ i ≤ n` |
+| `x_i` | Shamir x-coordinate of `P_i`, `1 ≤ x_i ≤ 256`, distinct per party |
+| `c_i` | `P_i`'s contribution to the joint seed, `c_i ∈ {0,1}^{8·seed_size}` |
+| `S` | joint master seed, `S ∈ {0,1}^{8·seed_size}` |
+| `share_i` | `P_i`'s Shamir share of the byte-sum used to mix to `S` |
+| `pk`, `sk` | FIPS 205 SLH-DSA group public / private keypair derived from `S` |
+
+## 2. Hash domain separation
+
+All cSHAKE / KMAC calls use function-name `"Magnetar"` and one of
+the following customisation tags:
+
+| Tag | Purpose |
+|---|---|
+| `MAGNETAR-DKG-COMMIT-V1` | committee-root digest |
+| `MAGNETAR-DKG-TRANSCRIPT-V1` | DKG transcript digest |
+| `MAGNETAR-SIGN-R1-V1` | threshold-sign Round-1 commit `D_i` |
+| `MAGNETAR-SIGN-R1-MAC-V1` | (reserved for v0.2 MAC envelope) |
+| `MAGNETAR-SIGN-MASK-V1` | per-attempt mask derivation |
+| `MAGNETAR-SEED-SHARE-V1` | Shamir coefficient stream + seed mix |
+
+The protocol-wide domain-separation context is the ASCII string
+`"lux-magnetar-v0.1"` (`tagDomainSep`).
+
+## 3. DKG protocol
+
+### Round 1 (dealer P_i)
+
+1. Sample `c_i ←$ {0,1}^{8·seed_size}` from `rng`.
+2. Sample `seed_size · 2 · (t-1)` bytes of coefficient material from `rng` (the random Shamir polynomial coefficients).
+3. Run byte-wise Shamir-share-deal over GF(257):
+   - For each byte position `b ∈ [0, seed_size)`, define a polynomial `f_b(x) = c_i[b] + a_{b,1}·x + ... + a_{b,t-1}·x^{t-1} (mod 257)` where `a_{b,j}` are derived from the coefficient stream.
+   - For each recipient `P_j`, compute `share_{i→j}[b] = f_b(x_j) (mod 257)` for every byte `b`. The result is a 2·seed_size-byte big-endian uint16 vector.
+4. Construct one envelope per recipient:
+   ```
+   Envelope_{i→j} := (share_{i→j} || c_i)
+   ```
+   The full `c_i` is duplicated into every envelope so that at Round 2 each `P_j` can sum contributions to compute the joint master public key locally.
+5. Broadcast `DKGRound1Msg{NodeID = P_i, Envelopes = { P_j ↦ Envelope_{i→j} }_{j∈[n]}}`.
+
+### Round 2 (party P_i)
+
+1. Receive Round-1 broadcasts from every dealer in committee.
+2. Validate: every broadcast contains an envelope for every recipient (no omissions); every envelope has the expected wire sizes; sender is in committee.
+3. Compute the transcript digest binding the entire ordered envelope set:
+   ```
+   τ_dkg := lux-magnetar-v0.1 ‖ Mode ‖ t ‖ n ‖ committee_in_order
+   D := cSHAKE256( τ_dkg ‖ for_each_dealer_in_order(for_each_recipient_in_order(share || contribution)),
+                   N="Magnetar", S="MAGNETAR-DKG-TRANSCRIPT-V1", 32 bytes )
+   ```
+4. Broadcast `DKGRound2Msg{NodeID = P_i, Digest = D}`.
+
+### Round 3 (party P_i)
+
+1. Receive Round-2 digests from every party.
+2. Verify every received digest equals `D` (computed locally). A mismatch is identifiable abort with `ComplaintKind = ComplaintEquivocation`; the conflicting digest pair is the evidence blob.
+3. Sum per-byte Shamir shares received from each dealer:
+   ```
+   my_share_sum[b] := Σ_{j∈[n]} share_{j→i}[b] (mod 257)  for b ∈ [0, seed_size)
+   ```
+4. Sum dealer contributions byte-by-byte over GF(257):
+   ```
+   master_byteSum[b] := Σ_{j∈[n]} c_j[b] (mod 257)  for b ∈ [0, seed_size)
+   ```
+5. Compute the committee root:
+   ```
+   committee_root := cSHAKE256( "MAGNETAR-COMMITTEE-V1" ‖ sorted_committee,
+                                 N="Magnetar", S="MAGNETAR-DKG-COMMIT-V1", 32 bytes )
+   ```
+6. Mix to the master seed:
+   ```
+   mix := (master_byteSum encoded as 2·seed_size big-endian uint16) ‖ committee_root
+   S := cSHAKE256( mix, N="Magnetar", S="MAGNETAR-SEED-SHARE-V1", seed_size bytes )
+   ```
+7. Derive the group public key via FIPS 205:
+   ```
+   (pk, sk) := slhdsa.Scheme(SLH-DSA-SHAKE-{192s,192f,256s}).DeriveKey(S)
+   ```
+   Discard `sk`; publish `pk` as the joint group public key. (Each party can compute the same `pk` because every party has identical `master_byteSum` and `committee_root` inputs.)
+8. Output: `KeyShare{NodeID = P_i, EvalPoint = x_i = i, Share = my_share_sum, Pub = pk}`.
+
+### DKG correctness
+
+For any quorum `Q ⊆ [n]` with `|Q| ≥ t`:
+```
+Lagrange-interpolate({(x_i, my_share_sum_i) : i ∈ Q}) = master_byteSum
+```
+because `my_share_sum_i = Σ_j share_{j→i} = Σ_j f_{j,b}(x_i)` and the Lagrange interpolation at `x=0` over GF(257) of the polynomial sums `Σ_j f_{j,b}` recovers `Σ_j c_j[b] = master_byteSum[b]`.
+
+Therefore any quorum's reconstructed seed `S` is identical to the one computed at Round 3.
+
+## 4. Threshold signing
+
+### Round 1 (signer P_i, i ∈ T ⊆ [n], |T| = t)
+
+1. Sample `rngBytes ←$ {0,1}^{8·2·seed_size}` from `rng`.
+2. Derive per-attempt mask:
+   ```
+   maskMix := rngBytes ‖ session_id ‖ attempt(BE 4 bytes) ‖ NodeID
+   r_i := cSHAKE256( maskMix, N="Magnetar", S="MAGNETAR-SIGN-MASK-V1", 2·seed_size bytes )
+   ```
+3. Mask the share byte-by-byte XOR:
+   ```
+   masked_i[b] := share_i[b] XOR r_i[b]  for b ∈ [0, 2·seed_size)
+   ```
+4. Compute Round-1 transcript binding:
+   ```
+   τ_1 := SP800-185-encode( session_id, attempt, quorum, NodeID, pk, message )
+   ```
+5. Compute commit:
+   ```
+   D_i := cSHAKE256( r_i ‖ masked_i ‖ τ_1, N="Magnetar", S="MAGNETAR-SIGN-R1-V1", 32 bytes )
+   ```
+6. Broadcast `Round1Message{NodeID, SessionID, Attempt, Commit = D_i}`.
+
+### Round 2 (signer P_i)
+
+1. Validate Round-1 broadcasts (consistent session/attempt).
+2. Reveal:
+   ```
+   Round2Message{NodeID, SessionID, Attempt, PartialSig = r_i ‖ masked_i}
+   ```
+
+### Combine (aggregator)
+
+1. For each Round-2 reveal `(r_i, masked_i)`:
+   a. Recompute `D'_i = cSHAKE256(r_i ‖ masked_i ‖ τ_1_i, ...)` and check `D'_i == Round1Message.Commit`. Reject on mismatch.
+   b. Recover `share_i = masked_i XOR r_i`.
+2. Collect `t` distinct shares. Pair each with its `KeyShare.EvalPoint` from the directory.
+3. Run Lagrange interpolation over GF(257) at `x=0`:
+   ```
+   reconstructed_byteSum[b] := Σ_{i∈Q} λ_i · share_i[b] (mod 257)
+   ```
+   where `λ_i = Π_{j≠i} (-x_j) / (x_i - x_j) (mod 257)`.
+4. Compute committee_root from `allShares` (same definition as Round 3 step 5).
+5. Mix to recover the master seed (identical to DKG Round 3 step 6):
+   ```
+   S := cSHAKE256( reconstructed_byteSum_BE ‖ committee_root, N="Magnetar", S="MAGNETAR-SEED-SHARE-V1", seed_size bytes )
+   ```
+6. Derive the SLH-DSA secret key:
+   ```
+   (pk_rec, sk_rec) := slhdsa.Scheme(...).DeriveKey(S)
+   ```
+   If `pk_rec ≠ groupPubkey`: abort with `ErrPubkeyMismatch`.
+7. Sign:
+   ```
+   sig := slhdsa.SignDeterministic(sk_rec, message, ctx)
+   ```
+   (When `randomized=true`, `SignRandomized` is used with the caller's `rng`.)
+8. Zeroize `S, sk_rec, mix, reconstructed_byteSum`.
+9. Return `Signature{Mode, Bytes = sig}`.
+
+## 5. Verify
+
+`Verify` is a thin dispatch to `slhdsa.Verify(pk, NewMessage(message), sig, ctx)`. **No Magnetar-specific envelope.** This is the Class-N1-analog property: any unmodified FIPS 205 verifier accepts Magnetar signatures.
+
+## 6. Class-N1-analog byte-equality claim
+
+**Claim (Magnetar reveal-and-aggregate byte-equality).** For any honest threshold-sign session over committee `[n]` with threshold `t`, any quorum `Q` of size `t`, message `m`, context `ctx`, session_id `sid`, attempt `κ`:
+
+> `Combine(...) = slhdsa.SignDeterministic(slhdsa.DeriveKey(S), NewMessage(m), ctx)`
+
+where `S` is the master seed computed at DKG Round 3.
+
+**Proof sketch.** Combine reconstructs `master_byteSum` from `Q`'s shares via Lagrange interpolation (correct by Shamir's secret sharing over GF(257) for any quorum of size ≥ t). It then computes `committee_root` from the same `allShares` set that fixed it at DKG time, and applies the identical cSHAKE256 mix → produces the identical `S`. Sign on `DeriveKey(S)` is byte-deterministic over `(S, m, ctx)`. ∎
+
+**Empirical validation.** See `n1_byte_equality_test.go`: `TestN1_ByteEquality_ThresholdMatchesCentralized` and `TestN1_ByteEquality_DifferentQuorumsSameSignature` exercise the claim across three configurations and across distinct quorums.
+
+## 7. Trust model — the v0.1 reveal-and-aggregate caveat
+
+**The aggregator process is in the trusted computing base (TCB) for the brief window the master seed is reconstructed in memory.**
+
+This is the same trust caveat Pulsar's v0.1 reveal-and-aggregate carries; it is documented honestly in Pulsar's `DEPLOYMENT-RUNBOOK.md` and is inherited verbatim by Magnetar.
+
+Specifically:
+
+- At step 6 of `Combine` (§4), the master SLH-DSA seed `S` is recomputed in aggregator memory.
+- At step 7, FIPS 205 `SignDeterministic` consumes `S` to produce the signature.
+- At step 8, all secret-bearing buffers (`S, sk_rec, mix, reconstructed_byteSum`) are explicitly zeroized.
+
+During steps 6–7, an adversary with arbitrary code-execution on the aggregator host can extract `S` via:
+- `/proc/<pid>/mem`
+- a coredump
+- a swap-file or hibernation image
+- `ptrace`
+- a malicious kernel/hypervisor
+
+Operational mitigations are described in `DEPLOYMENT-RUNBOOK.md` "Aggregator hardening".
+
+**What this caveat does NOT cover:**
+
+- A passive **network observer** never sees `S`. Round-1 commits and Round-2 reveals collectively carry `share_i` values (masked + revealed), but reconstruction requires combining `t` of them with the matching `EvalPoint` directory. v0.1 v1 envelopes are plaintext (a passive observer can see committee shares); v0.2 will wrap them under ML-KEM-768 to the recipient's long-term identity public key, matching Pulsar's BLOCKERS.md CR-8 pattern.
+- A **single Byzantine committee member** cannot forge a signature: forging requires reconstructing `S`, which requires `t` shares.
+- A **single Byzantine aggregator** cannot forge a signature for a message it did not receive valid Round-2 reveals on: Combine's commit-bind check (step 1a) rejects tampered reveals.
+
+## 8. Identifiable abort
+
+The protocol commits to identifiable abort: every detected deviation produces verifiable evidence suitable for slashing.
+
+| Complaint | Detected at | Evidence |
+|---|---|---|
+| `ComplaintEquivocation` | DKG Round 3 | Conflicting `Digest` from accused; honest party's local `Digest` |
+| `ComplaintBadDelivery` | DKG Round 2 (envelope shape check) | Malformed envelope |
+
+The v0.1 protocol omits the per-pair MAC layer that Pulsar uses (BLOCKERS.md CR-7). This is documented; v0.2 adds MACs once the trust model tightens.
+
+## 9. Parameter sets
+
+| Mode | NIST PQ Cat | Pub key | Priv key | Signature | Seed |
+|---|---|---|---|---|---|
+| `Magnetar-SHAKE-192s` | 3 | 48 B | 96 B | 16,224 B | 96 B |
+| `Magnetar-SHAKE-192f` | 3 | 48 B | 96 B | 35,664 B | 96 B |
+| `Magnetar-SHAKE-256s` | 5 | 64 B | 128 B | 29,792 B | 128 B |
+
+**Recommended production target: `Magnetar-SHAKE-192s`** (matches NIST Cat 3, smallest signature in its category).
+
+## 10. Honest non-claims
+
+Magnetar v0.1 does NOT claim:
+
+- **Full MPC threshold signing.** v0.1 is reveal-and-aggregate; the aggregator process is TCB.
+- **Network-observer secrecy of envelopes** in v0.1. Plaintext envelopes are visible to a passive observer; v0.2 closes this with ML-KEM-768 wrapping.
+- **Sub-second signing.** SLH-DSA single-party signing on SHAKE-192s is ~10–50ms depending on hardware; race-detector runs are 5–10× slower.
+- **Formal verification.** No EasyCrypt, Lean, or Jasmin artifacts ship in v0.1. See `BLOCKERS.md` BLK-7.
+
+## 11. References
+
+- FIPS 205: Stateless Hash-Based Digital Signature Standard (2024).
+- Shamir, A. *How to share a secret*. Communications of the ACM, 1979.
+- Pulsar v0.1 `SPEC.md` — reveal-and-aggregate pattern adapted from there.
+- `BLOCKERS.md` — outstanding Tier B → A path.
+- `DEPLOYMENT-RUNBOOK.md` — operator-facing trust-model disclosure.
+
+---
+
+**Document metadata**
+
+- File: `SPEC.md`
+- Version: v0.1
+- Date: 2026-05-18
+- Status: implementation specification; **not yet independently reviewed** (see BLK-9).

SUBMISSION-STATUS.md

@@ -1,90 +1,111 @@
 # NIST MPTC Submission Status — Magnetar
 
 > Honest status of Magnetar's path to NIST Multi-Party Threshold
-> Cryptography submission. Magnetar is **research-stage**; this
-> document scopes the work required to reach NIST MPTC v0.3 readiness
-> and commits to it as the target window.
+> Cryptography submission. **Tier B** as of v0.2.0
+> (production library + submission scaffold shipped). Mechanized
+> refinement + independent audit on the roadmap to Tier A.
 
-## Today
+## Today (v0.2.0)
 
-**NOT submission-ready.** Magnetar is a research direction, not a
-fixed protocol. Specifically:
+**Tier B: production library + submission scaffold landed.**
 
-- **No fixed construction.** Multiple candidate constructions exist
-  in the literature (Komlo/Goldberg style FROST-of-SLH-DSA, full-MPC
-  hash-computation, threshold seed-DKG with batched per-signature
-  ceremony). Lux has not selected one.
-- **No reference implementation.** `magnetar/` repo contains
-  `DESIGN.md` + `README.md` only.
-- **No KAT vectors.** Cannot exist without a fixed construction.
-- **No proof artifacts.** No EC theories, no Lean bridges, no Jasmin
-  sources.
-- **No constant-time analysis.** Threshold SLH-DSA's per-signature
-  MPC ceremony is hash-dominated; CT story is non-trivial.
+Specifically:
 
-## Why this is not Pulsar
+- **Construction selected.** v0.1 reveal-and-aggregate over the
+  SLH-DSA scheme seed (Shamir VSS in GF(257), Lagrange
+  reconstruction at sign time). Mirrors Pulsar's v0.1
+  reveal-and-aggregate pattern. See `SPEC.md`.
+- **Reference implementation shipped.** `ref/go/pkg/magnetar/` —
+  pure Go on top of `cloudflare/circl/sign/slhdsa`. Single-party
+  + DKG + threshold-sign + Combine. Three parameter sets
+  (SHAKE-192s / SHAKE-192f / SHAKE-256s).
+- **KAT vectors shipped.** `vectors/{keygen,sign,verify,
+  threshold-sign,dkg}.json` — deterministic regeneration via
+  `cmd/genkat`.
+- **Class-N1-analog evidence shipped.**
+  `n1_byte_equality_test.go` — threshold-produced signatures are
+  byte-identical to single-party `slhdsa.SignDeterministic` on
+  the reconstructed master seed; verifies under unmodified
+  FIPS 205.
+- **Honest trust-model disclosure shipped.**
+  `DEPLOYMENT-RUNBOOK.md` documents the v0.1 reveal-and-aggregate
+  aggregator-as-TCB caveat with the same rigor as Pulsar's.
 
-Pulsar's NIST MPTC v0.1 readiness rests on three structural
-advantages that Magnetar does not share:
+What is **NOT** yet shipped (the Tier B → A gap):
 
-1. **Linear-aggregation identity.** ML-DSA's Lagrange-reconstruction
-   identity at accept time lets Pulsar produce a byte-equal FIPS 204
-   signature from threshold inputs. SLH-DSA's hash-tree traversal
-   has no such identity.
-2. **Fixed FIPS standard to anchor against.** Pulsar's Class N1
-   claim is "byte-equal to single-party FIPS 204 ML-DSA." Magnetar
-   would have to define a NEW threshold construction (with its own
-   security analysis), not anchor to FIPS 205 byte-equally.
-3. **Mature academic basis.** Pulsar's protocol shape is FROST-like
-   threshold-Schnorr-style, well-studied. Threshold SLH-DSA work in
-   the literature is sparser and not yet converged.
+- **Proof artifacts** (EasyCrypt theories, Lean bridges, Jasmin
+  sources). See `BLOCKERS.md` BLK-7. This is multi-month research.
+- **Constant-time analysis** of the threshold layer under `dudect`
+  or formal tooling.
+- **ML-KEM-768 wrapping** of DKG Round-1 envelopes (closes
+  passive-network-observer channel). v0.1 envelopes are plaintext.
+- **Independent cryptographer review.** See `BLOCKERS.md` BLK-9.
+- **Full 16-document submission package** mirroring Pulsar's
+  layout. See `BLOCKERS.md` BLK-8.
+
+## Why this is not Pulsar (still, at Tier B)
+
+Pulsar v0.1 reached NIST MPTC submission-readiness on three
+structural advantages that Magnetar v0.1 partially shares and
+partially does not:
+
+1. **Linear-aggregation identity.** SHARED: at the SHARE level,
+   Shamir-shares over GF(257) admit linear Lagrange reconstruction
+   exactly as Pulsar's do. Magnetar inherits this property.
+2. **Fixed FIPS standard to anchor against.** SHARED: Magnetar's
+   Class-N1-analog claim is "byte-equal to single-party FIPS 205
+   SLH-DSA on the reconstructed seed," directly analogous to
+   Pulsar's Class N1 byte-equality claim against FIPS 204 ML-DSA.
+3. **Mature academic basis.** PARTIALLY SHARED: the reveal-and-
+   aggregate pattern itself has the same security story for SLH-DSA
+   as it does for ML-DSA — the aggregator is TCB; this is honest
+   v0.1 design space. What's NOT shared: there is no peer-reviewed
+   paper specifically targeting threshold-SLH-DSA reveal-and-
+   aggregate. Magnetar inherits the construction-equivalence
+   argument from Pulsar's v0.1 design rather than citing a fresh
+   threshold-SLH-DSA paper. This is acknowledged in `SPEC.md` §6
+   and remains an open citation gap.
 
 ## Path to NIST MPTC v0.3
 
-Estimated 2-3 months of focused research + 1-2 months of
-implementation + 2-3 months of submission-package authoring.
+Estimated 2-3 months of formal-methods work + 1-2 months of
+submission-package authoring + parallel independent review.
 
-### Phase 1 — Construction selection (research)
+### Phase 1 — Construction selection (DONE, v0.2.0)
 
-- Survey published threshold SLH-DSA constructions
-- Compare on: per-signature MPC complexity, distributed seed
-  generation, identifiable abort, public-key preservation across
-  resharing
-- Select ONE construction; freeze its protocol shape
-- Output: `SPEC.md` (initial draft) + reference paper citation
+- ✅ Surveyed candidates (Komlo-style FROST-of-SLH-DSA, full-MPC, reveal-and-aggregate)
+- ✅ Selected reveal-and-aggregate (mirrors Pulsar v0.1 pattern; honest TCB caveat)
+- ✅ Documented in `SPEC.md`
 
-### Phase 2 — Reference implementation (engineering)
+### Phase 2 — Reference implementation (DONE, v0.2.0)
 
-- Implement the selected construction in Go
-- Targets: `magnetar/ref/go/pkg/magnetar/` mirroring Pulsar's layout
-- Use existing SLH-DSA single-party implementations (cloudflare/circl,
-  pq-crystals reference) as the underlying primitive
-- Output: `ref/go/`, `vectors/`, `test/`
+- ✅ Implemented in Go (`ref/go/pkg/magnetar/`)
+- ✅ Three parameter sets (SHAKE-192s, SHAKE-192f, SHAKE-256s)
+- ✅ KAT vectors + deterministic regeneration
+- ✅ N1 byte-equality test passes across (3,2), (5,3), (7,4) configurations
 
-### Phase 3 — Proof artifacts (formal methods)
+### Phase 3 — Proof artifacts (OPEN, BLK-7)
 
-- EasyCrypt theories for correctness + Class N1-equivalent claim
-  (whatever the analog is for Magnetar — likely "verifies under
-  unmodified FIPS 205 verification given seed-DKG soundness")
-- Lean bridges for the algebraic identities
-- Jasmin constant-time analysis of the threshold layer
-- Output: `proofs/`, `jasmin/`
+- EasyCrypt theories for threshold reconstruction correctness
+- Lean bridges (where applicable — SLH-DSA is hash-based, so the bridge story differs from lattice schemes; expect to cite SLH-DSA's existing libjade constant-time analysis for the single-party layer)
+- Jasmin constant-time analysis of the threshold layer (DKG / Combine / Round1 / Round2)
+- Output target: `proofs/`, `jasmin/`
 
-### Phase 4 — Submission package (documentation)
+### Phase 4 — Submission package (OPEN, BLK-8)
 
 Mirror Pulsar's 16-doc structure adapted to Magnetar's specifics:
 
 - `SUBMISSION.md`, `NIST-SUBMISSION.md`, `SPEC.md`
 - `PATENTS.md`, `PROOF-CLAIMS.md`, `AXIOM-INVENTORY.md`,
   `FIPS-TRACEABILITY.md`, `TRUSTED-COMPUTING-BASE.md`
-- `CHANGELOG.md`, `DEPLOYMENT-RUNBOOK.md`
+- `CHANGELOG.md`, `DEPLOYMENT-RUNBOOK.md` (✅ landed v0.2.0)
 - `docs/{evaluation,nist-mptc-category,design-decisions,
   patent-claims,family-architecture,threat-model,
   ietf-draft-skeleton}.md`
 - `scripts/cut-submission.sh` + supporting build/test/bench/vector
   generation scripts
 
-### Phase 5 — Independent cryptographer review
+### Phase 5 — Independent cryptographer review (OPEN, BLK-9)
 
 - Same model as Pulsar's `CRYPTOGRAPHER-SIGN-OFF.md`
 - Independent reviewer attests construction + impl + proofs + tests
@@ -98,7 +119,9 @@ Mirror Pulsar's 16-doc structure adapted to Magnetar's specifics:
 
 ## Cross-references
 
-- `DESIGN.md` — research-direction notes
+- `SPEC.md` — construction specification (v0.2.0 landed)
+- `BLOCKERS.md` — Tier B → A path
+- `DEPLOYMENT-RUNBOOK.md` — v0.1 trust-model disclosure (v0.2.0 landed)
 - `README.md` — repo purpose + status
 - [`luxfi/quasar`](https://github.com/luxfi/quasar) — Polaris cert
   profile depends on Magnetar maturing
@@ -106,17 +129,22 @@ Mirror Pulsar's 16-doc structure adapted to Magnetar's specifics:
   submission package to mirror at Phase 4
 - [`luxfi/lps/ROADMAP-CRYPTO-STACK.md`](https://github.com/luxfi/LPs/blob/main/ROADMAP-CRYPTO-STACK.md) — multi-year crypto stack plan
 
-## Honest non-claims
+## Honest non-claims (at Tier B)
 
-Magnetar today is NOT:
+Magnetar v0.2.0 today is NOT:
 
-- A NIST MPTC submission (won't be until v0.3)
-- A production cryptographic primitive (no impl)
-- A specification (construction not selected)
-- A security claim (no analysis)
-- A drop-in for the Polaris cert profile (the profile is reserved;
-  not deployable until Magnetar matures)
+- A NIST MPTC submission (won't be until Tier A, target 2027 Q3)
+- A production cryptographic primitive **without** the v0.1
+  reveal-and-aggregate trust caveat (aggregator is TCB; see
+  `DEPLOYMENT-RUNBOOK.md`)
+- A formally verified scheme (no EasyCrypt / Lean / Jasmin yet)
+- Independently reviewed (no cryptographer sign-off yet)
+- A drop-in replacement for Pulsar (Pulsar M-LWE is the
+  production cert-profile target; Magnetar is the cross-family
+  diversity leg in the Polaris profile)
 
-This repo exists so the Polaris cert profile in `luxfi/quasar` has
-a real repo to reference, and so the NIST MPTC v0.3 work has a home
-to land in. It is a placeholder with intent, not a delivery.
+This repo now exists as a **production library** for v0.1
+reveal-and-aggregate threshold SLH-DSA, with the honest trust
+caveat documented operationally. The path to Tier A
+(formal verification + independent review + full submission
+package) is on the NIST MPTC v0.3 roadmap.