papers/ethos-of-lux.tex

\documentclass[11pt,a4paper]{article}
\usepackage{shared/luxcover}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{amsmath,amssymb,amsfonts,amsthm}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage{booktabs}
\usepackage{enumitem}
\usepackage{xcolor}

\hypersetup{colorlinks=true,linkcolor=black,citecolor=blue,urlcolor=blue}

\title{The Ethos of Lux\\[4pt]
\large Eight Principles for a Durable Blockchain Platform}

\author{
Zach Kelling\thanks{Corresponding author: [email protected]}\\
\textit{Lux Industries, Inc.}\\
\texttt{[email protected]}
}

\date{Original: January 2020\quad|\quad Revised: March 2026}

\begin{document}

\luxcoverpage

\begin{abstract}
This document codifies the eight design principles that have guided
every architectural decision in the Lux Network since its inception on
January 1, 2020. These principles are not technical
specifications---they are constraints on the solution space. Every
protocol, every API, every cryptographic choice in the Lux ecosystem
is evaluated against these principles before it ships.
\end{abstract}

\tableofcontents
\newpage

%% ============================================================
\section{Preamble}

Blockchain platforms fail for predictable reasons: they are too hard to
use, too brittle to extend, too slow to adapt, and too narrow to
interoperate. The Ethos of Lux exists to prevent those failure modes by
naming the properties we optimize for, in order of priority.

These principles were articulated as the Lux Network was founded on
January 1, 2020. They formalized constraints that were already implicit
in the earliest research---the lattice cryptography library
(\texttt{luxfi/lattice}, August 2019)~\cite{lux-lattice}, the quantum-resistant consensus
primitives~\cite{lux-consensus}, and the multi-party computation design~\cite{lux-mpc}. This revision adds,
for each principle, a single sentence mapping it to its production
realization as of March 2026.

%% ============================================================
\section{The Eight Principles}

\subsection{Approachability}

We want to enable anyone to be a blockchain developer. Lux provides an
intuitive set of APIs and libraries that cater to a wide array of
developer experience levels.

The barrier to entry for blockchain development remains unconscionably
high. Developers must learn new languages (Solidity, Move), new
execution models (gas, nonces, revert semantics), and new deployment
pipelines---all before writing a single line of business logic. Lux
treats developer experience as a first-class engineering objective,
not a documentation afterthought.

\medskip\noindent\textit{2026 status}: The Lux CLI provides one-command
chain creation, contract deployment, and validator management. The
\texttt{luxfi/sdk} supports Go, TypeScript, and Python with identical
API shapes.

\subsection{Availability}

As a payments-focused platform, we appreciate the necessity of
maintaining an extraordinarily high SLA. We provide the best possible
assurances in terms of reliable access to blockchain infrastructure
and ensure developers can count on our APIs to power their business.

A financial system that is intermittently available is not a financial
system. Lux targets five-nines availability at the RPC layer. This
drives every decision from consensus protocol design (Quasar's
leaderless architecture~\cite{lp105} eliminates single-point-of-failure leaders) to
infrastructure topology (multi-region validator sets with geographic
diversity requirements).

\medskip\noindent\textit{2026 status}: Quasar consensus (LP-020)
achieves sub-second finality with no leader election, eliminating
the availability cliff that leader-based protocols suffer under
validator churn.

\subsection{Composability}

As developers, we value small, modular tools and components that we can
assemble to solve any problem at hand. Our focus on composability
provides a simple system to reason about and a flexible platform for
solving problems.

Composability is the difference between a toolkit and a monolith. Every
Lux component---chains, VMs, precompiles, threshold signature
schemes---is designed to be used independently or in combination. A
developer can use the DEX orderbook~\cite{lp306} without the bridge, the MPC signer
without the DEX, the FHE library without the MPC signer. The AMM pools~\cite{lp308}
and the quantum network comparison framework~\cite{lp309} are similarly independent.

\medskip\noindent\textit{2026 status}: 19 EVM precompiles are
independently activatable at genesis. \texttt{luxfi/standard}~\cite{lux-standard} provides
composable Solidity contracts. \texttt{luxfi/mpc}~\cite{lux-mpc} supports CGGMP21,
FROST, and Pulsar~\cite{lux-corona} as independent protocol modules.

\subsection{Flexibility}

Our platform is designed to support extensive customization and is
adaptable to fit the needs of any business. We have used our libraries
and APIs to support a wide range of different businesses and business
models.

Flexibility without constraint is chaos. Lux provides flexibility
through well-defined extension points: custom VMs, pluggable consensus,
configurable precompile sets, and per-chain genesis parameters. The
invariant is that every extension point has exactly one way to use it.

\medskip\noindent\textit{2026 status}: White-label deployments
run sovereign L1 chains with custom token economics, branding, and
regulatory configurations---all on the same node binary compiled with
\texttt{-tags allvms}.

\subsection{Longevity}

We are dedicated to providing developers the most forward-looking
options available and are committed to building a platform that
developers can commit to using for years without fear of missing out
on cutting-edge technology.

Longevity means making bets that will still be correct in a decade.
Lattice-based cryptography over RSA. UTXO models where quantum
resistance matters. Leaderless consensus over leader-based. These are
not trend-chasing decisions---they are durability decisions.

\medskip\noindent\textit{2026 status}: Post-quantum cryptography
(ML-DSA, ML-KEM, Pulsar)~\cite{lp305} is deployed at the consensus layer, not
as a future upgrade path. Quasar's hybrid BLS + lattice design~\cite{lp105,lp307}
ensures the network is quantum-resistant today.

\subsection{Interoperability}

We want to free developers from caring about specific blockchain
implementations while affording them the flexibility to experiment
with as many different blockchain technologies as possible.

A blockchain that cannot talk to other blockchains is a database with
extra steps. Lux provides native cross-chain messaging (Warp), a
bridge architecture with MPC threshold signing (2-of-3, no single
point of compromise), and EVM compatibility for the largest existing
developer ecosystem.

\medskip\noindent\textit{2026 status}: Warp messaging with BLS
aggregation is live. The MPC bridge~\cite{lux-mpc} supports 15+ blockchain networks
via CGGMP21 (ECDSA) and FROST (EdDSA). EVM precompiles provide
in-protocol verification of cross-chain proofs.

\subsection{Security}

Especially given our focus and industry, security is of the utmost
importance. We believe decentralized solutions are inherently more
secure and have designed our architecture always with decentralization
and security foremost in our minds.

Security is not a feature---it is a property of every component. Lux
enforces defense in depth: post-quantum signatures at consensus,
threshold cryptography for key management, FHE for computation privacy,
and formal verification of the core consensus protocol. No single
compromise of any one layer grants an adversary access to user assets.

\medskip\noindent\textit{2026 status}: Three independent PQ signature
schemes (ML-DSA-65, SLH-DSA, Pulsar) are available as EVM
precompiles. The FHE library~\cite{lux-fhe} implements TFHE with
threshold key management. MPC wallets use 2-of-3 threshold signing.

\subsection{Scalability}

We want to remove barriers to widespread adoption of blockchain
technology in terms of both consumer friendliness and ability to
meet demand.

Scalability is not just transactions per second. It is the ability to
add capacity without redesigning the system. Lux achieves this through
horizontal chain creation (each application can run its own chain with
its own validator set), parallelized EVM execution, and a DAG-based
consensus structure that does not serialize all transactions through a
single leader.

\medskip\noindent\textit{2026 status}: The GPU-accelerated CLOB matching
engine sustains 104--126M byte-exact \texttt{uint256} fills per second on an
NVIDIA GB10 (6.9\,ns/match) and roughly 250M fills/s on an Apple M4 Max
(4.15\,ns/match), byte-identical to the CPU reference~\cite{lp306}. Quasar
consensus scales linearly with validator count up to tested limits of 1,000
nodes.

%% ============================================================
\section{Epilogue}

These eight principles have not changed since 2020. What has changed
is the depth of their realization. In 2020, post-quantum security was
an aspiration; in 2026, it is a deployed consensus property
(Quasar~\cite{lp105}: BLS $\wedge$ ML-DSA $\wedge$ Pulsar, Christmas 2025).
In 2020, interoperability meant EVM compatibility; in 2026, it means
native cross-chain messaging (Warp) with threshold-signed bridge
transactions across 15+ blockchain networks~\cite{lux-mpc}.

The principles remain the filter. Every proposal, every pull request,
every architectural decision is evaluated against them. If a change
improves one principle without degrading another, it ships. If it
trades one principle for another, it requires explicit justification
and CTO sign-off.

The Ethos of Lux is not a marketing document. It is the engineering
constitution of the network. The full research archive~\cite{lux-papers} and formal
verification artefacts~\cite{lux-proofs} are publicly available.

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

\bibliographystyle{plain}
\begin{thebibliography}{9}

\bibitem{lp105}
Z.~Kelling, ``LP-020: Quasar --- Quantum-Secure Multi-Engine Consensus
with Triple-Proof Quantum Finality,'' Lux Industries, 2025.

\bibitem{lp305}
Z.~Kelling, ``LP-305: Quantum Secure Assets --- A Pioneering Methodology
for Lux Network in a Post-Quantum Age,'' Lux Industries, 2023 (rev.\ 2026).

\bibitem{lp306}
Z.~Kelling, ``LP-306: LX --- Decentralized Social Trading Exchange,''
Lux Industries, 2022 (rev.\ 2026).

\bibitem{lp307}
Z.~Kelling, ``LP-307: Quantum Consensus Protocol --- Eisenstein Series
and Lattice Signatures,'' Lux Industries, 2023 (rev.\ 2026).

\bibitem{lp308}
Z.~Kelling, ``LP-308: QuantumSwap --- Post-Quantum AMM with
Fungible/Non-Fungible Liquidity Pools,'' Lux Industries, 2024 (rev.\ 2026).

\bibitem{lp309}
Z.~Kelling, ``LP-309: Quantum Network --- Comparative Analysis of
Post-Quantum Resistance Across Blockchain Networks,'' Lux Industries,
2025 (rev.\ 2026).

\bibitem{lux-lattice}
\textit{luxfi/lattice}: Lattice-based cryptographic primitives (CKKS,
BFV, TFHE). Origin: August 2019. \url{https://github.com/luxfi/lattice}.

\bibitem{lux-fhe}
\textit{luxfi/fhe}: TFHE boolean-gate bootstrapping library with
threshold key management. \url{https://github.com/luxfi/fhe}.

\bibitem{lux-corona}
\textit{luxfi/corona}: Module-LWE threshold signature scheme (Ringtail-derived).
\url{https://github.com/luxfi/corona}.

\bibitem{lux-mpc}
\textit{luxfi/mpc}: Multi-party computation (CGGMP21 for ECDSA, FROST
for Ed25519). \url{https://github.com/luxfi/mpc}.

\bibitem{lux-standard}
\textit{luxfi/standard}: Composable Solidity contracts for the Lux EVM.
\url{https://github.com/luxfi/standard}.

\bibitem{lux-consensus}
\textit{luxfi/consensus}: Quasar consensus engine (BLS + ML-DSA +
Pulsar). \url{https://github.com/luxfi/consensus}.

\bibitem{lux-papers}
\textit{luxfi/papers}: Lux research paper archive.
\url{https://github.com/luxfi/papers}.

\bibitem{lux-proofs}
\textit{luxfi/proofs}: Formal verification artefacts (Lean 4, TLA+,
Tamarin, Halmos). \url{https://github.com/luxfi/proofs}.

\end{thebibliography}

\end{document}