zeekay
ec0b0deef3
Port the atomic import/export into the native dexvm matcher so the in-luxd D-Chain PRODUCES and CONSUMES the same primary-network shared-memory objects the 0x9999 precompile speaks — the owner's chosen model (D matches under its own consensus; C-Chain 0x9999 settles by consuming a node-local atomic object D produces; no BLS receipt, no external venue). - atomic.go: the seam. encodeSeamObject/decodeSeamObject reproduce the precompile's 69-byte wire (rail|owner|asset|amount|spent) BYTE-FOR-BYTE, and DeriveIntentID its id derivation — ONE wire across precompile/proxy/native. executeImport consumes a C->D object (Get under the C chain + shared-memory Remove) and funds the taker's native D account; executeExport debits the matched proceeds and writes a D->C object keyed exactly as ImportSettlement reads it, bound to the per-intent escrow (owner/asset/remaining) so Phase B's owner/asset/amount + per-taker-cap checks pass. commitSeamAtomic applies the removes/puts atomically with the block overlay (the platformvm acceptor pattern). No root change needed: the in-consensus matcher makes the atomic ops a pure function of the already-rooted txs (unlike the proxy's live venue). - vm.go: capture init.Runtime -> shared-memory handle + C-Chain id. - tx.go: TxImport (intentID) / TxExport (intentID|asset|amount|spent), both authorized by the cross-chain object, not a signature. - block.go: execute drives the seam in the account-scoped lane; Accept commits via commitSeamAtomic. - atomic_seam_e2e_test.go: two-phase e2e over REAL shared memory — Phase A intent -> native D import + a real crossing under D consensus -> native D export -> Phase B (the exact 0x9999 ImportSettlement consume) credits once; replay rejected; over-export beyond the locked principal rejected; conservation holds. Plus a golden-wire test pinning encodeSeamObject to the SAME cross-repo golden the precompile pins ImportSettlement against (native == precompile == proxy). go.sum: re-record re-tagged luxfi/[email protected] (stale hash blocked the build). go.mod: luxfi/runtime indirect -> direct (atomic.go uses it).
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++ — order matching runs on CPU
- 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. Order matching runs on CPU — see "Why matching stays on CPU" 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).
Why matching stays on CPU
GPU order matching exists only as a CUDA path on Linux (commercial
lux-private/dex); there is no Apple/Metal matching path. A single match is
~169 ns — smaller than the dispatch overhead of handing a batch to an
integrated GPU — so the CPU wins for matching. The GPU pays off in the FHE
layer instead: the Metal NTT kernel is 23× 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)
| 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
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.