mirror of
https://github.com/lux-apps/papers.git
synced 2026-11-03 05:07:46 +00:00
zeekayandHanzo Dev
e2cb62c540
I resolved these files toward a June commit that called the billion-order figures fabricated, and that commit was itself the mistaken one. The July campaign it predates does not assert its numbers, it checks them: a GPU-versus-CPU parity run matching exactly, 38,000,000 fills on both sides at 1,000,000 books, depth 32, 32 takers each, on hardware this estate owns. It also names the error in the earlier framing. Consensus determinism was taken to force a single-thread launch and forfeit the GPU. It does not: determinism constrains ordering WITHIN a book and says nothing across books, so one thread per book — each matching its taker stream in strict price-time priority, bit-for-bit re-executable, millions of threads — saturates the accelerator with every book deterministic. Restored at the later versions across all 27 files: the accounting section, the CLOB matcher, lightspeed-dex, lp-306, lp-308, lp-137, p3q-corona, the precompile engineering sections and the FHE orderbook application. Paper builds, 23 pages, no errors. Co-authored-by: Hanzo Dev <[email protected]>
107 lines
4.4 KiB
TeX
107 lines
4.4 KiB
TeX
\section{Architecture: 2022 Design vs.\ 2026 Implementation}
|
|
|
|
|
|
\subsection{Matching Engine}
|
|
|
|
\textbf{2022}: C++ matching engine compiled to Solidity WASM,
|
|
running on a Lux L1 chain. Order book stored on-chain.
|
|
|
|
\textbf{2026}: Multi-engine architecture
|
|
(\texttt{luxfi/dex}): Go (default), C++ (high-freq), Rust
|
|
(safety-critical), MLX (Apple Silicon). CLOB matching with
|
|
AMM fallback. Clearinghouse with margin and liquidation.
|
|
Cross-chain gateway bridging 8 chains. The GPU CLOB kernel
|
|
sustains 9.13\,B byte-exact \texttt{uint256} orders/sec on an NVIDIA
|
|
GB10, 12.76\,B on an AMD Radeon 8060S, and 5.60/2.80\,B on Apple
|
|
M4 Max/M1 Max; the throughput levers are a coalesced structure-of-arrays
|
|
arena layout ($\sim$6$\times$ over an un-coalesced baseline) and a
|
|
Knuth Algorithm-D division that replaces a 512-iteration bit-serial
|
|
\texttt{uint256} VWAP, with output byte-identical to the CPU
|
|
oracle (LP-203).
|
|
|
|
\subsection{Social Trading and Copy Swaps}
|
|
|
|
\textbf{2022}: Permission-mapped liquidity aggregator smart
|
|
contracts allowing expert traders to manage investor capital
|
|
on-chain while investors retain key custody. People-Based
|
|
Portfolios (PBPs) with transparent performance stats.
|
|
|
|
\textbf{2026}: The Lux ATS (\texttt{luxfi/ats}) implements the
|
|
regulated version: SecurityToken deployments via \texttt{luxfi/standard}
|
|
on the Lux EVM, portfolio management via the exchange frontend
|
|
(\texttt{luxfi/exchange}), and social trading features
|
|
(leaderboards, copy-trade, rebalancing). The permission-mapping
|
|
concept was absorbed into the MPC wallet architecture: users
|
|
sign with their WebAuthn key share, the ATS co-signs after
|
|
compliance checks, and capital never leaves the user's
|
|
on-chain wallet.
|
|
|
|
\subsection{Decentralized Liquidity Pool}
|
|
|
|
\textbf{2022}: Uniswap V3--style concentrated liquidity with
|
|
up to 4000x capital efficiency, extended to support both
|
|
fungible and non-fungible assets in a single pool.
|
|
|
|
\textbf{2026}: The Lux DEX implements a native orderbook
|
|
(CLOB) rather than an AMM-only model. AMM pools exist as
|
|
fallback liquidity via \texttt{luxfi/standard/contracts/amm/}
|
|
(AMM V1--V4, Oracle-Mirrored AMM). The NFT liquidity pool
|
|
concept was not pursued --- the market moved toward
|
|
orderbook-based NFT trading (Blur/Tensor model) rather than
|
|
AMM curves for non-fungibles.
|
|
|
|
\subsection{Atomic Swaps and Bridge}
|
|
|
|
\textbf{2022}: HTLC-based atomic swaps with BTC, subsidized
|
|
by gateway deposits. Cross-chain interoperability via oracles
|
|
(Chainlink).
|
|
|
|
\textbf{2026}: The Z-Chain (zero-knowledge bridge) uses
|
|
homomorphic encryption for shielded cross-chain transfers.
|
|
The Lux DEX cross-chain gateway supports 8 chains natively.
|
|
\texttt{luxfi/standard/contracts/bridge/} implements the
|
|
Warp Messenger protocol for L1$\leftrightarrow$L2 asset
|
|
movement. Chainlink oracles replaced with Lux Oracle
|
|
(native, threshold-signed price feeds).
|
|
|
|
\subsection{Governance and DAO}
|
|
|
|
\textbf{2022}: LUX token governance with quadratic voting,
|
|
holographic consensus, proof-of-humanity biometric
|
|
authentication, proxy voting, and Ricardian contracts.
|
|
|
|
\textbf{2026}: DAO governance contracts exist in
|
|
\texttt{luxfi/standard/contracts/dao/} and
|
|
\texttt{contracts/governance/}. Voting is on-chain with
|
|
LUX staking. Quadratic voting and proof-of-humanity were
|
|
not implemented --- standard token-weighted voting with
|
|
delegation is the current model. Ricardian contracts were
|
|
superseded by on-chain compliance gates
|
|
(\texttt{IComplianceGate} interface).
|
|
|
|
\subsection{Security}
|
|
|
|
\textbf{2022}: SHA-3, PKI, time-delayed multisig, benign
|
|
fill, hardware wallets for all signing, homomorphic
|
|
zero-knowledge file systems.
|
|
|
|
\textbf{2026}: All realized plus post-quantum upgrades:
|
|
\begin{itemize}[nosep]
|
|
\item SHA-3 $\rightarrow$ used throughout (Keccak-256 for
|
|
EVM compatibility, SHA3-256 for non-EVM).
|
|
\item Multisig $\rightarrow$ 2-of-3 MPC
|
|
(CGGMP21 + FROST), strictly superior to multisig
|
|
(single on-chain address, no $n$-of-$m$ script
|
|
complexity).
|
|
\item Hardware wallets $\rightarrow$ HSM co-signing
|
|
(AWS KMS, GCP, Zymbit) for settlement intents.
|
|
\item Zero-knowledge file system $\rightarrow$
|
|
\texttt{PrivateStore.sol} + \texttt{/v1/base/private}
|
|
(E2E encrypted blind blob store, shipped Q1 2026).
|
|
\item FHE for front-running prevention $\rightarrow$ FHE
|
|
CRDT merge (shipped Q1 2026), encrypted orderbook
|
|
on the DEX roadmap (Section~\ref{sec:roadmap}).
|
|
\end{itemize}
|
|
|
|
%% ============================================================
|