papers/lux-for-coinbridge/lux-for-coinbridge.tex

\documentclass[11pt,a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[margin=1in]{geometry}
\usepackage{longtable}
\usepackage{booktabs}
\usepackage{enumitem}
\usepackage{hyperref}
\usepackage{xcolor}
\usepackage{array}
\usepackage{tabularx}

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

\definecolor{accent}{RGB}{22,82,163}
\newcommand{\product}{\textsc{Sovereign}}
\newcommand{\customer}{Coinbridge.US}

\title{Lux for \customer\\[4pt]
\large A sovereign, post-quantum, non-custodial stack for regulated
securities tokenization}
\author{Lux Network}
\date{}

\begin{document}
\maketitle

\begin{abstract}
This document describes what Lux proposes to deliver to \customer\ as our
first white-label customer: a complete, regulated digital-securities
platform that \customer\ operates under its \emph{own} brand, on its
\emph{own} sovereign Layer-1 blockchain, with keys it never has to
custody. The platform folds a core bank, banking-as-a-service, payment
rails, a general-securities tokenization engine, an alternative trading
system, broker-dealer and transfer-agent functions, and a non-custodial
custody service into a single binary whose every capability can be turned
on or off per deployment. The chain underneath it carries its own EVM,
its own Uniswap-compatible DEX, and an FHE coprocessor for confidential
compute. Signing is post-quantum throughout. A live demonstration runs on
two isolated networks --- testnet and devnet --- reachable today at
\texttt{*.testnet.lux.financial} and \texttt{*.devnet.lux.financial}.
\end{abstract}

\section{The proposition}

\customer\ needs to issue, trade, settle, and custody tokenized
securities under U.S.\ and offshore regulatory regimes, with the
operational independence of running its own infrastructure rather than
renting a slot on someone else's. Lux delivers exactly that as a
\textbf{white-label reference stack}: a single deployable that \customer\
brands as its own, configures to the capabilities it is licensed for, and
runs on a sovereign chain it controls.

Three properties define the offer:

\begin{enumerate}[leftmargin=*]
  \item \textbf{Sovereign.} \customer\ runs its own Layer-1 --- its own
  validator set, its own EVM chain id, its own DEX and FHE coprocessor.
  The platform does not depend on any shared mainnet to function. Any
  customer can launch its own L1 the same way.
  \item \textbf{Non-custodial.} Private keys are never assembled in one
  place. Custody is threshold MPC with an FHE policy layer; \customer\
  --- and Lux --- can be structurally incapable of unilaterally moving a
  client's assets.
  \item \textbf{Post-quantum.} Service identity and signing use
  lattice-based ML-DSA today, so records signed now remain verifiable
  after a cryptographically-relevant quantum computer exists.
\end{enumerate}

The remainder of this document walks the capabilities and the live demo.

\section{The sovereign Layer-1}

Each deployment settles on its own sovereign L1. Following the
sovereign-L1 model, the primary network id \emph{equals} the EVM chain id
--- one identifier names the chain everywhere (wallets, tools,
staking-key derivation), eliminating the ambiguity of separate network
and chain ids. The reference demo runs two isolated sovereign networks:

\begin{center}
\begin{tabular}{lll}
\toprule
Environment & Network id (= EVM chain id) & Demo hosts \\
\midrule
testnet & 5 & \texttt{*.testnet.lux.financial} \\
devnet  & 6 & \texttt{*.devnet.lux.financial} \\
\bottomrule
\end{tabular}
\end{center}

These ids are deliberately distinct from any production chain id. Each
network carries:

\begin{itemize}[leftmargin=*]
  \item a full \textbf{EVM} with the complete precompile set, so standard
  Solidity tooling, audited token templates, and existing contracts work
  unmodified;
  \item a \textbf{Uniswap-compatible DEX} for on-chain secondary
  liquidity in tokenized instruments, white-labeled into \customer's swap
  surface;
  \item an \textbf{FHE coprocessor} for confidential on-chain compute ---
  encrypted balances, private order matching, and policy checks that never
  expose the underlying values.
\end{itemize}

A block explorer is published per network so \customer\ and its auditors
can inspect every issuance, transfer, and settlement.

\section{General-securities tokenization}

The tokenization engine treats a security as an ERC-20-shaped on-chain
instrument wrapped in a regulatory record. It supports a general,
extensible set of asset classes:

\begin{center}
\begin{tabular}{ll}
\toprule
Class & Examples \\
\midrule
equity      & common / preferred shares, SAFE conversions \\
debt        & notes, bonds, revenue-based instruments \\
fund        & LP interests, tokenized funds \\
note        & convertible and promissory notes \\
warrant     & options and warrants \\
real\_estate & fractional property, REIT units \\
commodity   & metals, carbon, tokenized reserves \\
stablecoin  & fiat-referenced settlement tokens \\
\bottomrule
\end{tabular}
\end{center}

Each issuance records the issuer, the asset class, decimals and supply (in
base units), the jurisdiction, and whether the instrument is
transfer-restricted (e.g.\ Reg~D / Reg~S lock-ups). Off-chain the
issuance is a signed registry entry; on a connected chain it deploys the
contract and anchors the registry id, so the registry and the chain agree
by construction. Symbols are unique per issuer.

The flow is live in the demo today. Issuing an instrument is a single
call --- the platform validates the request, scales the amount to base
units, persists the regulatory record, and (with a chain connected)
deploys and mints. The same procedure is reachable as an HTTP endpoint and
as a binary RPC the admin console uses directly.

\section{Non-custodial custody (MPC + TFHE)}

Custody is built on threshold MPC: a private key is split into shares held
by independent parties and \emph{never} reconstructed --- signatures are
produced by a distributed protocol, so no single host (and no single
operator) ever holds a spendable key. An FHE/TFHE policy layer evaluates
spending policy over encrypted state, so authorization checks --- limits,
allow-lists, dual control --- run without decrypting balances or
beneficiary data.

For \customer\ this means client assets are protected by cryptography, not
merely by access control, and the custody posture is demonstrable to a
regulator: the system is \emph{structurally} non-custodial.

\section{Regulated trading and transfer}

\begin{description}[leftmargin=*]
  \item[ATS] An alternative trading system with a high-throughput
  central-limit order book for tokenized instruments, multi-tenant from
  day one, settling on the sovereign L1.
  \item[Broker-Dealer] Order intake, suitability, and execution surfaces
  for the regulated broker-dealer function.
  \item[Transfer Agent] The authoritative cap table: holders, positions,
  restrictions, corporate actions --- kept in lock-step with on-chain
  balances.
\end{description}

These compose with tokenization and custody as modules in the same
binary, so an instrument issued by the tokenization engine is immediately
tradeable on the ATS and tracked by the transfer agent without
integration glue.

\section{Banking: BaaS and payments}

The core bank ledger fronts a banking-as-a-service backend. The reference
integration targets \textbf{SF Private Bank LTD} (International Banking
Licence L17601/SFPB, Union of Comoros Offshore Finance Authority --- FSA
Offshore; LEI 254900Y05KODH3HSN321) as the BaaS provider; a customer
swaps in its own provider through one configuration block. A payment
service provider module supplies fiat on/off ramps and settlement rails.
Credentials are resolved from KMS at boot --- never inlined.

\section{White-label and sovereignty}

Everything a customer sees is data, not code. Brand name, legal name,
domain, logo, colors, and the regulatory licence citation come from one
white-label configuration resolved per request by hostname. The product
ships brand-neutral; \customer\ supplies its identity and the platform
renders as \customer's own. The capability set is gated the same way:
\customer\ enables exactly the modules it is licensed to operate, and the
rest are never mounted.

Because the chain is sovereign, \customer\ owns the network --- and any
future customer launches its own L1 by the same procedure. There is no
shared multi-tenant chain to trust.

\section{The live demonstration}

The demo is deployed on the two isolated sovereign networks above. On each
of \texttt{*.testnet.lux.financial} and \texttt{*.devnet.lux.financial},
\customer\ will see:

\begin{itemize}[leftmargin=*]
  \item \texttt{admin.\{testnet,devnet\}.lux.financial} --- the unified,
  brand-configurable console listing every composed capability;
  \item \texttt{ats.\,/bd.\,/ta.\,/baas.} --- the regulated stack
  surfaces, each on its subdomain;
  \item the \textbf{tokenization} flow end-to-end: issue a tokenized
  security, see it on the cap table and in the explorer;
  \item the \textbf{swap} surface: a Uniswap-compatible DEX trade of a
  tokenized instrument;
  \item the \textbf{explorer}: every issuance, transfer, and settlement
  on-chain;
  \item post-quantum signing and non-custodial custody operating
  underneath all of it.
\end{itemize}

The networks are demo-only (testnet/devnet); production for a licensed
customer settles on that customer's own mainnet L1.

\section{Architecture}

The stack is one Go binary. Each capability --- bank, BaaS, PSP,
tokenization, ATS, broker-dealer, transfer-agent, custody --- is a module
that mounts its own HTTP routes and binary RPC procedures onto a shared
host; the host gates which modules are enabled per customer. A module
never owns a process, so the identical code runs as one folded binary or
as independent services. Persistence is an encrypted embedded store;
transport is a single binary wire protocol that browsers reach over
WebSocket, so the console and back-end services share one procedure
registry. The build is pure Go --- no native toolchain --- and
post-quantum signing is on by default.

\section{Engagement}

We propose a staged engagement: (1) \customer\ explores the live demo on
the testnet and devnet sovereign L1s; (2) we configure \customer's brand,
jurisdiction, licence citation, and enabled capabilities; (3) we stand up
\customer's own sovereign mainnet L1 under \customer's validators and
brand. The platform \customer\ evaluates is the platform \customer\ ships
--- the only differences are configuration and the network it settles on.

\end{document}