fix: replace L2/subnet language with sovereign L1 across all docs

All Zoo, Hanzo, SPC, Pars, and Liquidity chains are sovereign L1s with their own validator sets, not L2s or rollups. Changes across 45 files: - "L2 EVM" -> "Sovereign L1 EVM" in chain docs, bridge, wallet, SDK, operator, cloud, CLI, faucet, explorer, and all reference docs - chains/evm.mdx title: "L2 EVM" -> "EVM Chains" - deploy-subnet.mdx title: "Deploy an L2" -> "Deploy a Chain" - CLI chain types: remove L2 default, L1 is now default - Post-quantum doc: update Dilithium -> ML-DSA-65 (FIPS 204), Kyber -> ML-KEM-768 (FIPS 203), SPHINCS+ -> SLH-DSA (FIPS 205), mark Phase 1+2 as Deployed, Phase 3 as In Governance Review, add Quasar triple hybrid consensus (BLS + Corona + ML-DSA), add Smart Account PQ signing via SafeMLDSASigner (ERC-1271) - plugins: "L2 EVM" alias -> "subnet-evm", fix URLs to luxfi/evm Left as-is: SafeL2 (Gnosis Safe contract name), NIST L2 (security level), L2 norm (math), Optimism/Polygon/Base (they are L2s), LP proposal titles, Go struct names, wire protocol field names.
2026-09-24 00:25:32 +00:00 · 2026-04-09 21:17:53 -07:00
parent bd55c44fa8
commit 1982a62421
45 changed files with 171 additions and 124 deletions
@@ -57,5 +57,5 @@ Lux supports multiple virtual machine implementations:
 | VM | Description | Use Case |
 |----|-------------|----------|
 | EVM | Ethereum Virtual Machine | Smart contracts |
-| L2 EVM | Customizable EVM | Enterprise apps |
+| Sovereign L1 EVM | Customizable EVM | Enterprise apps |
 | Custom VMs | Purpose-built VMs | Specialized workloads |
@@ -31,7 +31,7 @@ The Lux Bridge supports transfers between Lux Network chains and external blockc

 ## Intra-Lux Transfers (Warp)

-Transfers between Lux C-Chain and L2 chains use the native Warp messaging protocol. These are fast (sub-second) and do not require MPC signing.
+Transfers between Lux C-Chain and sovereign L1 chains use the native Warp messaging protocol. These are fast (sub-second) and do not require MPC signing.

 ## External Chain Transfers (MPC)

@@ -20,7 +20,7 @@ User ──► Bridge UI ──► Bridge API ──► MPC Nodes ──► Dest
 | Chain | Type | Assets |
 |-------|------|--------|
 | Lux C-Chain | EVM | LUX, WLUX, tokens |
-| Zoo | L2 EVM | ZOO, tokens |
-| Hanzo | L2 EVM | HANZO, tokens |
+| Zoo | Sovereign L1 EVM | ZOO, tokens |
+| Hanzo | Sovereign L1 EVM | HANZO, tokens |
 | Ethereum | EVM | ETH, ERC-20 |
 | Bitcoin | UTXO | BTC |
@@ -41,7 +41,7 @@ When HSM attestation is enabled:
 | Ethereum | 12 blocks | ~2.4 minutes |
 | Bitcoin | 3 blocks | ~30 minutes |
 | Lux C-Chain | 1 block | ~2 seconds |
-| L2 EVM | 1 block | ~2 seconds |
+| Sovereign L1 EVM | 1 block | ~2 seconds |

 ## Incident Response

@@ -1,12 +1,12 @@
 ---
-title: "L2 EVM"
-description: "Custom EVM chains with configurable gas, fees, and precompiles. Used by Zoo, Hanzo, SPC, Pars."
+title: "EVM Chains"
+description: "Sovereign L1 EVM chains with configurable gas, fees, and precompiles. Used by Zoo, Hanzo, SPC, Pars."
 icon: Code
 ---

-L2 EVM allows deploying custom EVM-compatible blockchains as Lux chains. Each L2 chain has its own gas configuration, fee structure, precompiles, and genesis state while sharing the security of the Lux validator set.
+Each sovereign L1 EVM chain has its own validator set, gas configuration, fee structure, precompiles, and genesis state while participating in the Lux Network for cross-chain messaging and shared security.

-## Deployed L2 Chains
+## Deployed Chains

 | Chain | Chain ID (Mainnet) | Chain ID (Testnet) | Chain ID (Devnet) | Explorer |
 |-------|-------------------|-------------------|-------------------|---------|
@@ -17,7 +17,7 @@ L2 EVM allows deploying custom EVM-compatible blockchains as Lux chains. Each L2

 ## RPC Endpoints

-L2 chain RPCs are accessible via the gateway using their blockchain ID:
+Chain RPCs are accessible via the gateway using their blockchain ID:

 ```
 https://api.lux.network/mainnet/ext/bc/{blockchain-id}/rpc
@@ -34,7 +34,7 @@ https://api.lux.network/mainnet/ext/bc/pars/rpc

 ## Genesis Configuration

-A L2 EVM genesis defines the initial state, fee parameters, and precompile configuration. Key fields:
+An EVM chain genesis defines the initial state, fee parameters, and precompile configuration. Key fields:

 ```json
 {
@@ -74,7 +74,7 @@ A L2 EVM genesis defines the initial state, fee parameters, and precompile confi
 | `minBlockGasCost` | 0 | Minimum gas cost charged to the block producer |
 | `maxBlockGasCost` | 1,000,000 | Maximum gas cost charged to the block producer |

-## Deploying a New L2 EVM Chain
+## Deploying a New EVM Chain

 1. Create the genesis JSON with your desired chain ID, allocations, and fee config.

@@ -95,11 +95,11 @@ luxd --track-chains=<chain-id>

 ## Standard Contract Deployments

-All L2 chains include a standard set of 20 deployed contracts: WLUX, bridged tokens, AMM (router, factory, pairs), governance, identity (DIDRegistry), treasury, LSSVM, and DeFi utilities. Contract addresses are identical across all L2 chains (deployed from nonce 0).
+All chains include a standard set of 20 deployed contracts: WLUX, bridged tokens, AMM (router, factory, pairs), governance, identity (DIDRegistry), treasury, LSSVM, and DeFi utilities. Contract addresses are identical across all chains (deployed from nonce 0).

 ## RPC API

-L2 EVM chains expose the full Ethereum JSON-RPC API, identical to the C-Chain. All `eth_*`, `net_*`, `web3_*`, and `debug_*` methods are supported.
+EVM chains expose the full Ethereum JSON-RPC API, identical to the C-Chain. All `eth_*`, `net_*`, `web3_*`, and `debug_*` methods are supported.

 ## Related LPs

@@ -17,9 +17,9 @@ Every Lux node validates these three chains. They form the backbone of the netwo
 | **P-Chain** | PlatformVM | -- | Chain (linear) | Validators, staking, chain management |
 | **X-Chain** | ExchangeVM | -- | DAG | UTXO-based asset creation and transfers |

-## L2 EVM Chains
+## Sovereign L1 EVM Chains

-Custom EVM chains deployed as chains with configurable gas, fees, and precompiles.
+Sovereign L1 EVM chains with their own validator sets, configurable gas, fees, and precompiles.

 | Chain | Chain ID (Mainnet) | Chain ID (Testnet) | Chain ID (Devnet) | Purpose |
 |-------|-------------------|-------------------|-------------------|---------|
@@ -58,7 +58,7 @@ Where `network` is `mainnet`, `testnet`, or `devnet`, and `chain` is the chain a

 ## Node Configuration

-To track an L2 chain, pass the **chain ID** (not blockchain ID) to your node:
+To track a chain, pass the **chain ID** (not blockchain ID) to your node:

 ```bash
 luxd --track-chains=<chain-id-1>,<chain-id-2>
@@ -38,9 +38,8 @@ lux chain export <name>

 | Type | Flag | Description |
 |------|------|-------------|
-| L2 (default) | `--type=l2` | L2 EVM chain validated by a subset of validators |
-| L1 | `--type=l1` | Sovereign chain with its own validator set |
-| L3 | `--type=l3` | Application-specific chain anchored to an L2 |
+| L1 (default) | `--type=l1` | Sovereign L1 chain with its own validator set |
+| L3 | `--type=l3` | Application-specific chain anchored to an L1 |

 ## Chain Configuration

@@ -62,7 +61,7 @@ When deploying, the CLI:
 3. Creates the blockchain with the genesis file
 4. Configures all nodes to track the new chain

-## Pre-deployed L2 Chains
+## Pre-deployed Chains

 | Chain | Mainnet Chain ID | Chain ID |
 |-------|-----------------|-----------|
@@ -1,6 +1,6 @@
 ---
-title: Deploy an L2
-description: Create and deploy an L2 EVM chain
+title: Deploy a Chain
+description: Create and deploy a sovereign L1 EVM chain
 icon: Layers
 ---

@@ -18,7 +18,7 @@ lux network start --testnet
 # Check that all nodes are healthy
 lux network status

-# Create a new L2 EVM chain
+# Create a new sovereign L1 EVM chain
 lux chain create mychain --evm-chain-id=12345

 # Deploy it to the running network
@@ -10,7 +10,7 @@ icon: Zap
 lux network start
 ```

-## Create an L2
+## Create a Chain

 ```bash
 lux chain create mychain --evm
@@ -13,7 +13,7 @@ A chain is an independent network with its own:

 - **Validator set** - Choose which validators participate
 - **Consensus parameters** - Tune finality speed and throughput
- **Virtual machine** - Run EVM, L2 EVM, or a fully custom VM
+- **Virtual machine** - Run EVM, Sovereign L1 EVM, or a fully custom VM
 - **Gas token** - Use LUX or a custom native token
 - **Access control** - Public or permissioned networks

@@ -21,7 +21,7 @@ A chain is an independent network with its own:
  Chains do not share state or execution with other chains. They are isolated environments that leverage the Lux Primary Network for validator coordination and security.
 </Callout>

-## Create an L2
+## Create a Chain

 ### Using the CLI

@@ -39,7 +39,7 @@ A chain is an independent network with its own:
    ```

    You will be prompted to select:
-    - **VM type**: L2 EVM (recommended), Custom
+    - **VM type**: Sovereign L1 EVM (recommended), Custom
    - **Chain ID**: A unique EVM chain identifier
    - **Gas configuration**: Fee structure and limits
    - **Airdrop**: Optional initial token distribution
@@ -68,9 +68,9 @@ A chain is an independent network with its own:
  </Step>
 </Steps>

-## L2 EVM Configuration
+## Sovereign L1 EVM Configuration

-L2 EVM is the most common VM for chains. It is a configurable fork of the Lux C-Chain EVM.
+Sovereign L1 EVM is the most common VM for chains. It is a configurable fork of the Lux C-Chain EVM.

 ### Genesis Configuration

@@ -175,7 +175,7 @@ type ChainVM interface {
 ```

 <Callout>
-  Custom VMs are powerful but require careful design. For most applications, L2 EVM with custom precompiles provides sufficient flexibility without the complexity of a fully custom VM.
+  Custom VMs are powerful but require careful design. For most applications, Sovereign L1 EVM with custom precompiles provides sufficient flexibility without the complexity of a fully custom VM.
 </Callout>

 ## Chain Architecture
@@ -315,7 +315,7 @@ Deploy your own chain with a custom gas token and fee structure.
    ```

    When prompted, configure:
-    - **VM**: L2 EVM
+    - **VM**: Sovereign L1 EVM
    - **Chain ID**: 99999 (or any unique ID)
    - **Gas token symbol**: GAME
    - **Initial supply**: 1,000,000 GAME
@@ -14,7 +14,7 @@ description: Complete reference for backend and frontend configuration
 | `CHAIN_ID` | `96369` | EVM chain ID |
 | `COIN` | `LUX` | Native currency symbol |
 | `NETWORK` | `LUX Network` | Network display name |
-| `SUBNETWORK` | `C-Chain` | L2 network name |
+| `SUBNETWORK` | `C-Chain` | Chain network name |

 ## Frontend Variables

@@ -46,7 +46,7 @@ All `explore-*.lux.network` domains point to the lux-k8s load balancer (`134.199

 ## Memory Management

-For L2 chains with small block counts, use the memory-saving environment variables from the [Indexing](/explorer/backend/indexing) page. Set container memory limit to 8Gi with `Recreate` strategy.
+For sovereign L1 chains with small block counts, use the memory-saving environment variables from the [Indexing](/explorer/backend/indexing) page. Set container memory limit to 8Gi with `Recreate` strategy.

 ## PostgreSQL Selector

@@ -37,7 +37,7 @@ The backend manages funded wallets per chain, signs and sends transactions, and

 | Feature | Description |
 |---------|-------------|
-| **Multi-Chain** | Supports C-Chain and L2 EVM chains |
+| **Multi-Chain** | Supports C-Chain and sovereign L1 EVM chains |
 | **ERC-20 Tokens** | Drips USDC, WLUX, and other test tokens |
 | **Rate Limiting** | Per-address, per-IP, and global limits |
 | **CAPTCHA** | reCAPTCHA verification to prevent bots |
@@ -47,7 +47,7 @@ spec:

 ## LuxChain

-Declares an L2 chain with VM configuration and validator assignments.
+Declares a sovereign L1 chain with VM configuration and validator assignments.

 ```yaml
 apiVersion: lux.network/v1alpha1
@@ -14,7 +14,7 @@ The operator provides 6 CRDs under the `lux.network/v1alpha1` API group:
 | CRD | Shortname | Purpose |
 |-----|-----------|---------|
 | LuxNetwork | `luxnet` | Validator cluster (StatefulSet, Services, PDB) |
-| LuxChain | `luxchain` | L2 chain deployment and tracking |
+| LuxChain | `luxchain` | Sovereign L1 chain deployment and tracking |
 | LuxIndexer | `luxidx` | Blockchain data indexer per chain |
 | LuxExplorer | `luxexp` | Block explorer frontend |
 | LuxGateway | `luxgw` | API gateway with rate limiting and routing |
@@ -28,34 +28,45 @@ Classical public-key cryptography (RSA, ECDSA, Ed25519) relies on the hardness o

 Lux Network aligns with the NIST Post-Quantum Cryptography standardization process, adopting algorithms from the finalized standard set.

-### CRYSTALS-Dilithium (ML-DSA)
+### ML-DSA-65 (FIPS 204)

-Dilithium is a **lattice-based** digital signature scheme selected as the primary NIST standard for post-quantum signatures (FIPS 204).
+ML-DSA-65 (formerly CRYSTALS-Dilithium) is a **lattice-based** digital signature scheme standardized by NIST as the primary post-quantum signature algorithm.

 - **Security basis**: Module Learning With Errors (MLWE) problem
- **Signature size**: ~2.4 KB (Dilithium2), ~3.3 KB (Dilithium3)
- **Public key size**: ~1.3 KB (Dilithium2)
+- **Security level**: NIST Level 3 (192-bit)
+- **Signature size**: ~3.3 KB
+- **Public key size**: ~1.95 KB
 - **Performance**: Fast signing and verification, suitable for blockchain throughput requirements
- **Use in Lux**: Primary signature scheme for transaction signing and validator authentication
+- **Use in Lux**: Default signature scheme for new validator keys and transaction signing

-### SPHINCS+ (SLH-DSA)
+### SLH-DSA (FIPS 205)

-SPHINCS+ is a **hash-based** signature scheme selected by NIST as a conservative alternative (FIPS 205).
+SLH-DSA (formerly SPHINCS+) is a **hash-based** signature scheme standardized by NIST as a conservative alternative.

 - **Security basis**: Security of the underlying hash function only
- **Signature size**: ~7.8 KB (SPHINCS+-128f) to ~49 KB (SPHINCS+-256s)
+- **Signature size**: ~7.8 KB (SLH-DSA-128f) to ~49 KB (SLH-DSA-256s)
 - **Public key size**: 32-64 bytes
 - **Performance**: Slower signing but very fast verification
 - **Use in Lux**: Available as a fallback signature scheme for maximum conservatism

+### ML-KEM-768 (FIPS 203)
+
+ML-KEM-768 (formerly CRYSTALS-Kyber) is a **lattice-based** key encapsulation mechanism standardized by NIST for post-quantum key exchange.
+
+- **Security basis**: Module Learning With Errors (MLWE) problem
+- **Security level**: NIST Level 3 (192-bit)
+- **Ciphertext size**: ~1.09 KB
+- **Public key size**: ~1.18 KB
+- **Use in Lux**: TLS key exchange via X25519MLKEM768 hybrid, inter-node communication
+
 ### Comparison

-| Property | CRYSTALS-Dilithium | SPHINCS+ | ECDSA (classical) |
-|----------|-------------------|----------|-------------------|
+| Property | ML-DSA-65 (FIPS 204) | SLH-DSA (FIPS 205) | ECDSA (classical) |
+|----------|---------------------|---------------------|-------------------|
 | Security assumption | Lattice (MLWE) | Hash function | Elliptic curve DLP |
 | Quantum resistant | Yes | Yes | No |
-| Signature size | ~2.4 KB | ~8-49 KB | 64 bytes |
-| Public key size | ~1.3 KB | 32-64 bytes | 33 bytes |
+| Signature size | ~3.3 KB | ~8-49 KB | 64 bytes |
+| Public key size | ~1.95 KB | 32-64 bytes | 33 bytes |
 | Sign speed | Fast | Slow | Fast |
 | Verify speed | Fast | Fast | Moderate |

@@ -65,16 +76,16 @@ Lux uses a **hybrid classical + post-quantum** strategy during the transition pe

 <Steps>
  <Step>
-    ### Phase 1: Hybrid Mode (Current)
-    Both classical (Ed25519) and post-quantum (Dilithium) signatures are supported. Validators verify both when present. This provides backward compatibility while enabling early PQ adoption.
+    ### Phase 1: Hybrid Mode -- Deployed
+    Both classical (Ed25519) and post-quantum (ML-DSA-65) signatures are supported. Validators verify both when present. This provides backward compatibility while enabling PQ adoption.
  </Step>
  <Step>
-    ### Phase 2: PQ Preferred
-    Post-quantum signatures become the default for new accounts. Classical signatures remain valid for existing accounts. Wallet software generates PQ keys by default.
+    ### Phase 2: PQ Preferred -- Deployed
+    ML-DSA-65 is the default for new validator keys. Backup keys use `age1pq` (age with ML-KEM). TLS between nodes uses X25519MLKEM768 hybrid key exchange. Classical signatures remain valid for existing accounts.
  </Step>
  <Step>
-    ### Phase 3: PQ Required
-    A governance-approved network upgrade requires all new transactions to use post-quantum signatures. Legacy accounts are given a migration window.
+    ### Phase 3: PQ Required -- In Governance Review
+    A governance-approved network upgrade will require all new transactions to use post-quantum signatures. Legacy accounts will be given a migration window. Requires network upgrade vote via LP governance.
  </Step>
 </Steps>

@@ -100,7 +111,7 @@ PQ keys require different handling:

 ```
 Classical key:    32 bytes private + 33 bytes public  = ~65 bytes
-Dilithium key:   2.5 KB private  + 1.3 KB public     = ~3.8 KB
+ML-DSA-65 key:   4.0 KB private  + 1.95 KB public    = ~5.95 KB
 ```

 Lux wallets store PQ keys alongside classical keys, with the same HD derivation structure extended to support lattice-based key generation.
@@ -110,8 +121,8 @@ Lux wallets store PQ keys alongside classical keys, with the same HD derivation
 Lux uses a PQ-aware address format that encodes the key type:

 ```
-lux1qpq...    # Post-quantum address (Dilithium)
-lux1qph...    # Post-quantum address (SPHINCS+)
+lux1qpq...    # Post-quantum address (ML-DSA-65)
+lux1qph...    # Post-quantum address (SLH-DSA)
 lux1c...      # Classical address (Ed25519)
 ```

@@ -134,6 +145,43 @@ For existing users and applications:
  </Card>
 </Cards>

+## Quasar Consensus
+
+Lux's Quasar consensus uses a **triple hybrid signature scheme** combining three independent cryptographic families:
+
+| Scheme | Family | Purpose |
+|--------|--------|---------|
+| BLS (BLS12-381) | Pairing-based | Aggregatable validator signatures for efficient block finalization |
+| Corona | Lattice-based | Post-quantum ring signatures for anonymous validator voting |
+| ML-DSA-65 | Lattice-based (FIPS 204) | Post-quantum identity binding for validator authentication |
+
+An attacker must break all three schemes simultaneously to forge a consensus vote. BLS provides efficient aggregation (reducing bandwidth), Corona provides voter privacy (preventing targeted attacks on specific validators), and ML-DSA-65 provides quantum-resistant identity authentication.
+
+## Smart Account PQ Signing
+
+EVM smart accounts (ERC-4337 / Safe) can verify post-quantum signatures on-chain via precompiles:
+
+| Precompile | Address | Purpose |
+|-----------|---------|---------|
+| `ML-DSA Verify` | `0x0b14` | Verify ML-DSA-65 signatures in Solidity |
+| `SLH-DSA Verify` | `0x0b15` | Verify SLH-DSA signatures in Solidity |
+| `Corona Verify` | `0x0b16` | Verify Corona ring signatures in Solidity |
+
+The `SafeMLDSASigner` module implements ERC-1271 signature verification using ML-DSA-65, allowing Safe multisig wallets to authorize transactions with post-quantum keys. This works on the C-Chain and all sovereign L1 EVM chains with PQ precompiles enabled.
+
+```solidity
+// Safe module: verify ML-DSA-65 via precompile
+function isValidSignature(bytes32 hash, bytes memory signature)
+    external view returns (bytes4)
+{
+    (bool ok, bytes memory result) = ML_DSA_PRECOMPILE.staticcall(
+        abi.encode(ownerPQKey, hash, signature)
+    );
+    require(ok && abi.decode(result, (bool)), "PQ sig invalid");
+    return 0x1626ba7e; // ERC-1271 magic value
+}
+```
+
 ## Further Reading

 - [Architecture](/architecture) - How PQ cryptography integrates with each chain
@@ -92,7 +92,7 @@ description: "Comprehensive reference documentation for all 31 Lux skills — de
    Hardware acceleration for Lux — GPU compute, FPGA support, Rust crypto acceleration, and ZeroMQ integration.
  
  - [Lux EVM - Unified Go Execution Engine](/reference/lux-evm)
-    Lux EVM is the unified Go-based EVM execution engine for both C-Chain and L1/L2 L2 EVM chains.
+    Lux EVM is the unified Go-based EVM execution engine for both C-Chain and sovereign L1 EVM chains.
  
  - [Lux FHE - Fully Homomorphic Encryption](/reference/lux-fhe)
  
@@ -26,7 +26,7 @@ description: "Developer Toolchain for Blockchain Development"
 |---------|---------|---------|
 | `luxfi/sdk` | v1.16.46 | Lux SDK (wallet, API, tx building) |
 | `luxfi/node` | v1.23.21 | Node binary management |
-| `luxfi/evm` | v0.8.35 | EVM/L2 EVM configuration |
+| `luxfi/evm` | v0.8.35 | EVM/Sovereign L1 EVM configuration |
 | `luxfi/coreth` | v1.21.48 | C-Chain coreth dependency |
 | `luxfi/netrunner` | v1.15.7 | Local network runner |
 | `luxfi/genesis` | v1.6.1 | Genesis configuration |
@@ -48,7 +48,7 @@ description: "Developer Toolchain for Blockchain Development"
 ```
 lux
  chain          Blockchain lifecycle (create/deploy/list/describe/delete/import)
-    create       Create new blockchain configuration (L1/L2/L3)
+    create       Create new blockchain configuration (L1/L3)
    deploy       Deploy to local/testnet/mainnet
    list         List all configured blockchains
    describe     Show detailed blockchain information
@@ -27,7 +27,7 @@ Lux Deploy (`github.com/luxfi/deploy`) is the production deployment system for L

  cmd/
    deploy-chains/
-      main.go            # Go tool for P-L2 chain/blockchain creation
+      main.go            # Go tool for P-Chain chain/blockchain creation
      go.mod             # Module: github.com/luxfi/deploy-chains
      go.sum
      deploy-chains     # Compiled binary
@@ -59,7 +59,7 @@ Lux Deploy (`github.com/luxfi/deploy`) is the production deployment system for L
 1. **Configuration Layer** -- Environment variables, network/chain configs
 2. **Plugin Layer** -- EVM plugin installation and VMID mapping
 3. **Network Layer** -- 5-node validator bootstrap, port management, health monitoring
-4. **Chain Layer** -- Chain/L2 deployment, genesis configuration
+4. **Chain Layer** -- Sovereign L1 deployment, genesis configuration
 5. **Data Layer** -- RLP block import, progress monitoring, state verification
 6. **Persistence Layer** -- Snapshot creation, restoration, archival

@@ -225,9 +225,9 @@ LUX_MNEMONIC="word1 word2 ..." ./deploy-chains \
 | `github.com/luxfi/consensus` | v1.22.62 | Consensus types (indirect) |
 | `github.com/luxfi/geth` | v1.16.73 | Ethereum types (indirect) |

-### L2 EVM VMID
+### Sovereign L1 EVM VMID

-`ag3GReYPNuSR17rUP8acMdZipQBikdXNRKDyFszAysmy3vDXE` (used for all L2 chains)
+`ag3GReYPNuSR17rUP8acMdZipQBikdXNRKDyFszAysmy3vDXE` (used for all sovereign L1 chains)

 ## Shell Library (lib/)

@@ -5,7 +5,7 @@ description: "Official Docs Site"

 ## Overview

-Official Lux Network documentation platform hosted at `docs.lux.network`. Built as a Turborepo monorepo with 13 independent documentation apps, each powered by Next.js and the `@hanzo/docs` framework. Covers the full Lux ecosystem: node operation, consensus, SDK usage, contract deployment, chain/L2 architecture, and every major subsystem (bridge, explorer, wallet, HSM, MPC, bootnode, KMS, indexer, netrunner, CLI).
+Official Lux Network documentation platform hosted at `docs.lux.network`. Built as a Turborepo monorepo with 13 independent documentation apps, each powered by Next.js and the `@hanzo/docs` framework. Covers the full Lux ecosystem: node operation, consensus, SDK usage, contract deployment, sovereign L1 chain architecture, and every major subsystem (bridge, explorer, wallet, HSM, MPC, bootnode, KMS, indexer, netrunner, CLI).

 ## Repository

@@ -5,7 +5,7 @@ description: "Unified Go EVM Execution Engine"

 ## Overview

-Lux EVM (`github.com/luxfi/evm`) is the unified Go-based EVM execution engine for the Lux Network. It powers both the C-Chain (the primary EVM-compatible chain on the Lux primary network) and all Chain/L1/L2 EVM chains. The former `coreth` codebase was **merged into this repo** -- `github.com/luxfi/coreth` is deprecated and no longer maintained separately.
+Lux EVM (`github.com/luxfi/evm`) is the unified Go-based EVM execution engine for the Lux Network. It powers both the C-Chain (the primary EVM-compatible chain on the Lux primary network) and all sovereign L1 EVM chains. The former `coreth` codebase was **merged into this repo** -- `github.com/luxfi/coreth` is deprecated and no longer maintained separately.

 The EVM runs as a **plugin binary** loaded by `luxd` (the Lux node). The binary is built from `plugin/main.go` and communicates with the node via the `rpcchainvm` gRPC interface. It is not a standalone process -- it requires `luxd` to operate.

@@ -29,7 +29,7 @@ The EVM runs as a **plugin binary** loaded by `luxd` (the Lux node). The binary
 - Building custom stateful precompiles for EVM chains
 - Integrating with C-Chain via JSON-RPC or WebSocket
 - Cross-chain messaging between EVM chains using Warp
- Running a custom L2 EVM with configurable fees, gas limits, and precompiles
+- Running a custom sovereign L1 EVM with configurable fees, gas limits, and precompiles
 - Migrating from `coreth` to the unified EVM module

 ### Hard Requirements
@@ -84,9 +84,9 @@ The default mode when running as part of the Lux primary network:
 - **Chain ID**: 96369 (mainnet), 96368 (testnet), 96370 (devnet)
 - **Warp address**: Legacy `0x0200000000000000000000000000000000000005` (also accessible at `0x16201`)

-### L2 EVM Mode (L1/L2 Chains)
+### Sovereign L1 EVM Mode

-When deployed as a chain/L1/L2 chain:
+When deployed as a sovereign L1 chain:

 - **Configurable fees** via FeeManager precompile or genesis JSON
 - **Configurable gas limits** and block gas costs
@@ -100,7 +100,7 @@ Backend, DB, frontend, NFT media handler, Nginx, Redis, sig-provider, smart-cont

 ### RPC Integration

-The `EthereumJSONRPC` app connects to Lux nodes via L2 EVM-compatible endpoints:
+The `EthereumJSONRPC` app connects to Lux nodes via EVM-compatible endpoints:

 ```
 ETHEREUM_JSONRPC_HTTP_URL = http://<luxd>:9650/ext/bc/<blockchain-id>/rpc
@@ -108,7 +108,7 @@ ETHEREUM_JSONRPC_WS_URL   = ws://<luxd>:9650/ext/bc/<blockchain-id>/ws
 ETHEREUM_JSONRPC_VARIANT  = geth
 ```

-Each Lux L2 chain has a unique blockchain ID (e.g., `dnmzhuf6poM6PUNQCe7MWWfBdTJEnddhHRNXz2x7H6qSmyBEJ` for LUX mainnet C-Chain).
+Each Lux chain has a unique blockchain ID (e.g., `dnmzhuf6poM6PUNQCe7MWWfBdTJEnddhHRNXz2x7H6qSmyBEJ` for LUX mainnet C-Chain).

 ### Branding

@@ -152,7 +152,7 @@ Dependencies: `gorilla/mux` 1.8.1, `gorilla/websocket` 1.5.4, `lib/pq` 1.11.2.
 - Elixir 1.19+, Erlang/OTP 27+
 - PostgreSQL 14+
 - Node.js 16+ (for frontend)
- Running Lux node (luxd) with L2 EVM
+- Running Lux node (luxd) with EVM

 ### Build

@@ -182,4 +182,4 @@ The `REVERSE_PROXIES` setting in `GLOBAL_RL` controls how many trusted proxies t

 - `lux/lux-cli.md` -- CLI for network management
 - `lux/lux-node.md` -- Validator nodes (provide RPC endpoints)
- `lux/lux-evm.md` -- C-Chain and L2 EVM execution
+- `lux/lux-evm.md` -- C-Chain and sovereign L1 EVM execution
@@ -5,7 +5,7 @@ description: "Documentation for Lux Genesis"

 ## Overview

-`github.com/luxfi/genesis` is a Go module that provides canonical genesis configurations for all Lux blockchain networks. It contains embedded genesis JSON for mainnet, testnet, devnet, and local/custom networks, along with CLI tools for generating, extracting, and validating genesis state. The package supports the primary C-Chain (EVM), P-Chain (Platform), X-Chain (Exchange), and L2 chains (Zoo, SPC, Hanzo, Pars).
+`github.com/luxfi/genesis` is a Go module that provides canonical genesis configurations for all Lux blockchain networks. It contains embedded genesis JSON for mainnet, testnet, devnet, and local/custom networks, along with CLI tools for generating, extracting, and validating genesis state. The package supports the primary C-Chain (EVM), P-Chain (Platform), X-Chain (Exchange), and sovereign L1 chains (Zoo, SPC, Hanzo, Pars).

 ## When to use

@@ -91,7 +91,7 @@ genesis -genesis-dir ./mainnet -output primary.json
 | Devnet | 3 | 96370 | Fast iteration dev network |
 | Local/Custom | 1337 | 1337 | Local development |

-### L2 Chains
+### Sovereign L1 Chains

 | Chain | Mainnet ID | Testnet ID | Devnet ID | Treasury |
 |-------|-----------|-----------|-----------|----------|
@@ -131,7 +131,7 @@ genesis/
    pars-mainnet/        # Pars chain genesis
    ...                  # testnet/devnet variants for each chain
  builder/               # Genesis builder with tests
-  chains/                # L2 chain definitions (ai, spc, zoo)
+  chains/                # Sovereign L1 chain definitions (ai, spc, zoo)
  mainnet/               # Production genesis exports
  testnet/               # Test network genesis exports
  keys/mainnet/          # Mainnet key material
@@ -69,7 +69,7 @@ Uses `github.com/luxfi/indexer/evm` -- full EVM block/transaction indexing with

 ### EVM Multi-Chain Process (`evmchains`)

-A single-process server that indexes all 5 Lux mainnet EVM L2 chains concurrently, sharing one PostgreSQL database with table prefixes. Configured via `configs/evmchains.yaml`.
+A single-process server that indexes all 5 Lux mainnet EVM chains concurrently, sharing one PostgreSQL database with table prefixes. Configured via `configs/evmchains.yaml`.

 | Slug | Name | Chain ID | Port |
 |------|------|----------|------|
@@ -5,11 +5,11 @@ description: "Documentation for Lux Migrate - Blockchain Data Migration Framewor

 ## Overview

-Lux Migrate is a **generic blockchain data migration framework** for importing and exporting block data, state, and accounts between Lux VM implementations. It defines Exporter, Importer, and Migrator interfaces with implementations for L2 EVM (PebbleDB), C-Chain (BadgerDB + RPC), and other Lux chain types. JSONL is the canonical intermediate format.
+Lux Migrate is a **generic blockchain data migration framework** for importing and exporting block data, state, and accounts between Lux VM implementations. It defines Exporter, Importer, and Migrator interfaces with implementations for Sovereign L1 EVM (PebbleDB), C-Chain (BadgerDB + RPC), and other Lux chain types. JSONL is the canonical intermediate format.

 ## When to use

- Migrating blockchain data between L2 EVM and C-Chain
+- Migrating blockchain data between Sovereign L1 EVM and C-Chain
 - Exporting blocks or state from PebbleDB/BadgerDB/LevelDB
 - Importing blocks via the `migrate_importBlocks` RPC API
 - Converting genesis files to JSONL for block import
@@ -41,7 +41,7 @@ migrate/
  pchain/             # Platform chain support (stub)
  xchain/             # Exchange chain support (stub)
  qchain/             # Quantum chain support (stub)
-  zool2/              # Zoo L2 chain support (stub)
+  zool1/              # Zoo L1 chain support (stub)
  jsonl/              # JSONL streaming format (reader/writer)
  rpcapi/             # RPC API type definitions
  cmd/                # CLI tools (20 commands)
@@ -79,12 +79,12 @@ type Migrator interface {

 | VM Type | Export | Import | Database |
 |---------|--------|--------|----------|
-| `L2 EVM` | Implemented | Stub | PebbleDB |
+| `subnet-evm` | Implemented | Stub | PebbleDB |
 | `c-chain` | Stub | Implemented | BadgerDB + RPC |
 | `p-chain` | Stub | Stub | - |
 | `x-chain` | Stub | Stub | - |
 | `q-chain` | Stub | Stub | - |
-| `zoo-l2` | Stub | Stub | - |
+| `zoo-l1` | Stub | Stub | - |

 ## CLI tools

@@ -121,7 +121,7 @@ cd migrate
 go build -o bin/export ./cmd/export/
 go build -o bin/import-rpc ./cmd/import-rpc/

-# Export from L2 EVM PebbleDB
+# Export from Sovereign L1 EVM PebbleDB
 ./bin/export \
  -db /path/to/pebbledb \
  -output blocks.jsonl \
@@ -178,5 +178,5 @@ go build -o bin/import-jsonl ./cmd/import-jsonl/
 ## Related Skills

 - `lux/lux-node.md` -- Node that hosts the migrate_importBlocks API
- `lux/lux-evm.md` -- L2 EVM with MigrateAPI endpoint
+- `lux/lux-evm.md` -- EVM with MigrateAPI endpoint
 - `lux/lux-cli.md` -- CLI integration for `lux network export/import data`
@@ -7,7 +7,7 @@ description: "Multi-Engine Network Orchestrator"

 Lux Netrunner is a **multi-engine network orchestration and testing tool** for the Lux blockchain. It manages local multi-node validator networks via a gRPC/REST control plane, supports heterogeneous consensus engines (Lux, Geth, OP Stack, Eth2), and provides snapshot-based state management with incremental BadgerDB backups.

-Not just a test runner -- Netrunner orchestrates full L1/L2/L3 stacks with cross-chain bridging, multi-network management with shared BadgerDB for cross-chain ACID transactions, and YAML-based stack manifests for reproducible environments.
+Not just a test runner -- Netrunner orchestrates full L1/L3 stacks with cross-chain bridging, multi-network management with shared BadgerDB for cross-chain ACID transactions, and YAML-based stack manifests for reproducible environments.

 ## Quick Reference

@@ -65,7 +65,7 @@ Lux Node (`luxd`) is the core validator node for the Lux Network -- a multi-chai

 - Running a Lux mainnet/testnet/devnet validator
 - Building custom Virtual Machines (VMs) for the Lux ecosystem
- Developing chain/L1/L2/L3 chains on the Lux network
+- Developing sovereign L1/L3 chains on the Lux network
 - Cross-chain messaging via LP-118 Warp protocol
 - Post-quantum secure blockchain operations
 - AI compute attestation and decentralized inference
@@ -50,7 +50,7 @@ type Config struct {
    Validators    validators.Manager

    // SequencerIDForChain returns the validator-set identity that sequences chainID
-    // Examples: C-Chain -> PrimaryNetworkID, Zoo L2 -> ZooChainID
+    // Examples: C-Chain -> PrimaryNetworkID, Zoo L1 -> ZooChainID
    SequencerIDForChain func(chainID ids.ID) ids.ID

    GenesisBytes         []byte
@@ -160,7 +160,7 @@ cd fhe && make
 ## Key Themes Across Papers

 - **Post-quantum readiness**: Multiple papers address quantum resistance (ETHFALCON, Quasar, universal threshold sigs, quantum consensus)
- **Multi-chain architecture**: Papers define how chains/L2s interact (warp messaging, interchain transfers, bridge)
+- **Multi-chain architecture**: Papers define how sovereign L1 chains interact (warp messaging, interchain transfers, bridge)
 - **Application-specific chains**: Dedicated chain designs for specific workloads (AI compute, MPC custody, privacy, GraphQL)
 - **Privacy**: Z-Chain ZK proofs, privacy pools, FHE for computation privacy
 - **Economic sustainability**: Tokenomics, validator economics, appchain incentive design
@@ -26,7 +26,7 @@ plugins-core/
  vms/                   -- VM definitions (one YAML per VM)
    blobvm.yaml              Content-addressable KV store VM
    spacesvm.yaml            Hierarchical storage VM
-    L2 EVM.yaml          L2 EVM (Solidity smart contracts)
+    subnet-evm.yaml          Sovereign L1 EVM (Solidity smart contracts)
  chains/               -- Chain definitions (one YAML per chain)
    spaces.yaml              Spaces Chain Demo (SpacesVM)
    wagmi.yaml               Zoo EVM Demo (high-throughput testbed)
@@ -71,21 +71,21 @@ BlobVM provides a content-addressable key-value store chain. Keys are derived fr

 SpacesVM provides authenticated, hierarchical key-value storage using any EIP-712 compatible wallet. It powers the Spaces chain where users can claim hierarchical namespaces (like DNS) and store arbitrary key/value data under them.

-### L2 EVM
+### Sovereign L1 EVM (subnet-evm)

 | Field | Value |
 |-------|-------|
-| Alias | `L2 EVM` |
+| Alias | `subnet-evm` |
 | VM ID | `srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy` |
 | Version | 0.2.7 |
-| Homepage | `https://github.com/luxdefi/L2 EVM` |
-| Description | L2 EVM -- simplified Coreth VM for Chain Contract Chains with full Ethereum Virtual Machine and Solidity smart contract support |
+| Homepage | `https://github.com/luxfi/evm` |
+| Description | Sovereign L1 EVM -- simplified Coreth VM for sovereign L1 chains with full Ethereum Virtual Machine and Solidity smart contract support |
 | Install Script | `scripts/build.sh build/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy` |
 | Binary Path | `build/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy` |
-| Release URL | `https://github.com/luxdefi/L2 EVM/archive/refs/tags/v0.2.7.tar.gz` |
+| Release URL | `https://github.com/luxfi/evm/archive/refs/tags/v0.2.7.tar.gz` |
 | SHA256 | `c0d63b56031820007cce5fa8ea635628b8b9a5897111290a78b60538838509f8` |

-L2 EVM is the primary VM for creating new EVM-compatible blockchains on Lux. It is a simplified version of Coreth (C-Chain VM), parameterizable for different throughput and gas configurations.
+Sovereign L1 EVM is the primary VM for creating new EVM-compatible blockchains on Lux. It is a simplified version of Coreth (C-Chain VM), parameterizable for different throughput and gas configurations.

 ## Registered Chains

@@ -121,7 +121,7 @@ validatorOnly: false             -- Open to non-validators
 | Alias | `wagmi` |
 | Chain ID | `28nrH5T2BMvNrWecFcV3mfccjs6axM1TVyqe79MCv2Mhs8kxiY` |
 | Homepage | `https://github.com/luxfi/evm` |
-| VM | `evm` (Coreth/L2 EVM) |
+| VM | `evm` (Coreth/Sovereign L1 EVM) |
 | Description | High-throughput testbed for EVM optimizations, parameterized to run at higher capacity than mainnet C-Chain |
 | Maintainer | `[email protected]` |

@@ -249,7 +249,7 @@ VM binaries must be named with their base58-encoded VM ID. The Lux node discover
 ```
 ~/.lux/plugins/kM6h4LYe3AcEU1MB2UNg6ubzAiDAALZzpVrbX8zn3hXF6Avd8   # BlobVM
 ~/.lux/plugins/sqja3uK17MJxfC7AN8nGadBw9JK5BcrsNwNynsqP5Gih8M5Bm   # SpacesVM
-~/.lux/plugins/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy   # L2 EVM
+~/.lux/plugins/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy   # Sovereign L1 EVM
 ```

 ## Usage with LPM
@@ -264,10 +264,10 @@ lpm list-vms
 # Install a VM by alias
 lpm install --vm blobvm
 lpm install --vm spacesvm
-lpm install --vm L2 EVM
+lpm install --vm subnet-evm

 # Update a VM to latest version
-lpm update --vm L2 EVM
+lpm update --vm subnet-evm

 # Install a chain (installs all referenced VMs)
 lpm install --chain spaces
@@ -327,6 +327,6 @@ These parameters control Snow consensus behavior for chains:
 ## Related Skills

 - `lux/lux-node.md` -- Core node that loads and runs VM plugins
- `lux/lux-evm.md` -- L2 EVM execution engine
+- `lux/lux-evm.md` -- Sovereign L1 EVM execution engine
 - `lux/lux-spacesvm.md` -- SpacesVM storage chain
 - `lux/lux-cli.md` -- CLI for chain creation and management
@@ -77,7 +77,7 @@ Lux SDK is the **official Go SDK** for building and managing Lux networks. It pr

 | Package | Import | Purpose |
 |---------|--------|---------|
-| `blockchain` | `.../sdk/blockchain` | `Builder` -- `CreateBlockchain()`, `Deploy()`. Types: `BlockchainType` (L1/L2/L3), `VMType` (evm/wasm/custom/tokenvm/morpheusvm), `Blockchain`, `Net`, `GenesisAccount`, `GenesisValidator` |
+| `blockchain` | `.../sdk/blockchain` | `Builder` -- `CreateBlockchain()`, `Deploy()`. Types: `BlockchainType` (L1/L3), `VMType` (evm/wasm/custom/tokenvm/morpheusvm), `Blockchain`, `Net`, `GenesisAccount`, `GenesisValidator` |
 | `chainconfig` | `.../sdk/chainconfig` | Chain config and genesis generation/parsing |
 | `configspec` | `.../sdk/configspec` | Configuration specification utilities |
 | `fees` | `.../sdk/fees` | Fee configuration |
@@ -9,7 +9,7 @@ Lux Standard (`github.com/luxfi/standard`) is the official Solidity smart contra

 ### Why

-Lux Standard is the canonical contract library for building on Lux C-Chain and L2 chains (Zoo, Hanzo/AI, SPC, Pars). It provides Lux-native naming (LRC20 instead of ERC20), native bridge token support (LRC20B), post-quantum signer modules for Safe wallets, FHE-encrypted token balances and governance via T-Chain, and unified deployment scripts for all Lux ecosystem chains. Every DeFi primitive needed to build on Lux is here in one audited monorepo.
+Lux Standard is the canonical contract library for building on Lux C-Chain and sovereign L1 chains (Zoo, Hanzo/AI, SPC, Pars). It provides Lux-native naming (LRC20 instead of ERC20), native bridge token support (LRC20B), post-quantum signer modules for Safe wallets, FHE-encrypted token balances and governance via T-Chain, and unified deployment scripts for all Lux ecosystem chains. Every DeFi primitive needed to build on Lux is here in one audited monorepo.

 ### Tech Stack

@@ -38,7 +38,7 @@ Lux Standard is the canonical contract library for building on Lux C-Chain and L

 ## When to use

- Building any token (fungible, NFT, multi-token) on Lux C-Chain or L2 chains
+- Building any token (fungible, NFT, multi-token) on Lux C-Chain or sovereign L1 chains
 - Deploying DeFi protocols (AMM, lending, perpetuals, liquid staking) on Lux
 - Implementing cross-chain bridges using Lux Warp messaging
 - Creating DAO governance with on-chain voting and timelocks
@@ -13,7 +13,7 @@ All Lux chains expose JSON-RPC APIs. The SDK wraps these APIs with typed clients
 | P-Chain | `/ext/bc/P` | Validators, chains, staking, delegations |
 | X-Chain | `/ext/bc/X` | UTXO operations, asset creation and transfer |
 | C-Chain | `/ext/bc/C/rpc` | EVM JSON-RPC (eth, net, web3 namespaces) |
-| L2 EVM | `/ext/bc/{name}/rpc` | Same as C-Chain, per-chain endpoint |
+| Sovereign L1 EVM | `/ext/bc/{name}/rpc` | Same as C-Chain, per-chain endpoint |
 | Info | `/ext/info` | Node info, network ID, node ID |
 | Health | `/ext/health` | Node and chain health status |
 | Admin | `/ext/admin` | Node administration (whitelisted) |
@@ -3,7 +3,7 @@ title: RPC Operations
 description: JSON-RPC calls to Lux nodes using the Go SDK
 ---

-The Go SDK provides typed wrappers around all Lux node JSON-RPC endpoints. Each chain type (P, X, C, L2 EVM) has its own client.
+The Go SDK provides typed wrappers around all Lux node JSON-RPC endpoints. Each chain type (P, X, C, Sovereign L1 EVM) has its own client.

 ## C-Chain (EVM) RPC

@@ -79,9 +79,9 @@ asset, err := client.GetAssetDescription(
 )
 ```

-## L2 EVM RPC
+## Sovereign L1 EVM RPC

-L2 EVM chains use the same `ethclient` interface with a different endpoint:
+Sovereign L1 EVM chains use the same `ethclient` interface with a different endpoint:

 ```go
 // Zoo chain RPC
@@ -22,7 +22,7 @@ Client libraries for interacting with all Lux chain types. Each SDK provides wal
 | P-Chain transactions | Yes | Yes | Read-only |
 | X-Chain UTXO operations | Yes | Yes | Read-only |
 | C-Chain EVM | Yes | Yes | Yes |
-| L2 EVM | Yes | Yes | Yes |
+| Sovereign L1 EVM | Yes | Yes | Yes |
 | HD wallet (BIP-44) | Yes | Yes | Yes |
 | Key generation | Yes | Yes | Yes |
 | Network management | Yes | No | No |
@@ -5,7 +5,7 @@ index: true
 icon: FileCode
 ---

-The Python SDK (`luxfi-sdk`) provides a high-level interface for interacting with Lux Network from Python applications. It supports C-Chain and L2 EVM chains via Web3.py, with convenience wrappers for common operations.
+The Python SDK (`luxfi-sdk`) provides a high-level interface for interacting with Lux Network from Python applications. It supports C-Chain and sovereign L1 EVM chains via Web3.py, with convenience wrappers for common operations.

 ## Installation

@@ -52,7 +52,7 @@ print(f"Balance: {balance} wei")
 | Chain | RPC | Transactions | Contracts |
 |-------|-----|-------------|-----------|
 | C-Chain | Yes | Yes | Yes |
-| L2 EVM (Zoo, Hanzo, SPC, Pars) | Yes | Yes | Yes |
+| Sovereign L1 EVM (Zoo, Hanzo, SPC, Pars) | Yes | Yes | Yes |
 | P-Chain | Read-only | No | N/A |
 | X-Chain | Read-only | No | N/A |

@@ -29,9 +29,9 @@ gas_price = w3.eth.gas_price
 print(f"Gas price: {gas_price} wei")
 ```

-## L2 EVM RPC
+## Sovereign L1 EVM RPC

-Connect to any L2 EVM chain by changing the endpoint:
+Connect to any sovereign L1 EVM chain by changing the endpoint:

 ```python
 # Zoo chain
@@ -86,7 +86,7 @@ tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)

 ## Chain Transactions

-Same patterns work on any L2 EVM chain -- just change the provider URL and chain ID:
+Same patterns work on any sovereign L1 EVM chain -- just change the provider URL and chain ID:

 ```python
 # Zoo chain (chain ID 200200)
@@ -53,7 +53,7 @@ console.log("Balance:", balance, "wei");
 | P-Chain | Yes | Yes | N/A |
 | X-Chain | Yes | Yes | N/A |
 | C-Chain | Yes | Yes | Yes |
-| L2 EVM | Yes | Yes | Yes |
+| Sovereign L1 EVM | Yes | Yes | Yes |

 ## Framework Integration

@@ -68,9 +68,9 @@ const { result } = await response.json();
 console.log("Validators:", result.validators.length);
 ```

-## L2 EVM RPC
+## Sovereign L1 EVM RPC

-All L2 EVM chains use the same interface -- change the endpoint URL:
+All sovereign L1 EVM chains use the same interface -- change the endpoint URL:

 ```typescript
 // Zoo chain
@@ -13,10 +13,10 @@ The Lux wallet supports all chain types in the Lux Network. Each chain type uses
 | P-Chain | Platform | Bech32 (`P-lux1...`) | Custom | 6 |
 | X-Chain | Exchange | Bech32 (`X-lux1...`) | UTXO | 6 |
 | C-Chain | Contract | Hex (`0x...`) | EVM | 18 |
-| Zoo | L2 EVM | Hex (`0x...`) | EVM | 18 |
-| Hanzo | L2 EVM | Hex (`0x...`) | EVM | 18 |
-| SPC | L2 EVM | Hex (`0x...`) | EVM | 18 |
-| Pars | L2 EVM | Hex (`0x...`) | EVM | 18 |
+| Zoo | Sovereign L1 EVM | Hex (`0x...`) | EVM | 18 |
+| Hanzo | Sovereign L1 EVM | Hex (`0x...`) | EVM | 18 |
+| SPC | Sovereign L1 EVM | Hex (`0x...`) | EVM | 18 |
+| Pars | Sovereign L1 EVM | Hex (`0x...`) | EVM | 18 |

 ## P-Chain Operations

@@ -60,6 +60,6 @@ X-Chain -> export -> C-Chain -> import

 Each cross-chain transfer requires two transactions: an export on the source chain and an import on the destination chain.

-## L2 EVM Chains
+## Sovereign L1 EVM Chains

-All L2 EVM chains (Zoo, Hanzo, SPC, Pars) use the same EVM interface as the C-Chain. The only difference is the RPC endpoint URL and chain ID.
+All sovereign L1 EVM chains (Zoo, Hanzo, SPC, Pars) use the same EVM interface as the C-Chain. The only difference is the RPC endpoint URL and chain ID.
@@ -83,7 +83,7 @@ X-Chain -> C-Chain: export from X, import to C
 | P-Chain | Fixed | 0.001 LUX |
 | X-Chain | Fixed | 0.001 LUX |
 | C-Chain | EIP-1559 dynamic | Variable (gas price * gas used) |
-| L2 EVM | EIP-1559 dynamic | Variable |
+| Sovereign L1 EVM | EIP-1559 dynamic | Variable |

 ## Transaction Types