Lux Network Architecture

Lux Network employs a multi-layer architecture designed for scalability, security, and flexibility.

Network Layers

P-Chain (Platform Chain)

The Platform Chain coordinates validators, tracks active chains, and enables the creation of new chains.

• Validator management and staking
• Chain creation and configuration
• Cross-chain messaging coordination

X-Chain (UTXO Chain)

The UTXO Chain is a high-throughput chain for asset creation and transfer using a UTXO model.

• Native asset creation (NFTs, tokens)
• Fast asset transfers
• Low-latency trading operations

C-Chain (Contract Chain)

The Contract Chain is an EVM-compatible chain for smart contracts.

• Full Solidity support
• Ethereum tooling compatibility
• Sub-second finality

Chain Architecture

Chains are sovereign networks that define their own:

• Validator requirements
• Consensus parameters
• Virtual machine implementations

┌─────────────────────────────────────────┐
│              Primary Network             │
│  ┌─────────┬─────────┬─────────┐       │
│  │ P-Chain │ X-Chain │ C-Chain │       │
│  └─────────┴─────────┴─────────┘       │
└─────────────────────────────────────────┘
        │           │           │
   ┌────┴───┐  ┌────┴───┐  ┌────┴───┐
   │Chain A│  │Chain B│  │Chain C│
   └────────┘  └────────┘  └────────┘

Virtual Machines

Lux supports multiple virtual machine implementations:

Post-Quantum Security Architecture

Lux's security model is decomplected — one dealerless post-quantum threshold core, with custody capabilities added as orthogonal, optional extensions. The core depends on none of the extensions.

                  ┌──────────────────────────────────────────┐
                  │   Dealerless PQ-threshold consensus core  │
                  │   luxfi/consensus · pulsar · corona       │
                  │   (Quasar compact-cert finality)          │
                  └──────────────────────────────────────────┘
                       ▲                 ▲                ▲
        optional ──────┘        optional ┘       depends on (one-way)
   ┌─────────────────┐   ┌─────────────────┐   ┌────────────────────────┐
   │   luxfi/mpc     │   │   luxfi/tee     │   │   luxfi/cc (attest)    │
   │  MPC custody    │   │  TEE custody    │   │  one attestation       │
   │  (CGGMP21/FROST)│   │  (attested      │   │  verifier, orthogonal  │
   │                 │   │   enclave)      │   │  hardware Kinds        │
   └─────────────────┘   └─────────────────┘   └────────────────────────┘

One core, optional extensions

• Consensus core — Quasar finality is a compact-certificate envelope built on two dealerless-capable PQ threshold kernels: Pulsar (Module-LWE, FIPS-204 ML-DSA) and Corona (Ring-LWE, Ringtail). Corona's natively-dealerless Pedersen DKG carries the permissionless-public guarantee. The core needs no TEE and no external MPC vendor. See Consensus.
• luxfi/mpc (v1.16.0) — optional MPC custody for bridge/institutional signing (CGGMP21 for ECDSA, FROST for Schnorr/EdDSA). The consensus core does not depend on it. See MPC and Wallet Security.
• luxfi/tee (v0.1.0) — optional TEE-backed threshold-signing custody extension. Explicitly not required by the threshold core and not used on the permissionless/dealerless production signing path; the dependency direction is one-way (tee → pulsar/corona/mpc, never the reverse).
• luxfi/cc (v0.2.0) — one attestation verifier with orthogonal hardware Kinds, six production CPU/GPU vendors (AMD SEV-SNP, Intel TDX, Intel SGX, NVIDIA nvtrust, AWS Nitro, ARM CCA), shared by MPC custody, TEE custody, and confidential AI. It depends on none of them. See Confidential Compute.

This is the seam: the permissionless chain runs on the dealerless PQ core alone; TEE and external-MPC custody are accelerators an operator opts into, never trust assumptions baked into the open validator set.