mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
fc9b2e03e1
Auto-fixes from the paper accuracy swarm: unambiguous build-breakers, broken \ref/\cite/\input targets, and prose typos. Substantive accuracy findings (dates, contradictory numbers, LP numbering) reported separately for review.
56 lines
3.2 KiB
TeX
56 lines
3.2 KiB
TeX
\section{Introduction}
|
|
|
|
%%==========================================================================
|
|
|
|
The Lux Network's appchain architecture enables developers to deploy application-specific
|
|
blockchains with full control over consensus parameters, virtual machines, gas tokens,
|
|
and validator admission policies. As of 2025, 47 appchains serve production traffic,
|
|
spanning DeFi protocols, gaming applications, institutional asset management platforms, and
|
|
enterprise supply chain systems.
|
|
|
|
Despite this proliferation, the economic layer governing appchain creation and operation
|
|
remains underspecified in the public literature. Practitioners face concrete questions
|
|
without rigorous answers: How much should an appchain spend to attract enough validators?
|
|
What fee structure maximizes long-run revenue while remaining competitive with alternative
|
|
L2 solutions? How should fee revenue be split between appchain-native validators and Primary
|
|
Network validators who provide underlying security? How can a new appchain bootstrap a
|
|
native token without creating inflationary pressure that undermines its own economics?
|
|
|
|
This paper addresses these questions through a combination of mechanism design, empirical
|
|
calibration, and simulation. Our contributions:
|
|
|
|
\begin{enumerate}[leftmargin=1.5em]
|
|
\item \textbf{Appchain cost model}: A detailed cost accounting framework for appchain
|
|
creation and operation across five throughput tiers (Section~\ref{sec:costs}).
|
|
\item \textbf{Validator incentive mechanism}: A formal model of the validator's
|
|
participation decision, including the opportunity-cost constraint relative to
|
|
Primary Network staking (Section~\ref{sec:validators}).
|
|
\item \textbf{Cross-appchain MEV analysis}: A formal treatment of MEV arising from
|
|
cross-appchain transaction ordering, with an on-chain redistribution mechanism
|
|
(Section~\ref{sec:mev}).
|
|
\item \textbf{Fee sharing protocol}: A two-tier fee-sharing mechanism balancing appchain
|
|
sovereignty with Primary Network security incentives (Section~\ref{sec:feesharing}).
|
|
\item \textbf{Token bootstrapping}: A liquidity-weighted emission schedule for appchain
|
|
native tokens that avoids inflationary oversupply (Section~\ref{sec:bootstrapping}).
|
|
\item \textbf{Elastic scaling}: A dynamic validator set sizing mechanism based on
|
|
observed demand (Section~\ref{sec:elastic}).
|
|
\end{enumerate}
|
|
|
|
\subsection{The Appchain Value Stack}
|
|
|
|
We conceptualize appchain economics as a value stack with four layers:
|
|
|
|
\begin{description}[leftmargin=2em,style=nextline]
|
|
\item[Layer 1: Infrastructure] P-Chain consensus, validator hardware, network bandwidth.
|
|
\item[Layer 2: Security] Economic collateral staked by Primary Network and appchain
|
|
validators.
|
|
\item[Layer 3: Execution] Transaction processing, VM computation, state storage.
|
|
\item[Layer 4: Application] MEV, user-level fees, protocol revenue.
|
|
\end{description}
|
|
|
|
Each layer has costs that must be covered by the value generated at that layer and the
|
|
layers above. A sustainable appchain economy requires that application-layer revenue flows
|
|
sufficiently downward to sustain infrastructure and security.
|
|
|
|
%%==========================================================================
|