Files
zeekayandHanzo Dev 178febad68 papers: reconcile T-Chain -> M-Chain / F-Chain / B-Chain per LP-134
Every rendered "T-Chain" / "ThresholdVM" / "teleportvm" reference across
the paper corpus is rewritten to the correct canonical chain by concern:
threshold signing / MPC / bridge custody / key recovery -> M-Chain (MVM);
FHE / encrypted compute / threshold decryption -> F-Chain (FVM); teleport
/ cross-chain messaging -> B-Chain (bridgevm); consensus Pulsar stays
Q-Chain. Section lux-trust-kernel/03-t-chain-threshold-governance.tex
renamed -> 03-f-chain-encrypted-policy.tex (with \input + xref fixes).
Braided "T-Chain" sections split by concern (M vs F). Only lp-020's
chain-separation rationale and the shared lux/chains/thresholdvm library
path retain the name, to record the removal. All changed papers rebuilt
(pdflatex, rc=0, no undefined refs).

§09 of lux-dao-governance-framework reframed: fabricated "production
deployment" metrics ($50M/$240k/$12M, survey %s, "as of Oct 2024")
relabeled as illustrative design configurations with no invented
replacements; reality noted (DAO treasury is a 1/1 Safe); conclusion
echo + one "first production" overclaim softened.

This commit also captures concurrent corpus workstreams on the same tree.

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-02 00:57:09 -07:00

52 lines
3.3 KiB
TeX

%% ===================================================================
%% LP-134 canonical naming (2025-12-15):
%% Per LP-134 (Lux Chain Topology), M-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)
%% M-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{Agent Capsule}
\label{sec:capsule}
\begin{definition}[Agent Capsule]
An Agent Capsule $\mathcal{C} = (I, V, K, B, M)$ is a tuple comprising:
\begin{itemize}
\item $I$: a decentralized identifier (DID) anchored on the I-Chain,
\item $V$: an encrypted vault (SQLite database encrypted with a capsule-local key),
\item $K$: a capability set---a collection of scoped, time-bounded permission tokens,
\item $B$: a budget capsule---an on-chain account with per-action spend limits enforced by the M-Chain,
\item $M$: a private memory store with CRDT synchronization across instances.
\end{itemize}
\end{definition}
The capsule is the atomic unit of agent sovereignty. It is created by a \emph{principal}---a human user, an organization, or another agent---who provisions the initial identity, seeds the vault, grants the initial capability set, and funds the budget. Once instantiated, the capsule operates autonomously within the bounds of its capabilities and budget.
\subsection{Vault}
The vault is an AES-256-GCM encrypted SQLite database stored locally to the agent's execution environment. The encryption key is derived from the agent's DID private key via HKDF-SHA256:
\begin{equation}\label{eq:vault-key}
k_{\text{vault}} = \text{HKDF}(\text{sk}_I, \text{``vault''}, 256)
\end{equation}
The vault stores the agent's persistent state: tool configurations, learned preferences, intermediate computation results, credential material, and action history. The vault is opaque to the host environment---the execution platform cannot read its contents without the agent's private key.
\subsection{Lifecycle}
An Agent Capsule transitions through four states:
\begin{enumerate}
\item \textbf{Provisioned.} The principal creates the DID, encrypts the initial vault, grants capabilities, and funds the budget. The capsule exists on-chain but is not executing.
\item \textbf{Active.} The capsule is bound to an execution environment and processing tasks. It reads and writes to its vault, exercises capabilities, and draws from its budget.
\item \textbf{Suspended.} The capsule is temporarily halted---capabilities are frozen, budget draws are paused, but state is preserved. Suspension can be triggered by the principal, by budget exhaustion, or by a capability revocation event.
\item \textbf{Terminated.} The capsule is permanently deactivated. The vault is sealed (encrypted with a recovery key held by the principal), the DID is marked as deactivated on the I-Chain, and remaining budget is returned to the principal.
\end{enumerate}
State transitions are recorded on the I-Chain as verifiable lifecycle events, ensuring that the full history of a capsule's existence is auditable.