mirror of
https://github.com/lux-apps/papers.git
synced 2026-11-03 05:07:46 +00:00
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]>
90 lines
3.9 KiB
TeX
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}
|
|
|
|
%%==========================================================================
|