papers/lux-restaking/sections/01-introduction.tex

\section{Introduction}

%%==========================================================================

Proof-of-stake networks achieve Byzantine fault tolerance by requiring validators to post
economic collateral that may be confiscated---\emph{slashed}---if they behave dishonestly.
This arrangement transforms cryptographic security into economic security: the cost of an
attack is bounded below by the value of stake at risk. However, as the number of services
requiring such security grows, naive staking architectures suffer from a fundamental tension.

On one side, validators face a \emph{capital allocation problem}: each new service they wish
to secure demands a fresh deposit, fragmenting their capital and reducing the yield they
earn on any given unit. On the other side, new services face a \emph{bootstrapping problem}:
accumulating enough staked capital to credibly threaten slashers requires either recruiting
an entirely new validator set or offering yields so high they are economically unsustainable.

\textbf{Restaking} resolves this tension by permitting a single deposit to simultaneously
collateralize multiple services. The key insight is that staked tokens can serve as economic
security \emph{jointly} across services so long as the aggregate slashing exposure is bounded
and the rules governing each service are transparent and enforceable on-chain.

This paper describes the design, analysis, and early implementation of the Lux Restaking
Protocol. Our contributions are:

\begin{enumerate}[leftmargin=1.5em]
  \item A formal model of restaking as a hypergraph over staking commitments, with rigorous
    definitions of operator exposure, aggregate economic security, and systemic risk
    (Section~\ref{sec:model}).
  \item A slashing architecture that coordinates across independent AVS slashers while
    preventing double-slash attacks and ensuring stake coverage invariants
    (Section~\ref{sec:slashing}).
  \item An operator registration protocol with cryptographic attestation, on-chain delegation,
    and progressive opt-in/opt-out semantics (Section~\ref{sec:operators}).
  \item A marketplace design for AVS discovery and negotiation, including reputation scoring
    and minimum-security thresholds (Section~\ref{sec:marketplace}).
  \item Formal capital efficiency and systemic risk analyses, with comparison to EigenLayer
    (Sections~\ref{sec:efficiency}--\ref{sec:comparison}).
  \item Prototype implementation benchmarks on Lux Fuji testnet
    (Section~\ref{sec:implementation}).
\end{enumerate}

\subsection{Motivation}

The Lux Network operates a Primary Network of validators who secure the Exchange Chain (X),
Platform Chain (P), and Contract Chain (C). Appchains---application-specific blockchains---may
elect their own validator sets from any subset of Primary Network validators. This architecture
creates a natural restaking substrate: Primary Network validators already post their LUX stake
once; extending that commitment to additional appchains and services is an incremental rather
than additive cost.

As of 2025, Lux hosts 47 production appchains with a combined transaction throughput
exceeding 450,000 TPS. Many emerging appchains, particularly those launched by DeFi protocols,
gaming studios, and institutional asset managers, require economic security guarantees before
they can attract liquidity and users. LRP directly addresses this bootstrapping bottleneck.

\subsection{Paper Organization}

Section~\ref{sec:background} reviews related work and the Lux Network architecture.
Section~\ref{sec:model} develops the formal staking hypergraph model.
Section~\ref{sec:slashing} describes slashing conditions and the veto committee.
Section~\ref{sec:operators} details operator registration and delegation.
Section~\ref{sec:marketplace} presents the AVS marketplace design.
Section~\ref{sec:efficiency} analyzes capital efficiency.
Section~\ref{sec:risk} analyzes systemic risk.
Section~\ref{sec:comparison} compares LRP with EigenLayer, Babylon, and Symbiotic.
Section~\ref{sec:implementation} describes the prototype implementation.
Section~\ref{sec:security} provides the formal security analysis.
Section~\ref{sec:conclusion} concludes.

%%==========================================================================