The canonical specification corpus for the Lux Network — 234 proposals across chains, post-quantum cryptography, consensus, bridges, and DeFi.
Comprehensive specification for digital securities on Lux Network
ComplianceHook integration with V4 DEX precompile for regulated on-chain trading
SecurityBridge lock/mint/burn/release pattern for cross-chain security token transfers
Machine-checked proofs of consensus safety, liveness, and smart contract invariants
Modular financial platform architecture for MTL-licensed digital securities operations
Multi-currency banking platform specification
Central limit order book matching engine specification
Unified type system for multi-asset class trading
GPU-accelerated EVM with bytecode fiber VM, Block-STM parallel execution, and async cold-state page faults
GPU-native, lane-aware ordered MVCC execution fabric for QuasarGPU
GPU-accelerated batch cryptographic operations via luxcpp/gpu
NIST FIPS post-quantum algorithms accelerated on GPU via NTT
TFHE operations accelerated on GPU as the F-Chain compute fabric, integrated into QuasarGPU's wave-tick scheduler for in-process encrypted EVM
Interchangeable EVM implementations as Lux L1/L2 VM plugins
Secure validator key lifecycle — generation, storage, rotation, genesis binding, and post-quantum readiness
The canonical v1 architecture lock-in for Lux Network and every sovereign L1 spawned from it
How the v1 PQ threshold stack composes inside Lux consensus — wire codecs, cert profiles, and the formal verification bridge
Unified Network CR (one Kind covers L2 + Sovereign L1 + Independent), driven by two data fields (networkID + validators), with an atomic P-Chain primitive that materializes a sovereign L1 with N chains, validators, and PQ profile
What lives in ~/work/lux/genesis/configs/ at v1, what does not, and the field-naming invariants every allocation entry obeys
How operator-controlled MPC custody composes the v1 PQ threshold stack with TEE attestation, KMS release gates, HSM-resident keys, and human-in-the-loop approval
The cryptographic construction that lets v1 threshold-sign FIPS 205 SLH-DSA on a public-BFT chain without a TEE and without ever reconstructing the master seed
Binary wire protocol with sub-microsecond serialization for Lux node communication
Erasure coding data availability guarantees for Lux block data
The Lux P-chain wire is ZAP. The Go struct IS the wire. No marshal. No codec. No encode/decode step. From genesis of the new final Lux network.
Merkle-based state synchronization for fast node bootstrapping
Interactive fraud proof game for optimistic execution verification
Verkle tree state proofs for bandwidth-efficient light clients
Wave propagation protocol for sub-100ms block dissemination
Fast Probabilistic Consensus protocol for rapid binary agreement
Number Theoretic Transform for efficient lattice-based cryptographic operations
P-chain virtual machine for validator management, staking, and L1/L2 lifecycle
X-chain DAG-based asset exchange VM for high-throughput UTXO operations
Central Limit Order Book DEX VM with GPU-accelerated matching
Q-chain virtual machine for quantum-resistant operations and key management
B-chain virtual machine for cross-chain bridge custody and settlement
AI compute attestation VM for verifiable inference and model registration
G-chain GraphQL indexing VM for on-chain data queries
Z-chain zero-knowledge privacy VM for shielded transactions and private computation
Oracle aggregation VM for decentralized price feeds and external data
Canonical Safe multisig pattern with the eight-signer set Lux uses for treasury, validator-set, and DAO multisigs across the Quasar v1 era.
Uniswap V2 style constant-product automated market maker
How Zoo, Hanzo, Pars, Osage and other white-label brands consume the audited Lux DAO + Safe + Quasar-signer stack without forking.
Concentrated liquidity AMM with capital-efficient position ranges
Cross-chain message relay VM for warp-style verified message passing
Unified identity chain — DIDs, verifiable credentials, names, and domains
Curve-style StableSwap AMM optimized for pegged asset pairs
Distributed key management chain — key lifecycle for the whole network
LPX-style perpetual futures protocol with up to 50x leverage
Morpho-style isolated lending markets with per-pair risk isolation
MPC-as-a-service — threshold signing sessions and threshold FHE for the network
Committee-based PQ quorum certificates for N=1000+ validator networks
Liquid staking protocol producing sLUX (rebasing) and xLUX (non-rebasing) derivatives
European-style options protocol with on-chain settlement and Black-Scholes pricing
Post-quantum secure private messaging service node registry
How transaction fees, block rewards, and service fees are divided among validators who opt into PQ security work
Sablier-style token streaming for continuous payments and vesting
Protocol insurance with underwriter staking and parametric claims
Bounded N=100 validator set via NFT seats, open stake delegation, unlimited read-only replicas for service scaling
Optimistic oracle prediction markets for binary and scalar outcomes
Intent-based trading with limit orders, RFQ, and solver network
Sudoswap-style NFT AMM with bonding curve pricing
Multi-source price oracle aggregation for on-chain consumption
EigenLayer/Symbiotic-style restaking for shared security
Credit-based lending with reputation scoring for reduced collateral requirements
LUX token economics including emission schedule, vesting, and fee burns
Soul-bound reputation system with activity-weighted scoring and time decay
Rebasing governance token that accrues protocol revenue
Aggregated voting power from xLUX and DLUX for unified governance
Gauge weight voting for directing protocol fee distribution across pools
W3C DID method for Lux Network with on-chain DID documents and resolver
OAuth 2.1 and OpenID Connect identity architecture for Lux services
HSM-backed key management service for all Lux/Hanzo infrastructure secrets, integrated as a Quasar precompile per LP-133
Z-Chain hosts the MLDSAGroth16 cert-lane rollup for Quasar 3.0 plus the general-purpose ZKP verifying-key registry committed in zchain_vk_root
Shielded deposit/withdrawal pool with nullifier-based double-spend prevention
Mesh network of TEE enclaves for confidential computation on Lux validators
Threshold FHE scheme for encrypted on-chain computation
ERC-20 token standard with FHE-encrypted balances and transfer amounts
Private cross-chain transfers combining shielded pools and Warp messaging
FALCON-512/1024 signature verification precompile for EVM
Complete registry of all 37 EVM precompile packages with addresses, gas costs, and specifications
Burn addresses splitting fees 50% deflationary burn and 50% DAO treasury
Cross-chain fee aggregation from all L1 / L2 chains to the primary treasury
Fee routing contract distributing protocol revenue to LiquidLUX vault
Validator reward distribution vault with proportional stake-weighted payouts
LUX token economics including issuance schedule, supply cap, and fee model
Game-theoretic analysis of validator incentives, rewards, and slashing
DAO structure with Karma reputation, DLUX governance token, and vLUX voting power
Governor contract with gauge-weighted voting for resource allocation
Shariah-compliant financial product framework for Lux Network
ERC-3643 (T-REX) compliant securities token framework with modular compliance
Sovereign governance model allowing each L1/L2 chain independent DeFi governance
ERC-20 wrapped version of native LUX for DeFi composability
Bridge token standard for 67+ cross-chain tokens with mint/burn mechanics
GPU compute mining token with hardware attestation for AI workloads
sLUX liquid staking receipt token representing staked LUX
xLUX master yield vault aggregating staking rewards and protocol fees
Multi-signature safe contracts for secure team and treasury fund management
ERC-4337 account abstraction with smart accounts, paymasters, and bundlers
Multicall contract for batching multiple contract calls into a single transaction
cevm GPU-accelerated EVM interpreter for parallel transaction execution
Complete auditor-ready protocol specification document for Lux Network
Framework for chain state migration and regenesis operations
Only P-Chain and Q-Chain are required for the primary network. All other chains are optional L1s.
E2E post-quantum encrypted streaming replication for SQLite (WAL-based) and ZapDB (incremental backup) to S3-compatible storage using age (ML-KEM-768 + X25519)
Classical curve threshold signature kernel — sister to Pulsar. FROST-derived 2-round Schnorr/EdDSA threshold signing with key-era lifecycle, verifiable secret resharing, persistent group public key. Replaces the stub LSS-FROST integration.
Authoritative naming for the Lux consensus and post-quantum cryptography stack. Cosmological + optical + cryptographic only. No borrowed brands. Defines Photon, Nebula, Lumen, Beam, LSS, Lens, Pulsar, Pulse, Prism, Horizon, Quasar.
Shared `luxfi/math` substrate (modular arithmetic, Montgomery, NTT, RNS, polynomial ops, bounded codec, backend dispatch) that consensus protocols, lattice algebra, FHE schemes, and curve threshold protocols all consume.
Promote `lux/math` to the single canonical compute substrate. Rip out duplicate kernels, vapor stubs, and half-baked GPU paths. Define the production gate every implementation must pass.
Baby Jubjub twisted Edwards curve operations for ZK circuit compatibility
Raw Edwards25519 point operations for ring signatures, Bulletproofs, and VRFs
Pallas and Vesta curve operations for recursive proof composition
X25519 Diffie-Hellman key exchange precompile
AES-256-GCM authenticated encryption and decryption precompile
ChaCha20-Poly1305 authenticated encryption and decryption precompile
Pedersen hash commitment scheme over BN254 for hiding and binding commitments
Elliptic Curve Integrated Encryption Scheme for on-chain public key encryption
RFC 9180 HPKE with classical and post-quantum KEM support
SR25519 (Schnorrkel/Ristretto255) signature verification for Substrate interop
TEE remote attestation verification for GPU, TPM, and compute environments
On-chain GraphQL query interface to the G-Chain unified query layer
On-chain precompile discovery and address scheme documentation
AI mining reward calculation and cryptographic verification for compute-to-earn
Verifiable random function verification precompile (ECVRF-EDWARDS25519-SHA512-ELL2)
GPU-native execution adapter for Quasar-certified rounds — wave-tick scheduler, device-resident rings, EVM fibers, MVCC Block-STM, async cold-state, per-lane cert verification
Hanzo Gateway lane-affinity routing; native Base appchains on Quasar consensus; MPC and KMS as Quasar cert lanes
Canonical taxonomy of the nine Lux chains and how each plugs into the QuasarGPU substrate
QuasarSTM 4.0 — production spec activated on 2026-02-14. Closes the gaps left by 3.0: full EVM coverage, real BLS/Corona/Groth16 verifiers, lane-clock Tier 1, semantic reducers Tier 3, ConflictSpec ABI, NEMO LaneClass, dynamic per-lane versioning, fiber checkpoints, commit horizon, MVCC GC, Motor VersionBlock, A/B/M/F drain services, CSMV commit-server scaffold, cross-backend determinism harness.
Permissionless decentralized cloud where every customer runs in their own Quasar-native appchain — GPU compute, storage, AI inference, DEX engines, and FHE compute priced per-appchain via on-chain markets
t-of-n threshold FHE services (PartialDecrypt, ShareVerify, ShareAggregate) built on the MPCVM v0.62 four-kernel template, with the wire-up plan for Quasar precompile integration.
Type-system foundation that prevents silent FHE correctness failures across Go and C++ kernel boundaries.
Per-chain audit of BlockSTM coverage, parallelism granularity, and GPU dispatch points across the 9-chain Lux topology
Specification to replace the placeholder threshold-FHE implementation in luxfi/threshold/protocols/tfhe with a real Shamir-share + lattice partial-decrypt + Lagrange combine pipeline.
Trust-mode + IO-level enums, worker / node capability records, lane + workload eligibility policy, and composite attestation envelope for the Lux GPU Runtime.
The "no chain-local hot path leaves GPU memory" invariant — full optimization checklist for QuasarGPU 4.0+ activation
Cross-chain message relay VM for warp-style verified message passing
Unified identity chain — DIDs, verifiable credentials, names, and domains
Distributed key management chain — key lifecycle for the whole network
MPC-as-a-service — threshold signing sessions and threshold FHE for the network
Committee-based PQ quorum certificates for N=1000+ validator networks
Post-quantum secure private messaging service node registry
How transaction fees, block rewards, and service fees are divided among validators who opt into PQ security work
Bounded N=100 validator set via NFT seats, open stake delegation, unlimited read-only replicas for service scaling
Authoritative umbrella LP for the Lux FHE stack. Defines a dual-runtime split — Go for canonical semantics + chain integration; C++/GPU for production throughput — with cross-runtime KATs ensuring semantic equivalence and FHE result roots binding into Nebula/Quasar transcripts.
Lux-side mirror of Hanzo HIP-0077. Adopts ML-DSA-65 mesh identity, Lux-consensus-backed gossip, and on-chain receipt payments under the canonical LUX_STRICT_PQ profile. Heavy spec lives in HIP-0077; this LP pins the Lux genesis, ProfileID, and luxfi/* package surface.
Lux-side mirror of Hanzo HIP-0078. Pins Z-Chain as the Lux PQ identity / DKG-transcript / attestation rollup under the canonical LUX_STRICT_PQ profile. STARK / FRI / SHA-3 only; Groth16 / BN254 and KZG are explicit refusal markers on the Lux wire. Heavy spec lives in HIP-0078.
Lux-side mirror of Hanzo HIP-0079. Pins the compact finality-block wire format for the Quasar consensus engine on Lux. Single Pulsar-65 threshold sig per block; TupleHash256 transcript binding over 23 axes; Z-Chain roots anchored by hash. Heavy spec lives in HIP-0079.
Lux-side mirror of Hanzo HIP-0084. Pins Pulsar-65 as the threshold ML-DSA primitive consumed by Q-Chain finality. Epoch-cadence DKG, identifiable abort, no BLS fallback. Threshold-aggregated signature verifies under unmodified FIPS 204 ML-DSA.Verify. Heavy spec lives in HIP-0084 and the NIST MPTC submission package.
Lux-side mirror of Hanzo HIP-0085. Adopts the 48-byte ML-DSA-65-derived AccountID and BIP-32 path m/44'/9000'/nid'/0/n under the canonical LUX_STRICT_PQ profile. Heavy spec lives in HIP-0085; this LP pins the luxfi/* package surface.
Lux-side mirror of Hanzo HIP-0086. Pins the typed PQ transaction-signing envelope under LUX_STRICT_PQ. ML-DSA-65 signature over a TupleHash256 transcript bound by cust string TX-AUTH-V1; verifier is unmodified FIPS 204. Heavy spec lives in HIP-0086.
Lux-side mirror of Hanzo HIP-0087. ML-DSA-65 typed-data permit replacing EIP-2612 for ERC-20-style approvals under LUX_STRICT_PQ. TupleHash256 transcript bound by PERMIT-V1 cust string. Heavy spec lives in HIP-0087.
Lux-side mirror of Hanzo HIP-0088. Locks ML-KEM-768 (default) and ML-KEM-1024 (high-value) as the PQ session KEM under LUX_STRICT_PQ. Classical X25519 refused. KMAC256 KDF over TupleHash256 transcript. Heavy spec lives in HIP-0088.
Lux-side mirror of Hanzo HIP-0089. Hash-DRBG over SHA3-384 per NIST SP 800-90A as the canonical randomness beacon under LUX_STRICT_PQ. QRNG entropy + Pulsar aggregation reseed each epoch. Heavy spec lives in HIP-0089.
Lux-side mirror of Hanzo HIP-0103. Bridge contracts under LUX_STRICT_PQ refuse all inbound state that is not finalised under a strict-PQ profile, with field-byte equality on the counterparty profile and Pulsar-65 verification. Heavy spec lives in HIP-0103.
Lux-side mirror of Hanzo HIP-0098. Routine governance uses Pulsar-87 (threshold ML-DSA-87, FIPS 204). Cold-root upgrade keys use SLH-DSA-256s (FIPS 205) under k-of-n with k >= ceil(2n/3)+1. Heavy spec lives in HIP-0098.
Lux-side mirror of Hanzo HIP-0104. Four precompiles at 0x0301..0x0304 (ML-DSA-65 / ML-DSA-87 / SLH-DSA / Z-Chain auth proof) provide the contract-side strict-PQ auth surface. Heavy spec lives in HIP-0104.
Tracks the Pulsar NIST MPTC submission package at luxfi/pulsar. Pins the deliverables (spec, reference impl, KAT vectors, Class N1 interop, Lean mechanization, Jasmin/EasyCrypt high-assurance scaffold) and the schedule (preview 2026-Jul-20, first call 2026-Nov-16).
A canonical agent-to-agent payment protocol covering HTTP/402 quotes, ZAP-framed offers, on-chain escrow, streaming sessions, and threshold-signed multi-party settlements
The Lux consensus wire is ZAP. The Go struct IS the wire. No marshal. No codec. No encode/decode step. From genesis of the new final Lux network.
The Lux X-chain wire is ZAP. The Go struct IS the wire. No marshal. No codec. No encode/decode step. From genesis of the new final Lux network.
The Lux primary-network EVM's internal-wire surfaces — atomic-tx style payloads, predicate-result blobs, state metadata — are ZAP. External Ethereum RLP (block header, body, signed tx, receipts, logs) is preserved unchanged. Ethereum tooling is consumed at the chain boundary as RLP.
ZAP wire across all chain VMs in luxfi/chains. The Go struct IS the wire. No marshal. No codec. No encode/decode step. From genesis of the new final Lux network.
Decomplected blockchain architecture where the ZAP buffer IS the wire format AND the in-memory representation AND the on-disk record. One byte stream from network to mempool to state to ZapDB to backup. No codec, no marshal, no encode/decode step.
The Transport.Pick() selector contract for peer-to-peer transports, plus the QUIC default implementation, mDNS LAN discovery, and Kademlia DHT for content addressing. Defines Transport.Register() so future transports (LP-207 RDMA-IB, future CXL fabric, future DPDK) register against one contract. Replaces luxfi/p2p which is archived. From genesis of the new final Lux network.
Formal pipelining contract and atomic-unwind primitives for the ZAP Stack. Bidirectional + immutable buffer + zero-copy + MVCC = N-deep pipelining with O(1) unwind at every layer. Codec-based blockchains cannot do this.
GPU isn't an optimization — it's the architecture. The ZAP buffer in unified memory lets the GPU read consensus bytes with zero CPU memcpy. Signature verification, lattice signing, Merkle root computation, and threshold aggregation run as CUDA/Metal/ROCm kernels. NIC bytes go straight to GPU memory via GPUDirect RDMA. DPDK kernel-bypass delivers 10M packets/sec to a single validator.
Round-blocking Quasar floors throughput at one block per round-latency. Pipelined Quasar runs 3 blocks in flight — Select for block N+2, Build for N+1, Sign for N — collapsing the per-block wall-clock to max(stage_time) at steady state. Cert wire format unchanged; only protocol orchestration changes. The single-leader rotating scheduler is preserved; leaderless DAG mempool ordering is the sibling LP (LP-208 + LP-209).
A rack-scale shared state region exposed via CXL 3.0 (Compute Express Link) Type-3 memory pool. Validators in the same rack mount the ZAP buffer pool from a pooled CXL memory device; LP-200 ZAP buffers, LP-210 MVCC snapshots, and LP-211 staged overlays become shared reads at sub-100ns latency. The DHT (LP-201) replicates rack-pool snapshots globally; the in-rack pool is a fast path, not a substitute for global replication.
An implementation of the LP-201 Transport.Pick() contract for cross-rack peers within a single data center. Registers `rdma-ib` (CapRDMAIB) and `rdma-rocev2` (CapRDMARoCEv2) via Transport.Register(name, factory). Carries LP-201's stream-type bytes (0xD0..0xDF) on RDMA WRITE_WITH_IMM (gossip) and RDMA SEND+SEND (RPC), with ~3 μs cross-rack NIC-to-NIC RTT on Mellanox ConnectX-7 NDR. Selector semantics are owned by LP-201; this LP defines only the RDMA-IB implementation.
The traditional single-mempool-per-validator model caps aggregate transaction throughput at `min(validators)`. The DAG mempool inverts this — every validator continuously emits ZAP headers carrying tx hashes; bodies are stored in the Kademlia DHT; aggregate throughput becomes `sum(validators)`. Total-ordering of the DAG is deferred to LP-209 (Mysticeti). This LP defines only the DAG construction surface — schema IDs 0xE0..0xE1 (DAGHeader, DAGBody), header/body wire format, parent-hash linking, garbage collection — so that the leaderless mempool is decoupled from the consensus that orders it.
Turn the LP-208 header DAG into a total-ordered sequence of blocks for execution. Leader-anchored waves; causal sort within wave; lexicographic tiebreak; LP-217 cert ceremony per wave. 2-RTT to finality under <33% byzantine; 3-RTT under <50%.
Within each LP-209 committed wave, execute N txs in N goroutines via optimistic STM over ZapDB MVCC snapshots. Read/write-set tracking; commit-phase conflict detection; per-tx rollback; re-execution in dependency order. Speedup ≈ min(N cores, parallelism-in-wave).
Cross-shard 2PC via a parent-L1 QuasarCert. Per-shard LP-210 waves prepare; the coordinator collects prepare-acks; the parent-L1 wave at LP-217 mode commits all shards atomically. PQ-heavy cert (LP-217; was "Polaris" in LP-017) at parent L1 = irreversible cross-shard finality. ALL shards commit OR NONE.
A stateless verifier that downloads block headers + state proofs via Kademlia DHT and verifies arbitrary chain state without storing full state. Sub-100ms catch-up. QuasarCert (any LP-217 mode) verified locally via the P3Q precompile family.
Operator-facing naming for the QuasarCert profile selector. Replaces the LP-017 v1 codenames (Pulsar / Aurora / Polaris) with a 4-mode additive ladder (PQ-off, PQ-fast, PQ-strict, PQ-heavy) plus three pure-PQ variants. Names describe posture, not internals.
A rollup pattern where the sequencer signs each batch with a PQ threshold signature, the parent L1 verifies that signature via the P3Q precompile at EVM slot 0x012205 (a single kind-byte-dispatched verifier covering Pulsar / Corona / Magnetar PQ families), and the rollup state inherits the parent L1's QuasarCert finality. No rollup-side validator set, no fraud-proof bond for the cryptographic path, no codec hop on the sequencer-to-L1 wire. Optimistic and ZK variants share the same envelope; the difference is whether the batch carries a STARK/Groth16 proof of correct execution.
Two or more L3 rollups deployed on the same Z-Chain may atomically commit a cross-rollup transaction group via a single parent-L1 PQ-heavy cert (LP-217; was "Polaris" in LP-017). The LP-211 cross-shard 2PC pattern, applied at the rollup tier — per-rollup sequencer prepares, cross-rollup coordinator collects acks, a single Z-Chain rollup-batch-tx aggregates both prepares, the Z-Chain's QuasarCert is the cross-rollup commit anchor. ALL rollups commit OR NONE. No new wire schema family; LP-219 reuses LP-211 schema IDs at the rollup tier.
LP-218 P3Q at slot 0x012205 is the unified rollup-batch PQ verifier family with kind-byte dispatch. LP-220 specifies kinds 0x02 (Corona, Module-LWE threshold) and 0x03 (Magnetar, FIPS-205 SLH-DSA threshold) on that same slot, alongside LP-218's kind 0x01 (Pulsar / FIPS-204 ML-DSA-65 threshold). Same slot, same ABI, three primitive kinds, three independent PQ families. A PQ-heavy rollup submits one P3Q call per kind per batch for cross-family maximum security; a PQ-fast rollup submits only kind 0x01. Operator-tunable per LP-217 mode and gas budget.
A dedicated EVM precompile at slot `0x012220` for verifying strict-PQ STARK proofs built on FRI low-degree testing over the Goldilocks 64-bit prime field, with cSHAKE256 Merkle commitments and no classical-curve surface. Distinct from LP-218 P3Q (threshold signature dispatch at 0x012205): one slot for SNARK proofs, one slot for signatures, orthogonal use cases.
Single source of truth for every TypeKind byte, ShapeKind byte, ZAP schema ID, and EVM precompile slot allocated across the LP corpus. Decomplects allocations currently scattered across LP-022 / LP-073 / LP-078 / LP-181 / LP-182 / LP-186 / LP-201 / LP-208 / LP-209 / LP-210 / LP-211 / LP-214 / LP-217 / LP-218 / LP-219 / LP-220 / LP-0011 / LP-0120. Any future allocation MUST be registered here first.
Status document quantifying what (if any) original Avalanche / avalanchego / ava-labs code remains in today's luxd; the structural reasons luxd is faster and lower-memory; the optional classical-only profile that strips PQ for apples-to-apples benchmarks; and the methodology by which Lux measures wins against upstream. As of the Quasar Edition genesis (2025-12-25 16:20 PST), zero upstream code paths survive in the luxd `main` line.
Canonical adoption of Tokeny ONCHAINID (ERC-734/735) and T-REX (ERC-3643) as the Lux securities-token standard. Lux maintains brand-neutral forks tracking upstream semver, with Lux extensions delivered exclusively as overlay layers. Core interfaces remain compatible with the unmodified ERC-3643 ecosystem.