papers/lux-warp-messaging/sections/11-protocol-extensions.tex

\section{Protocol Extensions}
\label{sec:extensions}

\subsection{Conditional Message Execution}

Warp messages can include execution conditions evaluated on the destination:

\begin{definition}[Conditional Warp Message]
A conditional message $\mathcal{M}_c = (\mathcal{M}, \mathsf{condition})$ where $\mathsf{condition}$ is a predicate over destination chain state. The message payload executes only if the condition evaluates to true at execution time.
\end{definition}

Use cases include price-conditional cross-chain swaps, time-locked governance votes, and state-dependent contract calls.

\subsection{Message Ordering Guarantees}

\begin{definition}[FIFO Ordering]
For messages from the same source to the same destination, LWM guarantees FIFO delivery: if $\mathcal{M}_1$ is emitted before $\mathcal{M}_2$ on the source, then $\mathcal{M}_1$ is processed before $\mathcal{M}_2$ on the destination.
\end{definition}

This is enforced by the nonce mechanism (Algorithm~\ref{alg:verification}, line 8): the destination accepts nonce $k$ only if nonce $k-1$ has been processed.

\begin{proposition}[Causal Ordering]
FIFO ordering per source-destination pair, combined with application-level dependency tracking, provides causal ordering for multi-party cross-chain protocols.
\end{proposition}

\subsection{Recursive Aggregation for Multi-Hop}

For messages traversing multiple appchains (e.g., $A \to B \to C$), recursive BLS aggregation avoids linear proof growth:

\begin{algorithm}[H]
\caption{Multi-Hop Warp Relay}
\label{alg:multihop}
\begin{algorithmic}[1]
\Require Message $\mathcal{M}$ from appchain $A$ to appchain $C$ via appchain $B$
\State Appchain $A$ validators sign $\mathcal{M}$, produce $\Pi_A$
\State Relayer delivers $(\mathcal{M}, \Pi_A)$ to appchain $B$
\State Appchain $B$ verifies $\Pi_A$, processes or forwards
\State Appchain $B$ validators sign forwarded message, produce $\Pi_B$
\State $\Pi_{\text{recursive}} \gets (\Pi_A, \Pi_B)$ \Comment{Chain of proofs}
\State Relayer delivers $(\mathcal{M}, \Pi_{\text{recursive}})$ to appchain $C$
\State Appchain $C$ verifies $\Pi_B$ (trusts $B$'s verification of $\Pi_A$)
\end{algorithmic}
\end{algorithm}

Each hop adds 48 bytes (aggregate signature) plus bitmap. For a 3-hop path with 100-validator appchains: total proof $\approx 3 \times (48 + 13) = 183$ bytes.

\subsection{Version Identification}

LWM messages include a version byte in the domain separator for honest version identification across forward-only protocol upgrades:
\begin{equation}
    d_v(\mathcal{M}) = H_{\text{warp}}\bigl(\texttt{"LUX-WARP-V"} \| v \| \mathsf{src} \| \cdots\bigr)
\end{equation}

The version byte is for identification, not protocol-level fallback: a destination that cannot validate a version's transcript binding rejects those bytes rather than downgrading. Migration is forward-only---no negotiation and no simultaneous multi-version acceptance---as specified for Warp 2.0 (LP-021v2).

\paragraph{Warp 2.0 (LP-021v2 / LP-6022).}
The current shipping version is \textbf{Lux Warp 2.0}, a Prism-bound
hybrid envelope that carries the Warp 1.x message intact (the
\emph{Beam} lane: BLS aggregate + signer bitmap, this paper) alongside
two post-quantum lanes: a per-validator \emph{ML-DSA cert set}
(FIPS 204) and a \emph{Pulse} produced by the source chain's Pulsar
threshold kernel (Lux's variant with DKG2 + Pulsar-SHA3, see LP-073).
All three lanes are bound to a common source-chain transcript, so a
destination chain can verify under any combination of classical / PQ
assumptions, and Warp 1.x bytes parse forward into a Warp 2.0 envelope
with PQ lanes empty. Reference implementation:
\texttt{github.com/luxfi/warp} (\texttt{envelope.go}, \texttt{pulsar/}).
Warp 2.0 is the envelope path used by Lux's Quasar consensus
integration (LP-110); Lux Teleport (LP-6332) is the asset-transfer
protocol layered on top.

\subsection{Rate Limiting and Flow Control}

To prevent spam, each source-destination pair has a configurable message rate limit:

\begin{definition}[Rate Limit]
Each appchain pair $(s, d)$ has a maximum message rate $\mu_{s,d}$ messages per epoch. Messages exceeding this rate are queued and delivered in subsequent epochs. The rate limit is set by the destination appchain's governance.
\end{definition}

\begin{table}[H]
\centering
\caption{Default rate limits by message type.}
\label{tab:ratelimits}
\begin{tabular}{lrr}
\toprule
\textbf{Message Type} & \textbf{Per-Epoch Limit} & \textbf{Per-Block Limit} \\
\midrule
Token transfer & 10,000 & 50 \\
Contract call & 5,000 & 25 \\
Validator set update & 1 & 1 \\
Governance action & 10 & 1 \\
\bottomrule
\end{tabular}
\end{table}