docs/comments: correct lattice-family label Ring-LWE -> Module-LWE (Corona is Module-LWE)

Corona is Module-LWE (threshold-Raccoon/Ringtail), NOT Ring-LWE. Confirmed in code: sign/sign.go samples A in R_q^{8x7} (sign.go:87 SamplePolyMatrix M=8,N=7), secret s a rank-7 ring vector, b=A*s+e (sign.go:106-107) over R_q=Z_q[X]/(X^256+1) (LogN=8), q=0x1000000004A01 -- rank>1 module structure, not rank-1 ring-LWE. threshold/threshold.go:4-5 already said Module-LWE. Fixed the family label across README, SPEC, SUBMISSION, NIST-SUBMISSION, PATENTS, LLM, CONTRIBUTING, SECURITY, CHANGELOG, DEPLOYMENT-RUNBOOK, Makefile, AXIOM-INVENTORY, PROOF-CLAIMS, BLOCKERS, CRYPTOGRAPHER-SIGN-OFF, FIPS-TRACEABILITY, TRUSTED-COMPUTING-BASE, AUDIT-2026-05/06, docs/mptc/*, jasmin/README, 3 Go comments + cli help string. Also corrected the downstream false claim that Corona (Ring-LWE) and Pulsar (Module-LWE) are 'different lattice families' giving 'structural/family diversity': both are Module-LWE, so the Double-Lattice defense is construction/implementation diversity (threshold-Raccoon vs ML-DSA), not hardness-family diversity; a Module-LWE break affects both legs (hash-based Magnetar is the assumption-diversifier). Fixed companion R-SIS -> Module-SIS where it was the module scheme's SIS assumption; added the Langlois-Stehle (DCC 2015) Module-LWE citation alongside LPR 2010. Delicate artifacts: proof identifiers (rlwe_sign_op, RLWE_Functional theory/file, *_eq_rlwe bridges, CentralRLWESign, RLWESign, rlwe_compute_*) were NOT renamed -- EasyCrypt/jasmin toolchains are absent here so a rename cannot be compile-verified, and .assurance/ gates parse those names. Added clarifying naming notes to the 5 prominent .ec files, proofs/easycrypt/README.md, AXIOM-INVENTORY.md, and jasmin/rlwe/sign.jazz. .assurance/*.txt left untouched (already say Module-LWE/Module-SIS; rlwe tokens are gate-parsed identifiers). Left AUDIT-2026-06.md:463 historical rename-log and the ProtoStar-LWE paper-title substring untouched. go build ./... and go test ./... green (GOWORK=off; all packages ok).
2026-07-27 02:50:34 +00:00 · 2026-06-27 16:12:24 -07:00
parent 26eb3f35b7
commit df1db68bd0
37 changed files with 252 additions and 190 deletions
@@ -102,7 +102,7 @@ former.
 ## 2. SOTA refresh — is Boschini 2024/1113 still current?
 **Yes.** Boschini-Takahashi-Tibouchi 2024/1113 ("Threshold Raccoon"
-/ BTT24) remains the canonical 2-round non-interactive R-LWE
+/ BTT24) remains the canonical 2-round non-interactive Module-LWE
 threshold signature. No 2025 paper supersedes it as the production
 construction. Subsequent work refines specific aspects:
@@ -64,7 +64,7 @@ the complaint pipeline (§1.4 below). The chain MUST run
 `AUDIT-2026-05.md §10`).
 **Hash-to-curve binding**: Corona doesn't use hash-to-curve;
-it's an R-LWE scheme. The challenge `c = H(A, bTilde, w, μ, sid, T)`
+it's a Module-LWE scheme. The challenge `c = H(A, bTilde, w, μ, sid, T)`
 is a sponge output (Corona-SHA3 via KMAC256), and is
 domain-separated by `QUASAR-CORONA-*` prefixes
 (see `primitives/hash.go`).
@@ -278,7 +278,7 @@ trust-anchor citations, not integration specs.
   Silicon; honest disclosure that Apple does NOT publish a remote
   attestation root (local-only defense-in-depth).
 5. **Intel SGX**: NOT RECOMMENDED for Corona (long CVE record of
-   side-channel attacks against R-LWE math).
+   side-channel attacks against Module-LWE math).
 ### §2.3 Decomplecting rule
@@ -402,7 +402,7 @@ ops/mpcvm/wgsl/mpcvm_Corona.wgsl
 ops/crypto/Corona/cuda/
 ```
-These are **NOT** Corona's R-LWE math — they're the MPCVM
+These are **NOT** Corona's Module-LWE math — they're the MPCVM
 ceremony-state-machine kernel (Corona DKG ceremony op + Corona
 sign ceremony op as a generic "lattice ceremony" workflow). The
 real lattice arithmetic (NTT, Gaussian sampling, MLWE matrix
@@ -481,7 +481,7 @@ The fumadocs Next.js site at `docs/` was 3057 lines of MDX that
 framed Corona as a **privacy ring-signature scheme** with
 linkable Schnorr signatures, hash-to-curve, and "ring signatures
 for transaction privacy". That is NOT what Corona is — Corona is
-a 2-round R-LWE threshold signature scheme (Boschini et al.
+a 2-round Module-LWE threshold signature scheme (Boschini et al.
 2024/1113). The docs referenced a non-existent
 `github.com/luxfi/Corona` Go module and would have shipped a
 misleading product to anyone reading them. They are gone.
@@ -616,7 +616,7 @@ The audit closes the four scope dimensions:
   audits.
 **Production deployment posture (unchanged from v0.7.5)**: APPROVED
-WITH ROADMAP GATES for public-permissionless deployment as a R-LWE
+WITH ROADMAP GATES for public-permissionless deployment as a Module-LWE
 threshold signature primitive in Lux Quasar consensus, with the
 v0.8.0 GATE-3b + GATE-4 + GATE-5 carryovers remaining as
 research-track work. The TEE integration spec landed by this audit
@@ -19,6 +19,15 @@
 > **Lagrange-reconstructed master secret**). They are now correctly
 > classified **C / OPEN**.
 > **Naming note.** Identifiers and EasyCrypt/Lean file names containing
 > `rlwe` / `RLWE` (e.g. `rlwe_sign_op`, `RLWE_Functional.ec`, the wrapper
 > bridges `*_eq_rlwe`, and the informal "centralised RLWE sign" reference
 > signer) are retained **proof identifiers** for the single-party reference
 > signer the threshold protocol refines against; they are deliberately not
 > renamed, to keep the EasyCrypt/Lean developments compiling. Corona is a
 > **Module-LWE** scheme (threshold-Raccoon/Ringtail; module dims M=8, N=7
 > over `Z_q[X]/(X^256+1)`).
 ## Buckets
 - **A — STANDARD-MATH-FACT.** Cited field/algebra/coding identity EC lacks
@@ -33,14 +42,14 @@
 ## §1 Construction-level assumptions (cryptographic substrate — NOT Lux-closable)
-These are the underlying hardness + soundness assumptions of the R-LWE
+These are the underlying hardness + soundness assumptions of the Module-LWE
 threshold construction, inherited from the literature. They are not closed
 in any Lux work and are not counted in the EC axiom histogram below.
 | Assumption | Reference | Rationale for non-closure |
 |---|---|---|
-| Module-LWE / Ring-LWE hardness | Lyubashevsky-Peikert-Regev (TOC 2013); Langlois-Stehlé (DCC 2015) | Standard PQ lattice hardness; same substrate as ML-DSA / ML-KEM. |
+| Module-LWE hardness | Lyubashevsky-Peikert-Regev (TOC 2013); Langlois-Stehlé (DCC 2015) | Standard PQ lattice hardness; same substrate as ML-DSA / ML-KEM. |
-| R-SIS hardness over `R_q` | Ajtai (1996); Micciancio-Regev (SIAM 2007) | Unforgeability reduces to R-SIS at `sign/config.go` parameters. |
+| Module-SIS hardness over `R_q` | Ajtai (1996); Micciancio-Regev (SIAM 2007); Langlois-Stehlé (DCC 2015) | Unforgeability reduces to Module-SIS at `sign/config.go` parameters. |
 | Boschini-Kaviani-Lai-Malavolta-Takahashi-Tibouchi soundness | IACR ePrint 2024/1113; IEEE S&P 2025 | The 2-round threshold protocol's UC-soundness is in the cited paper; Lux's fork inherits it. Note: this is the Ringtail/Corona-family paper, NOT a Pulsar citation. |
 | Pedersen-VSS soundness | Pedersen (CRYPTO 1991) | Corona's DKG (`dkg2/`) reduces to discrete-log hardness. |
 | cSHAKE256 / KMAC256 collision + preimage resistance | NIST SP 800-185 | Domain-separated hashing across DKG/signing/reshare. |
@@ -137,7 +146,7 @@ ADMIT key counts the *word* "admit" in comments and is informational.
 | A13 | `rnd_to_bits_id` | RLWE_Functional.ec:241 | As A10. | As A10. |
 | A14 | `bits_to_sig_id` | RLWE_Functional.ec:242 | As A10. | As A10. |
 | A15 | `poly_degree_nonneg` | Corona_N1.ec:245 | `0 <= poly_degree s` (abstract `poly_degree`). | Discharge after `share_t` concretization. |
-| A16 | `accept_signing_attempt_iff_components` | Corona_N1.ec:547 | accept ⇔ (l2-z ∧ l2-Δ ∧ full-rank): algebra of the R-LWE accept predicate. | Discharge with the concrete accept predicate. |
+| A16 | `accept_signing_attempt_iff_components` | Corona_N1.ec:547 | accept ⇔ (l2-z ∧ l2-Δ ∧ full-rank): algebra of the Module-LWE accept predicate. | Discharge with the concrete accept predicate. |
 | A17 | `compute_mu_injective` | Corona_N1.ec:563 | distinct (m,ctx) ⇒ distinct mu (transcript binder injectivity). | Discharge with concrete transcript_hash. |
 | A18 | `context_bytes_len_bound` | Corona_N1.ec:356 | `0 <= |context_bytes ctx| <= 65535`. | Discharge after `context_bytes` concretization. |
@@ -188,24 +197,24 @@ Corona's EC byte-equality (`corona_n1_byte_equality` /
 `CombineAbs.combine`, whose body (`wrapper_combine_refines_abs`, lines
 96–142 of Corona_N1_Combine_Wrapper.ec) reduces — via the bridge axioms
 below — to `rlwe_sign_op (reconstruct quorum shares) m ctx rho_rnd`: the
-**centralised R-LWE signer applied to the Lagrange-reconstructed master
+**centralised Module-LWE signer applied to the Lagrange-reconstructed master
 secret**. This is the **reconstruct-then-sign / CombineAbs reconstruct-then-
 sign abstraction**. The "steps 2–6" of the Boschini combine (the
 `CombineAbs.combine` open/aggregate/reject steps) are **opened**, not
 proved leak-free. The no-leak property of the production signer is
-**interop-tested (Go↔C++ KAT byte-equality; and the production R-LWE path's
+**interop-tested (Go↔C++ KAT byte-equality; and the production Module-LWE path's
 correctness is by code review against the paper), NOT EC-proven**.
 Tracked: `BLOCKERS.md` § "EC reconstruct-then-sign model".
 | # | Axiom | File:line | What is assumed (open) |
 |---|---|---|---|
-| C1 | `combine_body_axiom` (declare axiom) | Corona_N1.ec:697 | `T.combine ~ CombineAbs.combine` on honest-quorum inputs — the extracted threshold combine equals the centralised RLWE sign of the reconstructed secret. The module-contract form of the whole combine refinement; closure pathway is the Jasmin byte-walk (production target v0.8.0). |
+| C1 | `combine_body_axiom` (declare axiom) | Corona_N1.ec:697 | `T.combine ~ CombineAbs.combine` on honest-quorum inputs — the extracted threshold combine equals the centralised Module-LWE sign of the reconstructed secret. The module-contract form of the whole combine refinement; closure pathway is the Jasmin byte-walk (production target v0.8.0). |
 | C2 | `S_functional_spec` (declare axiom) | Corona_N1.ec:712 | `S.sign ~ CentralRLWESign.sign` on accepted inputs — the single-party module is a faithful Boschini signer. |
 | C3 | `combine_body_spec` | Corona_N1_Combine_Refinement.ec:63 | the Jasmin-extracted combine writes exactly `combine_abs_op(args)` to sig_out. Atomic byte-walk; **steps 2–6 are inside this axiom, unproved.** |
 | C4 | `sign_body_spec` | Corona_N1_Sign_Refinement.ec:42 | the Jasmin-extracted central sign writes exactly `sign_abs_op(args)` to sig_out. Atomic byte-walk. |
 | C5 | `combine_abs_op_lifted_bridge` | Corona_N1_Combine_Wrapper.ec:47 | the share-typed lifted combine op = the byte-level `combine_abs_op` modulo encoding. The bridge from the abstract module interface to the byte-walk; the security content rides here. |
 | C6 | `sign_abs_op_lifted_bridge` | Corona_N1_Sign_Wrapper.ec:27 | the share-typed lifted sign op = the byte-level `sign_abs_op` modulo encoding. |
-| C7 | `sign_abs_op_lifted_eq_rlwe` | Corona_N1_Sign_Wrapper.ec:38 | **the reconstruct-then-sign identity in its starkest form**: `sign_abs_op_lifted sk … = rlwe_sign_op sk …` — the lifted op IS the centralised Boschini signer (the analog of libjade's role for Pulsar, but in-house since R-LWE has no FIPS target). This is the open Boschini-conformance claim. |
+| C7 | `sign_abs_op_lifted_eq_rlwe` | Corona_N1_Sign_Wrapper.ec:38 | **the reconstruct-then-sign identity in its starkest form**: `sign_abs_op_lifted sk … = rlwe_sign_op sk …` — the lifted op IS the centralised Boschini signer (the analog of libjade's role for Pulsar, but in-house since Module-LWE threshold has no FIPS target). This is the open Boschini-conformance claim. |
 | C8 | `rlwe_sign_size` | RLWE_Functional.ec:204 | per-instance signature byte length under Boschini's rejection-sampling. Carries the construction's wire-size contract; classified C because it is a construction-level claim from the paper, not a pure layout identity. |
 | C9 | `sign_round1_constant_time` (declare axiom) | lemmas/Corona_CT.ec:80 | Round-1 commit is constant-time. A CT *contract*, discharged Jasmin-side via `jasminc -checkCT` (roadmap), NOT by EC; a timing property, so a name/EC claim cannot certify it (see `proof-by-rename.sh` rationale). |
 | C10 | `sign_round2_constant_time` (declare axiom) | lemmas/Corona_CT.ec:110 | Round-2 response is constant-time. As C9. |
@@ -7,7 +7,7 @@ N4 reshare / code-review-against-Boschini claims are at the disclosed
 v0.7.0/v0.8.0-roadmap tier; the EasyCrypt byte-equality proof rests on an
 OPEN reconstruct-then-sign axiom cone, the constant-time evidence is a
 static audit (dudect-submission-grade pending), and there is no independent
-interop verifier for the R-LWE construction. None of these is hidden — they
+interop verifier for the Module-LWE construction. None of these is hidden — they
 are the honest proof-tier of a published-construction implementation. See
 `PROOF-CLAIMS.md` §0 and `AXIOM-INVENTORY.md` §C.
@@ -43,7 +43,7 @@ admits) **relative to** the bucket-C-idealised axioms:
  steps 2–6 are INSIDE it, unproved.
 - `combine_abs_op_lifted_bridge` + `sign_abs_op_lifted_eq_rlwe` — the
  wrapper bridges pinning the lifted op to
-  `rlwe_sign_op (reconstruct quorum shares) …`, i.e. the centralised R-LWE
+  `rlwe_sign_op (reconstruct quorum shares) …`, i.e. the centralised Module-LWE
  signer on the **Lagrange-reconstructed master secret**.
 - `combine_body_axiom` / `S_functional_spec` — the section-local contracts.
@@ -126,7 +126,7 @@ residual C11′ and the unchanged B-bucket codec bridges.
 Remaining OPEN:
 - The production no-leak path's correctness is ALSO established by code
-  review + cross-runtime KAT (Go↔C++); there is no independent R-LWE
+  review + cross-runtime KAT (Go↔C++); there is no independent Module-LWE
  verifier (CORONA-NO-INDEP-VERIFIER — by design, no NIST target).
 - `no_leak_reduction`'s full simulation-soundness proof (the v0.8.0
  EC/paper artifact) is not written; disclosed as a Module-LWE/MSIS reduction.
@@ -180,18 +180,18 @@ dudect harness (`ct/dudect/`) is wired at smoke-budget.
 ### CORONA-NO-INDEP-VERIFIER (MEDIUM — interop disclosure)
-**Status: OPEN by design (no NIST target for R-LWE).** Corona's signature
+**Status: OPEN by design (no NIST target for Module-LWE).** Corona's signature
 byte-equality is cross-validated only **Go↔C++ of the SAME construction**
 (`luxcpp/crypto/corona` via `scripts/regen-kats.sh --verify`), NOT against
 an independent verifier. Unlike Pulsar (CIRCL + pq-crystals FIPS 204), the
-Boschini R-LWE construction has no second independent implementation to
+Boschini Module-LWE construction has no second independent implementation to
 diff against. Therefore Corona's combine byte-equality is **asserted +
 same-construction-KAT-tested**, never "proven/verified" in the
 ≥2-independent-implementations sense. `PROOF-CLAIMS.md` is worded to never
 claim otherwise.
 **Resolution criteria:**
- [ ] An independent R-LWE verifier (third-party or a from-the-paper
+- [ ] An independent Module-LWE verifier (third-party or a from-the-paper
      re-implementation) is stood up and the KAT manifest diffs against it, OR
 - [ ] External review accepts the same-construction KAT + code-review
      posture as sufficient for the disclosed tier (shared external-review
@@ -288,7 +288,7 @@ from the v0.6.0 sign-off.
 - `~/work/lux/proofs/lean/Crypto/Corona/OutputInterchange.lean` --
  Class N1 verifier-compatibility.
 - `~/work/lux/proofs/lean/Crypto/Corona/Unforgeability.lean` --
-  EUF-CMA reduction to Ring-LWE.
+  EUF-CMA reduction to Module-LWE.
 - `~/work/lux/proofs/lean/Crypto/Corona/dkg2.lean` -- Pedersen-VSS DKG.
 ### Jasmin sources
@@ -350,7 +350,7 @@ FIPS 204 sibling), adapted honestly to Corona's lighter proof tier.
 - `SUBMISSION.md` — NIST MPTC cover sheet. Cites Boschini et al. ePrint
  2024/1113 (IEEE S&P 2025) as the underlying construction. Declares
-  construction-level N1 (no FIPS standard target available for R-LWE
+  construction-level N1 (no FIPS standard target available for Module-LWE
  threshold) + N4 (`(A, bTilde)` preserved across reshare within key era).
  Two-variant honesty disclosure: Pedersen DKG (`dkg2/`) is the production
  path; legacy `dkg/` is retained for historical reference only.
@@ -380,7 +380,7 @@ FIPS 204 sibling), adapted honestly to Corona's lighter proof tier.
  Boschini et al. construction).
 - `docs/design-decisions.md`, `docs/family-architecture.md`,
  `docs/threat-model.md` — adapted from Pulsar's pattern to Corona's
-  R-LWE / `R_q` setting.
+  Module-LWE / `R_q` setting.
 ### Honest gaps documented
@@ -394,7 +394,7 @@ This submission EXPLICITLY does NOT include (per `PROOF-CLAIMS.md` §3):
  `papers/lp-073-pulsar/` are the current canonical material).
 - Parameter-set worksheet with concrete lattice-estimator bounds.
 - ACVP/CAVP algorithm validation certificate (no NIST ACVP test vector
-  set exists for R-LWE threshold).
+  set exists for Module-LWE threshold).
 - FIPS 140-3 module validation (downstream).
 - External cryptographic audit (engaged lab) — roadmap v0.8.0.
@@ -2,7 +2,7 @@
 ## What we accept
-This repository is **both** a production Ring-LWE threshold signature
+This repository is **both** a production Module-LWE threshold signature
 library for Quasar consensus AND a NIST-MPTC-track submission
 package. Until the 2026-Nov-16 package submission, contributions that
 align with the MPTC submission are highest priority:
@@ -42,8 +42,9 @@ Until after the MPTC submission lands:
  KMAC256 / TupleHash256 exclusively (Corona-SHA3). The legacy
  Corona-BLAKE3 suite is retained for cross-port byte checks only;
  new BLAKE3 deltas should NOT land.
- Patches that introduce Pulsar (M-LWE) types into Corona (R-LWE).
+- Patches that introduce Pulsar (ML-DSA) types into Corona
-  The two libraries are independent with no shared types; keep
+  (threshold-Raccoon). Both are Module-LWE, but they are distinct
  constructions in independent libraries with no shared types; keep
  them that way.
 These reopen post-submission.
@@ -1,6 +1,6 @@
 # Cryptographer sign-off -- luxfi/corona v0.7.0
-> Independent review of the Corona threshold R-LWE implementation
+> Independent review of the Corona threshold Module-LWE implementation
 > at `main` of `github.com/luxfi/corona`.
 > Date of review: 2026-05-18.
 > Reviewer: cryptographer agent (Hanzo Dev, internal review).
@@ -69,14 +69,14 @@ byte-equality with `luxcpp/crypto/corona/`).
 - **`~/work/lux/proofs/lean/Crypto/Corona/`**:
  - `Shamir.lean` -- Lagrange-over-polynomial-ring algebraic core.
  - `OutputInterchange.lean` -- Class N1 verifier-compatibility.
-  - `Unforgeability.lean` -- EUF-CMA reduction to R-LWE.
+  - `Unforgeability.lean` -- EUF-CMA reduction to Module-LWE.
  - `dkg2.lean` -- Pedersen-VSS DKG correctness statement.
 - **`jasmin/`**:
  - `lib/` -- shared primitives (corona_params, seed, transcript,
    mac, lagrange).
  - `threshold/round1.jazz`, `round2.jazz`, `combine.jazz` -- the
    Boschini 2-round threshold protocol with `#ct` annotations.
-  - `rlwe/sign.jazz` -- centralized R-LWE Sign reference.
+  - `rlwe/sign.jazz` -- centralized Module-LWE Sign reference.
 - **`ct/dudect/`**:
  - `verify_ct.go` + `dudect_verify.c` -- Verify CT harness.
  - `combine_ct.go` + `dudect_combine.c` -- Combine CT harness.
@@ -197,7 +197,7 @@ byte-equality with `luxcpp/crypto/corona/`).
 I attest that, given the above review and the explicit non-claims
 documented in `corona/PROOF-CLAIMS.md` §3 (now reflecting the v0.7.0
 EC + Lean + Jasmin scaffold), `luxfi/corona` v0.7.0 is **APPROVED
-WITH ROADMAP GATES** for production use as a R-LWE threshold
+WITH ROADMAP GATES** for production use as a Module-LWE threshold
 signature primitive in Lux Quasar consensus' Aurora and Polaris cert
 profiles.
@@ -1,6 +1,6 @@
 # Deployment Runbook — luxfi/corona
-> Operational guidance for deploying Corona (threshold Ring-LWE
+> Operational guidance for deploying Corona (threshold Module-LWE
 > signing + Pedersen DKG + proactive resharing) in production
 > validator sets. Discloses the v0.2 trust-model caveats and pins
 > the safe operating envelope.
@@ -1,6 +1,6 @@
 # FIPS-TRACEABILITY — Corona
-> Construction-paper → code traceability map. R-LWE has no FIPS
+> Construction-paper → code traceability map. Module-LWE has no FIPS
 > standard, so this document maps **Boschini ePrint 2024/1113 (IEEE
 > S&P 2025)** sections to `~/work/lux/corona/` implementation paths.
 > Equivalent role to Pulsar's `FIPS-TRACEABILITY.md` (which maps
@@ -89,7 +89,7 @@ unforgeability — see `AXIOM-INVENTORY.md` §2.
 - NOT a security proof. The Boschini construction's security is
  proved in the cited paper.
- NOT a NIST FIPS standard reference (R-LWE has no FIPS standard).
+- NOT a NIST FIPS standard reference (Module-LWE has no FIPS standard).
 - NOT a mechanized refinement against the cited paper. EC theories
  that formalize this mapping are roadmap v0.7.0 (see
  `AXIOM-INVENTORY.md` §2 + `PROOF-CLAIMS.md` §3).
@@ -6,7 +6,7 @@
 ## Purpose (one-liner)
-Ring-LWE threshold signature library used as the post-quantum threshold
+Module-LWE threshold signature library used as the post-quantum threshold
 layer in Quasar consensus. Corona provides O(1) per-cert proofs after
 DKG, paired with BLS12-381 + ML-DSA-65 in the QuasarCert.
@@ -21,7 +21,7 @@ keygen path. This is why **Corona — not Pulsar — carries the permissionless
 no-trusted-dealer guarantee** in the Quasar AND-mode dual-PQ cert: Pulsar's
 byte-FIPS-204 keygen is provably stuck at a trusted dealer (a dealerless sum
 of FIPS-204 secrets breaks ML-DSA's small-norm `S_η` bound), so the
-dealerless property must come from Corona's R-LWE leg.
+dealerless property must come from Corona's Module-LWE leg.
 This repository is BOTH the production library AND the active NIST MPTC
 submission package (Class N1 + N4). The submission tarball is cut from a
@@ -45,7 +45,7 @@ tag on `main` via `scripts/cut-submission.sh`; reviewer feedback lands here.
 | `docs/patent-claims.md` | Attorney-prep claim drafts (FEWER than Pulsar — only Corona-novel lifecycle additions) |
 **HONESTY GUARD**: do not claim Corona has EC / Lean / Jasmin proofs. It does not.
-Pulsar does; Corona's R-LWE has no FIPS standard target to refine against. See
+Pulsar does; Corona's Module-LWE construction has no FIPS standard target to refine against. See
 `PROOF-CLAIMS.md` §3 for the explicit non-claims list.
 ## Recent significant commits
@@ -73,7 +73,7 @@ Pulsar does; Corona's R-LWE has no FIPS standard target to refine against. See
 ### Active versions
 - Repo: `v0.8.0`. The default `keyera.Bootstrap` / `keyera.BootstrapWithSuite` route through `BootstrapPedersen` (dealerless Pedersen DKG over R_q); the legacy trusted-dealer impl is the unexported `bootstrapTrustedDealerImpl`, reachable only via the explicit `BootstrapTrustedDealer*` / `ReanchorTrustedDealer*` names.
- Pinned by: `luxfi/consensus v1.23.6+` (R-LWE path is consensus-only).
+- Pinned by: `luxfi/consensus v1.23.6+` (Module-LWE path is consensus-only).
 ### Canonical params
 - Ring degree: 256 (LogN=8).
@@ -87,7 +87,7 @@ Pulsar does; Corona's R-LWE has no FIPS standard target to refine against. See
 - `golang.org/x/crypto/sha3` → cSHAKE256 / KMAC256 / TupleHash256.
 - `zeebo/blake3` → LEGACY only (cross-port byte-check).
 - Consumed by:
-  - `luxfi/consensus/protocol/quasar` (R-LWE threshold for QuasarCert).
+  - `luxfi/consensus/protocol/quasar` (Module-LWE threshold for QuasarCert).
 - Cross-runtime byte-equal port: `~/work/luxcpp/crypto/corona/` (KAT manifest at `scripts/regen-kats.manifest.sha256`).
 ### Where to look for X
@@ -105,9 +105,9 @@ Pulsar does; Corona's R-LWE has no FIPS standard target to refine against. See
 ### Open follow-ups (tracked in BLOCKERS.md)
 - Constant-time: `jasminc -checkCT` on the extracted threshold layer + dudect submission-grade 10⁹-sample run (CORONA-CT-PENDING).
 - `no_leak_reduction` discharged to a full Module-LWE/M-SIS simulation proof, OR accepted by external review as a standard reduction; plus the C11′ public-`w` commitment-aggregate bridge (CORONA-EC-RECON-MODEL).
- Independent R-LWE interop verifier, OR external review accepting the same-construction Go↔C++ KAT posture (CORONA-NO-INDEP-VERIFIER).
+- Independent Module-LWE interop verifier, OR external review accepting the same-construction Go↔C++ KAT posture (CORONA-NO-INDEP-VERIFIER).
 - External cryptographic review — shared gate across the three open findings above.
- Variable-size R-LWE certs remain a wire-size cost vs Pulsar M-LWE; consensus uses Corona for finality-throughput and Pulsar for the identity rollup.
+- Variable-size Corona (Module-LWE, Raccoon-line) certs remain a wire-size cost vs Pulsar's fixed-size ML-DSA certs; consensus uses Corona for finality-throughput and Pulsar for the identity rollup.
 ## Rules
@@ -116,7 +116,7 @@ Pulsar does; Corona's R-LWE has no FIPS standard target to refine against. See
   hardcode SHAKE / KMAC outside `hash/sp800_185.go`.
 3. Param changes require a new key-era boundary; never edit in place.
 4. NEVER claim mechanized refinement Corona does not have. See `PROOF-CLAIMS.md` §3.
-5. NEVER mix Pulsar (M-LWE) types into Corona (R-LWE) — independent libraries with no shared types.
+5. NEVER mix Pulsar (ML-DSA) types into Corona (threshold-Raccoon) — both Module-LWE, but independent libraries with no shared types.
 6. NEVER push the legacy `dkg/` package onto a deployment surface — it has known
   leakage (Feldman VSS without blinding). Production uses `dkg2/`.
 7. Cross-runtime byte-equality with the C++ port (`~/work/luxcpp/crypto/corona/`)
@@ -1,4 +1,4 @@
-# Corona - Post-Quantum Ring-LWE Threshold Signature Scheme
+# Corona - Post-Quantum Module-LWE Threshold Signature Scheme
 # Makefile for building, testing, and managing the project
 .PHONY: all build test clean fmt lint vet coverage bench run help install-tools
@@ -33,7 +33,7 @@ all: test build
 ## help: Display this help message
 help:
-	@echo "Corona - Post-Quantum Ring-LWE Threshold Signature Scheme"
+	@echo "Corona - Post-Quantum Module-LWE Threshold Signature Scheme"
 	@echo ""
 	@echo "Usage: make [target]"
 	@echo ""
@@ -10,10 +10,10 @@
 |---|---|
 | Submission name | **Corona** |
 | Submitting organisation | Lux Industries, Inc. |
-| Algorithm | Threshold Ring-LWE 2-round signing + Pedersen DKG + proactive resharing |
+| Algorithm | Threshold Module-LWE 2-round signing + Pedersen DKG + proactive resharing |
 | MPTC classes | **N1** (construction-level threshold signing) + **N4** (multi-party key generation with public-key preservation across resharing) |
 | Underlying construction | Boschini, Kaviani, Lai, Malavolta, Takahashi, Tibouchi. *Practical two-round threshold signatures from learning with errors.* IACR ePrint **2024/1113**, IEEE S&P 2025 |
-| Lattice family | Ring-LWE over `R_q = Z_q[X]/(X^N + 1)`, `N = 256`, `q = 0x1000000004A01` (48-bit NTT-friendly prime) |
+| Lattice family | Module-LWE over `R_q = Z_q[X]/(X^N + 1)`, `N = 256`, module dims `M = 8` × `N = 7`, `q = 0x1000000004A01` (48-bit NTT-friendly prime) |
 | Round count | 2 rounds per signature |
 | Hash suite | Corona-SHA3 (cSHAKE256 / KMAC256 / TupleHash256, FIPS 202 + SP 800-185) |
 | Repository | <https://github.com/luxfi/corona> |
@@ -31,17 +31,17 @@
 > a key era (Class N4 invariant).
 **Theorem framing**: construction-level interchangeability. Corona
-implements the published Boschini et al. 2-round R-LWE threshold
+implements the published Boschini et al. 2-round Module-LWE threshold
 signature scheme (IACR ePrint 2024/1113) on a fixed parameter set;
 Corona's contribution beyond the academic paper is the production
 lifecycle (Pedersen DKG over `R_q`, proactive resharing, identifiable
 abort, activation certs, KAT-deterministic Corona-SHA3 hash suite).
-**Verifier-side reality.** R-LWE threshold signatures have no NIST
+**Verifier-side reality.** Module-LWE threshold signatures have no NIST
 standard at submission time. The Boschini et al. construction
 verifier is the spec. Corona's `sign.Verify` is the canonical
 implementation of that verifier; there is no third-party
-FIPS-validated R-LWE verifier to cross-check against. This is the
+FIPS-validated Module-LWE verifier to cross-check against. This is the
 honest framing distinction from Pulsar (M-LWE / FIPS 204), which
 DOES cross-check against BoringSSL FIPS / AWS-LC / OpenSSL 3.0 PQ.
@@ -60,7 +60,7 @@ DOES cross-check against BoringSSL FIPS / AWS-LC / OpenSSL 3.0 PQ.
 ## What makes this submission different
-1. **Production-hardened R-LWE threshold** — beyond the Boschini et al.
+1. **Production-hardened Module-LWE threshold** — beyond the Boschini et al.
   academic construction, Corona adds Pedersen DKG over `R_q`
   (`dkg2/`), proactive resharing with two distinct primitives
   (`Refresh` for same-set; `ReshareToNewSet` for set rotation),
@@ -122,10 +122,10 @@ The trust base for Corona at submission time reduces to:
 | Out-of-scope claim | Why |
 |---|---|
-| Byte-equality with FIPS 204 ML-DSA | That is Pulsar's claim. Corona is R-LWE; ML-DSA is M-LWE. |
+| Byte-equality with FIPS 204 ML-DSA | That is Pulsar's claim. Both are Module-LWE, but Corona is the Raccoon/Ringtail-line threshold, not FIPS-204 ML-DSA. |
-| Mechanized refinement proof | Multi-month research project. No FIPS standard target exists for R-LWE threshold. See `PROOF-CLAIMS.md`. |
+| Mechanized refinement proof | Multi-month research project. No FIPS standard target exists for Module-LWE threshold. See `PROOF-CLAIMS.md`. |
-| Post-quantum hardness of R-LWE | Assumed from Lyubashevsky-Peikert-Regev (2010) and follow-up analysis. |
+| Post-quantum hardness of Module-LWE | Assumed from Lyubashevsky-Peikert-Regev (2010), the Langlois-Stehlé (2015) module generalisation, and follow-up analysis. |
-| ACVP/CAVP algorithm validation certificate | Not applicable — NIST has no ACVP test vector set for R-LWE threshold. |
+| ACVP/CAVP algorithm validation certificate | Not applicable — NIST has no ACVP test vector set for Module-LWE threshold. |
 | FIPS 140-3 module validation | Downstream — applies to packaged modules. |
 | Asynchronous identifiable abort | Synchronous only. |
 | 1-round signing | Construction is 2-round by design (Boschini et al.). |
@@ -1,4 +1,4 @@
-# PATENTS — Corona Threshold Ring-LWE Signature
+# PATENTS — Corona Threshold Module-LWE Signature
 > **Statement of Intellectual Property and Royalty-Free Patent Grant**
 > for the Corona threshold-signing construction submitted to the NIST
@@ -15,7 +15,7 @@ interoperability test.
 The grant terminates automatically and prospectively against any
 party that asserts a patent claim against Corona, the underlying
-Boschini et al. R-LWE construction, FIPS 204 ML-DSA, or any other
+Boschini et al. Module-LWE construction, FIPS 204 ML-DSA, or any other
 NIST-standardized post-quantum signature scheme. Defensive
 termination mirrors Apache-2.0 §3.
@@ -38,8 +38,8 @@ It does NOT cover, and explicitly DISCLAIMS, the following prior art:
 | Component | Status |
 |---|---|
-| The base 2-round Ring-LWE threshold construction (Boschini, Kaviani, Lai, Malavolta, Takahashi, Tibouchi. *Practical two-round threshold signatures from learning with errors.* IACR ePrint 2024/1113, IEEE S&P 2025) | Academic prior art. Corona implements this construction unchanged in its math. Lux asserts no patents on the published Boschini et al. algorithm itself. |
+| The base 2-round Module-LWE threshold construction (Boschini, Kaviani, Lai, Malavolta, Takahashi, Tibouchi. *Practical two-round threshold signatures from learning with errors.* IACR ePrint 2024/1113, IEEE S&P 2025) | Academic prior art. Corona implements this construction unchanged in its math. Lux asserts no patents on the published Boschini et al. algorithm itself. |
-| Ring-LWE (R-LWE) primitive (Lyubashevsky, Peikert, Regev. *On ideal lattices and learning with errors over rings.* EUROCRYPT 2010) | Academic / public domain. |
+| Module-LWE primitive (Langlois, Stehlé. *Worst-case to average-case reductions for module lattices.* Designs, Codes and Cryptography 2015), building on the Ring-LWE primitive (Lyubashevsky, Peikert, Regev. *On ideal lattices and learning with errors over rings.* EUROCRYPT 2010) | Academic / public domain. |
 | Shamir secret sharing (1979) | Public domain. |
 | Lagrange polynomial interpolation | Classical mathematics. |
 | Pedersen verifiable secret sharing (Pedersen 1991) | Academic prior art. Corona's `dkg2/` adapts the Pedersen VSS construction to `R_q^M` lattice commits; the adaptation pattern is generic. |
@@ -55,7 +55,7 @@ Subject to attorney review (see `docs/patent-claims.md` for the
 detailed numbered claim drafts), Lux considers the following Corona
 contributions to be candidates for patent protection. Note: this
 list is intentionally narrower than Pulsar's because the underlying
-2-round R-LWE construction is published academic prior art (Boschini
+2-round Module-LWE construction is published academic prior art (Boschini
 et al. 2024/1113). Corona's novel contributions are the production
 lifecycle layers atop the published construction.
@@ -79,14 +79,14 @@ implementation in `dkg2/`.
 Proactive secret-sharing protocol that rotates shares across
 committee changes while preserving the group public key `(A, bTilde)`
-in the R-LWE setting. Permits long-lived public identity with
+in the Module-LWE setting. Permits long-lived public identity with
 rotating custodians. Two distinct primitives:
 - `Refresh` — same committee, fresh shares (HJKY97 lineage adapted
-  to R-LWE).
+  to Module-LWE).
 - `ReshareToNewSet` — set rotation with `t_old → t_new` threshold
  changes (Desmedt-Jajodia / Wong-Wang-Wing lineage adapted to
-  R-LWE).
+  Module-LWE).
 Detailed in `papers/lp-073-pulsar/lp-073-pulsar-resharing.tex`;
 implementation in `reshare/`.
@@ -179,7 +179,7 @@ injection into Sign"; implementation in `primitives/hash.go` +
 >
 > (i) The Corona construction; or
 > (ii) The underlying Boschini-Kaviani-Lai-Malavolta-Takahashi-Tibouchi
->      2-round R-LWE threshold signature construction (IACR ePrint
+>      2-round Module-LWE threshold signature construction (IACR ePrint
 >      2024/1113); or
 > (iii) FIPS 204 ML-DSA, or any other NIST-standardized post-quantum
 >       signature scheme; or
@@ -229,7 +229,7 @@ lifecycle additions as follows:
   for §102 purposes; filing before submission preserves priority).
 2. **PCT international application** within 12 months of the
-   provisional, designating jurisdictions where R-LWE deployment is
+   provisional, designating jurisdictions where Module-LWE deployment is
   anticipated (EU, JP, CN, KR, IN, AU, CA, UK, BR).
 3. **EPO and major-jurisdiction national-phase entries** at the PCT
@@ -273,7 +273,7 @@ signature schemes.
 ### §5.3 Compatibility with the published Boschini et al. construction
-The underlying 2-round R-LWE threshold protocol is published in the
+The underlying 2-round Module-LWE threshold protocol is published in the
 academic literature (IACR ePrint 2024/1113, IEEE S&P 2025). Lux
 asserts no patents on the published academic construction itself;
 Corona's claims are limited to the production-lifecycle additions.
@@ -27,7 +27,7 @@ NOT the production residual (RE-SCOPED this pass).**
 `_extracted` prove the threshold combine equals `CombineAbs.combine`, whose
 body reduces — via `combine_abs_op_lifted_bridge` and
 `sign_abs_op_lifted_eq_rlwe` — to `rlwe_sign_op (reconstruct quorum
-shares) …`: the centralised R-LWE signer applied to the
+shares) …`: the centralised Module-LWE signer applied to the
 **Lagrange-reconstructed master secret**. The Boschini combine steps 2–6 are
 opened inside `combine_body_spec`, not proved. So Model 1 is machine-checked
 (0 admits) modulo a C-cone that **reconstructs-then-signs** — an idealised
@@ -54,7 +54,7 @@ pending EasyCrypt**; its Lean core is machine-checked now.
 **Disclosure 2 — the no-leak property is NOT independently interop-tested.**
 Corona's KAT cross-validation is **Go↔C++ of the SAME construction**
 (`luxcpp/crypto/corona`), not against an independent verifier. There is no
-CIRCL/pq-crystals analog for R-LWE (no NIST target). So Corona's combine
+CIRCL/pq-crystals analog for Module-LWE (no NIST target). So Corona's combine
 output byte-equality is **asserted + same-construction-KAT-tested**, NOT
 interop-tested in the ≥2-independent-implementations sense (unlike Pulsar's
 CIRCL + pq-crystals). We therefore do NOT claim Corona byte-equality is
@@ -138,27 +138,28 @@ secret). See §0 Disclosure 1.
 The implementation-backed N1 byte-equality theorem to cite is
 `Corona_N1_Extracted.corona_n1_byte_equality_extracted`.
-R-LWE threshold signing has no NIST standard target. The Boschini
+Module-LWE threshold signing has no NIST standard target. The Boschini
 et al. ePrint 2024/1113 construction IS the spec; the EC theories
 refine the Go implementation against the in-house mechanization of
 that spec (`lemmas/RLWE_Functional.ec`), which is the analog of
 Pulsar's libjade dependence on FIPS 204.
-### §3.2 NOT proved: lattice-hardness of R-LWE
+### §3.2 NOT proved: lattice-hardness of Module-LWE
 This submission says nothing about the post-quantum hardness of
-Ring-LWE itself. R-LWE security rests on Lyubashevsky-Peikert-Regev
+Module-LWE itself. Module-LWE security rests on Lyubashevsky-Peikert-Regev
-(2010) and follow-up cryptanalytic analysis. The parameter set
+(2010), the Langlois-Stehlé (2015) module generalisation, and follow-up
 cryptanalytic analysis. The parameter set
 (`N = 256`, `q = 0x1000000004A01`, 48-bit prime) was chosen to
 provide ≥ 128 bits of post-quantum security per lattice-estimator
 methodology — but Corona ships no parameter-set worksheet at this
 revision; that is roadmap item v0.6.0.
 **The defensible PQ-safety claim**:
-> Corona implements a published academic R-LWE threshold signature
+> Corona implements a published academic Module-LWE threshold signature
 > construction (Boschini et al. ePrint 2024/1113) on a parameter
 > set chosen to provide ≥ 128 bits of post-quantum security against
-> known R-LWE attacks per the lattice-estimator methodology of
+> known Module-LWE attacks per the lattice-estimator methodology of
 > Albrecht-Player-Scott. The construction's EUF-CMA reduction is in
 > the cited paper.
@@ -168,9 +169,10 @@ revision; that is roadmap item v0.6.0.
 ### §3.3 NOT proved: byte-equality with FIPS 204 ML-DSA
 Corona signatures are NOT byte-equal to FIPS 204 ML-DSA signatures.
-The two constructions use different lattice families (Corona is
+The two constructions are different schemes within the Module-LWE
-R-LWE; ML-DSA is M-LWE), different ring degrees, different
+family (Corona is the Raccoon/Ringtail line; ML-DSA is the Dilithium
-parameter sets. Any reviewer expecting FIPS 204 byte-equality
+line), with different moduli, module dimensions, and parameter sets.
 Any reviewer expecting FIPS 204 byte-equality
 should look at the Pulsar sibling at `~/work/lux/pulsar/`.
 ### §3.4 NOT proved: statistical constant-time validation (dudect)
@@ -273,7 +275,7 @@ same-construction Go↔C++ KAT only (§0 Disclosure 2).
 > Corona's submission package establishes that the Go reference
 > implementation faithfully implements the Boschini, Kaviani, Lai,
-> Malavolta, Takahashi, and Tibouchi 2-round R-LWE threshold
+> Malavolta, Takahashi, and Tibouchi 2-round Module-LWE threshold
 > signature construction (IACR ePrint 2024/1113, IEEE S&P 2025) on a
 > fixed parameter set, plus production lifecycle additions (Pedersen
 > DKG over `R_q`, proactive resharing with Refresh + ReshareToNewSet
@@ -282,7 +284,7 @@ same-construction Go↔C++ KAT only (§0 Disclosure 2).
 > suite). Unlike the Pulsar sibling submission (which ships a
 > mechanized EasyCrypt + Lean + Jasmin refinement chain against
 > FIPS 204), Corona ships NO machine-checked refinement at this
-> submission — R-LWE has no NIST standard target, the construction
+> submission — Module-LWE has no NIST standard target, the construction
 > IS the spec, and mechanizing the construction itself is a multi-
 > month research roadmap item. Corona's correctness evidence
 > reduces to code review of the Go reference against the published
@@ -4,19 +4,20 @@
 See [LP-105 §Claims and evidence](https://github.com/luxfi/lps/blob/main/LP-105-lux-stack-lexicon.md#claims-and-evidence) for the canonical claims/evidence table and the ten architectural commitments — single source of truth.
-**Corona** is the Lux **Ring-LWE** post-quantum threshold signature library
+**Corona** is the Lux **Module-LWE** post-quantum threshold signature library
 for **Quasar consensus**. The 2-round threshold construction line traces back
-to the Boschini–Kaviani–Lai–Malavolta–Takahashi–Tibouchi R-LWE paper
+to the Boschini–Kaviani–Lai–Malavolta–Takahashi–Tibouchi Module-LWE paper
 ([ePrint 2024/1113](https://eprint.iacr.org/2024/1113)). Corona adds the
 production lifecycle that line lacked: Pedersen DKG over `R_q` with proper
 hiding, proactive resharing for epoch validator rotation, identifiable
 abort, and the integration surface Quasar consumes.
-The **Module-LWE sibling library** lives at [`luxfi/pulsar`](https://github.com/luxfi/pulsar).
+The **ML-DSA sibling library** lives at [`luxfi/pulsar`](https://github.com/luxfi/pulsar).
-Pulsar's threshold signature output is byte-equal to FIPS 204 single-party
+Pulsar is also Module-LWE, but a different construction: its threshold
-ML-DSA (NIST MPTC Class N1). The two libraries are independent — there is
+signature output is byte-equal to FIPS 204 single-party ML-DSA (NIST MPTC
-no import line between them — and Quasar consumes them as parallel kernels
+Class N1). The two libraries are independent — there is no import line
-selected per-chain via `FinalitySchemeID`.
+between them — and Quasar consumes them as parallel kernels selected
 per-chain via `FinalitySchemeID`.
 ## Why "Corona"
@@ -33,7 +34,7 @@ research artefact — trusted-dealer DKG, no proactive resharing, no
 integration surface. Corona is the production track that fills those
 gaps:
-| Layer | Original R-LWE construction | Corona |
+| Layer | Original Module-LWE construction | Corona |
 |---|---|---|
 | 2-round threshold sign | ✅ same byte-equal protocol | ✅ inherited |
 | Trusted-dealer Gen | ✅ for fixed federation | ✅ tests / KAT / CLI / permissioned bridge MPC only — never the chain keygen path |
@@ -43,15 +44,18 @@ gaps:
 ## Composition with Pulsar as optional layered PQ defense
-Corona is independently usable: a chain can pick Ring-LWE Corona as its
+Corona is independently usable: a chain can pick Corona as its
 sole PQ threshold layer, no cross-dependency on Pulsar. Lux primary-
-network QuasarCert combines both lattice families as a **Double Lattice**
+network QuasarCert combines both Module-LWE schemes as a **Double Lattice**
-layered defence so a break in one family does not break finality:
+layered defence so a break in one *construction or implementation* does not
 break finality. (Both legs are Module-LWE, so this is construction- and
 implementation-diversity, not lattice-family diversity — a break of the
 shared Module-LWE problem would affect both legs):
 ```
 QuasarCert {
    BLS         — optional classical fast-path (BLS-12-381 aggregate)
-    Corona      — Ring-LWE   threshold ML-DSA (this repo)
+    Corona      — Module-LWE threshold (Raccoon/Ringtail line; this repo)
    Pulsar      — Module-LWE threshold ML-DSA (luxfi/pulsar)
    MLDSARollup — per-validator ML-DSA-65 rolled up via STARK/FRI (P3Q)
 }
@@ -84,7 +88,7 @@ Pulsar's key generation provably stuck at a trusted dealer.
 ## Status
 Production. The 2-round Sign+Verify path is byte-equal-validated against
-the original R-LWE construction (ePrint 2024/1113) via 16 SHA-256 KATs.
+the original Module-LWE construction (ePrint 2024/1113) via 16 SHA-256 KATs.
 The dealerless **Pedersen DKG** (`dkg2/`, entered through
 `keyera.Bootstrap` / `BootstrapPedersen`) is the **production keygen
 default since v0.7.5**: it opens a new key era without a trusted dealer,
@@ -96,7 +100,7 @@ alongside it; the trusted-dealer keygen helpers remain only as
 tests / KAT / CLI footguns (and permissioned bridge MPC), never the
 chain keygen path.
-Corona remains the Ringtail/Raccoon-derived R-LWE leg (Boschini et al.,
+Corona remains the Ringtail/Raccoon-derived Module-LWE leg (Boschini et al.,
 ePrint 2024/1113) with its own parameter set: it is **not** FIPS-204
-byte-equal, and its certificates are variable-size R-LWE certificates,
+byte-equal, and its certificates are variable-size Module-LWE certificates,
 larger than Pulsar's FIPS-204-equal output.
@@ -10,7 +10,7 @@ fix lands and downstream consumers have had a 14-day private window.
 ## What is in-scope
 Corona is **production-hardened reference implementation** for
-Ring-LWE threshold signing in Quasar consensus, and a NIST MPTC
+Module-LWE threshold signing in Quasar consensus, and a NIST MPTC
 submission package. The following are in-scope for responsible
 disclosure:
@@ -1,7 +1,7 @@
-# SPEC — Corona Threshold Ring-LWE Signature (v0.2)
+# SPEC — Corona Threshold Module-LWE Signature (v0.2)
 > **Standalone protocol specification** for **Corona** — a 2-round
-> threshold Ring-LWE signature scheme with Pedersen DKG over `R_q`
+> threshold Module-LWE signature scheme with Pedersen DKG over `R_q`
 > and proactive resharing.
 >
 > Companion to:
@@ -17,7 +17,7 @@
 ## §1 Scope
-This document specifies **Corona**, the Ring-LWE 2-round threshold
+This document specifies **Corona**, the Module-LWE 2-round threshold
 signature construction shipped at `github.com/luxfi/corona`. Corona
 implements the published construction of Boschini, Kaviani, Lai,
 Malavolta, Takahashi, and Tibouchi (IACR ePrint 2024/1113, IEEE S&P
@@ -27,10 +27,10 @@ proactive resharing, identifiable abort, activation certificates,
 KAT-deterministic Corona-SHA3 hash suite).
 This spec does NOT cover:
- The single-party FIPS 204 ML-DSA algorithm (different lattice
+- The single-party FIPS 204 ML-DSA algorithm (a different
-  family — see Pulsar at `~/work/lux/pulsar/`).
+  Module-LWE construction — see Pulsar at `~/work/lux/pulsar/`).
 - Verifier implementations beyond the Corona reference verifier
-  (`sign/sign.go:Verify`). No third-party R-LWE threshold verifier
+  (`sign/sign.go:Verify`). No third-party Module-LWE threshold verifier
  exists at submission time.
 - Pulsar (Module-LWE sibling) — see `https://github.com/luxfi/pulsar`.
 - Magnetar (Tier 3 SLH-DSA research profile) — see
@@ -63,7 +63,7 @@ This spec does NOT cover:
 The single-set submission is intentional: Corona ships a fixed
 parameter set tuned to provide ≥ 128 bits of post-quantum security
-against the best known R-LWE attacks (per the lattice-estimator
+against the best known Module-LWE attacks (per the lattice-estimator
 methodology of Albrecht-Player-Scott). A second parameter set
 targeting NIST PQ Category 3 is on the roadmap but is NOT in this
 submission package.
@@ -78,8 +78,9 @@ Per `DESIGN.md` §"Three layers, one shipping path". Summary:
 - Pedersen DKG (`dkg2/`) provides hiding and binding; legacy `dkg/`
  (Feldman VSS without blinding) is documented as broken for public
  broadcast and is retained for historical reference only.
- R-LWE hardness over the fixed parameter set (Lyubashevsky-Peikert-
+- Module-LWE hardness over the fixed parameter set (Langlois-Stehlé
-  Regev 2010 + follow-up analysis).
+  2015 module generalisation of Lyubashevsky-Peikert-Regev 2010 +
  follow-up analysis).
 - cSHAKE256 / KMAC256 / TupleHash256 collision/preimage resistance
  per FIPS 202 + SP 800-185.
@@ -181,7 +182,7 @@ The verifier:
 3. Verifies `c' == c` via constant-time `r.Equal` (lattigo).
 4. Checks low-norm bound on `z` (`primitives.CheckL2Norm`).
-No third-party FIPS-validated verifier exists for R-LWE threshold
+No third-party FIPS-validated verifier exists for Module-LWE threshold
 signatures at submission time. Corona's verifier is the spec.
 ## §9 Proactive resharing
@@ -22,7 +22,7 @@ auditable.
 **Maturity stamp**: v0.2 ready. This submission is **not**
 NIST-ratified, **not** FIPS 140-3 validated, **not** ACVP-validated,
-and explicitly **not anchored to a FIPS standard** (R-LWE threshold
+and explicitly **not anchored to a FIPS standard** (Module-LWE threshold
 signing has no NIST standard — the academic Boschini et al. paper is
 the construction spec). It is the algorithm-level reference plus
 production lifecycle additions plus reproducibility tooling.
@@ -33,10 +33,10 @@ production lifecycle additions plus reproducibility tooling.
 |---|---|
 | Submission name | **Corona** |
 | Submitting organisation | Lux Industries, Inc. |
-| Algorithm | Threshold Ring-LWE 2-round signing + DKG + proactive resharing |
+| Algorithm | Threshold Module-LWE 2-round signing + DKG + proactive resharing |
 | Target NIST MPTC classes | **N1** (threshold signing, single-party-output-compatible against the construction's own verifier) + **N4** (multi-party key generation with public-key preservation across resharing) |
 | Underlying construction | Boschini, Kaviani, Lai, Malavolta, Takahashi, Tibouchi. *Practical two-round threshold signatures from learning with errors.* IACR ePrint **2024/1113**, IEEE S&P 2025 |
-| Lattice family | Ring-LWE over `R_q = Z_q[X]/(X^N + 1)`, `N = 256`, `q = 0x1000000004A01` (48-bit NTT-friendly prime) |
+| Lattice family | Module-LWE over `R_q = Z_q[X]/(X^N + 1)`, `N = 256`, module dims `M = 8` × `N = 7`, `q = 0x1000000004A01` (48-bit NTT-friendly prime) |
 | Round count | 2 rounds per signature |
 | Signature output | Byte-compatible with the construction's own verifier (`sign.Verify`); **NOT byte-equal to FIPS 204 ML-DSA** — that property belongs to the M-LWE sibling [`luxfi/pulsar`](https://github.com/luxfi/pulsar) |
 | Hash suite | Corona-SHA3 (cSHAKE256 / KMAC256 / TupleHash256 per FIPS 202 + SP 800-185); legacy Corona-BLAKE3 retained for cross-port byte checks |
@@ -59,12 +59,12 @@ production lifecycle additions plus reproducibility tooling.
 > events within a key era (Class N4 invariant).
 This is a **construction-level interchangeability** claim, NOT a FIPS
-204 byte-equality claim. Corona uses Ring-LWE arithmetic that has no
+204 byte-equality claim. Corona uses Module-LWE arithmetic that has no
 NIST standard analogue at the time of submission; the Boschini et al.
 construction IS the spec.
 **Verifier-side story (load-bearing for N1 framing).** Because there
-is no NIST standard R-LWE threshold signature, the Class N1
+is no NIST standard Module-LWE threshold signature, the Class N1
 "output-interchangeability" axis is reduced to: any verifier that
 accepts a single-party run of the underlying Boschini et al.
 construction MUST accept a Corona threshold-aggregated signature on
@@ -75,7 +75,7 @@ in that respect. A reviewer evaluating the N1 claim should compare
 Corona's threshold-emitted bytes to the bytes a single-party run of
 the same parameter set would produce on the reconstructed secret —
 the comparison is via the same `Verify` routine, not via a third
-party FIPS-validated verifier (which does not exist for R-LWE
+party FIPS-validated verifier (which does not exist for Module-LWE
 threshold).
 ## Algorithm scope
@@ -169,7 +169,7 @@ tests, tars the entire submission checkout, and prints the SHA-256.
 The N1 claim is asserted at **three** levels of evidence (one fewer
 than Pulsar; the missing level is the machine-checked refinement
-chain, because R-LWE has no FIPS standard to refine against):
+chain, because Module-LWE threshold has no FIPS standard to refine against):
 | Evidence | Where |
 |---|---|
@@ -181,7 +181,7 @@ chain, because R-LWE has no FIPS standard to refine against):
 - No EasyCrypt refinement chain (Corona has no FIPS-standard target).
 - No Lean ↔ EC algebraic bridge files.
- No Jasmin high-assurance implementation (libjade does not cover Corona's R-LWE parameter set).
+- No Jasmin high-assurance implementation (libjade does not cover Corona's Module-LWE parameter set).
 - No machine-checked `Class N1 byte-equality` theorem.
 The honest framing for Corona is: **production-hardened
@@ -216,7 +216,7 @@ delta:
 | 5/5 Lean ↔ EC algebraic-bridge files | none | NOT PRESENT |
 | 3/3 jasmin-ct blocking on threshold layer | none | NOT PRESENT — libjade does not target this parameter set |
 | Class N1 byte-equality theorem (mechanized) | construction-level claim only | NOT MECHANIZED — Boschini et al. paper is the spec, no FIPS target |
-| `pq-crystals` / BoringSSL / OpenSSL cross-validation | none possible | NOT APPLICABLE — no third-party R-LWE threshold verifier exists |
+| `pq-crystals` / BoringSSL / OpenSSL cross-validation | none possible | NOT APPLICABLE — no third-party Module-LWE threshold verifier exists |
 What Corona DOES offer at submission-time:
@@ -238,7 +238,7 @@ What Corona DOES offer at submission-time:
 ## What this submission does NOT claim
 - **No byte-equality with FIPS 204 ML-DSA** — that is Pulsar's claim.
-  Corona is an independent R-LWE construction with no NIST standard
+  Corona is an independent Module-LWE construction with no NIST standard
  to verify against.
 - **No mechanized refinement proof** — no EasyCrypt, no Lean, no
  Jasmin. The construction is the published academic paper; the Go
@@ -249,7 +249,7 @@ What Corona DOES offer at submission-time:
  cryptographic modules, not this reference implementation. Downstream
  of this submission.
 - **No ACVP / CAVP algorithm validation certificate** — no NIST ACVP
-  test vector set exists for R-LWE threshold signatures.
+  test vector set exists for Module-LWE threshold signatures.
 - **No identifiable abort under network partition** — synchronous
  network assumption only; asynchronous identifiable abort is a
  separate problem.
@@ -267,17 +267,21 @@ What Corona DOES offer at submission-time:
 | Submission | Lattice | Round count | Output story | NIST class |
 |---|---|---|---|---|
-| **Corona** (this) | Ring-LWE (R-LWE) | 2 | Construction-level interchangeable with single-party Corona verifier; no NIST standard target | N1 + N4 |
+| **Corona** (this) | Module-LWE (Raccoon/Ringtail line) | 2 | Construction-level interchangeable with single-party Corona verifier; no NIST standard target | N1 + N4 |
 | **Pulsar** ([`luxfi/pulsar`](https://github.com/luxfi/pulsar)) | Module-LWE (M-LWE) | 2 | Byte-equal to FIPS 204 ML-DSA-65 | N1 + N4 |
 | Raccoon (NIST PQC) | Module-LWE | 3 | Compatible verification | not MPTC |
-| Boschini et al. (academic upstream) | R-LWE | 2 | Construction-level; trusted-dealer Gen only | not submitted as MPTC |
+| Boschini et al. (academic upstream) | Module-LWE | 2 | Construction-level; trusted-dealer Gen only | not submitted as MPTC |
-The R-LWE / M-LWE pair is intentional. Lux's primary-network
+The Corona / Pulsar pair is intentional. Both are Module-LWE, but they
-QuasarCert MAY combine Corona (R-LWE) and Pulsar (M-LWE) as a
+are distinct constructions (Corona is the Ringtail/Raccoon-line threshold;
-**Double Lattice** layered defence so a break in one lattice family
+Pulsar is FIPS-204 ML-DSA made threshold). Lux's primary-network
-does not break finality. That layered combination is the consumer's
+QuasarCert MAY combine them as a **Double Lattice** layered defence so a
-design choice and is not part of this submission. Corona stands
+break in one *construction or implementation* does not break finality.
-alone as an MPTC Class N1 + N4 candidate.
+Because both legs are Module-LWE, a break of the shared Module-LWE problem
 would affect both — the diversity is at the construction/implementation
 layer, not the lattice family. That layered combination is the consumer's
 design choice and is not part of this submission. Corona stands alone as
 an MPTC Class N1 + N4 candidate.
 ## Contact
@@ -180,14 +180,14 @@ incorporating Corona):
  modify the hash suite, the claim's transferable guarantees
  attenuate.
 - **For FIPS 140-3 module validation**, Corona is NOT a candidate
-  — R-LWE threshold has no NIST standard, so no FIPS 140-3 module
+  — Module-LWE threshold has no NIST standard, so no FIPS 140-3 module
  can claim FIPS 204-style algorithm validation for it. For
  FIPS-validation pathways, use Pulsar (M-LWE / FIPS 204) instead.
 - **For NIST MPTC review**, Corona's role is the algorithm-level
  reference + production lifecycle artifacts; module packaging +
  external audit are downstream.
 - **For threshold signing in a Quasar deployment**, Corona is the
-  R-LWE kernel; the consuming consensus layer is responsible for
+  Module-LWE kernel; the consuming consensus layer is responsible for
  the chain-of-custody and validator-rotation orchestration (the
  LSS adapter at `~/work/lux/threshold/protocols/lss/lss_pulsar.go`
  is the canonical orchestrator).
@@ -201,11 +201,11 @@ incorporating Corona):
 | Jasmin verified compiler | YES (threshold layer in Jasmin) | NO (pure Go) |
 | OCaml runtime | YES (EC is OCaml) | NO |
 | Go toolchain | YES (Go reference) | YES (Go reference; primary) |
-| lattigo / `luxfi/lattice/v7` | NO (Jasmin path) | YES (R-LWE primitives) |
+| lattigo / `luxfi/lattice/v7` | NO (Jasmin path) | YES (Module-LWE primitives) |
 | `crypto/subtle` | YES (Go reference path) | YES (primary CT helper) |
 | `golang.org/x/crypto/sha3` | YES | YES |
 | Academic construction paper | FIPS 204 (NIST standard) | Boschini et al. ePrint 2024/1113 (2024 academic) |
-| Third-party FIPS-validated verifier | YES (BoringSSL FIPS / AWS-LC / OpenSSL 3.0) | NO (none exists for R-LWE threshold) |
+| Third-party FIPS-validated verifier | YES (BoringSSL FIPS / AWS-LC / OpenSSL 3.0) | NO (none exists for Module-LWE threshold) |
 **Net effect**: Corona's TCB is smaller (fewer proof-tool
 dependencies) but the trust per-component is higher (no fall-back
@@ -23,7 +23,7 @@ func NewCmd() *cobra.Command {
 		Aliases: []string{"corona"},
 		Short:   "Corona threshold signing",
 		Long: `The rt (corona) command provides tools for Corona threshold signing,
-a post-quantum threshold signature scheme using Ring-LWE.
+a post-quantum threshold signature scheme using Module-LWE.
 Corona is part of the triple consensus (BLS + Corona + ML-DSA) used
 by Lux validators. It provides threshold signatures where t-of-n parties
@@ -1,24 +1,28 @@
 # Corona — Design Decisions
 > Rationale for the design choices behind Corona's production
-> lifecycle on top of the Boschini et al. ePrint 2024/1113 R-LWE
+> lifecycle on top of the Boschini et al. ePrint 2024/1113 Module-LWE
 > threshold construction.
-## §1 Why Ring-LWE (not Module-LWE)?
+## §1 Why two Module-LWE schemes (Corona threshold-Raccoon + Pulsar ML-DSA)?
 Both Corona and Pulsar are Module-LWE; they are distinct *constructions*,
 not distinct lattice families. Corona is the Ringtail/Raccoon-line 2-round
 threshold construction; Pulsar is FIPS-204 ML-DSA made threshold.
 | Question | Answer |
 |---|---|
-| Why ship an R-LWE library when ML-DSA (M-LWE) is the NIST standard? | The R-LWE 2-round construction (Boschini et al. 2024/1113) was published a year before the M-LWE equivalent matured. Lux deployed the R-LWE path first because it was the only construction with a published peer-reviewed 2-round threshold signature analysis for lattice-based signatures at the time of consensus design. |
+| Why ship Corona when ML-DSA (Pulsar) is the NIST standard? | Corona's 2-round *threshold* construction (Boschini et al. 2024/1113, the Ringtail/Raccoon line) was published with a peer-reviewed 2-round threshold analysis a year before the ML-DSA threshold path matured. Lux deployed it first because it was the only construction with a published peer-reviewed 2-round threshold signature analysis for lattice-based signatures at the time of consensus design. |
-| Why keep R-LWE after the M-LWE path (Pulsar) is ready? | Lux's primary-network QuasarCert is designed to consume BOTH lattice families as a **Double Lattice** layered defence so a break in one lattice family does not break finality. The two are complementary, not interchangeable. |
+| Why keep Corona after the ML-DSA path (Pulsar) is ready? | Lux's primary-network QuasarCert is designed to consume BOTH as a **Double Lattice** layered defence: two *independent constructions and codebases* (threshold-Raccoon vs ML-DSA) so that a construction- or implementation-specific flaw in one does not break finality. The two are complementary, not interchangeable. |
-| Why not converge on a single lattice family? | A break in Module-LWE (which Pulsar uses) would not automatically break Ring-LWE (which Corona uses), and vice versa. The cost is wire-size overhead (Corona certs are variable-size; Pulsar certs are fixed-size); the benefit is structural diversity. |
+| Does running both give lattice-family diversity? | No. Both legs are Module-LWE, so a break of the Module-LWE problem itself would affect both. The diversity is at the *construction and implementation* layer, not the hardness assumption. Hardness-assumption diversity in the stack comes from the (research-stage) hash-based Magnetar (SLH-DSA), not from Corona-vs-Pulsar. The cost of running both is wire-size overhead (Corona certs are variable-size; Pulsar certs are fixed-size); the benefit is construction and implementation diversity. |
 ## §2 Why this parameter set?
 | Parameter | Value | Rationale |
 |---|---|---|
-| Ring degree `N` | 256 | Standard choice for 128-bit post-quantum security per the lattice-estimator methodology; matches lattigo's default ring sizing for R-LWE. |
+| Ring degree `N` | 256 | Standard choice for 128-bit post-quantum security per the lattice-estimator methodology; matches lattigo's default ring sizing. |
 | Prime `q` | `0x1000000004A01` | 48-bit NTT-friendly prime. Wide enough to absorb the Lagrange-aggregation coefficient growth without overflow; narrow enough that single-`q` polynomial arithmetic fits in `uint64`. |
-| Module width `M` | 8 | Balances signature size against security margin under R-LWE attacks. |
+| Module width `M` | 8 | Balances signature size against security margin under Module-LWE attacks. |
 | Module height `N_M` | 7 | Matches `M` − 1 to give comfortable EUF-CMA reduction margin. |
 | Challenge weight `Kappa` | 23 | Ternary challenge weight per Boschini et al. parameter analysis. |
@@ -175,24 +175,26 @@ Corona v0.4.1 ships a single parameter set:
 ### §9.2 Concrete security claim
 Target: ≥ 128 bits of post-quantum security against the best known
-R-LWE attacks per the lattice-estimator methodology of
+Module-LWE attacks per the lattice-estimator methodology of
 Albrecht-Player-Scott.
 **Roadmap**: a worksheet with concrete lattice-estimator output for
 the parameter set is roadmap item v0.6.0. At submission scaffolding
 this revision, the concrete bounds are NOT included; the parameter
-set was chosen by Lux engineering against the academic R-LWE
+set was chosen by Lux engineering against the academic Module-LWE
 literature, but the documented worksheet is pending.
-### §9.3 R-LWE prior art
+### §9.3 Module-LWE prior art
 Underlying construction: Boschini, Kaviani, Lai, Malavolta, Takahashi,
 Tibouchi. *Practical two-round threshold signatures from learning
 with errors.* IACR ePrint 2024/1113, IEEE S&P 2025. EUF-CMA reduction
 in §3 of the paper. Corona inherits the analysis.
-R-LWE primitive: Lyubashevsky, Peikert, Regev. *On ideal lattices and
+Module-LWE primitive: Langlois, Stehlé. *Worst-case to average-case
-learning with errors over rings.* EUROCRYPT 2010.
+reductions for module lattices.* Designs, Codes and Cryptography 2015,
 building on the Ring-LWE primitive of Lyubashevsky, Peikert, Regev.
 *On ideal lattices and learning with errors over rings.* EUROCRYPT 2010.
 Concrete cryptanalysis literature: Albrecht, Player, Scott. *On the
 concrete hardness of learning with errors.* J. Math. Cryptol. 2015
@@ -206,8 +208,9 @@ IACR ePrint archive 2015–2026.
 - Concrete lattice-estimator output for the parameter set (roadmap
  v0.6.0).
 - Comparison benchmarks against single-party FIPS 204 ML-DSA — Corona
-  and ML-DSA are different lattice families; like-for-like comparison
+  and ML-DSA are different constructions (both Module-LWE, but a
-  is not meaningful.
+  threshold Raccoon-line scheme vs single-party Dilithium); like-for-
  like comparison is not meaningful.
 - Threshold-vs-single-party overhead measurements at specific (n, t)
  — these depend heavily on network conditions in production; the
  reference benchmark suite measures the local compute portion.
@@ -6,12 +6,13 @@
 ## §1 The three-library family
-Lux ships three post-quantum threshold signature libraries with
+Lux ships three post-quantum threshold signature libraries spanning
-distinct lattice families and use cases:
+two post-quantum families (Module-LWE lattice and hash-based) with
 distinct constructions and use cases:
-| Library | Lattice | Role | NIST MPTC class | Repository |
+| Library | Family / construction | Role | NIST MPTC class | Repository |
 |---|---|---|---|---|
-| **Corona** (this) | Ring-LWE (`R_q`) | Consensus-finality threshold (Quasar R-LWE finality kernel) | N1 + N4 (construction-level) | `luxfi/corona` |
+| **Corona** (this) | Module-LWE (`R_q^{8×7}`), Raccoon/Ringtail line | Consensus-finality threshold (Quasar Module-LWE finality kernel) | N1 + N4 (construction-level) | `luxfi/corona` |
 | **Pulsar** | Module-LWE (`R_q^k × R_q^l`) | Identity-layer threshold + FIPS 204 byte-equality | N1 + N4 (FIPS-anchored) | `luxfi/pulsar` |
 | **Magnetar** (research) | SLH-DSA (FIPS 205) | Hash-based fallback (research-stage) | not submitted at this writing | `luxfi/magnetar` |
@@ -23,9 +24,9 @@ layer (e.g., QuasarCert combines Corona + Pulsar + BLS).
 | Decomposition axis | Choice rationale |
 |---|---|
-| Per-lattice-family library | A break in one lattice family (R-LWE vs M-LWE vs hash-based) should not break the others. Independent libraries with no shared types is the safest decomposition for defence-in-depth. |
+| Per-construction library | A flaw in one library — whether a construction-specific cryptanalytic break or an implementation bug — should not break the others. Corona and Pulsar are both Module-LWE, so this isolates construction/implementation faults between them, not a break of Module-LWE itself; Magnetar's hash-based SLH-DSA additionally diversifies the hardness assumption. Independent libraries with no shared types is the safest decomposition for defence-in-depth. |
 | No shared types | Pulsar and Corona share NO Go types. If a vulnerability is found in Corona, the fix landing in Corona does not touch Pulsar (and vice versa). Each library's go.mod is independent. |
-| Separate KAT vectors | Pulsar's KATs target FIPS 204 byte-equality. Corona's KATs target Go ↔ C++ cross-runtime byte-equality. The two KAT formats are intentionally different (different lattice algebra; different signature byte layouts). |
+| Separate KAT vectors | Pulsar's KATs target FIPS 204 byte-equality. Corona's KATs target Go ↔ C++ cross-runtime byte-equality. The two KAT formats are intentionally different (different parameter sets and constructions; different signature byte layouts). |
 | Separate hash-suite registries | Pulsar uses SHAKE / cSHAKE / KMAC per FIPS 204 layouts. Corona uses cSHAKE256 / KMAC256 / TupleHash256 per FIPS 202 + SP 800-185 with `CORONA-*` customization strings. Even though the underlying primitives overlap, the domain-separation registries are disjoint. |
 ## §3 Composition surface — QuasarCert
@@ -36,10 +37,10 @@ Lattice** layered certificate:
 ```
 QuasarCert {
-    BLS         — classical fast-path (BLS-12-381 aggregate); pre-quantum
+    BLS         — classical fast-path (BLS-12-381 aggregate)       ; pre-quantum
-    Corona      — Ring-LWE   threshold (this repo)            ; PQ kernel A
+    Corona      — Module-LWE threshold, Raccoon line (this repo)   ; PQ kernel A
-    Pulsar      — Module-LWE threshold (luxfi/pulsar)         ; PQ kernel B
+    Pulsar      — Module-LWE threshold ML-DSA (luxfi/pulsar)       ; PQ kernel B
-    MLDSARollup — per-validator ML-DSA-65 rolled up via P3Q   ; PQ accountability
+    MLDSARollup — per-validator ML-DSA-65 rolled up via P3Q        ; PQ accountability
 }
 ```
@@ -107,15 +108,15 @@ Naming history (from `LLM.md` and `DESIGN.md`):
 - **Pulsar** — the M-LWE threshold ML-DSA library at `luxfi/pulsar`.
  Named for the rotating-neutron-star metaphor: persistent group
  key, rotating share distribution.
- **Corona** — the R-LWE threshold library (this repo). Named for
+- **Corona** — the Module-LWE threshold library (this repo). Named
-  the luminous ring of light surrounding a star, brand-paired with
+  for the luminous ring of light surrounding a star, brand-paired
-  Pulsar at a different lattice layer.
+  with Pulsar at a different layer.
 A historical rename from `Pulsar` → `Corona` happened in 2026 when
-the M-LWE work picked up the `Pulsar` name and the R-LWE work
+the ML-DSA work picked up the `Pulsar` name and the Ringtail/Raccoon-line
-retained the pulsar metaphor under the `Corona` brand. The
+work retained the pulsar metaphor under the `Corona` brand. The
 `papers/lp-073-pulsar/` directory retains the old name; the LaTeX
-sections inside refer to the R-LWE construction (now called Corona)
+sections inside refer to the Module-LWE construction (now called Corona)
 under the historical paper name LP-073.
 ## §7 Two distinct primitives, one lifecycle
@@ -159,7 +160,7 @@ What is preserved across Reanchor:
 ## §9 Relationship to the upstream academic construction
 Boschini, Kaviani, Lai, Malavolta, Takahashi, Tibouchi (IACR ePrint
-2024/1113, IEEE S&P 2025) published the 2-round R-LWE threshold
+2024/1113, IEEE S&P 2025) published the 2-round Module-LWE threshold
 signature construction. The paper specifies:
 - The 2-round signing protocol (Round 1 commit + Round 2 response +
  Combine).
@@ -1,11 +1,11 @@
-# IETF Internet-Draft Skeleton — Corona Threshold Ring-LWE Signature
+# IETF Internet-Draft Skeleton — Corona Threshold Module-LWE Signature
 > **HONEST FRAMING**: this document is a **draft skeleton**, not a
 > submitted Internet-Draft. The CFRG submission timing is contingent
 > on the v0.7.0 mechanized refinement work and the v0.8.0 external
 > audit landing. At submission scaffolding this revision, the
 > skeleton enumerates the sections an eventual `draft-luxfi-cfrg-
-> corona-threshold-rlwe-XX.txt` would carry; it does NOT claim CFRG
+> corona-threshold-mlwe-XX.txt` would carry; it does NOT claim CFRG
 > adoption, working-group status, or any timeline.
 >
 > The canonical algorithmic spec at this submission revision is
@@ -21,14 +21,14 @@ Internet-Draft                                       Lux Industries, Inc.
 Intended status: Informational                                 [draft-XX]
 Expires: [TBD]                                                 [date-XX]
-       Corona: a 2-round threshold Ring-LWE signature scheme
+       Corona: a 2-round threshold Module-LWE signature scheme
                 with proactive resharing
-              draft-luxfi-cfrg-corona-threshold-rlwe-XX
+              draft-luxfi-cfrg-corona-threshold-mlwe-XX
 Abstract
   This document specifies Corona, a 2-round threshold signature
-   scheme over Ring-LWE for use in post-quantum threshold signing
+   scheme over Module-LWE for use in post-quantum threshold signing
   deployments. Corona implements the construction of Boschini,
   Kaviani, Lai, Malavolta, Takahashi, and Tibouchi (IACR ePrint
   2024/1113, IEEE S&P 2025) on a fixed parameter set, plus
@@ -41,8 +41,9 @@ Abstract
 - §1.1 Motivation — threshold PQ signatures for blockchain finality
  (Quasar consensus reference).
- §1.2 Relationship to FIPS 204 ML-DSA — Corona is R-LWE; ML-DSA is
+- §1.2 Relationship to FIPS 204 ML-DSA — Corona and ML-DSA are both
-  M-LWE; the two are independent. The M-LWE sibling is Pulsar
+  Module-LWE but distinct constructions (Corona is the Raccoon/Ringtail
  line); the two are independent. The ML-DSA sibling is Pulsar
  (`luxfi/pulsar`).
 - §1.3 Document scope — algorithm specification + reference
  parameter set; deployment specifics (HSM, validator orchestration)
@@ -157,7 +158,7 @@ See `SPEC.md` §13 + `hash/sp800_185.go`.
 ## §13 Security considerations
- §13.1 R-LWE hardness assumption.
+- §13.1 Module-LWE hardness assumption.
 - §13.2 EUF-CMA reduction — inherited from Boschini et al. ePrint
  2024/1113 §3.
 - §13.3 Constant-time guarantees on threshold + dkg2 paths.
@@ -212,7 +213,7 @@ revisions may request:
  Dynamic and Resilient Threshold Signatures.* August 2025.
 - [FIPS204] NIST. *Module-Lattice-Based Digital Signature Standard
  (ML-DSA).* August 2024. (For context — Pulsar (M-LWE) targets
-  byte-equality with FIPS 204; Corona (R-LWE) does NOT.)
+  byte-equality with FIPS 204; Corona (Module-LWE) does NOT.)
 ## Appendix A — Test vectors
@@ -20,16 +20,16 @@ NIST MPTC subdivides threshold schemes into:
  - **N4**: ML keygen / DKG (Module-Lattice key generation, distributed)
 Corona aims for **N1 (construction-level threshold signing) + N4
-(distributed Ring-LWE keygen + reshare preservation)**.
+(distributed Module-LWE keygen + reshare preservation)**.
 ### N1 framing for Corona — HONEST distinction from Pulsar
 NIST's Class N is defined relative to a "NIST-specified primitive."
-**R-LWE threshold signing has no NIST standard at submission time.**
+**Module-LWE threshold signing has no NIST standard at submission time.**
 This makes Corona's N1 framing structurally different from Pulsar's
 (which targets FIPS 204 ML-DSA byte-equality):
-| Aspect | Pulsar (M-LWE) | Corona (R-LWE) |
+| Aspect | Pulsar (ML-DSA) | Corona (Module-LWE, Raccoon line) |
 |---|---|---|
 | NIST standard target | FIPS 204 ML-DSA-65 | **none** |
 | Verifier-side interchange | byte-equal with BoringSSL FIPS / AWS-LC / OpenSSL 3.0 PQ | construction-level only (Corona's own `sign.Verify`) |
@@ -59,7 +59,7 @@ Corona's submission package is structured to support **either reading**:
  injection) as the "novel threshold-friendly design" novelty.
 The downstream consumer story is identical either way: Quasar
-consensus uses Corona as the R-LWE finality kernel; threshold-emitted
+consensus uses Corona as the Module-LWE finality kernel; threshold-emitted
 signatures verify under `sign.Verify` regardless of whether NIST
 ultimately classifies the submission N or S.
@@ -123,7 +123,7 @@ bits of post-quantum security per lattice-estimator methodology.
 A second parameter set targeting NIST PQ Category 3 is roadmap
 v0.6.0. Concrete lattice-estimator output for the current parameter
 set is roadmap v0.6.0 — at submission scaffolding the security claim
-is qualitative (per Lux engineering's design choice against the R-LWE
+is qualitative (per Lux engineering's design choice against the Module-LWE
 literature) rather than quantitative.
 ## Class N vs Class S decision (deferred to NIST)
@@ -149,10 +149,11 @@ byte-equal to FIPS 204 ML-DSA-65 verified by unmodified BoringSSL
 FIPS / AWS-LC / OpenSSL 3.0 PQ. Pulsar's submission is at
 <https://github.com/luxfi/pulsar>.
-The R-LWE / M-LWE pair is intentional: Lux's primary-network
+The Corona / Pulsar pair is intentional: both are Module-LWE but
-QuasarCert may combine Corona + Pulsar as a **Double Lattice**
+distinct constructions, so Lux's primary-network QuasarCert may combine
-layered defence (separate consumer-side design choice; not part of
+them as a **Double Lattice** layered defence — construction- and
-this submission).
+implementation-diversity, not lattice-family diversity (separate
 consumer-side design choice; not part of this submission).
 ## Status
@@ -17,7 +17,7 @@
 +--------------------------------------------------------------+
 | share storage / signing: sealed share -> Round1/Round2/Final  |  crypto
 +--------------------------------------------------------------+
-| Corona kernel: 2-round R-LWE signing                          |  math
+| Corona kernel: 2-round Module-LWE signing                     |  math
 +--------------------------------------------------------------+
 ```
@@ -287,7 +287,7 @@ unwrapped `KeyShare` struct.
 **Status**: NOT recommended. Intel SGX has a long published CVE
 record of micro-architectural side-channel attacks (Foreshadow,
-ZombieLoad, LVI, ÆPIC Leak). Corona's R-LWE arithmetic spends
+ZombieLoad, LVI, ÆPIC Leak). Corona's Module-LWE arithmetic spends
 significant time on `lattigo`'s NTT and Gaussian sampling — both
 data-dependent paths that have been demonstrated vulnerable to
 side-channel extraction on SGX in the published literature.
@@ -31,7 +31,7 @@ adversary** with the following capabilities:
 | Eavesdropping on all broadcast messages | YES |
 | Active modification of broadcast messages | YES (Byzantine adversary; messages are signed and complaints expose tampering) |
 | Asynchronous corruption / late corruption mid-session | OUT OF SCOPE |
-| Quantum computer | YES — the construction is post-quantum (R-LWE) |
+| Quantum computer | YES — the construction is post-quantum (Module-LWE) |
 | Side-channel observation | OUT OF SCOPE for the math; addressed at the implementation layer via `CONSTANT-TIME-REVIEW.md` and `DEPLOYMENT-RUNBOOK.md` hardening checklist |
 ### §2.2 Adversary cannot
@@ -84,8 +84,8 @@ protocol transcript with high probability.
 | Assumption | Where used |
 |---|---|
-| Ring-LWE hardness over `R_q = Z_q[X]/(X^N + 1)` with `N = 256`, `q = 0x1000000004A01` | Inherits EUF-CMA reduction from Boschini et al. ePrint 2024/1113. |
+| Module-LWE hardness over `R_q = Z_q[X]/(X^N + 1)` with `N = 256`, module dims `M = 8` × `N = 7`, `q = 0x1000000004A01` | Inherits EUF-CMA reduction from Boschini et al. ePrint 2024/1113. |
-| Ring-SIS hardness (informally; the construction's reduction passes through SIS in the random oracle model) | Same paper. |
+| Module-SIS hardness (informally; the construction's reduction passes through SIS in the random oracle model) | Same paper. |
 | cSHAKE256 / KMAC256 / TupleHash256 collision and preimage resistance | All transcript hashes, MAC derivation, PRF derivation. |
 | Random oracle model | The EUF-CMA reduction in Boschini et al. relies on ROM. |
@@ -98,7 +98,7 @@ protocol transcript with high probability.
 ### §4.3 What this DOES NOT cover
- Lattice-cryptanalysis breakthroughs that reduce R-LWE security
+- Lattice-cryptanalysis breakthroughs that reduce Module-LWE security
  parameters below current estimates.
 - Quantum-cryptanalytic breakthroughs against the random oracle
  model.
@@ -199,7 +199,7 @@ historical reference and reading existing test fixtures.
 ### §8.1 What the chain trusts
 - The Bootstrap MPC ceremony at chain genesis (one-time).
- The R-LWE construction's correctness (per Boschini et al.
+- The Module-LWE construction's correctness (per Boschini et al.
  paper).
 - The Go reference implementation's correctness (per code review +
  KAT + fuzz).
@@ -1,7 +1,7 @@
 // Copyright (C) 2025-2026, Lux Industries Inc. All rights reserved.
 // See the file LICENSE for licensing terms.
-// Package gpu wires Corona (R-LWE threshold signing) into the lattice
+// Package gpu wires Corona (Module-LWE threshold signing) into the lattice
 // library's per-SubRing GPU NTT dispatcher.
 //
 // Decomplecting note. Corona never speaks CGO directly. The lattice
@@ -1,6 +1,6 @@
 # Corona Jasmin sources
-Constant-time threshold layer + centralized R-LWE Sign reference,
+Constant-time threshold layer + centralized Module-LWE Sign reference,
 written in Jasmin (https://github.com/jasmin-lang/jasmin) for
 jasmin-ct verification + EasyCrypt extraction.
@@ -10,7 +10,7 @@ jasmin-ct verification + EasyCrypt extraction.
 jasmin/
  lib/                  -- Shared primitives (corona_params, seed,
                           transcript, mac, lagrange).
-  rlwe/                 -- Centralized R-LWE Sign (single-party).
+  rlwe/                 -- Centralized Module-LWE Sign (single-party).
  threshold/            -- Threshold round1.jazz, round2.jazz,
                           combine.jazz.
 ```
@@ -1,4 +1,9 @@
-// Corona centralized R-LWE Sign reference (single-party).
+// Corona centralized Module-LWE Sign reference (single-party).
 //
 // NAMING NOTE: the jasmin/rlwe/ directory name is a retained build-path
 // identifier (referenced by scripts/checks/extraction.sh and jasmin.sh);
 // the scheme is Module-LWE (threshold-Raccoon/Ringtail). The path is kept
 // as-is so the high-assurance scripts keep resolving it.
 //
 // Mirrors the centralized signer for the Boschini construction (single
 // party holds the full secret). This is the dispatch target the
@@ -1,3 +1,7 @@
 (* NAMING NOTE: 'RLWE' / 'rlwe_*' identifiers and the RLWE_Functional    *)
 (* theory are the retained proof names for the single-party reference    *)
 (* signer; the scheme is Module-LWE (threshold-Raccoon/Ringtail; module  *)
 (* dims M=8, N=7 over Z_q[X]/(X^256+1)). Identifiers are not renamed.    *)
 (* -------------------------------------------------------------------- *)
 (* Corona -- Class N1 byte-equality reduction                           *)
 (* -------------------------------------------------------------------- *)
@@ -1,3 +1,7 @@
 (* NAMING NOTE: 'RLWE' / 'rlwe_*' identifiers (e.g.                      *)
 (* combine_abs_op_lifted_eq_rlwe, rlwe_sign_op) are the retained proof   *)
 (* names for the single-party reference signer; the scheme is           *)
 (* Module-LWE (threshold-Raccoon/Ringtail; M=8, N=7, X^256+1).          *)
 (* -------------------------------------------------------------------- *)
 (* Corona -- Combine wrapper bridge                                     *)
 (* -------------------------------------------------------------------- *)
@@ -1,3 +1,6 @@
 (* NAMING NOTE: 'RLWE' / 'rlwe_*' identifiers here are the retained      *)
 (* proof names for the single-party reference signer; the scheme is      *)
 (* Module-LWE (threshold-Raccoon/Ringtail; M=8, N=7 over Z_q[X]/X^256+1).*)
 (* -------------------------------------------------------------------- *)
 (* Corona -- Class N1 NO-LEAK telescoping-mask model                    *)
 (* -------------------------------------------------------------------- *)
@@ -131,7 +134,7 @@ type public_transcript_t.     (* per-party commitments, rounded h, z-sum, c *)
 type rlwe_leakage_t.          (* one single-party Boschini sig's public footprint *)
 op module_lwe_hard : bool.    (* Gaussian-masked commitments pseudorandom *)
-op module_sis_hard : bool.    (* extracting short s from the z-sum is R-SIS *)
+op module_sis_hard : bool.    (* extracting short s from the z-sum is Module-SIS *)
 op transcript_simulator : rlwe_leakage_t -> public_transcript_t.
 (* NO-LEAK REDUCTION (C / OPEN, but now a STANDARD-ASSUMPTION reduction).
@@ -1,3 +1,7 @@
 (* NAMING NOTE: 'RLWE' / 'rlwe_*' identifiers (e.g. RLWESign,            *)
 (* sign_abs_op_lifted_eq_rlwe) are the retained proof names for the      *)
 (* single-party reference signer; the scheme is Module-LWE              *)
 (* (threshold-Raccoon/Ringtail; M=8, N=7, X^256+1). Not renamed.        *)
 (* -------------------------------------------------------------------- *)
 (* Corona -- centralized Sign wrapper bridge                            *)
 (* -------------------------------------------------------------------- *)
@@ -4,6 +4,13 @@ This directory holds the EasyCrypt mechanization of the Class N1
 (byte-equality) and Class N4 (reshare public-key preservation)
 correctness claims for Corona, mirroring `~/work/lux/pulsar/proofs/easycrypt/`.
 > **Naming note.** Identifiers and file names containing `RLWE` / `rlwe`
 > here (e.g. the `RLWESign` module type, `rlwe_sign_op`, and
 > `lemmas/RLWE_Functional.ec`) are retained proof identifiers for the
 > single-party reference signer the threshold protocol refines against;
 > Corona is a **Module-LWE** scheme (threshold-Raccoon/Ringtail; module
 > dims M=8, N=7 over `Z_q[X]/(X^256+1)`).
 ## File map
 | File | Contains |
@@ -1,3 +1,7 @@
 (* NAMING NOTE: 'RLWE' / 'rlwe_*' identifiers and the RLWE_Functional    *)
 (* theory are the retained proof names for the single-party reference    *)
 (* signer; the scheme is Module-LWE (threshold-Raccoon/Ringtail; module  *)
 (* dims M=8, N=7 over Z_q[X]/(X^256+1)). Identifiers are not renamed.    *)
 (* -------------------------------------------------------------------- *)
 (* RLWE_Functional -- in-house EC mechanization of the Boschini et al.  *)
 (* (ePrint 2024/1113) R-LWE single-party signature operator             *)
@@ -4,7 +4,7 @@
 package threshold
 // verify_batch.go -- parallel CPU batch verifier for Corona
-// (Ring-LWE 2-round threshold) signatures.
+// (Module-LWE 2-round threshold) signatures.
 //
 // Corona signatures are NOT FIPS 204 byte-equal (that's Pulsar's
 // Module-LWE sibling); the wire encoding is the (C, Z, Delta) ring