Files
zeekay b55171116e papers: replace fabricated DEX perf claims with measured numbers; document decomplected architecture
Retract the fabricated '581M/597ns / 100M+/s / 434M GPU / planet-scale' headline (a
time.Sleep sim + x40 fudge that measured nothing) across the corpus. Flagship lux-lightspeed-dex
rewritten (decomplected d-chain engine / dexvm atomic proxy / Go wrapper / 0x9010 CLOB facade;
measured GB10 104-126M & M4 Max ~250M fills/s byte-parity-gated; Knuth-D division lever; Block-STM
settlement; P3Q->starkfri rollup to Z-Chain). Technical papers (precompile-engineering, gpu-crypto-stack,
evmgpu-benchmark, p3q-corona, smart-order-routing, fhe-mpc-hybrid) carry the measured impl + cross-ref
the flagship. >1B/s framed honestly as N-node aggregation, never single-GPU. All compile.
2026-06-17 17:15:10 -07:00

61 lines
3.0 KiB
TeX

\section{MEV Resistance}
\label{sec:mev}
\subsection{The MEV problem}
\textbf{Maximal extractable value} (MEV) is profit obtained by reordering, inserting, or
censoring transactions. The common attacks against a DEX are frontrunning (observing a
large buy and trading ahead of it), the sandwich (placing orders immediately before and
after a victim), and just-in-time liquidity (adding liquidity right before a large trade
to capture its fees). On public AMMs these extract substantial value from users every
year~\cite{daian2020,flashbots2024}.
The D-Chain's structure removes two of the levers MEV relies on. Matching is a CLOB with
price-time priority, not a bonding curve, so there is no curve to sandwich. Ordering is
fixed by consensus and re-derived deterministically by every validator
(Section~\ref{sec:determinism}), so a single proposer cannot silently reorder a block in
its favor without being rejected. The remaining lever---seeing order contents before they
are committed---is addressed below.
\subsection{Pre-trade confidentiality}
Orders can be submitted encrypted under a threshold key and revealed only at block
finalization:
\[
\mathrm{Enc}(\mathrm{order}) = \mathrm{ThresholdEncrypt}\big(\mathrm{order},\,
\{pk_1,\dots,pk_n\}\big),
\]
with decryption requiring $t$ of $n$ validators to cooperate. Until the block is
finalized, no party---including the proposer---can read an order's contents, so there is
nothing to frontrun. The encrypted commitment fixes the order's position in the sequence
before its contents are known, which is the property that defeats latency-based
extraction.
\subsection{Price-time priority is deterministic}
Priority is the pair $(\mathrm{price}, \mathrm{sequence})$, where the sequence is the
order's position in the consensus-fixed block ordering rather than a wall-clock reading.
Two consequences follow. First, priority is reproducible: every validator computes the
same priority because the inputs are in the block (Section~\ref{sec:determinism}).
Second, priority cannot be gamed by timing, because it derives from consensus sequence,
not from a clock a participant can race. A validator that reorders fills inconsistently
with $(\mathrm{price}, \mathrm{sequence})$ produces a state root that disagrees with
honest re-execution and is rejected.
\subsection{Frequent batch auctions}
For markets where uniform clearing is preferable to continuous matching, orders in a
block are matched simultaneously at a single clearing price (a frequent batch auction):
\begin{enumerate}
\item Collect the orders committed in a block.
\item Match them simultaneously at a uniform clearing price for the batch.
\item Settle atomically (Section~\ref{sec:settlement}).
\end{enumerate}
Batch clearing eliminates intra-block timing games---every order in the batch is treated
identically---and improves price discovery by aggregating the block's liquidity into one
auction. Because the batch is the block, the auction inherits the determinism guarantees
of Section~\ref{sec:determinism}: the clearing price is a deterministic function of the
committed orders.