mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
f4ee7a0525
Bylines, paper authorship, correspondence addresses and the founder blurb under each post named an individual. They name the organisation that published the work instead: the brand on posts and pages, the research byline on papers, and research@ in place of a personal address. Both are what these repositories already used elsewhere — nothing new was coined. Co-authors are untouched. Where a paper named someone else alongside, they stay named; only the one byline changed. Bibliography entries, running heads, PDF metadata and affiliations move with it, so a citation still resolves to whoever the cited paper names. Sample and fixture data uses the placeholder name these tests already use elsewhere, so no assertion changed meaning.
81 lines
3.0 KiB
TeX
81 lines
3.0 KiB
TeX
\documentclass[11pt]{article}
|
|
\usepackage{../shared/luxcover}
|
|
\usepackage{amsmath,amssymb,amsthm}
|
|
\usepackage{mathtools}
|
|
\usepackage{bm}
|
|
\usepackage{graphicx}
|
|
\usepackage{booktabs}
|
|
\usepackage{hyperref}
|
|
\usepackage{enumitem}
|
|
\usepackage{algorithm}
|
|
\usepackage{algpseudocode}
|
|
\usepackage{xcolor}
|
|
\usepackage{tikz}
|
|
\usepackage{pgfplots}
|
|
\pgfplotsset{compat=1.18}
|
|
\usepackage{array}
|
|
\usepackage{multirow}
|
|
\usepackage{float}
|
|
\hypersetup{colorlinks=true,linkcolor=black,citecolor=blue,urlcolor=blue}
|
|
|
|
\newtheorem{theorem}{Theorem}
|
|
\newtheorem{lemma}[theorem]{Lemma}
|
|
\newtheorem{proposition}[theorem]{Proposition}
|
|
\newtheorem{corollary}[theorem]{Corollary}
|
|
\newtheorem{definition}{Definition}
|
|
\newtheorem{remark}{Remark}
|
|
|
|
\title{\textbf{Restaking Protocol for Lux Network Security Extension}\\
|
|
\large Enabling Capital-Efficient Economic Security Sharing Across Appchains and Actively Validated Services}
|
|
|
|
\author{
|
|
Lux Research\thanks{Corresponding author: [email protected]}\\
|
|
\textit{Lux Industries, Inc.}\\
|
|
\texttt{[email protected]}
|
|
}
|
|
|
|
\date{2025}
|
|
|
|
\begin{document}
|
|
|
|
\luxcoverpage
|
|
|
|
\begin{abstract}
|
|
We present the \textbf{Lux Restaking Protocol} (LRP), a mechanism enabling LUX token holders
|
|
to extend the economic security of their staked capital to multiple Actively Validated Services
|
|
(AVSs) and application-specific appchains simultaneously. Unlike traditional staking, where each
|
|
validator commitment is siloed within a single chain, LRP allows a single unit of staked LUX
|
|
to simultaneously secure an arbitrary set of registered services subject to independent
|
|
slashing conditions. We formalize the security model as a hypergraph of staking commitments,
|
|
prove that aggregate economic security is subadditive in the presence of shared stake, and
|
|
derive tight bounds on the systemic risk introduced by correlated slashing events. Our
|
|
capital-efficiency analysis demonstrates that LRP achieves a 4.7$\times$ improvement in
|
|
security-per-token-staked compared to isolated appchain validation, with measurable improvements
|
|
in bootstrapping economics for new appchains. We compare LRP to EigenLayer's design on
|
|
Ethereum, identifying five structural advantages arising from Lux's native Beacon consensus
|
|
and its existing Primary Network validator architecture. A prototype deployment on Lux Fuji
|
|
testnet processes operator registrations in under 200 ms and executes slashing with sub-2-second
|
|
finality, demonstrating practical viability at scale.
|
|
\end{abstract}
|
|
|
|
\tableofcontents
|
|
\newpage
|
|
|
|
%%==========================================================================
|
|
|
|
\input{sections/01-introduction}
|
|
\input{sections/02-background}
|
|
\input{sections/03-formal-model}
|
|
\input{sections/04-slashing-architecture}
|
|
\input{sections/05-operator-registration-protocol}
|
|
\input{sections/06-avs-marketplace}
|
|
\input{sections/07-capital-efficiency-analysis}
|
|
\input{sections/08-systemic-risk-analysis}
|
|
\input{sections/09-comparison-with-eigenlayer}
|
|
\input{sections/10-implementation}
|
|
\input{sections/11-formal-security-analysis}
|
|
\input{sections/12-discussion}
|
|
\input{sections/99-conclusion}
|
|
|
|
\end{document}
|