zeekayandHanzo Dev
7ca0c2c521
A TxDeposit MINTS ledger balance, but its authorization was the DEPOSITOR'S OWN signature (verifyTxSignature required signer == the body's beneficiary), and handleDeposit exposed it on the same public ZAP route as dex_place/dex_submit. So any authenticated principal could self-sign a deposit and mint unlimited unbacked balance, then withdraw it (redteam_unbacked_deposit_test proved 500B minted). OPTION B (gate to the trusted bridge authority) — chosen over Option A (route all deposits through the atomic import) because: (1) the trustless atomic import (TxImport, atomic.go) is only wired in production (runtime + shared memory) and credits a DIFFERENT account axis (crossChainAccount(C-address)) than the DEX tx-auth account (Account16) — routing all deposits through it would require wiring shared memory + reconciling account models across 17 test files; (2) tx.go:47 already documents TxDeposit as the bridge/proxy-credit path — this implements that intent correctly (the bug was the missing authority check); (3) the trustless atomic import remains UNCHANGED and available for cross-chain swaps. Both backing mechanisms now coexist: trustless import for swaps, authority-gated deposit for bridge-custodied funds. The fix: - VM gains depositAuthority (a CONSENSUS config param, vmConfig.DepositAuthority hex, decoded at Initialize). ZERO => no authority => EVERY TxDeposit rejected fail-closed (value then enters only via the backed atomic import). - authorizeTx (the authoritative consensus gate): a TxDeposit is accepted ONLY when the recovered signer == depositAuthority; else rejected (no mint, no nonce burn). - verifyTxSignature: a deposit no longer requires signer==beneficiary (the signer is the authority; the beneficiary is bound via the signed digest). Withdraw is UNCHANGED — still signer==beneficiary (a user withdraws their own funds). - submitTx: boundary pre-screen rejects a non-authority deposit before the mempool. Backing invariant enforced: Σ(ledger credits via TxDeposit) ≤ Σ(bridge-authorized deposits); combined with the import's Σ(credits) ≤ Σ(consumed C->D objects), NO path credits the ledger without backing. The authority gate also HARDENS RED #4: a stranded/self-signed deposit that lands in a later block is rejected, so it cannot mint; withdraw is untouched (debits own available, clamped — no burn). TDD: TestRedteam_UnbackedSelfSignedDepositMints now PASSES (self-signed deposit rejected at boundary + consensus; minted 0, withdrew 0). New TestBackedAuthoritySignedDepositCredits proves the legitimate authority-signed deposit credits + withdraws correctly. Test funding migrated to an authority-signed helper (fundAcct/fundTx); auth_test nonce expectations updated (a funded account's first own tx is nonce 0 — funding no longer consumes the user's nonce). ALL suites green (go test ./... -count=1), go vet clean; the F1-F5 cross-arch execRoots + ledgers still match byte-for-byte across arm64/amd64. KNOWN FOLLOW-UPS (tracked): (a) chains/dexvm + precompile/dex are separate modules that also encode the ZAP frame — they need the same exact-integer wire bump to interoperate; (b) F7 — retract the inflated 12.76B/9.13B/5.60B "ord/s" GPU benchmark numbers in ~/work/lux/papers (they measure all-cross synthetic fills/s ~71-85x inflated; the paper's own text already caps a single GPU below 10^9 fills/s). Co-authored-by: Hanzo Dev <[email protected]>
LX
Lux DEX — pure-Go matching engine, order book, oracle aggregator, and JSON-RPC / WebSocket / gRPC SDKs.
Open core
This repository is the public, pure-Go reference implementation of the Lux DEX matching engine. It is fully functional, runs standalone, and underpins every Lux DEX deployment.
For commercial deployments that need hardware acceleration (NUMA-aware
C++ order book, CUDA / Metal batched verification, FPGA fast paths)
the same Go interfaces are implemented by lux-private/dex and
selected at build time via the dex_gpu build tag. The accelerated
backend fails closed unless the operator's environment carries a Lux
commercial license token whose scope list includes dex. Contact
[email protected] for commercial licensing.
Features
- High performance (measured, Apple M1 Max): 11.88M orders/sec (C++ engine, 10 threads), 2.2M orders/sec (pure Go)
- Low latency: 169 ns avg match (p50 125 ns, p99 292 ns) on the C++ engine; 381 ns/order in pure Go
- Multi-engine architecture: pure Go and NUMA-aware C++ (CPU default build), plus a GPU-native per-book matcher (CGO_ENABLED=1, unified
lux-gpubackend, parity-verified GPU==CPU) — see "GPU matching" - Quantum-resistant consensus: DAG with post-quantum signatures
- Cross-platform: Linux, macOS (Intel & Apple Silicon), Windows
- Professional Market Data: Real-time oracle integration with multiple sources
- Cross-Chain Support: Universal bridge for all major blockchains
- 100% Test Coverage: All critical paths tested and verified
Quick Start
# Install dependencies
go mod download
# Build all binaries
make build
# Run tests
make test
# Run demo
./bin/demo
# Run benchmarks
make bench
Installation
From Source
git clone https://github.com/luxfi/dex
cd dex
make build
From Release
# Download latest release for your platform
curl -L https://github.com/luxfi/dex/releases/latest/download/lx-dex-$(uname -s | tr '[:upper:]' '[:lower:]')-$(uname -m) -o lx-dex
chmod +x lx-dex
./lx-dex
Performance
Measured first-hand on Apple M1 Max. The default (CGO-off) build matches on CPU; a GPU-native per-book matcher also exists — see "GPU matching" below.
| Engine | Avg match | p50 / p99 | Throughput |
|---|---|---|---|
| C++ (10 threads) | — | — | 11.88M orders/sec |
| C++ (single thread) | 169 ns | 125 ns / 292 ns | 5.91M orders/sec |
Pure Go (pkg/lx) |
381 ns | — | 2.2M orders/sec |
C++ order cancel: 49 ns. Pure-Go matching does 1–2 allocs/op (not zero-alloc).
GPU matching
The live default (CGO-off) build matches on CPU (11.88M ord/s C++, 169
ns/match): a single hot-book match is smaller than the dispatch overhead of
handing one book to an integrated GPU, so the CPU wins for the single-book hot
path. A GPU-native deterministic per-book matcher — byte-identical to the CPU
oracle (MatchOrderCPU) and parity-verified (pkg/lxgpu/orderbook_parity_test.go,
three_mode_parity_test.go) — is available with CGO_ENABLED=1 via the unified
lux-gpu backend (runtime-select CUDA/HIP/Metal), where it wins at planet scale
by running one thread per book across millions of books. Kernels ship prebuilt
from luxcpp/dex. Measured throughput (deterministic per-book, GPU==CPU parity):
| Device | Orders/sec |
|---|---|
| AMD Radeon 8060S | 12.76B |
| NVIDIA GB10 | 9.13B |
| Apple M4 Max | 5.60B |
| Apple M1 Max | 2.80B |
| Two-node fabric | 21.9B |
The GPU also drives the FHE layer: the Metal NTT kernel is 23.6× faster than the CPU NTT at N=4096, batch=128, where batched polynomial decomposition dominates.
Architecture
On-chain settlement follows D matches · C settles: the D-Chain (dexvm)
matches and BLS-signs a DFillReceipt; the C-Chain receipt-settlement precompile
0x9999 (Uniswap-V4 PoolManager ABI) verifies the certificate inline and settles
under Block-STM. See docs/ARCHITECTURE.md
and the normative spec LP-9999.
The DEX uses a multi-engine architecture; order matching runs on CPU:
- Pure Go engine (
pkg/lx): portable reference, 2.2M orders/sec, 381 ns/order - C++ engine: 11.88M orders/sec (10 threads), 5.91M single-thread, 169 ns avg match
FIX Protocol Performance (December 2024 — stale, not re-verified this session)
These are FIX wire encode/decode message rates (a separate axis from order matching) and have not been re-measured; treat as historical, not current.
| Engine | NewOrderSingle | ExecutionReport | MarketDataSnapshot |
|---|---|---|---|
| Pure Go | 163K/sec | 124K/sec | 332K/sec |
| Hybrid Go/C++ | 167K/sec | 378K/sec | 616K/sec |
| Pure C++ | 444K/sec | 804K/sec | 1.08M/sec |
| Rust | 484K/sec | 232K/sec | 586K/sec |
See docs/ for detailed documentation.
Development
Requirements
- Go 1.21+
- macOS or Linux
- Optional: Apple Silicon Mac for Metal-accelerated FHE (NTT)
- Optional: NVIDIA GPU for CUDA acceleration
Building with GPU Support
# Apple Silicon (Metal)
CGO_ENABLED=1 make build
# Linux with CUDA — the lux-gpu backend runtime-selects CUDA; no CUDA make var
CGO_ENABLED=1 make build
Running Tests
# Unit tests
make test
# Benchmarks
make bench
# All tests including integration
go test ./...
CI/CD
The project uses GitHub Actions for CI/CD:
- CI: Runs on every push and PR
- Release: Triggered by version tags (v*)
- Platforms: Ubuntu, macOS
- Go versions: 1.21, 1.22
See .github/workflows/ for workflow definitions.
Contributing
- Fork the repository
- Create your feature branch (
git checkout -b feature/amazing) - Commit your changes (
git commit -m 'feat: add amazing feature') - Push to the branch (
git push origin feature/amazing) - Open a Pull Request
License
Copyright (C) 2020-2025, Lux Industries Inc.