Lux Quasar

Overview

Quasar is the post-quantum finality layer at the center of every Lux chain. A finalized round is sealed by a ConsensusCert — a policy-gated aggregate quorum certificate. Policy declares which cryptographic legs are required; certificate bytes carry the per-leg evidence; every leg proves the same weighted-quorum predicate over the same domain-separated finality message.

• Implementation: luxfi/consensus protocol/quasar/ (released v1.26.0)
• Threshold kernels: luxfi/pulsar v1.2.0 (Module-LWE) · luxfi/corona v0.8.0 (Ring-LWE)

Four evidence kinds

The chain stores one compact typed evidence per lane, never N raw per-validator signatures. These four names are the value-level vocabulary; the suite registry maps each concrete suite to its orthogonal axes.

Beam, Pulsar, and Corona are O(1) in committee size. P3Q compresses a set of independent per-validator ML-DSA certs (the MLDSACertSet) — the always- available audit/challenge object, never the primary finality object when a compact Pulsar leg is live.

Two orthogonal axes

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

Pulsar and P3Q satisfy the same leg kind by different mechanisms — the policy "OR" (Beam ∧ (Pulsar OR P3Q)) is expressed at the mode level on a single required leg kind, never as an alternative leg.

Suite registry

A suite id is a wire-stable string naming one concrete, parameterised scheme. The registry is the single authority mapping a suite id to its (EvidenceKind, LegKind, EvidenceMode, param-set) — verifiers resolve suites only through it, so no suite string can dispatch to the wrong verifier and an unknown suite is a hard reject.

KeyEra — one group key per era

A threshold leg for a 1000-validator committee is one signature under one group public key. A KeyEra pins that single group key to one validator-set era:

type KeyEra struct {
    ChainID      uint32   // matches ConsensusCert.ChainID
    SignerSetID  [48]byte // P-Chain-pinned validator-set identity
    KeyEraID     uint64   // advances on signer-set rotation
    Generation   uint64   // advances on within-era key refresh / reshare
    PChainHeight uint64   // height the signer set was pinned at
    GroupPubKey  []byte   // the compact threshold GROUP key (scheme-interpreted)
    SchemeID     string   // e.g. "Lux-Pulsar-TALUS-MLDSA65" | "Lux-Corona-Ringtail-L3-v1"
    KeygenMode   string   // AUDIT only: "talus-mpc" | "ceremony" | "tee" | "p3q-rollup-fallback"
    // ...
}

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 sig, via pulsarwire.VerifyBytes) and Corona (Ringtail, via coronaThreshold.Verify). The chain does not care how the group key was produced; KeygenMode records that for audit and is orthogonal to verification.

The four postures (policy table)

The operator selects a finality posture per chain. The required leg kinds are committed into the cert's required-legs root; the permitted modes live in the policy's allow-table.

HYBRID_PQ_CHECKPOINT and RECOVERY_MODE share the same required leg kinds (hence the same required-legs root); they are distinguished by their evidence- policy id (bound into the message) and their allow-table — the requirement commits the kinds, the policy id + allow-table commit the modes.

Verifier invariants

The ConsensusCert verifier (VerifyConsensusCert) enforces, among others:

• Required legs come from policy only. The cert's required-legs root is recomputed from policy and checked; the cert may not assert its own required set.
• The signed message 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; cross-domain replay is closed.
• Every required leg must appear exactly once; a missing leg is a hard reject.
• Classical evidence can satisfy only a classical leg — never a required PQ leg; a classical-only cert is rejected under any posture requiring a PQ leg.
• SLH-DSA is never threshold-signed in production (a Magnetar threshold-sig leg is a hard reject).
• Threshold legs require signer accountability (signer root, aggregate weight, policy, session binding) or are rejected.
• Malformed bytes yield a typed error, never a panic and never unbounded work.

Compactness

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

Cross-references

• Consensus — the engine and sub-protocols
• Post-Quantum — Pulsar (TALUS) and Corona (Ringtail) in depth
• luxfi/consensus protocol/quasar/
• LPs — the governing Lux Proposals