Recursive Network Architecture and Cross-Chain Interoperability
Introduces Lux's recursive network architecture, wherein the network consists of multiple parallel chains that can each host specialized applications while remaining interconnected through native cross-chain messaging.
LP-134 canonical naming (2025-12-15): This LP predates the M-Chain / F-Chain split. Per LP-134 (Lux Chain Topology), MPC ceremonies for bridge custody of external wallets (BTC, ETH, SOL, etc.) now run on M-Chain (CGGMP21, FROST, Pulsar-general). FHE compute and TFHE bootstrap-key generation run on F-Chain. The name "T-Chain" is removed entirely — teleport / cross-chain messaging is B-Chain (
bridgevm, LP-6000). Where this LP says "T-Chain MPC" / "T-Chain threshold" / "T-Chain FHE" / "T-Chain custody", read it as M-Chain (for MPC) or F-Chain (for FHE).
Normative topology + fee model: LP-0130. The chain-hierarchy diagram in this LP is a taxonomic view; LP-0130 is the normative roster (10 chains, P/X as UTXO rails, all others funding fee balances from X via ImportTx/ExportTx). Where this LP frames chains as "primary" vs "optional L1", LP-0130 supersedes with a single flat roster + fee-policy matrix.
LP-0002: Recursive Network Architecture and Cross-Chain Interoperability
Abstract
Lux Network employs a recursive network architecture where multiple specialized chains operate in parallel, each optimized for specific workloads while sharing common infrastructure for security and interoperability. This document specifies how chains are created, how they coordinate, and how cross-chain messaging enables seamless asset and data transfers.
Motivation
Single-chain architectures face fundamental scalability limits. Rather than forcing all applications to compete for the same block space, Lux enables purpose-built chains that can:
- Optimize for workload: Different consensus parameters, VMs, and gas policies per chain
- Isolate state: Application-specific chains don't bloat shared state
- Scale horizontally: Add chains as demand grows
- Customize rules: Compliance, access control, and economic models per chain
Specification
Chain Hierarchy
Lux organizes chains into a recursive structure:
┌─────────────────────────────────────────────────────────────────────┐
│ LUX NETWORK │
├─────────────────────────────────────────────────────────────────────┤
│ PRIMARY NETWORK (Required — every validator) │
│ P-Chain: Platform — Validator coordination, staking, chain mgmt │
│ Q-Chain: Quantum — Post-quantum consensus finality (BLS+PQ) │
├─────────────────────────────────────────────────────────────────────┤
│ OPTIONAL L1 CHAINS (Validator opt-in via --track-chains) │
│ C-Chain: Contract — General-purpose EVM │
│ X-Chain: Exchange — High-throughput asset transfers (DAG) │
│ D-Chain: DEX — Native CLOB + AMM orderbook │
│ Z-Chain: ZK — Zero-knowledge proof verification │
│ M-Chain: MPC — CGGMP21/FROST/Pulsar threshold signing │
│ F-Chain: FHE — Encrypted EVM + threshold-FHE decryption │
│ B-Chain: Bridge — Cross-network asset movement │
│ A-Chain: Attestation — AI verification, proof-of-inference │
├─────────────────────────────────────────────────────────────────────┤
│ L2 CHAINS (Sovereign chain networks — own validators) │
│ Require P+Q only. Q optional for non-quantum L1s. │
│ Example: a regulated securities L1 (EVM + DEX + FHE) │
├─────────────────────────────────────────────────────────────────────┤
│ L1 CHAINS (Independent networks — own consensus) │
│ Q optional for quantum safety on native consensus. │
└─────────────────────────────────────────────────────────────────────┘
See LP-0110 for the full P+Q consensus specification.
Chain Registration
New chains register with the P-Chain, which maintains:
- Validator sets per chain
- Chain metadata and configuration
- Cross-chain messaging registry
- Staking requirements
Recursive Properties
The architecture is recursive because:
- Chains can spawn chains: Application chains can deploy their own sub-chains
- Validators can validate multiple chains: Same validator set can secure multiple chains
- Messaging propagates recursively: Cross-chain messages route through the hierarchy
- Security inherits: Child chains inherit security guarantees from parent validators
Cross-Chain Messaging
Warp Protocol
Lux implements native cross-chain messaging via the Warp protocol:
Chain A P-Chain Chain B
│ │ │
│ 1. Create message │ │
│──────────────────────────> │
│ │ │
│ 2. Validators sign │ │
│ (BLS aggregation) │ │
│ │ │
│ │ 3. Message relayed │
│ │─────────────────────────>│
│ │ │
│ │ 4. Verify signature │
│ │ against validator set │
│ │ │
Key Properties:
- No external bridges or relayers required
- BLS multi-signatures for efficient verification
- Validator set from source chain is trusted authority
- Supermajority (67%+) required for message validity
Message Format
type WarpMessage struct {
SourceChainID ids.ID
Payload []byte
SourceAddress common.Address
Nonce uint64
Signature []byte // Aggregated BLS
}
Rationale
Why Recursive Architecture?
vs. Single Chain: Horizontal scaling without state bloat vs. Sharding: Simpler coordination, chains are independent vs. L2 Rollups: Native security, no data availability concerns vs. External Bridges: Trustless, protocol-native messaging
Why BLS Signatures?
BLS allows signature aggregation: n validators produce one constant-size signature. This enables efficient cross-chain verification without transmitting n individual signatures.
Backwards Compatibility
This architecture is foundational. All Lux chains follow this model.
New chains must:
- Register with P-Chain
- Publish validator set
- Implement Warp message handling
Security Considerations
Chain Isolation
Chains are isolated by default. A compromised chain cannot:
- Affect other chains' state
- Forge messages from other chains
- Access other chains' assets without proper messaging
Validator Security
Cross-chain security depends on validator honesty:
- Source chain validators must not forge messages
- 33%+ Byzantine tolerance (67% supermajority required)
- Slashing for provably malicious behavior
Message Verification
Receiving chains MUST:
- Verify signature against known validator set
- Check nonce for replay prevention
- Validate source chain ID
Implementation
Chain Manager
Location: ~/work/lux/node/chains/
Key Files:
manager.go- Chain lifecycle managementregistrant.go- Chain creation hooksnets.go- Network isolation and chain namespace
Warp Messaging
Location: ~/work/lux/node/vms/platformvm/warp/
Features:
- BLS signature aggregation across validators
- Message validation and verification
- Chain-to-chain trusted messaging
Test Cases
cd ~/work/lux/node/chains && go test -v ./...
cd ~/work/lux/node/vms/platformvm/warp && go test -v ./...
Related LPs
- LP-0: Network Architecture Overview
- LP-3600: Virtual Machine and Execution Environment
- LP-605: Validator Management
Copyright
Copyright and related rights waived via CC0.