Files
papers/lux-tokenomics/sections/06-appchain-economic-coupling.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

49 lines
2.5 KiB
TeX

\section{Appchain Economic Coupling}
\label{sec:appchain}
\subsection{Appchain Registration and Fees}
Creating an appchain on Lux Network requires a one-time creation fee $F_{\text{create}}$ and ongoing validator staking. The creation fee is denominated in LUX and burned:
\begin{equation}
F_{\text{create}} = F_{\text{base}} \cdot (1 + \delta \cdot |\mathcal{K}|)
\end{equation}
where $F_{\text{base}} = 1{,}000$ LUX and $\delta = 0.001$ provides mild congestion pricing as the number of appchains $|\mathcal{K}|$ grows.
\subsection{Cross-Appchain Value Flow}
Each appchain contributes to the primary network economy through multiple channels:
\begin{enumerate}[label=(\arabic*)]
\item \textbf{Validator staking}: Appchain validators must stake LUX on the primary network.
\item \textbf{Fee tax}: A fraction $\tau_k \in [0.01, 0.05]$ of appchain fees flows to the primary network burn.
\item \textbf{Warp messaging fees}: Cross-appchain messages pay LUX fees on the primary network.
\item \textbf{Appchain token backing}: Appchains may optionally back their native tokens with LUX reserves.
\end{enumerate}
\begin{definition}[Economic Coupling Coefficient]
The economic coupling coefficient for appchain $k$ is:
\begin{equation}
\kappa_k = \frac{\tau_k \cdot F_k + \text{Stake}_k + \text{WarpFees}_k}{\text{TotalEconomicActivity}_k}
\end{equation}
measuring the fraction of appchain economic activity that accrues to the primary network.
\end{definition}
\subsection{Optimal Tax Rate}
\begin{theorem}[Revenue-Maximizing Tax Rate]
The appchain fee tax rate $\tau_k^*$ that maximizes total primary network revenue, accounting for the elasticity of appchain transaction demand, is:
\begin{equation}
\tau_k^* = \frac{1}{1 + \epsilon_k}
\end{equation}
where $\epsilon_k > 0$ is the price elasticity of demand for transactions on appchain $k$.
\end{theorem}
\begin{proof}
Primary network revenue from appchain $k$ is $\mathcal{R}_k(\tau_k) = \tau_k \cdot F_k(\tau_k)$ where $F_k(\tau_k) = F_k^0 \cdot (1 + \tau_k)^{-\epsilon_k}$ models demand elasticity. Taking the first-order condition:
\begin{equation}
\frac{\partial \mathcal{R}_k}{\partial \tau_k} = F_k - \tau_k \cdot \epsilon_k \cdot \frac{F_k}{1 + \tau_k} = 0
\end{equation}
Solving yields $\tau_k^* = 1 / (1 + \epsilon_k)$. For typical blockchain transaction elasticities $\epsilon_k \in [0.5, 2.0]$, this gives $\tau_k^* \in [0.33, 0.67]$. In practice, we cap $\tau_k \leq 0.05$ to encourage appchain adoption, accepting suboptimal revenue extraction.
\end{proof}