mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
b55171116e
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.
52 lines
2.0 KiB
TeX
52 lines
2.0 KiB
TeX
\section{Economic Model}
|
|
\label{sec:economic}
|
|
|
|
The economic model is a set of design parameters, not a measurement, and we present it as
|
|
such. Fee tiers and the fee split are configuration; the revenue and yield expressions are
|
|
illustrative formulas whose inputs are assumptions, explicitly labeled.
|
|
|
|
\subsection{Fee tiers}
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\renewcommand{\arraystretch}{1.2}
|
|
\begin{tabular}{l r r}
|
|
\toprule
|
|
\textbf{Tier} & \textbf{Maker} & \textbf{Taker} \\
|
|
\midrule
|
|
Retail & 0.05\% & 0.10\% \\
|
|
Pro & 0.03\% & 0.08\% \\
|
|
Institutional & 0.01\% & 0.05\% \\
|
|
Market maker & 0.00\% & 0.03\% \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\caption{Fee tiers. These are design parameters, not measured quantities, and a venue may
|
|
configure them.}
|
|
\label{tab:fees}
|
|
\end{table}
|
|
|
|
A CLOB rewards makers more than an AMM can: resting limit orders are the liquidity, so a
|
|
maker rebate directly deepens the book. The taker fee prices immediacy. The split is
|
|
orthogonal to the matching engine---it is applied at settlement and does not affect the
|
|
determinism or parity properties of matching.
|
|
|
|
\subsection{Fee distribution}
|
|
|
|
Collected fees are split among validators (proportional to stake), liquidity providers, a
|
|
buyback-and-burn of the native token, and a development fund. The exact percentages are
|
|
governance parameters; the design intent is that the buyback couples protocol usage to token
|
|
value and that the validator share funds the security budget once the D-Chain decentralizes.
|
|
|
|
\subsection{Illustrative revenue (assumptions, not a claim)}
|
|
|
|
For a venue with average daily volume $D$ and an average effective fee $\phi$, annual fee
|
|
revenue is
|
|
\[
|
|
\text{revenue} = D \times \phi \times 365.
|
|
\]
|
|
This is arithmetic, not a forecast: $D$ and $\phi$ are inputs a reader supplies. We
|
|
deliberately do not assert a specific daily volume, a specific revenue figure, or a validator
|
|
APY, because we have not measured a production deployment. Any such figure would be a
|
|
projection conditioned on an unmeasured volume assumption, and this paper reports measured
|
|
quantities and labels everything else.
|