Files
papers/lux-credit-protocol-spec/sections/01-introduction.tex
zeekay 4a753bb639 papers: reorganize into per-paper dirs, add Antje Worring as co-author
Restructured from flat .tex/.pdf files into per-paper subdirectories.
Added Antje Worring as co-author on all papers.
Synced PDFs to pdfs/ for download site.
2026-04-18 21:50:07 -07:00

23 lines
2.0 KiB
TeX

\section{Introduction}
\label{sec:intro}
Cross-chain liquidity systems occupy a contested design space between bridges, lending protocols, and synthetic asset platforms. Each framing carries implicit assumptions about user rights, failure modes, and regulatory posture that, if left undefined, produce semantic leakage: code that compiles and deploys but whose economic and legal meaning drifts across contexts.
The Lux Credit Protocol resolves this by committing to a single, precise classification: it is an \emph{omnichain collateralized credit and settlement protocol}. It is not a bridge. It is not a vault. It is not a stablecoin. It is not a liquid staking token. Each of these labels implies properties the system does not possess or obligations it does not accept.
Under this framing, the protocol comprises exactly four subsystems:
\begin{enumerate}[nosep]
\item \textbf{Collateral custody.} Vault-based asset custody with strategy deployment and cryptographic backing attestation.
\item \textbf{Credit issuance.} Minting of overcollateralized, in-kind redeemable credit tokens subject to hard LTV caps.
\item \textbf{Transport and finality.} Omnichain message relay with per-chain finality thresholds and threshold signature verification.
\item \textbf{Surplus allocation.} Protocol equity accrual from strategy yield, structurally separated from credit holder claims.
\end{enumerate}
Each subsystem is audited against different failure classes. This decomposition determines which invariants attach to which code paths, which failure modes trigger which recovery procedures, and which guarantees are offered to which participants.
\paragraph{Scope.} This document freezes the protocol semantics. It defines terminology, asset classes, message formats, invariants, the solvency state machine, failure behavior, trust assumptions, and the boundary conditions with the ATS compliance layer. Line-by-line router review proceeds from this specification, not the other way around.