The in-luxd native D-Chain plugin served HTTP only (the dev left the ZAP socket to standalone cmd/dvenue: handler.go said 'the in-luxd plugin does NOT use this path'). Owner transport decision: the ZAP socket is the CANONICAL native ingestion in-luxd (the HFT path — binary wire, streaming, co-located on the pod), HTTP stays as the compat surface (web/exchange-api/ debug). Both fold over the ONE clobMethods core; transport is orthogonal to consensus, so it is safe to serve both — an order from either transport hits the identical submitTx -> mempool.Add -> Verify-match path, and validators replay from accepted block BYTES, never the wire. zapingest.go: the VM owns its transports. Initialize parses init.Config for an optional zapIngestAddr and, when set, opens rpc.Listen co-located in the plugin process bound to clobMethods (reusing RegisterCLOB, the existing socket seam) — served concurrently, closed on Shutdown. Enabled by DATA (the chain config the operator/genesis sets), NOT a build tag or forked entry point: one binary, one core, the transport set is a per-environment knob. Empty addr => HTTP-compat-only (in-process tests + cmd/dvenue, which runs its own socket, are unaffected). Malformed config fails fast at Initialize. TDD (all !cgo): - TestZAPIngestCrossingOrdersMatchInBlock: an order over the VM's OWN config-started socket (no manual RegisterCLOB) -> consensus -> committed fill. - TestZAPIngestSharesOneCoreWithHTTP: maker rests over ZAP, taker crosses over HTTP against the SAME book -> proves one core, two transports. - TestParseConfig / TestNoZAPIngestWhenUnset / TestZAPIngestStopsOnShutdown: config contract (forwards-only), no-op path, clean idempotent teardown. Additive: RegisterCLOB unchanged; CreateHandlers/ingest.go unchanged; the runner (cmd/dchain) unchanged — the socket is a VM concern driven by config.
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
- Ultra-high performance: 13M+ orders/sec achieved with planet-scale architecture
- Sub-microsecond latency: 75.9ns order matching, 636ns position updates
- Multi-engine architecture: Pure Go, C++, and GPU (CUDA/MLX)
- 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
| Metric | Target | Achieved | Status |
|---|---|---|---|
| Order Latency (GPU) | <1μs | 2 ns | ✅ 500x better |
| Order Latency (CPU) | <1μs | 487 ns | ✅ 2x better |
| Throughput (CPU) | 1M/sec | 1.01M/sec | ✅ Exceeded |
| Throughput (GPU) | 100M/sec | 434M/sec | ✅ 4.34x |
| Test Coverage | 100% pass | 100% pass | ✅ Complete |
| Code Coverage | 30% | 39.1% | ✅ Exceeded |
*With MLX GPU acceleration on Apple Silicon M2 Ultra
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:
- Pure Go Engine: Portable, 830K orders/sec
- C++ Engine: Low latency, 800K+ orders/sec
- Rust Engine: High performance, 585K+ orders/sec
- MLX GPU Engine: Apple Silicon Metal, 6M+ msgs/sec (FIX), 434M+ orders/sec
FIX Protocol Performance (December 2024)
| 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 |
| MLX (Apple Silicon) | 3.12M/sec | 4.27M/sec | 5.95M/sec |
*MLX achieves sub-2μs average latency (0.68-1.75μs) via GPU parallelism
See docs/ for detailed documentation.
Development
Requirements
- Go 1.21+
- macOS or Linux
- Optional: Apple Silicon Mac for MLX GPU acceleration
- Optional: NVIDIA GPU for CUDA acceleration
Building with GPU Support
# Apple Silicon (Metal)
CGO_ENABLED=1 make build
# Linux with CUDA
CGO_ENABLED=1 CUDA=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.