LP-121: Lux Blockchain Go-Live Standard — Chains, VMs, Precompiles, Finality

Implementation status (code-audited 2026-07-03): PARTIAL Chain registry (node/genesis/builder/registry.go) and VerifyWeighted (engine/chain/quasar.go) confirmed; quorum-cert path is protocol/quasar/quorum_cert.go; no launch-gating tooling exists in code (process doc).

Status

Draft. No backwards compatibility. The pre-Quasar Edition Lux network (2020–2025) is a separate network out of scope. Every claim here is verified against shipping code; where an LP, doc, or memory note disagreed with code, code won and the disagreement was reconciled.

Normative topology + fee model: LP-0130. LP-0130 is the topology/fee spec this LP's §1 chain-letter map and §"Topology authority" section should be read against; where LP-134 fixed the 9-role taxonomy, LP-0130 adds the fee-rail rule (X = money rail, P = staking rail, LUX = fee currency, non-P/X chains fund fee balances from X) and the UTXO ownership rule (only P and X are canonical UTXO state machines).

Abstract

This LP is the one place an engineer or agent reads to know what the Lux primary network launches: which chains exist, which VM runs each, where every native precompile lives, how finality is computed, and the one boundary every VM obeys. It does not introduce a new primitive. It fixes the contested facts — the chain-letter map and the precompile slot map — from the code that is the source of truth, and points at the LPs that own each sub-spec.

Three rules govern the whole system:

One engine. Every VM is a pure state machine. The single Quasar engine (LP-0110) owns all consensus, all gossip, all propagation. A VM never ships its own consensus or its own gossip path.
One slot map. Every native precompile has exactly one address, set by one constant in ~/work/lux/precompile. Comments, docs, and LPs describe that constant; they never redefine it.
One place for value. A unit of value lives on exactly one chain at a time. Cross-chain motion is an atomic conserving move. The bridge is the only external on/off ramp.

1. The chains

The authoritative chain set is the Registry slice in node/genesis/builder/registry.go. Each row binds a canonical single letter, the VM that runs the chain, the non-letter aliases, and the display name. The whole node (alias resolution, VM-manager wiring, genesis chain creation) derives from this one table — there is no second list to keep in sync.

Letter	VM (`chains/`)	Role	Go-live
P	platformvm	Platform — staking, validators, epochs, slashing	Live
X	xvm	UTXO asset ledger — native assets, swaps, atomic txs	Live
C	evm (cevm)	Contract — general EVM smart contracts, DeFi	Live
D	dexvm	DEX — native CLOB + AMM, the trading product chain	Go-live target
Q	quantumvm	Quantum — Pulsar 2-round threshold ceremony for PQ consensus signing	Live
A	aivm	AI / Attestation — Proof-of-AI, TEE/GPU attestation, provenance	Go-live target
B	bridgevm	Bridge — cross-chain messaging + teleport, MPC-secured custody	Go-live target
M	mpcvm	MPC ceremonies — bridge-custody threshold signing (CGGMP21, FROST, Pulsar-general), per LP-7100	Live
F	fhevm	FHE — encrypted EVM, TFHE bootstrap-key generation, threshold-FHE decryption, per LP-8200	Go-live target
Z	zkvm	Zero-knowledge — zk-rollup, shielded UTXO, privacy	Go-live target
G	graphvm	Graph — GraphQL data layer, cross-chain queries	Experimental
K	keyvm	Key — ML-KEM/ML-DSA key management, threshold sharing	Live
I	identityvm	Identity — DIDs, verifiable credentials	Live
O	oraclevm	Oracle — decentralized data feeds, observation aggregation	Live
R	relayvm	Relay — cross-chain message passing (Lux Warp)	Live

The go-live target the network ships is D + A + Z + B working on top of the already-live P/X/C/Q/M/K/I/O/R. G (graphvm) is experimental and not gating.

Naming discipline: the letter is the value's name; the VM directory is where the implementation lives. They differ in three cases by design (X→xvm, C→evm, A→aivm). Do not "fix" a VM directory name to match its letter; the registry is the binding.

2. The VM / engine boundary

This is the single most important architectural invariant and the one most often violated.

A VM is a pure block.ChainVM. It parses bytes into blocks, verifies a block against its parent, and applies a verified block to its state. That is all. It is a deterministic state machine: same parent state + same block bytes → same child state on every validator, forever.

The engine owns everything else. The single Quasar engine (~/work/lux/consensus, LP-0110) drives the poll committee, collects the weighted quorum, assembles the certificate, and runs all block/vote gossip and propagation. There is no per-VM consensus and no per-VM gossip.

Self-heal on unknown vote. When the engine receives a vote for a block it has not yet seen, it fetches that block through the engine's own fetch path. A VM never reaches onto the wire to repair its own view; it exposes Get/Parse and trusts the engine to deliver bytes.

The cautionary tale: a VM that grows a private gossip path (e.g. a DEX VM that tries to relay its own order/fill stream out of band) forks consensus, because validators then disagree on inputs the engine never certified. The fix is always the same — delete the private path, let the engine carry it, replay state from block bytes only.

The DEX VM is where this matters most, and it has two distinct implementations that must not be confused:

Native (luxfi/dex/pkg/dchain) — the matcher runs at block Verify over the VM's own state (a pure block.ChainVM). This is the go-live target: matching is the deterministic state transition, never evaluated against a wall-clock stream, GPU non-determinism, or an external venue. Order ingestion and fills are carried in blocks and certified by the one engine.
Proxy (luxfi/chains/dexvm, which node/vms/dexvm currently re-exports for backward compatibility) — a stateless atomic proxy that relays fills produced by an external venue into blocks via its atomic.go carry-fills path. It gossips nothing matcher-related; the no-private-matcher-gossip invariant holds, but matching does not happen at Verify.

The native model is the canonical end state. Whichever VM is wired at go-live, the boundary rule is identical: the engine owns gossip and finality, and every validator must reach the same state from the same block bytes. (Owners of the dex and chains/dexvm trees drive the native-vs-proxy cutover; this LP fixes the contract both must satisfy, not the migration.)

Consequences a VM author must honor:

No wall-clock reads in Verify/Accept. Block time comes from the block.
No floating-point non-determinism in state transitions. GPU-accelerated block building is allowed only when the GPU result is byte-identical to the pure-Go result (KAT-gated — see §6); otherwise CPU.
No "modes" that change the state machine per node. Profile selection (§4) is a config knob read identically by every validator from chain config, never a per-node behavior switch.

3. Dynamic weighted quorum (finality core)

Finality is leaderless (LP-0013). No node proposes finality. A value block is final iff a set of distinct validators have each signed ACCEPT over the same position and their cumulative stake strictly exceeds ⅔ of the live stake — a fact any node recomputes from signed votes. Whoever first gathers those votes assembles the certificate; the certificate is byte-identical regardless of who assembles it (consensus/engine/chain/quorum_cert.go).

The quorum is dynamic and weighted (LP-0110 §3):

K = liveN — the committee size is the current live validator set, not a fixed sample.
α = strict-⅔ by stake — derived from VerifyWeighted; cumulative ACCEPT stake must be > 2/3 of total, never ≥.
Epoch-anchored — the stake weights and validator set are pinned to the epoch boundary so a cert cannot be satisfied by a set the round did not begin with.
Two-sided clamp — the effective threshold is clamped on both sides so neither a collapsing live set nor a transient spike can lower the ⅔-by-stake bar or push it past unanimity.

Photon (committee draw) drives preference and liveness; it does not elect a finality leader. The authoritative finality model is this weighted quorum certificate.

4. Two-tier finality and the certificate profile

Finality has two tiers that run in parallel, not in sequence-with- deprecation. This is the most commonly mis-stated fact in the codebase and is fixed here.

Tier 1 — BLS fast path (stays). A network-wide BLS12-381 aggregate signature gives a low-latency, provisional, edge-fast finality. BLS is the PQ-off leg and it is not deprecated. HFT-class chains and classical-compat L2s may run on it alone.

Tier 2 — native PQ, computed in parallel. The native PQ precompiles (§5: Pulsar at 0x012204, Corona at 0x012206, Magnetar at 0x012207, and the base ML-DSA verifier at 0x012202) produce additional post-quantum finality legs over the same round, so a break of the classical BLS leg does not break finality.

A precise word on family hardness (LP-0120 §"Corona vs Pulsar"): Pulsar and Corona are both lattice schemes — Corona is Module-LWE at module rank k=1, which is Ring-LWE, with polynomial-time reductions to Pulsar's Module-LWE. Stacking them gives implementation-level defense-in-depth (different parameter sets and codebases) but not family-disjoint hardness. True cross-family PQ diversity arrives only when a non-lattice leg is added: hash-based Magnetar (0x012207, collision resistance) on the signature side, or code-based HQC (0x012208, Syndrome Decoding) on the KEM side. So PQ-strict (BLS + Pulsar + Corona) is two lattice legs plus a classical leg; genuine family-disjoint PQ defense is a PQ-heavy (adds Magnetar) property. The ladder is sized accordingly.

The two tiers compose through the QuasarCert profile (LP-217), an operator config knob quasar.cert_mode. The profile is additive and monotone — each step adds exactly one independent leg:

PQ-off  ⊂  PQ-fast        ⊂  PQ-strict             ⊂  PQ-heavy
BLS        BLS + Pulsar      BLS + Pulsar + Corona     BLS + Corona + Pulsar + Magnetar

Pure-PQ variants drop the BLS leg for chains with no classical-bridge dependency: strict-PQ-fast (Pulsar), strict-PQ-strict (Pulsar + Corona), strict-PQ-heavy (Corona + Pulsar + Magnetar).

certType / the VerifierRegistry are profile selection, not a primitive swap. Adding a PQ leg never removes the BLS leg and never changes the cert wire format (LP-182); it sets which legs must be present and verified for a cert to be at mode M. Default for the new final Lux network: PQ-strict.

Rollup-commit tier (P3Q → Z-Chain → STARK-FRI)

Above the per-round cert sits the rollup-commit path, which is a distinct concern with a distinct verifier — do not conflate it with the consensus PQ legs:

P3Q (0x012205) is the rollup-commit verifier only (LP-218). It is a Solidity-callable shim: a Tier-3 rollup sequencer PQ-threshold- signs (prev_root, new_root, batch_hash), submits a RollupBatchTx to Z-Chain, and Z-Chain validators verify the signature via P3Q inside normal block validation. P3Q dispatches to the PQ family by a leading kind byte (0x01 Pulsar / 0x02 Corona / 0x03 Magnetar; LP-220). Its verifier core is the FIPS 204 ML-DSA verifier — there is no P3Q-specific crypto. P3Q is not a STARK and not the general consensus PQ.
STARK-FRI (0x012220) is the trustless rollup verifier (LP-221): a strict-PQ STARK over the Goldilocks field with FRI low-degree testing and cSHAKE256 Merkle commitments, no classical-curve surface. It is the integrity path for ZK rollups whose execution must be proven, not merely signed.

The rollup inherits the parent L1's QuasarCert finality because the commit is a Z-Chain transaction; there is no rollup-side validator set, and no fraud-proof bond is needed for the cryptographic path.

5. The precompile slot map (authoritative)

The addresses below are the registered constants in ~/work/lux/precompile — the only source of truth. Stale comments that labeled 0x012205 a "STARK" have been corrected in code; P3Q is a signature verifier, STARK-FRI is the STARK.

Unified PQ crypto block (`0x0122xx`, LP-4200)

Address	Primitive	Const (`precompile/...`)
`0x012201`	ML-KEM (Module-LWE KEM, FIPS 203)	`mlkem.ContractAddress`
`0x012202`	ML-DSA (Module-LWE single-sig, FIPS 204)	`mldsa.ContractMLDSAVerifyAddress`
`0x012203`	SLH-DSA (hash-based sig, FIPS 205)	`slhdsa.ContractSLHDSAVerifyAddress`
`0x012204`	Pulsar (Module-LWE threshold, FIPS 204 byte-equal)	`pulsar.ContractPulsarVerifyAddress`
`0x012205`	P3Q (rollup-commit PQ verifier; kind-byte dispatch)	`p3q.ContractP3QVerifyAddress`
`0x012206`	Corona (Module-LWE threshold, Ringtail/Raccoon line)	`corona.ContractCoronaThresholdAddress`
`0x012207`	Magnetar (SLH-DSA threshold, FIPS 205 byte-equal)	`magnetar.ContractMagnetarVerifyAddress`
`0x012208`	HQC (code-based KEM, family-disjoint backup)	`hqc.ContractAddress`
`0x012220`	STARK-FRI (strict-PQ STARK / FRI / SHAKE)	`starkfri.ContractStarkFRIVerifyAddress`

The native PQ precompiles are separate primitives at separate slots. P3Q (0x012205) is one consumer that dispatches to Pulsar/Corona/ Magnetar; it does not replace them and is not "PQ everywhere."

Threshold / MPC (`0x0800xx`)

Address	Primitive	Const
`0x0800…0002`	FROST (Schnorr threshold)	`frost.ContractFROSTVerifyAddress`
`0x0800…0003`	CGGMP21 (ECDSA threshold)	`cggmp21.ContractCGGMP21VerifyAddress`

ZK proofs (`0x0900xx`)

Address	Primitive
`0x0900…0001`	Groth16
`0x0900…0002`	PLONK
`0x0900…0003`	fflonk
`0x0900…0004`	Halo2
`0x0900…0010`	KZG
`0x0900…0020`–`0023`	PrivacyPool / Nullifier / Commitment / RangeProof
`0x0900…0030`–`0032`	RollupVerify / StateRoot / BatchProof

Other native primitives

Address	Primitive
`0x000b`–`0x0011`	BLS12-381 G1/G2/MSM/Pairing (EIP-2537)
`0x0100`	secp256r1 / P256 verify (EIP-7212)
`0x0700…0000`–`0003`	FHE (compute / ACL / input-verifier / gateway)
`0x0500…0004`	blake3
`0x0500…0007` / `0x0500…0008`	babyjubjub / pasta
`0x0500…0010`–`0013`	graph (GraphQL / Subscribe / Cache / Index)
`0x0300…0000`–`0010`	AI (ai / attestation / modelregistry / aivmbridge / compute)
`0x0400…0050` / `0x0400…0060`	math / stableswap (legacy leading-byte)
`0x0A00…0001`	sr25519
`0x…2202` / `0x…2221`	ed25519 (LP-3211) / hybrid-KEM (x25519+Kyber, LP-2221)

Address scheme

Two formats coexist by design and both are canonical:

Trailing-significant (PCII, LP-0099) — 0x…PCII, address ends with the LP number. P = family page, C = chain slot, II = item. This is the scheme for all LP-numbered precompiles.
Leading-byte legacy — math (0x0400…0050), stableswap (0x0400…0060), KZG (0xB002). Pre-PCII modules; not extended.

The PCII chain-slot (C) nibble in precompile/registry/registry.go addresses the chains that host C-routed precompiles plus the sovereign-L1 EVM targets (Zoo/Hanzo/SPC). It is an address-routing index, not a second chain registry; the authoritative chain set is §1. The nibble comment has been aligned so it no longer invents a phantom "M-Chain" and includes D-Chain.

6. GPU / C++ boundary

The public Go OSS is pure-Go plus cgo glue only — no GPU/C++ kernel source ships in the public repos. The kernels live in luxcpp (forked- OSS is public; proprietary kernels are a separate tree). The boundary is a device adapter (LP-132): the Go side calls the adapter, the adapter dispatches to a kernel if one is present and KAT-clean, otherwise falls back to pure-Go.

The gate is byte-identity. A GPU kernel may be wired into a consensus- relevant path only after a Known-Answer-Test proves its output is byte-identical to the pure-Go reference on the full KAT vector set. Any divergence (one example on record: a Metal blake3 vtbl that failed 1 of 6 KAT vectors; another: a corona kernel built on the wrong prime) keeps the kernel OUT of consensus until fixed and re-KAT'd. A wrong kernel that "mostly works" is worse than no kernel.

Block-STM device-resident parallel block building (LP-210, LP-137) is the sanctioned use: parallel across markets/accounts, deterministic per batch, and the GPU state root MUST equal the CPU state root. Same rule — byte-identity or it does not run under consensus.

7. Value conservation

A unit of value lives on exactly one chain at a time, drawn from {P, X, C, D, Z}. The motion primitive is uniform:

Conserving move — a cross-chain transfer destroys the value on the source chain and creates it on the destination chain atomically. The sum across all chains is invariant. There is no path that mints on the destination without burning on the source.
B is the only external ramp — assets enter or leave the Lux value set exclusively through the bridge (B-Chain, MPC custody). Internal moves never touch B.
Shielded via Z — privacy is a property of where value sits (Z-Chain shielded UTXO), reached by the same conserving move, not a separate asset class. The proof system on Z is a separate axis from the finality profile: a Z rollup whose execution must be proven uses the trustless STARK-FRI path (0x012220, strict-PQ, no classical-curve surface, §4); a legacy Groth16-over-BLS12-381 path is classical and is being retired in favor of STARK-FRI for the strict-PQ posture. Either way the value-move authorization follows the cert profile (§4).
PQ throughout — the signatures authorizing moves are subject to the same profile (§4); a strict-PQ chain never drops to a classical-only primitive on the wire (LP-0120).

8. Reconciliation record

Canonical facts this LP pins, and where it overrides older specs. Code is authoritative; every address and chain row above is the registered constant / the genesis Registry row, not a comment.

Slot map. 0x012205 is P3Q, the rollup-commit ML-DSA verifier; 0x012220 is STARK-FRI, the STARK. Any comment, doc, or memory note that labels 0x012205 a "STARK" or places STARK-FRI at 0x012205 is stale and is superseded by this LP and the registered constants in p3q/contract.go and starkfri/contract.go.
Chain-slot nibble. The precompile/registry/registry.go C-nibble is an address-routing index, not a chain registry. There is no M-Chain; D-Chain occupies C=3; Zoo/Hanzo/SPC are sovereign-L1 EVM targets, not primary-network chains. The 14-chain set in §1 is the authority.
P3Q scope. P3Q is rollup-commit-only with kind-byte dispatch — not "P3Q everywhere across consensus/settlement/bridge."
Two-tier finality. BLS is the fast path and stays; native PQ is an additional parallel leg; certType/VerifierRegistry is profile selection, not a primitive swap.
VM/engine boundary. One engine owns consensus and gossip; every VM is a pure block.ChainVM. The DEX VM has a native (matcher-at-Verify) and a proxy (carry-fills) form; the native form is the canonical end state (§2).

Topology authority. LP-134 is the authoritative chain topology. It fixes the canonical roster P/C/X/Q/Z/A/B/M/F and removes T-Chain entirely: MPC / threshold signing is M-Chain (mpcvm, LP-7100), FHE / encrypted compute is F-Chain (fhevm, LP-8200), and teleport / cross-chain messaging is B-Chain (bridgevm). There is no thresholdvm chain and no combined threshold surface — that framing is retired (see LP-7050). The §1 Registry above additionally lists the operational product/service chains realized in node/genesis/builder/registry.go (e.g. D-Chain first-class, plus K/I/O/R/G), which LP-134's nine-role taxonomy does not enumerate. Flag (genesis lag): where an interim genesis build still exposes a single combined MPC+FHE surface instead of distinct M- and F-Chains, that is a migration lag in registry.go to be reconciled to LP-134 — not a competing topology. LP-134's cert-pipeline and cross-chain-root binding remain authoritative.

Already-consistent inputs. The validated LPs/ corpus — LP-0110 (weighted quorum) and LP-0120 (mainnet defaults, which carries a code-accurate slot map and the Corona-vs-Pulsar family analysis cited in §4) — and the crypto-stack LPs LP-218 (P3Q rollup), LP-220 (Corona/ Magnetar kinds), LP-221 (STARK-FRI) were checked against code and agree on the slot map. Two known upstream wrinkles are noted, not inherited: LP-217's prose ladder at its opening (lines ~44–47) disagrees with its own LOCKED table — the LOCKED table is authoritative (PQ-fast = BLS + Pulsar, PQ-strict = BLS + Pulsar + Corona); and LP-0120's FinalitySchemeID default names the BLS+Pulsar leg-set while LP-217 names PQ-strict as the new-network default — this LP follows LP-217 (PQ-strict) as the posture default and treats BLS+Pulsar as the minimum floor.

References

LP-0110 — Quasar Unified Consensus (weighted quorum, leaderless)
LP-0120 — Quasar mainnet defaults, strict-PQ profile, L1 onboarding
LP-0013 — Leaderless invariant
LP-217 — Cert profile modes (PQ-off/fast/strict/heavy)
LP-218 — ZAP-native PQ rollups via P3Q (0x012205)
LP-220 — P3Q Corona + Magnetar kinds on 0x012205
LP-221 — STARK-FRI verifier precompile (0x012220)
LP-132 — Quasar GPU execution adapter (device boundary)
LP-210 / LP-137 — Block-STM parallel execution, GPU-residency invariant
LP-134 — Lux chain topology
LP-0099 — Precompile address scheme (PCII)
Code (authoritative): node/genesis/builder/registry.go, precompile/{p3q,starkfri,pulsar,corona,magnetar,mldsa,mlkem,slhdsa,hqc}/, precompile/registry/registry.go, consensus/engine/chain/quorum_cert.go

Lux Blockchain Go-Live Standard — Chains, VMs, Precompiles, Finality