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

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

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.

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