papers/lux-security-token-standard/sections/01-introduction.tex

\section{Introduction}


Security tokens---blockchain-based representations of regulated securities---require capabilities far beyond those of standard fungible tokens. An ERC-20 token can be transferred freely between any two addresses. A security token must enforce transfer restrictions based on investor accreditation, jurisdictional rules, lockup periods, and regulatory holds. It must support forced transfers for court orders and regulatory actions. It must maintain auditable records of all ownership changes. It must manage complex capital structures through partitions.

\subsection{Heritage: Arca st-contracts (2018)}

The first production implementation of these requirements was Arca's \texttt{st-contracts}, developed in 2018 for the ArCoin digital security. ArCoin was an interest-bearing token backed by US Treasury bills, requiring:

\begin{itemize}[nosep]
  \item Transfer restrictions: Only accredited investors in permitted jurisdictions could hold ArCoin.
  \item Interest distribution: Automated calculation and distribution of T-bill interest to token holders.
  \item NAV tracking: On-chain net asset value updates reflecting the underlying T-bill portfolio.
  \item Regulatory compliance: Compliance with SEC Regulation D, Rule 506(c) for accredited investor verification.
  \item Forced transfers: Ability to execute transfers mandated by court orders or regulatory actions.
\end{itemize}

The \texttt{st-contracts} implementation used ERC-1400 for the core security token interface and ERC-1404 for transfer restriction logic. This implementation was deployed on Ethereum mainnet and operated without incident for the lifetime of the ArCoin program.

\subsection{Limitations of the Original Design}

The Arca implementation, while functional, had several architectural limitations that motivated the Lux standard:

\begin{enumerate}[nosep]
  \item \textbf{Centralized controller}: A single Ethereum address controlled forced transfers and document management. Compromise of this key would grant full control over all securities.
  \item \textbf{Static restrictions}: Transfer restriction rules were compiled into the contract and required redeployment to update.
  \item \textbf{No quantum resistance}: ECDSA signatures protecting controller operations and investor wallets are vulnerable to Shor's algorithm on future quantum computers.
  \item \textbf{Limited partitioning}: The original ERC-1400 partition implementation did not support the complex capital structures required for private equity, real estate, and structured products.
  \item \textbf{Gas costs}: On Ethereum mainnet, the gas costs for compliance-checked transfers made small-denomination trading economically impractical.
\end{enumerate}

\subsection{Contributions}

This paper presents the Lux Security Token Standard, which addresses each limitation:

\begin{enumerate}[nosep]
  \item MPC threshold controller: Controller operations require $t$-of-$n$ threshold signatures, eliminating single points of compromise \cite{lux-mchain-mpc, lux-ats-architecture}.
  \item Dynamic compliance oracles: Transfer restrictions are evaluated by on-chain compliance oracles that reference I-Chain DID claims, enabling rule updates without contract redeployment.
  \item Post-quantum precompiles: ETHFALCON and Pulsar signature verification is available as EVM precompiles, enabling quantum-resistant token operations \cite{lux-ethfalcon-pq}.
  \item Extended partitions: Support for hierarchical partitions with independent restriction rules, enabling complex capital structures.
  \item Lux EVM execution: Low gas costs (sub-cent per transfer) make small-denomination trading viable.
\end{enumerate}