magnetar/AUDIT-2026-06.md

# Magnetar --- 2026-06 production-readiness audit

Audit performed against Magnetar at tag-equivalent commit `d640d15`
(post v1.2 ship state). Scope: public-permissionless-chain safety,
TEE integration story, GPU acceleration story, canonical-name
positioning across `luxfi/*`. Reviewer: cryptographer agent.

> **TL;DR.** v1.2 is shippable for the per-validator standalone
> primitive on any Lux public-permissionless chain and for the
> THBS-SE permissionless threshold primitive under the
> legacy-compat profile. Strict-PQ chains MUST route through the
> sibling `luxfi/threshold/protocols/slhdsa-tee` package's
> t-of-n attested-combiner pool. The gating discipline is correctly
> decomplected --- one profile gate function, one place, one canonical
> refusal sentinel. The audit identifies four open items below; none
> blocks v1.2 deployment, all are scoped against v1.3 / v1.4.

---

## 1. Public-permissionless-chain safety

### 1.1 Slashable evidence (extractability for permissionless slashing)

**Finding: APPROVED.** Equivocation is made cryptographically
extractable by THBS-SE's slot-bound commit-and-reveal discipline.
Specifically:

- A party's Round-1 broadcast is `D_i = cSHAKE256(r_i || s'_i || tau)`
  where `tau = SlotBinding.Encode() || msg || party_id`
  (`thbsse.go::deriveThbsSeCommit`). The slot binding hashes
  `(chain_id, epoch, slot, height, committee_id, message_domain)`
  into the commit. Same slot + different `msg` ⇒ different `tau` ⇒
  different `D_i` ⇒ third-party `VerifyThbsSeEvidence` confirms the
  party committed twice.
- `ThbsSeSlotRecord` persists `MessageDigest + Round1 + Round2`
  per slot (`thbsse.go:496-500`). Persisting both rounds is
  load-bearing for the slashing chain across restarts ---
  digest-only persistence is insufficient.
- `ThbsSeEvidence` is the wire-shaped slashing blob:
  `(PartyID, SlotID, prior_R1, prior_R2, new_R1, new_R2,
  prior_digest, new_digest)`. `VerifyThbsSeEvidence` (a pure
  function with no committee state) re-derives `D_i` from each
  reveal under the supplied `bindingPrior` and `bindingNew` and
  confirms both digests match.

**Critical correctness pin.** `VerifyThbsSeEvidence` requires
`bindingPrior` and `bindingNew` as inputs (`thbsse.go:609`). The
consensus layer MUST publish both slot bindings on-chain when
slashing --- without them the verifier cannot re-derive the
commits. This is a CONSUMER contract; the magnetar primitive is
self-contained.

**Adversarial-share evidence.** Malformed shares (commit mismatch,
wire-size, slot mismatch) produce `ThbsSeShareEvidence` with three
canonical reasons (`thbsse.go:973-977`). `VerifyThbsSeShareEvidence`
recomputes the expected commit and confirms `ExpectedD != ObservedD`
--- the slashable bit is positive proof the named party broadcast a
malformed reveal. No third-party state needed beyond the slot
binding + message.

### 1.2 State management (stateless SLH-DSA + slot-bound reuse refusal)

**Finding: APPROVED.** SLH-DSA is stateless at the primitive level
(unlike XMSS/Mldsa-with-state); the per-validator `Sign` path has
no internal counter to corrupt. THBS-SE's per-party slot binding
provides the one-time-per-slot enforcement via two layers:

- **Local**: `ThbsSeSlotGuard.Record` raises
  `*ThbsSeEquivocationError` if the party tries to sign a
  different `msg` under the same `slot_id`. Idempotent same-slot
  same-msg replay is permitted (`thbsse.go:716-733`) so a network
  retry does not become a slashing event.
- **Protocol-layer**: the slot binding flows into the FIPS 205 `ctx`
  string via `ctxFromSlot` (`thbsse.go:299-305`), so even a peer
  that bypasses its local guard produces signatures that bind
  unambiguously to one slot. Cross-slot replay deterministically
  fails verification.

**Soundness of slot-bound commit-and-reveal.** The mask
`r_i ← rng` (Round 1) blinds the share `s'_i = share_i XOR r_i`
in `D_i`'s SHAKE absorb. By the random-oracle model treatment of
cSHAKE256, `D_i` reveals zero bits about `share_i` before Round 2.
At Round 2 reveal, `share_i = r_i XOR s'_i` is recovered by anyone;
the byte-wise XOR over a uniformly-random 96-byte `r_i` is
information-theoretically hiding. The Class-N1-analog byte-equality
of the strict-atom Combine path to single-party FIPS 205
SignDeterministic is pinned by
`TestSlhdsaInternal_ByteEqualToCirclSign` across all three SHAKE
modes.

### 1.3 Adaptive corruption at t-of-n

**Finding: APPROVED FOR STATIC CORRUPTION; ADAPTIVE CORRUPTION HAS A
HONEST GAP TIED TO THE PVSS-DKG MODEL.**

The THBS-SE Combine path is secure under static t-of-n
corruption (the Class-N1 byte-equality theorem in `SPEC.md` §6 +
the EasyCrypt theory at
`proofs/easycrypt/Magnetar_N1_StrictAtom.ec`). Each non-corrupted
party's share is information-theoretically uniform from the
adversary's view (Shamir over GF(257)); the corrupted parties'
`t-1` shares are insufficient to reconstruct.

For adaptive corruption (adversary chooses which parties to
corrupt during execution), the standard threshold-Shamir bound
applies: adaptively corrupting any `t` parties recovers the
master. This is the inherent secret-sharing bound, not a Magnetar
choice. The v1.2 PVSS-DKG (`pvss_dkg.go`) is itself adaptive-secure
in the same sense: as long as fewer than `t` parties' Round-1
states are corrupted, the implicit master remains hidden.

**v1.3 work item (proposed).** Augment the PVSS-DKG with
proactive-resharing (zero-secret refresh against the same group
public key) so adaptive corruption is bounded by the refresh
interval, not the full keypair lifetime. This is the standard
lift; the share envelope shape is forward-compatible.

### 1.4 Combiner safety (anyone-can-combine + malicious shares)

**Finding: APPROVED.** The public combiner is a pure function of
its inputs:

- `Combine` validation order (`thbsse.go:802-957`): slot-mismatch
  rejected → wire-size rejected → unmatched-Round1 dropped silently
  → unknown party dropped silently → commit-mismatch produces
  `ThbsSeShareCommitMismatch` evidence → the remaining shares are
  collected, deduped by NodeID, sorted by `EvalPoint`, and the
  first `threshold` are passed to `assembleSignatureBytes`.
- Malicious shares cannot fork the output: shares that pass commit
  re-derivation are the unique GF(257) byte-reconstruction of the
  master. Two combiners running the same input set produce
  byte-identical output (the Class-N1 determinism). Two combiners
  with overlapping valid quora produce byte-identical signatures
  (any `t` evaluation points determine the Lagrange basis at
  `x=0`).
- The combiner DOES touch the FIPS 205 master byte material
  transiently in `derivedMaterial` (the SHAKE-expansion output
  buffer of the Lagrange-interpolated share vector). The
  strict-atom discipline at `thbsse_assemble.go` ensures
  (a) no variable in the call graph binds these bytes under any
  of the four forbidden FIPS 205 master names
  (`SK.seed | SK.prf | sk_seed | sk_prf`); (b) the bytes are
  accessed only as positional slices; (c) lifetimes are bounded by
  the enclosing function call with defer-zeroize.

**Residual gap (honestly documented):** the microsecond residency
of master bytes in the public combiner's `derivedMaterial`. A
peer-local memory-disclosure adversary (coredump,
`/proc/self/mem`) at exactly the combine moment could observe
them. This is the inherent Cozzo-Smart bound for threshold
hash-based signatures without full MPC over the hash tree. Closed
for the `strict-PQ` chain profile by routing every Combine through
the TEE-attested combiner pool (see §2).

### 1.5 Wire format + verifier interoperability

**Finding: APPROVED.** MAGS / MAGG wire codec (v0.5.1, commit
`1c84519`) is canonical and stateless. `VerifyBytes(gkBytes, msg,
sigBytes)` and `VerifyBytesCtx(gkBytes, msg, ctx, sigBytes)` are
pure dispatch into circl's FIPS 205 verifier. The headline
byte-identity claim (`TestMagnetar_Wire_FIPS205Verifiable` +
`TestThbsSE_Wire_FIPS205Verifiable`) is pinned across all three
shipped SHAKE modes (M192s / M192f / M256s).

The precompile at `luxfi/precompile/magnetar/contract.go` slot
`0x012207` is correct: the FIPS 205 SHAKE+SHA2 mode byte space is
fully addressable (`getModeParams`), the gas schedule mirrors
`luxfi/precompile/slhdsa`, and the on-chain `precompileCtx =
"lux-evm-precompile-magnetar-v1"` provides domain separation from
the single-party SLH-DSA precompile.

---

## 2. TEE integration (institutional / strict-PQ surface)

### 2.1 Current state (factual)

The TEE-attested signing path lives at
`luxfi/threshold/protocols/slhdsa-tee/` and is fully wired:

- `slhdsa-tee.Signer` (`signer.go`) is the single-host attested
  signer. Composes `kms.ReleaseGate + hsm.Provider +
  approval.ApprovalProvider + Config`. The HSM-stored master seed
  is unwrapped only inside the attested TEE; the host process
  outside the TEE sees only the AEAD-sealed session key, the
  wrapped seed ciphertext, and the resulting wire signature.
- `slhdsa-tee.CombinerPool` (`pool.go`) is the t-of-n
  attested-combiner registry. Default deployment posture is
  `t=2, n=3`; constructor refuses `t<2` (no single-host quorum).
  Combine drives each member's full Sign machinery and refuses
  byte-divergent quorum output (`ErrMagnetarSignatureDivergence`).
- Profile gate at `luxfi/threshold/pkg/thresholdd/magnetar.go`:
  `magnetarRefuseUnderStrictPQ` is ONE function in ONE place;
  refuses `Sign` and `Sign_Ctx` under `ProfileStrictPQ` with
  `ErrMagnetarNoTEEAttestation`. `Sign_TEE` / `Combine_TEE` are
  the only sign surfaces under strict-PQ.
- Chain attestation verifiers at `luxfi/mpc/cc/attest/`:
  `sev.go` PRODUCTION (go-sev-guest backed AMD KDS); `tdx.go`,
  `nras.go` STUBs returning `ErrNotImplemented` (tracked at #222
  stages 2--3). Strict-PQ deployments today MUST use SEV-SNP.

### 2.2 Threat model under strict-PQ

We model an adversary that controls:

- the operator's host process outside the TEE (compromised binary,
  malicious operator);
- the operator's at-rest HSM ciphertext (compromised HSM admin,
  stolen volume snapshot);
- the network between operator and chain (replay, reordering, drop).

We do NOT model:

- compromised AMD / Intel / NVIDIA vendor signing keys
  (defence-in-depth via vendor key rotation);
- physical access to the TEE die during sign (mitigated by
  chassis-attest for on-prem; CSP-hosted deployments inherit the
  CSP guarantee);
- compromised wall-clock / RotationWindow policy (operator policy,
  not cryptographic --- monitor for skew).

### 2.3 NVIDIA Confidential Computing (H100 / H200 / B200) story

**Finding: STUB.** `luxfi/mpc/cc/attest/nras.go` returns
`ErrNotImplemented`; `CombinerPool.Attest` refuses any envelope
routing through `Vendor = "nvidia.nras.v1"`. When the upstream
NRAS verifier ships, the pool's `KnownIssuers` set is the only
knob --- no magnetar-side code change required.

The SLH-DSA Sign path itself is CPU-bound; GPU acceleration is
NOT required for any deployment-rate signing case (per-signature
~ms on modern CPUs). The NVIDIA Confidential Computing story for
Magnetar matters only if a deployment uses GPU-accelerated HASH
batch (the throughput case for high-volume verifier deployments,
e.g. block-time-bound batch verification of N validators'
per-validator standalone signatures). See §3 for that path.

For the SIGNING TEE path, AMD SEV-SNP is the canonical production
substrate. NVIDIA Confidential Compute lands as an additive
substrate when (a) `cc/attest/nras` ships, AND (b) a NVIDIA
Confidential Compute SLH-DSA signer is deployed (a `Signer`
configured to drive the SLH-DSA sign loop inside an H100/H200/B200
CC VM with NRAS attestation). The pool config knob is exactly
`KnownIssuers: {"amd.sev.snp": {}, "nvidia.nras.v1": {}}`.

### 2.4 AMD SEV-SNP for share storage

**Finding: WIRED.** `pool.go` accepts SEV-SNP under
`KnownIssuers = {"amd.sev.snp"}` (the strict default); the
`luxfi/mpc/cc/attest/sev.go` chain validator drives AMD KDS
roundtrips (or `KDSGetter` test injection for offline runs). The
committed Milan fixture at
`pkg/thresholdd/testdata/sev_snp_attestation_milan.bin` +
`sev_snp_vcek_milan.cer` exercises the end-to-end pool drive in
`TestMagnetarCombine_AttestationVerified_AllowsSign`.

### 2.5 Apple Secure Enclave for keys

**Finding: DESIGN-ONLY.** Apple Secure Enclave does not currently
appear in `cc/attest/` as a vendor. The SE's threat model and
attestation surface (DeviceAttestKit, App Attest, Secure Element
attestation via PSE) is fundamentally a device-binding primitive
rather than a server-grade confidential-compute primitive. For
operator-side key storage on Apple Silicon hosts, the canonical
pattern is:

- Use Apple Keychain with `kSecAttrAccessControl =
  kSecAccessControlSecureEnclaveOnly` as the at-rest HSM provider
  (i.e. an `hsm.Provider` implementation backed by Keychain
  + SE-protected key wrap).
- The CombinerPool's TEE evidence chain still resolves to one of
  the supported vendors (SEV-SNP / TDX / NRAS) --- the Apple SE
  is a layer BELOW the attestation, not a substitute for it.

This is documented as v1.4 work item
`MAGNETAR-APPLE-SE-HSM-V14`. The `hsm.Provider` interface is the
seam; no magnetar-side change is required.

### 2.6 Recommended deployment matrix

| Chain profile | Sign primitive | TEE substrate | Vendor |
|---|---|---|---|
| `legacy-compat` (default) | per-validator standalone | none required | --- |
| `legacy-compat` (custody opt-in) | `Combine_TEE` (1-of-1 attested) | SEV-SNP | `amd.sev.snp` |
| `strict-PQ` (production today) | `Combine_TEE` (t-of-n pool) | SEV-SNP | `amd.sev.snp` |
| `strict-PQ` (post-#222 stage 2) | `Combine_TEE` (t-of-n pool) | TDX | `intel.tdx` |
| `strict-PQ` (post-#222 stage 3) | `Combine_TEE` (t-of-n pool) | NRAS (H100/H200/B200 CC VM) | `nvidia.nras.v1` |

The `KnownIssuers` map is the single configuration knob; mixed
deployments (e.g. AMD + NVIDIA in one pool) are permitted by
construction.

---

## 3. GPU acceleration (Magnetar's hash-tree throughput story)

### 3.1 Why this matters for Magnetar specifically

Two consumers benefit from GPU acceleration:

1. **Per-validator standalone aggregate-cert verification.** The
   `ValidatorBatchVerify` primitive in `standalone.go` is the
   bottleneck for block proposers verifying N independently-signed
   per-validator FIPS 205 signatures (the canonical Lux quorum
   shape, N = 21 typical, N = 100+ in extended deployments). At
   SLH-DSA-SHAKE-192s the per-signature CPU verify is ~2ms, so a
   N=21 quorum is ~42ms on a single core. GPU batch over the FORS
   + Merkle + WOTS+ public-byte recomputation amortizes well.

2. **THBS-SE high-throughput signing.** The strict-atom Combine
   path's `slhSignAtom` walks FIPS 205 §5-§8 sequentially. The
   hash-tree expansion is naturally parallelizable: WOTS+ chains,
   FORS subtrees, and XMSS layers all have data parallelism
   across leaves / chains / layers. For a block-time-bound
   high-throughput signing workload (e.g. bridge or institutional
   custody signing many independent messages per second), GPU
   batch sign is the throughput multiplier.

### 3.2 Current state of `~/work/lux-private/gpu-kernels/`

Inventoried 2026-06-03 at HEAD:

- `ops/crypto/shake256/` — FIPS 202 SHAKE256 XOF on CUDA + HIP +
  Metal + Vulkan + WGSL. Permission to share `keccak_f1600.cuh`
  permutation across the family. **THIS IS THE SUBSTRATE.**
- `ops/crypto/sha3_256/` — fixed 32-byte SHA3-256 on same 5
  backends. Different domain separator (0x06 vs 0x1F) than
  SHAKE256 but the same f[1600] permutation.
- `ops/crypto/keccak256/` — Ethereum-domain Keccak (0x01
  padding). Different domain separator than SHA3-256 / SHAKE256
  but same permutation.
- `ops/crypto/mldsa/` — CUDA only. NTT-bound (Module-LWE), not
  applicable to SLH-DSA.
- `ops/crypto/corona/` (Pulsar) — CUDA only. NTT-bound, not
  applicable.
- `ops/crypto/attestation/` — CUDA only. The NVTrust GPU-identity
  + attestation report generator (LP-2000). Relevant to the §2
  NRAS path but not to SLH-DSA arithmetic.

**Magnetar-specific kernels: NONE EXIST TODAY.** This is the
canonical GPU port gap.

### 3.3 Proposed port plan (v1.3 GPU acceleration)

The FIPS 205 SLH-DSA hash tree decomposes into four kernel
families, all naturally batched by independent input sets and all
already enabled by the f[1600] kernel family above. Each kernel
is a thin wrapper over `keccak_f1600` calling SHAKE256 in the
right modal mode.

#### Kernel 1: `magnetar_wotsplus_chain_batch`

- **Inputs**: batch of `(pkSeed, ADRS, x_base, i, s)` tuples.
- **Output**: batch of `chain(x_base, i, s, pkSeed, ADRS)` outputs
  = `F^s(x_base) = SHAKE256(pkSeed || ADRS || ... || x)` chained
  `s` times.
- **Parallelism**: across batch elements (independent
  invocations). Within one element, the chain is sequential by
  construction.
- **Use sites**: `wotsChain` in `slhdsa_internal.go:402`,
  `wotsSign:442`, `wotsPkGen:499`. Per-signature each WOTS+
  signature requires `wotsLen = 2n + 3` chain computations of
  average length `(w-1)/2 = 7.5`; per-hypertree-layer `wotsLen`
  per leaf; total per-signature SHAKE absorbs ≈
  `2 × d × (2n+3) × 7.5` ≈ 3,000-15,000.

#### Kernel 2: `magnetar_fors_subtree_batch`

- **Inputs**: batch of `(pkSeed, ADRS, leaf_idx, height)`
  tuples + the secret PRF callback's outputs (provided as a
  batch of `sk[i]` byte sequences).
- **Output**: batch of FORS subtree node values at `(i, z)` for
  each tuple.
- **Parallelism**: across batch elements AND, within one element,
  across siblings at each height layer.
- **Use sites**: `forsNodeCompute:735`, `forsSign:780`. Per
  signature: `k` subtrees of height `a`.

#### Kernel 3: `magnetar_xmss_subtree_batch`

- **Inputs**: batch of `(pkSeed, ADRS, leaf_idx, height)`
  tuples + the WOTS+ public-key outputs at the leaf level.
- **Output**: batch of XMSS node values at `(i, z)`.
- **Parallelism**: across batch elements AND within one element
  across the `hPrime`-height tree.
- **Use sites**: `xmssNodeCompute:546`, `xmssSign:582`. Per
  signature: `d` XMSS trees of height `hPrime`.

#### Kernel 4: `magnetar_hmsg_prfmsg_batch`

- **Inputs**: batch of `(R, pkSeed, pkRoot, msgPrime)` tuples
  (for `H_msg`) and `(SK.prf_segment, optRand, msgPrime)` tuples
  (for `PRF_msg`).
- **Output**: batched digest / randomizer outputs.
- **Parallelism**: across batch elements.
- **Use sites**: `hMsgPub:341`, `prfMsg` callback. Per signature:
  one of each.

#### Why this decomposes cleanly

All four kernels are pure SHAKE256 absorb-and-squeeze with
public-byte inputs (the secret-side `SK.seed` access stays
behind the `prfOut` callback, which is host-only in the
strict-atom discipline). The CPU host walks the FIPS 205
algorithm, dispatching batches of independent SHAKE invocations
to the GPU, and stitching outputs back into the algorithm flow.
This pattern is identical to how
`luxfi/crypto/slhdsa/gpu.go` already dispatches the existing
`luxfi/accel`-based SLH-DSA path for batch verify.

#### Implementation hook into existing infrastructure

`luxfi/crypto/slhdsa/gpu.go` already has the dispatch substrate
(serial / parallel / GPU tier ladder + provenance via
`LastValidatorBatchTier`). The wire is:

1. Land the four kernels above in
   `lux-private/gpu-kernels/ops/crypto/slhdsa/` with the same
   five-backend layout as `shake256/`.
2. Extend `luxcpp/gpu/include/lux/gpu.h` with the four batch APIs:
   `lux_gpu_slhdsa_wotsplus_chain_batch`,
   `lux_gpu_slhdsa_fors_subtree_batch`,
   `lux_gpu_slhdsa_xmss_subtree_batch`,
   `lux_gpu_slhdsa_hmsg_prfmsg_batch`.
3. Wire the GPU plugin into the magnetar `slhSignAtom` path via a
   pluggable interface (the `prfOut` callback already is the
   pluggability seam; one additional seam for the public-byte
   hash batch is sufficient).

#### Expected throughput

Conservative estimate based on FIPS 205-SHAKE-192s shape (~50K
SHAKE256 calls per signature, ~12K per verify):
- CPU single-core sign: ~80ms (M1 Max)
- CPU single-core verify: ~2ms
- GPU batch sign (M=64, M1 Max Metal): ~5ms / signature
  (~16x throughput at batch size 64)
- GPU batch verify (M=256, NVIDIA H100): ~0.05ms / verify
  (~40x throughput at batch size 256)

The threshold for GPU dispatch matches the existing crypto/slhdsa
pattern: above `BatchVerifyThreshold ≈ 64`, GPU wins.

### 3.4 Honest scope: when GPU is unnecessary

For consensus-rate signing (~1 sig/block on the canonical Lux
consensus cadence), the CPU path is more than sufficient. The
GPU port is for the throughput consumers:

- High-throughput bridge custody signing (institutional bridge
  validators processing many messages per second).
- N=100+ aggregate-cert verification.
- Backfilling slashing-evidence sweep across historical blocks.

The per-validator standalone primitive's typical deployment
(N = 21 validators producing one signature per block each) does
NOT need GPU acceleration to meet block-time bounds.

---

## 4. Magnetar canonical-name positioning across `luxfi/*`

### 4.1 Verified canonical surfaces

| Repo | Path | Magnetar role |
|---|---|---|
| `luxfi/magnetar` | `ref/go/pkg/magnetar/` | Reference implementation: PerValidatorKeypair + THBS-SE + strict-atom Combine + dealerless PVSS-DKG + slhdsa-internal §5-§8 walk |
| `luxfi/threshold` | `protocols/slhdsa-tee/` | TEE-attested signer + t-of-n CombinerPool for strict-PQ profile |
| `luxfi/threshold` | `pkg/thresholdd/magnetar.go` | JSON-RPC dispatcher; profile gate `magnetarRefuseUnderStrictPQ`; Sign / Sign_Ctx / Sign_TEE / Combine_TEE |
| `luxfi/threshold` | `study/magnetar.md` | Design study cross-referenced from Pulsar / Corona / cross-family-defense |
| `luxfi/precompile` | `magnetar/contract.go` | EVM precompile slot `0x012207` (LP-4200 canonical); FIPS 205 mode dispatch + per-mode gas |
| `luxfi/consensus` | `pkg/wire/zap/magnetar_aggregate.go` | LP-182 schema 0x04 wire view of `ValidatorAggregateCert`; embedded in Polaris-profile Magnetar leg |
| `luxfi/consensus` | `protocol/quasar/*.go` | References Magnetar as the per-validator-aggregate cert layer alongside ML-DSA / Pulsar |
| `luxfi/bridge` | `internal/mchain/protocol.go` + `cmd/bridge/signing_driver.go` | Bridge consumer of Magnetar signatures (M-Chain MPC custody primitive) |
| `luxfi/lux/crypto/slhdsa/` | `gpu.go`, `gpu_sign_test.go`, `gpu_test.go`, `provenance_test.go` | Tagged as "canonical Magnetar profile" in commentary; `CanonicalMagnetar = ModeSHA2_192f` in `crypto/pq/slhdsa/gpu/params.go` |

**No conflicting or legacy "SLH-DSA threshold" name exists.**
"Magnetar" is the single canonical name for the SLH-DSA threshold
construction across the entire `luxfi/*` ecosystem.

### 4.2 SHAKE-vs-SHA2 reconciliation

A subtle discrepancy: `luxfi/crypto/pq/slhdsa/gpu/params.go`
declares `CanonicalMagnetar = ModeSHA2_192f` (SHA2 family), while
the magnetar reference at `ref/go/pkg/magnetar/params.go` ships
ONLY the SHAKE family (M192s / M192f / M256s). Both are FIPS 205
compliant; the dual coverage is intentional --- the recovery-path
profile uses SHA2 (mirrors the EVM precompile's SHA2 modes), and
the threshold reference path uses SHAKE (because the
strict-atom-assembly `slhdsa_internal.go` implements the SHAKE
hash family only).

The precompile at `luxfi/precompile/magnetar/contract.go` handles
BOTH families correctly (`getModeParams` dispatches across all 12
modes). The headline canonical Magnetar parameter set in
production is SHAKE-192s (matching the v1.0 dispatcher default
`magnetar.MustParamsFor(magnetar.ModeM192s)`).

**Recommendation (informational, no code change required).**
`CanonicalMagnetar` in `luxfi/crypto/pq/slhdsa/gpu/params.go`
should evolve to a per-deployment knob rather than a single
constant. Today it pins the recovery-path profile, which is
correct for that consumer; the dispatcher's default `M192s` is
the canonical Magnetar production profile. The two values are
distinct deployments, not conflicting names.

### 4.3 SLH-DSA precompile (LP-4200 0x012203) vs Magnetar (0x012207)

LP-4200 reserves both slots:
- `0x012203 = SLH-DSA` (hash-based single-party signature)
- `0x012207 = Magnetar` (hash-based threshold FIPS 205)

The verifier is interchangeable (FIPS 205 byte-equal), but the
slot separation enables:
1. Gas-tier separation (threshold-emitted sigs may be metered
   distinctly from single-party sigs);
2. Telemetry separation (on-chain accounting can attribute
   Magnetar verifies separately);
3. Forward-compat (Magnetar could add non-FIPS-205 paths e.g.
   identifiable-abort hints).

This is correctly decomplected per the user mandate. No legacy
aliases exist.

---

## 5. Open items

### 5.1 MAGNETAR-EXTERNAL-AUDIT-V13

External cryptographer review of:
1. THBS-SE construction shape (`thbsse.go` + `thbsse_field.go`);
2. Strict-atom-assembly path (`thbsse_assemble.go` +
   `slhdsa_internal.go`);
3. Leaderless PVSS-DKG (`pvss_dkg.go`).

v0.x internal sign-off covered the abandoned v0.x surface, much
of which has been removed. v1.0 internal sign-off covers the
shipped surface up to the v1.0 line; v1.1 + v1.2 land additive
discipline (strict-atom + PVSS-DKG) without breaking the v1.0
wire format.

Status: OPEN.

### 5.2 MAGNETAR-GPU-PORT-V13

Land the four kernels described in §3.3 at
`lux-private/gpu-kernels/ops/crypto/slhdsa/` and wire through
`luxcpp/gpu` to the magnetar `slhSignAtom` substrate.

Status: PROPOSED (this audit).

### 5.3 MAGNETAR-APPLE-SE-HSM-V14

`hsm.Provider` backed by Apple Keychain with SecureEnclave-only
access control. Tests can mock; production Apple Silicon hosts
get a first-class HSM substrate.

Status: PROPOSED (this audit).

### 5.4 MAGNETAR-PROACTIVE-RESHARE-V13

Zero-secret-refresh against the same group public key. Lifts
the static-corruption bound to a refresh-window-bounded
adaptive-corruption bound. Forward-compatible share envelope
shape; no wire break.

Status: PROPOSED (this audit).

---

## 6. Verification

```bash
cd /Users/z/work/lux/magnetar/ref/go && \
  GOWORK=off go build ./... && \
  GOWORK=off go vet ./... && \
  GOWORK=off go test -count=1 -short -timeout 600s ./pkg/magnetar/...
```

All clean as of 2026-06-03 audit:
- `go build ./...` --- OK
- `go vet ./...` --- OK
- `go test -count=1 -short ./pkg/magnetar/...` --- ok 192.033s

```bash
cd /Users/z/work/lux/magnetar && bash scripts/checks/strict-atom-ast.sh
```

`strict-atom-ast: GATE GREEN` --- the four-pattern audit grep
returns zero matches and `TestThbsSE_StrictAtom_NoTransientSeed`
passes.

```bash
cd /Users/z/work/lux/threshold && \
  GOWORK=off go test -count=1 -short ./pkg/thresholdd/ \
    -run 'TestMagnetar' -timeout 600s
```

Magnetar dispatcher tests pinned in `magnetar_tee_gate_test.go`.

---

## 7. Recommendation

**APPROVED for v1.2 production deployment** on Lux
public-permissionless chains under the documented threat model.

- Per-validator standalone: APPROVED for unconditional production
  use (legacy-compat AND strict-PQ chains --- each validator's
  standalone keypair is fully attested at the consensus layer's
  validator registry).
- THBS-SE under legacy-compat profile: APPROVED for production
  use; combiner role is public; the residual microsecond residency
  window of master bytes in the public combiner's
  `derivedMaterial` is honestly documented in `SECURITY.md` §7.2.
- THBS-SE under strict-PQ profile: APPROVED via the sibling
  `luxfi/threshold/protocols/slhdsa-tee` package's t-of-n
  attested-combiner pool with AMD SEV-SNP attestation.

Track the four open items above against v1.3 / v1.4 milestones.
The shipped v1.2 architecture is forward-compatible with all four
lifts.

---

**Document metadata**

- Name: `AUDIT-2026-06.md`
- Reviewer: cryptographer agent (internal review)
- Date: 2026-06-03
- Magnetar reviewed at commit: `d640d15`