LP-032: DEX VM

Abstract

The DEX VM runs the D-chain, a purpose-built virtual machine for Central Limit Order Book (CLOB) exchange operations. It implements a GPU-accelerated matching engine as a VM-native operation, not a smart contract. Orders are submitted as transactions and matched by the VM's built-in engine; each fill updates the D-chain book deterministically within block execution and is emitted as a BLS-signed DFillReceipt. EVM-balance settlement is not done on the D-chain — the C-Chain 0x9999 receipt-settlement precompile verifies the receipt certificate and debits/credits balances (see Settlement / EVM entry point and LP-9999). The D-chain achieves sub-millisecond order matching with throughput exceeding 100,000 orders per second.

Specification

Order Types

Matching Engine

The matching engine runs as a VM-level operation during block execution:

1. Order book: per-market price-time priority queue stored in VM state

2. Matching: GPU kernel iterates the order book and matches incoming orders against resting orders

3. Fill: matched trades update the D-chain book/ledger deterministically (no intermediate state) and emit a DFillReceipt

4. Tick size: configurable per market (e.g., 0.01 USDC for LUX/USDC)

GPU acceleration uses the CUDA/Metal kernels from LP-011 for parallel order matching across multiple markets simultaneously.

Settlement / EVM entry point

The D-chain matches and produces fills; it does not move EVM balances. Each fill

is recorded as a BLS-signed DFillReceipt (a D-validator quorum signs the receipt

root per block/batch). The C-Chain 0x9999 receipt-settlement precompile

(LP-9999) then verifies that

certificate inline — BLS aggregate verification is deterministic, so it is

consensus-safe on the EVM verify path — debits the input asset from the sender,

credits the output asset to the recipient, and marks the receipt consumed. This is

the D matches · C settles split: the matcher runs on a permissioned D-validator

subset, while the full C-Chain validator set verifies the compact receipt and

settles in parallel under Block-STM (LP-010). The

verify path never calls a live matcher, which is what keeps a single-transaction

synchronous swap fork-safe. The certificate kind is a versioned certType (BLS

day-1; Q/PQ/ZK later) resolved through an on-chain verifier registry, so the

cryptography upgrades with no ABI change. The full settlement spec — receipt

binding, halt scopes, access set, and migration from 0x9010 — is normative in

LP-9999; this VM owns matching and receipt production only.

Market Registry

Markets are registered by governance:

Market {
    marketID    uint64
    baseAsset   address    // e.g., LUX
    quoteAsset  address    // e.g., USDC
    tickSize    uint256    // minimum price increment
    lotSize     uint256    // minimum quantity increment
    makerFee    int256     // negative = rebate
    takerFee    uint256    // fee in basis points
    status      uint8      // 0=inactive, 1=active, 2=halted
}

Fee Model

• Maker rebate: -0.5 bps (makers are paid for providing liquidity)
• Taker fee: 3.0 bps
• Net protocol revenue: 2.5 bps per matched trade
• Fee distribution: 70% to staking vault, 30% to treasury

Cross-Chain Integration

The D-chain accepts assets from other Lux chains via Warp (LP-021):

1. User locks assets on C-chain

2. Warp message delivers deposit to D-chain

3. User trades on D-chain

4. User withdraws via Warp back to C-chain

Deposits and withdrawals are processed within the same block as the Warp message.

Security Considerations

1. Front-running: all orders in a block are matched deterministically by price-time priority. The block proposer cannot reorder within a price level.

2. Market manipulation: wash trading detection runs off-chain; flagged accounts can be suspended by governance.

3. Circuit breakers: markets auto-halt if price moves >10% in a single block.

Reference

Copyright

Copyright (C) 2024-2026, Lux Partners Limited. All rights reserved.

Licensed under the MIT License.