papers/lux-threshold-ux/sections/03-approval-flows.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)
%% The legacy name "T-Chain" is retained ONLY for `teleportvm` (LP-6332).
%% Where this paper says "T-Chain MPC" / "T-Chain threshold governance" /
%% "T-Chain TFHE" / "T-Chain custody", read as M-Chain (MPC) or F-Chain (FHE).
%% ===================================================================

\section{Approval Flows}
\label{sec:approval}

An approval flow is the most direct product mapping of threshold signatures.
The user mental model is: ``This action requires approval from $t$ of $n$
designated approvers before it executes.''

\subsection{Approval Flow Architecture}

\begin{definition}[Approval Flow]
An approval flow $\mathcal{A} = (a, t, n, \{A_1, \ldots, A_n\}, \tau, \mathsf{esc})$
consists of:
\begin{itemize}
    \item $a$: the action to be approved (transaction, access request, configuration change)
    \item $t, n$: the threshold and total approver count
    \item $\{A_1, \ldots, A_n\}$: the set of designated approvers
    \item $\tau$: the timeout (maximum time to collect $t$ approvals)
    \item $\mathsf{esc}$: the escalation policy (what happens if $\tau$ expires without $t$ approvals)
\end{itemize}
\end{definition}

When a user initiates an action that requires approval, the system:

\begin{enumerate}
    \item Creates a pending action record on the T-Chain with the action
    payload and approval metadata.
    \item Sends push notifications to all $n$ approvers: ``[User] requests
    approval for [action description].''
    \item Each approver reviews the action and either approves (producing
    a FROST partial signature) or rejects (recording a rejection on-chain).
    \item When $t$ partial signatures are collected, the M-Chain aggregates
    them into a complete threshold signature, which authorizes the action.
    \item The action executes with the threshold signature as its
    authorization proof.
\end{enumerate}

The approver sees: ``Approve this payment of \$5,000 to Acme Corp?
[Approve] [Reject].'' They do not see: ``Please contribute your Shamir
share to the threshold ECDSA signing ceremony.''

\subsection{Timeout and Escalation}

Real approval flows must handle timeouts. If approvers are unavailable,
the action cannot remain pending indefinitely. The escalation policy
$\mathsf{esc}$ defines the fallback:

\begin{enumerate}
    \item \textbf{Auto-deny.} If $\tau$ expires, the action is denied.
    This is the default for high-security actions.
    \item \textbf{Escalation.} If $\tau$ expires, the approval request
    escalates to a secondary approver set $\{A'_1, \ldots, A'_{n'}\}$
    with a new timeout $\tau'$.
    \item \textbf{Threshold reduction.} If $\tau$ expires, the threshold
    decreases by one (from $t$ to $t-1$) for a limited escalation period.
    This models the real-world pattern of ``if two of three aren't
    available, one can approve with a time delay.''
    \item \textbf{Delegation.} An unavailable approver delegates their
    approval capability to a substitute for a bounded time period.
\end{enumerate}

\begin{proposition}[Escalation Security Bound]
Under the threshold reduction escalation policy, the minimum effective
threshold during escalation is $\max(1, t - e_{\max})$ where $e_{\max}$
is the governance-set maximum escalation depth. If $e_{\max} < t - 1$,
then escalation cannot reduce the threshold to single-signer authorization,
preserving the multi-party security guarantee even during escalation.
\end{proposition}