papers/lux-app-architecture/sections/04-the-trust-kernel.tex

%% ===================================================================
%% LP-134 canonical naming (2025-12-15):
%% Per LP-134 (Lux Chain Topology), T-Chain has been split into:
%%   M-Chain — MPC ceremonies for bridge custody of EXTERNAL wallets
%%             (CGGMP21, FROST, Pulsar-general)
%%   F-Chain — FHE compute + TFHE bootstrap-key generation (encrypted EVM)
%% T-Chain is REMOVED entirely; teleport is B-Chain (bridgevm, LP-6000). No teleportvm.
%% Where this paper says "M-Chain MPC" / "M-Chain threshold governance" /
%% "M-Chain TFHE" / "M-Chain custody", read as M-Chain (MPC) or F-Chain (FHE).
%% ===================================================================

\section{The Trust Kernel}
\label{sec:trust}
% ============================================================================

Lux serves as the trust kernel for all capsules. Trust is factored across four
purpose-built chains, each optimized for a specific class of trust operation.

\subsection{Architecture}

\begin{figure}[H]
\centering
\begin{tikzpicture}[
  chain/.style={draw, rounded corners, minimum width=2.8cm, minimum height=0.9cm,
                font=\small\bfseries, align=center},
  arr/.style={-{Stealth[length=2mm]}, thick},
  every node/.style={font=\small}
]
  % Chains
  \node[chain] (ichain) at (0,0) {I-Chain\\{\footnotesize Identity}};
  \node[chain] (kchain) at (3.5,0) {K-Chain\\{\footnotesize Key Policy}};
  \node[chain] (tchain) at (7,0) {M-Chain\\{\footnotesize Key Reveal}};
  \node[chain] (mchain) at (10.5,0) {M-Chain\\{\footnotesize MPC Signing}};

  % Primary network
  \node[chain, minimum width=11.8cm, fill=black!5] (primary)
    at (5.25,-2) {Lux Primary Network --- Audit Anchors};

  % Capsule
  \node[chain, dashed, minimum width=3cm] (capsule) at (5.25,2) {Capsule};

  % Arrows
  \draw[arr] (capsule) -- (ichain) node[midway,left,font=\footnotesize] {DID};
  \draw[arr] (capsule) -- (kchain) node[midway,left,font=\footnotesize] {policy};
  \draw[arr] (capsule) -- (tchain) node[midway,right,font=\footnotesize] {reveal};
  \draw[arr] (capsule) -- (mchain) node[midway,right,font=\footnotesize] {sign};
  \draw[arr] (ichain) -- (primary);
  \draw[arr] (kchain) -- (primary);
  \draw[arr] (tchain) -- (primary);
  \draw[arr] (mchain) -- (primary);
\end{tikzpicture}
\caption{Trust kernel architecture. Four purpose-built chains anchor to the Lux
primary network.}
\label{fig:trust}
\end{figure}

\subsection{I-Chain: Identity}\label{sec:ichain}

I-Chain stores DID documents conforming to the W3C DID Core specification.
Each capsule has exactly one DID anchored on I-Chain. The DID document contains:

\begin{itemize}[nosep]
  \item Public keys (verification methods) for authentication and capability
        invocation.
  \item Service endpoints for sync relay discovery.
  \item Controller relationships for organizational hierarchies.
  \item Post-quantum key material (ML-DSA public keys) alongside classical
        Ed25519 keys for hybrid verification.
\end{itemize}

DID resolution is a read from I-Chain state. DID updates require a transaction
signed by the current controller key. The full specification is
in~\cite{lux-id-did}.

\subsection{K-Chain: Key Policy}\label{sec:kchain}

K-Chain stores and enforces key lifecycle policies:

\begin{itemize}[nosep]
  \item \textbf{Rotation schedules}: mandatory key rotation intervals, grace
        periods, and automatic revocation on expiry.
  \item \textbf{Threshold definitions}: $(t, n)$ parameters for recovery,
        delegation, and administrative actions.
  \item \textbf{Wrapping policy}: which keys may wrap which other keys,
        preventing unauthorized key export.
  \item \textbf{Capability constraints}: maximum delegation depth, time-bounded
        grants, resource-scoped permissions.
\end{itemize}

K-Chain validators enforce policy at the transaction level. A key rotation
transaction that violates the capsule's policy (e.g., rotating before the
minimum interval) is rejected at consensus.

\subsection{M-Chain: Threshold Key Reveal}\label{sec:tchain}

M-Chain coordinates threshold operations: secret sharing, reconstruction, and
time-locked reveals. The protocol:

\begin{enumerate}[nosep]
  \item A proposer submits a \textit{reveal request} specifying the secret
        identifier, the threshold $(t, n)$, and an expiration block height.
  \item Each share holder submits their share as an encrypted payload
        (encrypted to the proposer's public key) within the expiration window.
  \item Once $t$ shares are submitted, M-Chain verifies the Feldman VSS
        commitments and emits a \textit{reveal receipt}.
  \item The proposer reconstructs the secret locally.
\end{enumerate}

The chain never sees the secret in plaintext. It verifies share validity
through commitment schemes and enforces the threshold policy defined on K-Chain.

\subsection{M-Chain: MPC Signing}\label{sec:mchain}

M-Chain provides decentralized multi-party computation for cross-chain signing,
as specified in~\cite{lux-mchain-mpc}. Capsules interact with M-Chain when they
need to authorize operations on external chains (Bitcoin, Ethereum, etc.) without
exposing a single private key.

The signing flow: the capsule submits a signing request to M-Chain. Validators
holding key shares execute the threshold signature protocol (CGG21 for ECDSA,
FROST for EdDSA, Pulsar for post-quantum). The aggregated signature is
returned to the capsule and broadcast to the target chain.

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