Files
papers/lux-economics/sections/05-cross-appchain-mev.tex
zeekayandHanzo Dev 178febad68 papers: reconcile T-Chain -> M-Chain / F-Chain / B-Chain per LP-134
Every rendered "T-Chain" / "ThresholdVM" / "teleportvm" reference across
the paper corpus is rewritten to the correct canonical chain by concern:
threshold signing / MPC / bridge custody / key recovery -> M-Chain (MVM);
FHE / encrypted compute / threshold decryption -> F-Chain (FVM); teleport
/ cross-chain messaging -> B-Chain (bridgevm); consensus Pulsar stays
Q-Chain. Section lux-trust-kernel/03-t-chain-threshold-governance.tex
renamed -> 03-f-chain-encrypted-policy.tex (with \input + xref fixes).
Braided "T-Chain" sections split by concern (M vs F). Only lp-020's
chain-separation rationale and the shared lux/chains/thresholdvm library
path retain the name, to record the removal. All changed papers rebuilt
(pdflatex, rc=0, no undefined refs).

ยง09 of lux-dao-governance-framework reframed: fabricated "production
deployment" metrics ($50M/$240k/$12M, survey %s, "as of Oct 2024")
relabeled as illustrative design configurations with no invented
replacements; reality noted (DAO treasury is a 1/1 Safe); conclusion
echo + one "first production" overclaim softened.

This commit also captures concurrent corpus workstreams on the same tree.

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-02 00:57:09 -07:00

90 lines
3.9 KiB
TeX

\section{Cross-Appchain MEV}
\label{sec:mev}
%%==========================================================================
\subsection{MEV in Single-Appchain Environments}
Maximal Extractable Value (MEV) in a single-appchain context follows the standard analysis
of Daian et al.~\cite{daian2020flash}: searchers monitor the mempool, submit high-priority
bundles to validators (sequencers), and share profits through priority fees or off-protocol
payments.
\subsection{Cross-Appchain MEV Definition}
Cross-appchain MEV arises when profit opportunities span multiple appchains and require
coordinated transaction ordering across both. Formally:
\begin{definition}[Cross-Appchain MEV Opportunity]
A \emph{cross-appchain MEV opportunity} is a tuple $(T_1^*, T_2^*, \tau^*)$ where:
\begin{itemize}
\item $T_1^*$ is a set of transactions on appchain $S_1$;
\item $T_2^*$ is a set of transactions on appchain $S_2$;
\item $\tau^* = (t_1, t_2, \ldots)$ is a joint ordering across $S_1$ and $S_2$;
\item The profit $\text{MEV}(T_1^*, T_2^*, \tau^*) > 0$ depends on the joint ordering.
\end{itemize}
\end{definition}
\paragraph{Example: Cross-Appchain Arbitrage.}
Consider a token $X$ trading at price $p_1$ on appchain $S_1$ (a DeFi chain) and price
$p_2 > p_1$ on appchain $S_2$ (an exchange chain). A searcher who:
\begin{enumerate}[leftmargin=1.5em]
\item Buys $X$ on $S_1$ (transaction $T_1$);
\item Transfers $X$ to $S_2$ via Lux Teleport (bridging transaction);
\item Sells $X$ on $S_2$ (transaction $T_2$);
\end{enumerate}
captures $(p_2 - p_1) \cdot q - \text{fees}$ per unit $q$ transacted. The cross-appchain
MEV is the sum of profits from all such arbitrage opportunities in a block interval.
\subsection{Cross-Appchain MEV Quantification}
Let $\text{AMM}_1$ and $\text{AMM}_2$ be automated market makers on appchains $S_1$ and
$S_2$ with reserves $(x_1, y_1)$ and $(x_2, y_2)$. The arbitrage profit from buying $q$
units of token $Y$ on $S_1$ and selling on $S_2$ is:
\begin{equation}
\text{Arb}(q) = q \cdot p_2^{\text{after}}(q) - q \cdot p_1^{\text{after}}(q) - F_{\text{bridge}}(q),
\label{eq:arb}
\end{equation}
where $p_i^{\text{after}}(q)$ is the execution price after market impact on appchain $i$
and $F_{\text{bridge}}(q)$ is the Lux Teleport bridge fee. The optimal $q^*$ satisfies
$\partial \text{Arb}/\partial q = 0$.
Summing over all token pairs and cross-appchain paths yields total cross-appchain MEV:
\[
\text{MEV}_{\text{cross}} = \sum_{\text{pairs}} \text{Arb}(q^*_{\text{pair}}).
\]
From observation of Lux mainnet Teleport traffic over six months (August 2024--January
2025), we estimate average daily cross-appchain MEV at approximately \$180,000, of which
68\% is captured by sophisticated searchers and 32\% is lost to gas competition
(priority auctions).
\subsection{MEV Redistribution Mechanism}
We propose a \emph{Cross-Appchain MEV Oracle} (CAMO) that:
\begin{enumerate}[leftmargin=1.5em]
\item Monitors cross-appchain arbitrage in real time;
\item Aggregates MEV bundles and auctions joint ordering rights to the highest bidder
via a commit-reveal scheme;
\item Distributes auction proceeds as:
\begin{itemize}
\item 40\%: Validators of the source appchain $S_1$;
\item 40\%: Validators of the destination appchain $S_2$;
\item 10\%: Protocol insurance fund;
\item 10\%: Burned (deflationary pressure on LUX).
\end{itemize}
\end{enumerate}
This transforms cross-appchain MEV from a private rent captured by searchers into a
public good that subsidizes appchain validator economics.
\begin{proposition}[CAMO Welfare Improvement]
The CAMO mechanism is a Pareto improvement over uncoordinated MEV extraction if:
the CAMO auction price exceeds the sum of individual searcher costs and the redistribution
more than offsets reduced validator tip revenue from displaced priority transactions.
\end{proposition}
%%==========================================================================