Lux Consensus

Lux runs the Quasar consensus stack, which cleanly separates two concerns: a leaderless metastable sampler decides, and a post-quantum compact certificate attests. The decider is Nova (linear chains) / Nebula (DAG): Photon → Wave → Focus sampling accrues β-confidence on one block per height and calls VM.Accept — acceptance is finality, leaderless, and depends on no certificate. A typed compact-certificate envelope (the ConsensusCert) then binds one or more cryptographic evidence legs to the canonical finality message as a post-accept attestation for external verifiers (bridges, the 0x9999 DEX settlement receipt): it authorizes export, never gates chain progress, and a break of any single primitive does not break it. This decide-then-attest separation — not a certificate-as-finality-trigger — is the canonical model of record; the normative spec is LP-305 (Nova · Quasar · Block-STM), with the cross-system comparison in LP-306.

Implementation: github.com/luxfi/consensus protocol/quasar/ (released v1.26.0).

Quasar Sub-Protocols

Each component owns one concern. They compose into two engine modes (linear chains and DAG chains).

Round flow

Linear (Nova): Photon → Wave → Focus → Ray → Sink

DAG (Nebula): Photon → Wave (per frontier vertex) → Flare → Horizon (safe prefix) → Field → Committer

Finality: the Compact-Certificate Envelope

Export finality is a ConsensusCert — a policy-gated aggregate quorum certificate. (Local finality is Nova's VM.Accept at β-confidence, above; the certificate trails it and authorizes export — bridges, cross-chain, the 0x9999 DEX receipt — per LP-305's two-tier accept/export separation. It never gates acceptance or chain progress.) Policy declares which cryptographic legs are required; certificate bytes carry per-leg evidence; every leg proves the same weighted-quorum predicate over the same domain-separated finality message M.

The signed message M binds the full consensus tuple — chain id, epoch, height, round, block hash, validator-set root, policy id, required-legs root, signer root, cert profile — never the block hash alone. Required legs come from policy only, never from the certificate's own bytes; the cert's required-legs root is recomputed from policy and any mismatch is a hard reject.

Four evidence kinds

The chain stores one compact typed evidence per lane, never N raw per-validator signatures.

Beam, Pulsar, and Corona are O(1) in committee size — one signature each. P3Q is the only O(N)-class object and is a fallback, never the normal finality object when a compact Pulsar leg is available.

Two orthogonal axes (decomplected)

A leg's kind (what requirement it satisfies) and its mode (how that requirement is proven) are orthogonal and never braided:

Pulsar and P3Q satisfy the same leg kind (the Module-LWE ML-DSA PQ-finality requirement) by different mechanisms — that is exactly the policy "OR": one required leg kind, two permitted modes.

KeyEra — one group key per era

A threshold leg for a 1000-validator committee is one signature under one group public key, not 1000 per-validator signatures. A KeyEra is the registry record that pins that single group key to one validator-set era: which chain, which P-Chain-pinned signer set, which key-era id + generation, which scheme/parameter set.

KeyEra is a value qualified by its scheme, not a place: one type and one boring verifier (VerifyThresholdLeg) serve every threshold lane — Pulsar (FIPS-204 ML-DSA group signature) and Corona (Ringtail). The chain does not care how the group signature was produced (TALUS MPC, an HSM ceremony, a TEE, or P3Q fallback); that is recorded in the era's KeygenMode for audit and is orthogonal to verification. The verifier stays in its lane: group sig, group key, M.

Compactness

ML-DSA-65 signatures are ~3.3 KB each. A naive per-validator certificate is 48 + N × 3309 bytes — linear in validator count. The compact threshold leg replaces the N × 3309 term with a single group signature, so the certificate for 1000 validators is the same size as for 4 — roughly three orders of magnitude smaller at 1000 validators.

naive O(N) cert  @ N=1000:  48 + 1000 × 3309  ≈ 3.3 MB
compact O(1) cert:          one ML-DSA-65 group sig (~3.3 KB) + envelope header

Finality Postures (Policy Table)

The operator selects a finality posture per chain. Each posture is a concrete policy the envelope verifies under; the required leg kinds are committed into the cert's required-legs root, and the permitted modes live in the policy's allow-table.

In STRICT_QUASAR, Beam, Pulsar, and Corona all sign one canonical message M under one P-Chain-pinned era (AND-mode). A classical-only certificate is rejected under any posture that requires a PQ leg; classical evidence can satisfy only the classical leg and can never stand in for a required PQ leg.

Properties

Liveness. The round driver makes progress whenever a 2f+1 fraction of the network is reachable. No single leader.

Safety. Holds whenever fewer than f Byzantine validators participate (committee size 3f+1). Every required leg signs the same domain-separated M, so an adversary that breaks one primitive still has to defeat the others.

PQ safety. Under STRICT_QUASAR, forging a certificate requires breaking both Module-LWE (Pulsar / ML-DSA) and Ring-LWE (Corona) simultaneously, in addition to BLS — two independent lattice families plus the classical leg.

Scalability. Threshold legs are O(1) in committee size; the certificate does not grow with the validator set. Quasar scales to thousands of validators without degrading finality or cert size.

Chain assignments

Further reading

• Post-Quantum Security — Pulsar (TALUS) and Corona (Ringtail) in depth
• Lux Quasar reference — the cert envelope, suites, and verifier
• Threshold VM — M-Chain MPC and F-Chain FHE
• github.com/luxfi/consensus — the implementation
• Run a validator