feat(defense): Reindustrialization suite — one-pager + 6 new papers, minimal covers, papers.hanzo.ai routes

- One-pager (hanzo-overview): 'Hanzo Cloud for Reindustrialization' — sovereign AI, robotics, spatial 3D, post-quantum, low-latency on-chain coordination; H logo, QR, links. - New papers: vs-claude, cloud-economics, agentic-prowess, fhe-native, security, compliance. - Reconciled case-study numbers (200+ microservices to 3 binaries; 3.07M to 1.06M lines; ~90% / ~$380K/yr GCP cost cut; 93 findings remediated). Client fully anonymized. - Minimal cover (H logo top-left), Hanzo-only branding, approved-for-public-release. - Site: per-paper /<slug> routes + bundled PDFs (fixes papers.hanzo.ai 404s).
2026-10-22 17:20:17 +00:00 · 2026-06-17 13:35:08 -07:00
parent 2235d2b379
commit bf4a779a2a
56 changed files with 2723 additions and 167 deletions
@@ -15,13 +15,21 @@ than on centralized cloud.

 Each claim below is developed in the catalogued papers ([INDEX.md](INDEX.md)):

- **Defense research suite (10 papers).** Autonomous agentic AI for cyber/intel/decision
-  support (`hanzo-agentic-ai`), DDIL/tactical assured networking over mesh and packet
-  radio (`hanzo-assured-networking`), FHE-mediated cross-domain MLS (`hanzo-cross-domain`),
-  edge AI/ML on embedded hardware (`hanzo-edge-ai-ml`), counter-exploitation
-  (`hanzo-countermeasures`), full-spectrum cyber (`hanzo-full-spectrum-cyber`), quantum
-  sensing/QKD (`hanzo-quantum-sensing-qkd`), verification & validation
-  (`hanzo-test-evaluation`), and the ZAP protocol (`hanzo-zap-protocol`).
+- **Defense & Reindustrialization suite (16 papers + one-pager).** Positioned for the
+  American industrial base — sovereign AI, robotics, post-quantum, and low-latency
+  on-chain coordination for factories, vehicles, drones, ships, and contested-edge
+  systems. **Strategy & case studies:** sovereign-vs-closed AI (`hanzo-vs-claude`), the
+  ~90% cloud-cost migration on real numbers (`hanzo-cloud-economics`), agentic
+  engineering at regulated scale (`hanzo-agentic-prowess`), FHE-native confidential
+  computing (`hanzo-fhe-native`), automated security auditing (`hanzo-security`), and
+  audit-ready compliance (`hanzo-compliance`). **Capability depth:** autonomous agentic
+  AI (`hanzo-agentic-ai`), DDIL/tactical assured networking (`hanzo-assured-networking`),
+  FHE-mediated cross-domain MLS (`hanzo-cross-domain`), edge AI/ML (`hanzo-edge-ai-ml`),
+  counter-exploitation (`hanzo-countermeasures`), full-spectrum cyber
+  (`hanzo-full-spectrum-cyber`), quantum sensing/QKD (`hanzo-quantum-sensing-qkd`),
+  verification & validation (`hanzo-test-evaluation`), and the ZAP protocol
+  (`hanzo-zap-protocol`). Start with the one-pager (`defense/hanzo-overview.pdf`); the
+  full suite is published at **[papers.hanzo.ai](https://papers.hanzo.ai)**.
 - **Production post-quantum cryptography.** All three NIST PQC standards — FIPS 203
  (ML-KEM), 204 (ML-DSA), 205 (SLH-DSA) — integrated into a live consensus system with
  hybrid classical/post-quantum security (`hanzo-full-spectrum-cyber`).
@@ -1,4 +1,4 @@
-\documentclass[11pt,a4paper]{article}
+\documentclass[11pt,letterpaper]{article}
 \usepackage{hanzo-defense}

 \doctitle{Agentic AI for Autonomous Cyber Operations\\and Multi-Domain Intelligence Fusion}
@@ -6,7 +6,7 @@
 \docversion{Version 1.0 --- February 21, 2026}
 \docdate{February 2026}
 \docauthors{Zach Kelling --- Hanzo Team}
-\docorgs{Hanzo Industries \quad Lux Industries \quad Zoo Labs Foundation\\[email protected]}
+\docorgs{Hanzo Industries\\[email protected]}

 \begin{document}
 \makecover
@@ -15,6 +15,9 @@
 We present an agentic AI framework comprising 83 specialized agents and 15 multi-agent orchestrators for autonomous cyber operations, intelligence fusion, and tactical decision support. The framework operates across three tiers: (1) a Playground control plane providing Kubernetes-like orchestration for autonomous AI agents with W3C DID identity, verifiable credentials, and durable state; (2) an agent SDK with async-first execution, OpenAI-compatible APIs, and native Model Context Protocol (MCP) integration exposing 13 canonical tools; and (3) a ZAP-based consensus protocol enabling distributed agent voting with threshold agreement and post-quantum authentication. Agents execute 200--300 sequential tool calls for deep analysis, coordinate via zero-copy binary RPC at 4.2M calls/second, and operate fully disconnected on edge hardware using quantized Zen models (0.8B--27B parameters). The system supports automated red/blue team operations, vulnerability chain analysis, multi-source intelligence correlation, and course-of-action generation with explainable reasoning via chain-of-thought traces. A multi-channel bot platform unifies 20+ messaging channels under local-first privacy controls for secure operator interaction.
 \end{abstract}

+\paragraph{Executive Summary.}
+This framework lets a team field a fleet of AI agents that investigate, defend, and analyze on their own---running on a laptop or a rugged edge device with no connection to the cloud. It is built for cyber-operations teams and intelligence analysts who must act at machine speed and cannot afford to ship sensitive data to an outside service. Every agent action is cryptographically signed, so there is a complete, tamper-proof record of what each agent did and why; and high-stakes calls require several independent agents to agree before anything is recommended, which guards against a single model's mistake. Operationally, this means continuous vulnerability hunting, automated red/blue exercises, and fused multi-source intelligence with a human always in the loop for final decisions---all owned and run by the operator, not rented from a remote provider. The result is autonomous capability without surrendering control, accountability, or the data itself.
+
 \tableofcontents
 \newpage

@@ -35,6 +38,10 @@ Agentic AI addresses these challenges through autonomous agents that reason, pla
 \item \textbf{Tool-native}: Agents interact with systems through 13 canonical MCP tools, not bespoke integrations.
 \end{enumerate}

+\subsection{Strategic Context}
+
+This agent framework is one layer of an integrated stack built by Hanzo, an American applied-AI lab founded in 2014 (Techstars '17) whose founder works at the frontier of both AI/ML and cryptography. American frontier AI has consolidated into a closed monoculture---effectively two labs---while the only openly available frontier model weights today are largely foreign. Hanzo is the American open-source frontier alternative: it owns both the model (the Zen family, 0.8B--1T+ parameters, with owned weights) and the cryptography (a production post-quantum stack), so defense and regulated users get sovereign, open, auditable AI without renting from the closed duopoly or depending on foreign open weights. For autonomous cyber and intelligence work that requirement is acute---the agents here reason over the most sensitive data an organization holds, so the model performing that reasoning must be one the operator can own, inspect, and run disconnected, on their own hardware, where the data already lives. The same agentic stack is what makes this practical at scale: Hanzo used it to deliver a FINRA/SEC-approved, SOC2-compliant securities platform to production---a full ATS/BD/TA stack consolidated from 200+ microservices into 3 compiled binaries, in record time, with a small team---demonstrating that agent-driven engineering meets the bar of a heavily regulated, audited domain.
+
 % ============================================================================
 \section{Agent Architecture}
 % ============================================================================
@@ -354,7 +361,7 @@ HUMINT & Report processing and entity extraction & \texttt{code} (NER), \texttt{

 \subsection{Graph-Based Fusion}

-The Lux GraphVM provides in-memory graph analytics for intelligence correlation:
+The GraphVM provides in-memory graph analytics for intelligence correlation:

 \begin{itemize}
 \item \textbf{Entity resolution}: Link entities across SIGINT, IMINT, and OSINT sources.
@@ -536,7 +543,7 @@ The framework's key differentiators---post-quantum agent identity, consensus-val

 \bibitem{zap} Hanzo Team, ``ZAP: Zero-Copy Application Protocol,'' 2026.

-\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Lux Industries, 2025.
+\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Hanzo, 2025.

 \bibitem{corona} ``Two-Round Threshold Signature from LWE,'' IACR ePrint 2024/1113.

@@ -0,0 +1,230 @@
+\documentclass[11pt,letterpaper]{article}
+\usepackage{hanzo-defense}
+
+\doctitle{Agentic Engineering at Regulated Scale:\\Building a Post-Quantum, FHE-Native\\Securities Platform}
+\docid{HAI-DEF-2026-013}
+\docversion{Version 1.0}
+\docdate{2026}
+\docauthors{Zach Kelling --- Hanzo Team}
+\docorgs{Hanzo Industries\\[email protected]}
+
+\begin{document}
+\makecover
+
+\begin{abstract}
+We document the engineering capability behind Hanzo's stack by way of its hardest
+production proof: an agent-driven team built a fully regulated securities
+venue---an SEC-registered alternative trading system (ATS) with broker-dealer and
+transfer-agent functions---on a next-generation foundation of production
+post-quantum cryptography, a high-performance native-GPU blockchain, and
+fully-homomorphic-encryption (FHE) privacy. The build \emph{consolidated} rather
+than sprawled---200+ microservices collapsed into 3 compiled binaries, with 3.07M
+lines of code reduced to 1.06M active ($\sim$3.5M lines of dead code deleted)---reaching
+production in record time with a small team, and passed FINRA/SEC approval and SOC\,2
+compliance. This is not template web
+software; it is among the most compliance-heavy and cryptographically advanced
+software domains that exists. We describe the throughput of the agentic
+engineering method that produced it, and we expand on the defense relevance of
+its FHE layer---computing on data one is not permitted to see.
+\end{abstract}
+
+\paragraph{Executive Summary.}
+The fastest way to judge an engineering organization is what it has shipped under
+real constraints. Hanzo's founding CTO, Zach Kelling, was ranked the
+\textbf{\#1 user of Anthropic by token count worldwide in 2025} (per public usage
+tracking at \texttt{claudecount.com})---a marker of an engineer operating
+agentic AI at the frontier of throughput. That throughput is not spent on
+brochure sites: the flagship production system built with Hanzo's agentic stack
+is a \textbf{fully regulated securities exchange}---an SEC-registered ATS with
+broker-dealer and transfer-agent functions---running on \textbf{post-quantum
+cryptography}, a \textbf{native-GPU high-performance blockchain}, and
+\textbf{fully homomorphic encryption} for privacy. The build \emph{consolidated}
+rather than sprawled---200+ microservices collapsed into 3 compiled binaries, 3.07M
+lines of code cut to 1.06M active---shipped fast with a small team, and cleared
+FINRA/SEC approval and SOC\,2. Regulated financial infrastructure is one of the hardest,
+most audited software domains there is; clearing it on a cryptographically
+advanced foundation is the proof that agent-driven engineering is production-grade,
+not a demo---and that it is exactly the capability needed to modernize defense
+software stacks.
+
+\tableofcontents
+\newpage
+
+% ============================================================================
+\section{The Engineer and the Throughput}
+% ============================================================================
+
+Agentic engineering multiplies a strong engineer; it does not replace one. Hanzo's
+founding CTO works at the frontier of both AI/ML and cryptography---the two
+disciplines this stack fuses---and operates agentic AI at a volume that placed him,
+by public token-count tracking (\texttt{claudecount.com}), as the top Anthropic
+user in the world in 2025. The relevant point is not the ranking for its own sake;
+it is what that volume was spent producing. Raw AI usage that yields disposable
+prototypes proves nothing. Raw AI usage that yields a regulated, audited,
+cryptographically advanced production system proves the method works where it is
+hardest.
+
+% ============================================================================
+\section{What Was Built}
+% ============================================================================
+
+The flagship system is a regulated securities venue, not a content site. In U.S.
+securities terms it spans three regulated functions that ordinarily take separate
+firms years to stand up:
+
+\begin{itemize}
+  \item \textbf{Alternative Trading System (ATS)} --- an SEC-registered trading
+  venue (Regulation ATS), matching and executing orders.
+  \item \textbf{Broker-Dealer (BD)} --- FINRA-regulated, with the supervisory,
+  recordkeeping, and capital obligations that entails.
+  \item \textbf{Transfer Agent (TA)} --- SEC-registered, maintaining the
+  authoritative record of securities ownership and transfers.
+\end{itemize}
+
+These functions are governed by some of the most exacting compliance regimes in
+software. The notable engineering fact is that the build \emph{consolidated} rather
+than sprawled: a legacy estate of \textbf{200+ microservices} on a public cloud was
+collapsed into \textbf{3 compiled binaries}, and the codebase went from
+\textbf{3.07M lines to 1.06M active} ($\sim$70\% smaller, with $\sim$3.5M lines of
+dead code deleted; the trading/auth core itself shrank from $\sim$264{,}000 to
+$\sim$44{,}000 lines, with 1.3\,GB of vendored dependencies eliminated and a single
+48\,MB binary subsuming 17+ formerly separate services). It reached production
+\textbf{in record time}, with a \textbf{small team}, and was carried through
+\textbf{FINRA/SEC approval} and \textbf{SOC\,2} compliance---leaner than the system
+it replaced, not larger.
+
+% ============================================================================
+\section{One Engineer, a Team's Output}
+% ============================================================================
+
+The result that matters most is the ratio of output to headcount. The agentic method
+let a \emph{single} AI-augmented engineer carry the bulk of a regulated production
+platform that a conventional organization staffs as a full team---and the project's
+own git history documents it. In a \textbf{10-day remediation sprint}, one engineer
+produced \textbf{3,694 commits}, added $\sim$55{,}000 lines and removed
+$\sim$\textbf{3.5 million lines of dead code} across \textbf{181 repositories}, and
+authored \textbf{100\% of the critical- and high-severity security fixes}---single-handedly---while
+driving the consolidation of 200+ microservices into three binaries. The security and
+compliance gaps were closed on the path to approval (a source audit of \textbf{93
+findings}, 22 critical, plus \textbf{780+ dependency vulnerabilities} remediated to
+zero actionable), through FINRA/SEC approval and SOC\,2.
+
+The economic consequence is direct. When one engineer, multiplied by the agentic
+stack, produces what a team produces, the \textbf{cost per line of shipped, audited,
+production code} falls by a large factor relative to a conventional staffing
+contract. For a defense or government program the implication is the whole argument:
+the same regulated, post-quantum, FHE-native system, delivered by a fraction of the
+headcount at a fraction of the cost---and owned, not rented. This is what ``agentic
+engineering'' means in practice---not a chatbot writing snippets, but one expert
+operating at the throughput of a department.
+
+% ============================================================================
+\section{The Foundation: Post-Quantum, GPU Blockchain, FHE}
+% ============================================================================
+
+What makes the build a genuine engineering flex is the foundation it runs on---
+each element of which is independently hard:
+
+\begin{itemize}
+  \item \textbf{Production post-quantum cryptography.} All three NIST PQC
+  standards (ML-KEM/203, ML-DSA/204, SLH-DSA/205) in a live system with hybrid
+  classical/quantum security---so the chain of custody for securities records is
+  protected against a future quantum adversary.
+  \item \textbf{Native-GPU high-performance blockchain.} A chain serving as the
+  authoritative, immutable, post-quantum-anchored record of transfers, with
+  GPU-accelerated cryptographic operations for throughput.
+  \item \textbf{Fully homomorphic encryption (FHE).} GPU-accelerated FHE
+  (BFV/BGV/CKKS/TFHE) with threshold decryption, so privacy-sensitive computation
+  runs \emph{on ciphertext}---no single component ever holds both the plaintext
+  and the result.
+\end{itemize}
+
+A team that can compose post-quantum cryptography, a GPU blockchain, and FHE into
+a system that clears securities regulators is a team that can modernize a defense
+software stack to the same foundation.
+
+% ============================================================================
+\section{FHE for the Military: Computing on Data You Cannot See}
+% ============================================================================
+
+Fully homomorphic encryption is the capability with the sharpest defense upside,
+so it is worth drawing out. FHE allows arbitrary computation directly on encrypted
+data: the operator performs the computation and returns an encrypted result
+without ever decrypting the inputs, and only the data owner (or a threshold of
+keyholders) can decrypt the output. The system doing the work never sees the
+plaintext. In the securities platform this protects order and ownership data; the
+same primitive answers several defense problems that have no clean classical
+solution:
+
+\begin{itemize}
+  \item \textbf{Cross-domain transfer on ciphertext.} A cross-domain guard can
+  evaluate a release policy against encrypted content and decide whether data may
+  move between security levels \emph{without ever seeing the data}---removing the
+  guard itself as a point of compromise (developed in the cross-domain paper).
+  \item \textbf{Coalition analytics without disclosure.} Allies can compute a
+  joint result---shared targets, overlapping indicators, combined logistics---over
+  their combined data while each party's raw data stays encrypted and private.
+  Nobody has to surrender sources or methods to get the joint answer.
+  \item \textbf{Private intelligence fusion.} Multi-source correlation can run
+  while the sources remain encrypted, so a breach of the fusion system does not
+  expose the underlying collection.
+  \item \textbf{Encrypted ML inference.} A model can classify encrypted imagery or
+  signals: the data owner never exposes the input, and the model operator never
+  sees it---useful when the data is sensitive, the model is sensitive, or both.
+  \item \textbf{Computation on untrusted infrastructure.} Sensitive workloads can
+  run on contractor or shared infrastructure without exposing the data to the host.
+\end{itemize}
+
+FHE's historical objection is speed; the practical answer in this stack is
+GPU acceleration of the underlying number-theoretic transforms, plus threshold
+decryption so no single party holds the key. ``Compute on data you are not allowed
+to see'' is a capability defense has wanted for decades; here it is a production
+component, not a research slide.
+
+% ============================================================================
+\section{Why Open Source Was the Accelerant}
+% ============================================================================
+
+The obvious question is how a small team shipped a regulated, cryptographically
+advanced system of this scale so quickly. The answer is open source---specifically,
+an \emph{owned} open-source stack composed by an agentic engineering method.
+
+Hanzo did not assemble the platform from a patchwork of third-party SaaS. It
+composed it from coherent open-source building blocks that Hanzo itself authors
+and controls---identity and access management, key management, the data layer, the
+gateway and ingress, the ZAP transport, the post-quantum and FHE cryptography, the
+operator, and the Zen models---each reusable, inspectable, and owned. The agentic
+stack is the multiplier; the owned OSS foundation is the leverage. You do not
+rebuild identity, key management, or a gateway for each new system; you compose
+owned, hardened components and point the agents at the application on top. That is
+how a regulated platform of this scope reaches production fast---and lean.
+
+For defense, open source inverts the usual security argument. A closed system asks
+you to trust a vendor you cannot inspect; an open one lets you read every line,
+verify it---here, with machine-checked proofs---confirm there are no hidden
+backdoors, and run it on hardware you control. Auditable beats opaque whenever the
+stakes are high. Open source is therefore not a cost-cutting compromise: it is
+simultaneously the source of \textbf{velocity} (compose, do not rebuild), of
+\textbf{security} (inspectable and formally verifiable), and of \textbf{sovereignty}
+(own it, modify it, run it anywhere, including air-gapped). The three properties a
+defense program most wants are the same three that made the build fast.
+
+Stated plainly as a hook: \emph{Hanzo builds massive, secure systems quickly
+because it builds on an open-source stack it owns---so the speed, the security, and
+the sovereignty all come from the same source.}
+
+% ============================================================================
+\section{Why It Matters for Defense Modernization}
+% ============================================================================
+
+The throughput and the difficulty compound. The same agentic engineering method
+that shipped a regulated, post-quantum, FHE-native securities exchange fast and
+small is the method Hanzo brings to defense and government modernization: take an
+existing, already-accredited stack and modernize it in place---to a sovereign,
+post-quantum, self-hostable footprint with FHE-grade privacy---faster and cheaper
+than a traditional rebuild, and owned by the operator. The securities venue is the
+existence proof that the method holds up under the most demanding regulatory and
+cryptographic constraints civilian software offers; defense modernization is the
+same engine pointed at the mission.
+
+\end{document}
@@ -1,4 +1,4 @@
-\documentclass[11pt,a4paper]{article}
+\documentclass[11pt,letterpaper]{article}
 \usepackage{hanzo-defense}

 \doctitle{Post-Quantum Resilient Mesh Networking\\for Maritime and Tactical Edge Operations}
@@ -6,7 +6,7 @@
 \docversion{Version 1.0 --- January 15, 2026}
 \docdate{January 2026}
 \docauthors{Zach Kelling --- Hanzo Team}
-\docorgs{Hanzo Industries \quad Lux Industries \quad Zoo Labs Foundation\\[email protected]}
+\docorgs{Hanzo Industries\\[email protected]}

 \begin{document}
 \makecover
@@ -15,6 +15,9 @@
 We present a post-quantum resilient networking architecture designed for maritime, tactical edge, and disconnected/degraded/intermittent/limited-bandwidth (DDIL) environments. The system integrates the Reticulum Network Stack (RNS) as a native consensus transport layer alongside traditional IP networking, enabling validators and edge nodes to communicate over LoRa, packet radio, serial links, and mesh topologies without reliance on centralized infrastructure or DNS. All transport sessions employ hybrid post-quantum key exchange (X25519 + ML-KEM-768, \fips{203}) and hybrid authentication (Ed25519 + ML-DSA-65, \fips{204}), providing defense-in-depth against both classical and quantum adversaries. The architecture includes a zero-trust overlay network with identity-first micro-segmentation, a zero-copy binary protocol achieving 11.5 million transactions per second, and fault-tolerant streaming over NATS JetStream. We demonstrate sub-second consensus finality over mesh networks and analyze the system's suitability for shipboard, shore-to-ship, expeditionary, and submarine communication scenarios.
 \end{abstract}

+\paragraph{Executive Summary.}
+This is a communications layer that keeps networked systems coordinated when the usual infrastructure---satellite links, cell towers, DNS, certificate authorities---is jammed, degraded, or simply absent. It runs over whatever carries bytes (long-range radio, serial cable, existing tactical radios, satellite) and falls back automatically as links drop, so nodes stay in agreement at sea, underground, or behind a contested boundary. Every link is encrypted with two independent locks at once---today's cryptography plus the new quantum-resistant standards mandated for national-security systems---so traffic recorded now cannot be decrypted later when quantum computers arrive. It is built for operators who must assume the network is hostile and the adversary is patient: defense program offices, government integrators, and operators of critical infrastructure that has to keep working when the connection does not. The performance figures and security properties stated below are measured, not aspirational.
+
 \tableofcontents
 \newpage

@@ -41,22 +44,26 @@ Traditional military networking architectures assume reliable, high-bandwidth li
 This paper presents the following contributions:

 \begin{enumerate}
-\item \textbf{RNS-Native Consensus}: Integration of the Reticulum Network Stack as a first-class transport layer in the Lux blockchain consensus protocol, enabling validator communication over any physical medium.
+\item \textbf{RNS-Native Consensus}: Integration of the Reticulum Network Stack as a first-class transport layer in the Hanzo consensus protocol, enabling validator communication over any physical medium.
 \item \textbf{Hybrid PQ Transport}: End-to-end post-quantum key exchange and authentication for all mesh links using \nist{} \fips{203} and \fips{204} algorithms.
 \item \textbf{Zero-Trust Overlay}: Identity-first networking with micro-segmentation, eliminating implicit trust from network position.
 \item \textbf{High-Performance Data Distribution}: The ZAP zero-copy binary protocol achieving 2.2~ns parse latency with zero memory allocations.
 \item \textbf{Tactical Deployment Analysis}: Concrete scenarios for shipboard mesh, shore-to-ship relay, and expeditionary force networking.
 \end{enumerate}

+\subsection{Strategic Context}
+
+Assured networking is the foundation on which everything else in a sovereign, disconnected AI stack rests: if nodes cannot reach agreement, neither the models nor the cryptography above them matter. Hanzo (American-owned, Techstars~'17, founded 2014) builds this transport in-house because the same organization owns both the post-quantum cryptography securing each link and the frontier AI---the \emph{Zen} model family---that runs over it. That vertical ownership is the strategic point. The center of gravity for ``open'' frontier AI has shifted offshore: the United States has narrowed to a closed two-vendor model duopoly, while the broad open ecosystem---and thus most openly available frontier weights---now sits abroad. Hanzo is the American open-source alternative that controls the model and the cryptography together, so defense and regulated operators can run auditable, sovereign AI on their own networks---offline, at the tactical edge, where the data lives---without renting from the closed duopoly or depending on foreign open weights. The mesh transport described here is what lets that stack operate when the network is contested rather than only in the data center.
+
 % ============================================================================
 \section{Reticulum Network Stack Integration}
 % ============================================================================

 \subsection{Architecture Overview}

-The Reticulum Network Stack (RNS) provides medium-agnostic, delay-tolerant, encrypted networking without dependence on IP infrastructure, DNS, or certificate authorities. We integrate RNS as a native transport layer in the Lux consensus node, alongside traditional TCP/IP endpoints.
+The Reticulum Network Stack (RNS) provides medium-agnostic, delay-tolerant, encrypted networking without dependence on IP infrastructure, DNS, or certificate authorities. We integrate RNS as a native transport layer in the Hanzo consensus node, alongside traditional TCP/IP endpoints.

-The Lux endpoint abstraction supports three addressing modes:
+The Hanzo endpoint abstraction supports three addressing modes:

 \begin{table}[H]
 \centering
@@ -69,7 +76,7 @@ Hostname & \texttt{validator.example.com:9631} & DNS resolved at dial time \\
 RNS & \texttt{rns://a5f72c3d...} & Cryptographic destination hash, no DNS \\
 \bottomrule
 \end{tabular}
-\caption{Unified endpoint addressing in Lux consensus.}
+\caption{Unified endpoint addressing in Hanzo consensus.}
 \label{tab:endpoints}
 \end{table}

@@ -102,7 +109,7 @@ LoRa, already supported as a first-class RNS interface, demonstrates the SDR int

 \subsection{Configuration}

-\begin{lstlisting}[language=Go,caption={RNS transport configuration in Lux node.}]
+\begin{lstlisting}[language=Go,caption={RNS transport configuration in the Hanzo node.}]
 type RNSConfig struct {
    ConfigPath       string        // ~/.reticulum/
    IdentityPath     string        // ~/.reticulum/identity
@@ -509,7 +516,7 @@ We have presented a comprehensive assured networking architecture that addresses
 \subsection{Current Capabilities}

 \begin{itemize}
-\item RNS transport fully integrated into Lux consensus with hybrid PQ handshake.
+\item RNS transport fully integrated into Hanzo consensus with hybrid PQ handshake.
 \item ZAP protocol achieving 11.5M TPS with zero-copy design.
 \item Zero-trust overlay with 7 transport plugins and HSM support.
 \item Production Kubernetes deployment with 65+ services.
@@ -543,9 +550,9 @@ We have presented a comprehensive assured networking architecture that addresses

 \bibitem{pip7009} Pars Network, ``PIP-7009: Reticulum Network Stack Integration,'' February 2026.

-\bibitem{luxconsensus} Hanzo Team, ``Lux Consensus: Multi-Protocol Byzantine Agreement with Post-Quantum Finality,'' Lux Industries, 2025.
+\bibitem{luxconsensus} Hanzo Team, ``Hanzo Consensus: Multi-Protocol Byzantine Agreement with Post-Quantum Finality,'' Hanzo, 2025.

-\bibitem{quasar} Hanzo Team, ``Quasar: Hybrid BLS-Corona Consensus with Sub-Second Quantum Finality,'' Lux Industries, 2025.
+\bibitem{quasar} Hanzo Team, ``Quasar: Hybrid BLS-Corona Consensus with Sub-Second Quantum Finality,'' Hanzo, 2025.

 \bibitem{corona} ``Practical Two-Round Threshold Signature from LWE,'' IACR ePrint 2024/1113, 2024.

@@ -560,7 +567,7 @@ We have presented a comprehensive assured networking architecture that addresses
 \end{thebibliography}

 \section*{Reproducibility}
-\textbf{Source code.} \texttt{github.com/luxfi/zap} (commit \texttt{TBD}).\\
+\textbf{Source code.} \texttt{github.com/hanzoai/zap} (commit \texttt{TBD}).\\
 \textbf{Build.} cargo build --release (Rust 1.78+); Go binaries via make build.\\
 \textbf{Hardware tested.} Apple M-series, Linux amd64/arm64 (edge: ARM Cortex-A), tested with mDNS multicast.\\
 \textbf{Standards referenced.} ML-KEM-768, ML-DSA-65 (FIPS 203/204), W3C DID, DOD DDIL.\\
@@ -0,0 +1,262 @@
+\documentclass[11pt,letterpaper]{article}
+\usepackage{hanzo-defense}
+
+\doctitle{Cloud Economics of a Sovereign OSS Stack:\\A Regulated Capital-Markets\\Migration Case Study}
+\docid{HAI-DEF-2026-012}
+\docversion{Version 1.0}
+\docdate{2026}
+\docauthors{Zach Kelling --- Hanzo Team}
+\docorgs{Hanzo Industries\\[email protected]}
+
+\begin{document}
+\makecover
+
+\begin{abstract}
+We document the infrastructure economics of migrating a regulated capital-markets
+platform from a sprawling multi-project Google Cloud (GCP) footprint to a
+consolidated, self-hostable open-source stack built with Hanzo's agentic
+engineering system. The client---a FINRA/SEC-regulated securities platform,
+anonymized here---was spending, by \emph{actual billing} once a startup-credit
+program expired, approximately \$35{,}158/month ($\approx\$421{,}900$/year) across
+eleven billing accounts, the great majority consumed by legacy GKE clusters and GPU
+virtual machines left over from an earlier architecture. Consolidation onto the new
+stack and owned hardware reduced spend to approximately \$3{,}500/month
+($\approx\$42{,}000$/year)---a $\sim$90\% reduction, on the order of \$380{,}000/year
+saved---and removed the dependency on a single cloud vendor. The same agentic stack
+also \emph{built} the platform: a full SEC-registered ATS with broker-dealer and
+transfer-agent functions, consolidated from 200+ microservices and
+3{,}071{,}930 active lines of a prior implementation down to 1{,}056{,}566 active
+lines ($\approx$70\% less code; $\sim$3.5\,M lines of dead code deleted) running as
+3 compiled Go binaries plus a small set of OSS platform services, carried through
+FINRA/SEC approval and SOC\,2. We decompose where the savings come from, report the
+figures with their provenance, and argue the same mechanism applies directly to
+government-contractor and defense modernization.
+\end{abstract}
+
+\paragraph{Executive Summary.}
+A regulated financial client appeared to be spending only a modest amount on Google
+Cloud because a startup-credit program was absorbing the bill. When those credits
+expired, the \emph{actual} cost surfaced: about \$35{,}158 a month---roughly \$926
+a day of newly cash-billed spend---almost all of it on old GKE clusters and GPU
+machines the new architecture had made unnecessary. Migrating to a consolidated,
+self-hostable open-source stack on owned hardware cut that bill to about \$3{,}500 a
+month ($\approx$90\%, on the order of \$380{,}000 a year), and removed the
+dependency on a single cloud vendor; ongoing consolidation targets a further floor
+near \$1{,}200/month (nearly 97 percent off the original bill) as the last legacy
+projects are retired. Just as
+important is \emph{how little code} now runs that platform: the agentic engineering
+stack collapsed 200+ legacy microservices into 3 compiled Go binaries plus a small
+set of OSS platform services, cutting the active codebase from $\sim$3.07\,M to
+$\sim$1.06\,M lines (deleting roughly 3.5\,M lines of dead code and eliminating
+1.3\,GB of vendored dependencies)---and still cleared the bar of a heavily
+regulated, audited domain (FINRA/SEC approval, SOC\,2). For a government
+contractor the lesson is concrete: the same approach modernizes an existing,
+already-accredited stack to a sovereign, self-hosted footprint that is far cheaper
+to run, smaller to maintain, and faster to build.
+
+\tableofcontents
+\newpage
+
+% ============================================================================
+\section{Before: A Sprawling, Credit-Masked Footprint}
+% ============================================================================
+
+The starting state is typical of an organization that grew fast on Google Cloud
+under promotional credits. Headline spend looked small because a startup-credit
+program was absorbing it; an audit of the \emph{actual} GCP billing console---after
+the credits expired---put true spend at approximately \textbf{\$35{,}158/month}
+($\approx$\$421{,}900/year), concentrated in legacy infrastructure rather than the
+live product. When the credits lapsed, roughly \textbf{\$27{,}783/month} of
+previously credit-masked spend---about \$926/day---flipped from a hidden line to
+cash. The footprint spanned \textbf{185 GCP projects} (27 billing-enabled, only
+$\sim$4 actually needed) across \textbf{11 billing accounts}:
+
+\begin{table}[h]
+\centering
+\small
+\begin{tabular}{p{0.46\textwidth} r r}
+\toprule
+\textbf{Billing account} & \textbf{\$/month} & \textbf{\$/year} \\
+\midrule
+Legacy / startup-credit account (the waste) & 27{,}783 & 333{,}396 \\
+Production account A & 4{,}040 & 48{,}480 \\
+Secondary product group & 3{,}087 & 37{,}044 \\
+New-stack non-prod (already efficient) & 248 & 2{,}976 \\
+\midrule
+\textbf{Total (actual billing)} & \textbf{$\sim$35{,}158} & \textbf{$\sim$421{,}900} \\
+\bottomrule
+\end{tabular}
+\caption{Actual monthly GCP spend by billing account, taken from the billing
+console after startup credits expired (11 billing accounts in total; the four
+material ones shown). A single legacy account accounted for $\sim$79\% of the total;
+the current-generation stack was already a rounding error.}
+\end{table}
+
+The legacy spend bought capacity the new design no longer needed: more than
+\textbf{125 GKE nodes across 20 clusters} (single clusters of 19, 17, and 14 nodes;
+64 of those nodes were 18\,GB machines), two standing \textbf{GPU virtual machines}
+(an A100-class instance at $\sim$\$2{,}900/month and an L4-class instance at
+$\sim$\$800/month, $\sim$\$3{,}700/month together), \textbf{5 Cloud SQL PostgreSQL
+instances}, and $\sim$\textbf{18.5\,TB} of persistent disk---several terminated VMs
+were even still paying for idle attached storage. Two problems compound here:
+\textbf{cost} (most of the spend bought unused capacity) and \textbf{sovereignty}
+(the entire footprint lived inside one hyperscaler---GKE, Cloud SQL, BigQuery, GCS,
+Artifact Registry, Cloud Build---with the data gravity and lock-in that implies).
+
+% ============================================================================
+\section{The Migration: Two Documented Steps}
+% ============================================================================
+
+The migration consolidated the workload onto Hanzo's open-source stack---the same
+self-hostable components (identity, key management, data, gateway, agent runtime)
+that run sovereign and disconnected---and onto owned hardware for the
+compute-heavy services. The savings landed in two measured steps:
+
+\begin{table}[h]
+\centering
+\small
+\begin{tabular}{p{0.50\textwidth} r r}
+\toprule
+\textbf{State} & \textbf{\$/month} & \textbf{vs.\ start} \\
+\midrule
+Actual billing (credits expired) & $\sim$35{,}158 & --- \\
+\midrule
+\emph{Step 1 --- retire legacy:} stop 2 GPU VMs ($-\$3{,}700$),
+delete legacy GKE clusters, close dead projects & $\sim$6{,}489 & $-82\%$ \\
+\emph{Step 2 --- consolidate \& right-size} onto the owned stack
+and owned hardware & $\sim$3{,}500 & $-90\%$ \\
+\midrule
+\emph{Target --- finish consolidation} (retire last legacy projects) & $\sim$1{,}200 & $\approx$$-97$ pts \\
+\bottomrule
+\end{tabular}
+\caption{Reduction to date. Step 1 (retiring unused legacy) alone removed $\sim$82\%
+of spend with no impact on the live product; Step 2 consolidated the remaining
+workload onto the self-hostable stack, landing at $\sim$\$3{,}500/month
+($\approx$\$380{,}000/year saved). The $\sim$\$1{,}200/month line is a forward
+\emph{target} as the last legacy projects are retired---not yet realized.}
+\end{table}
+
+Decommissioning was clean precisely because the legacy capacity was unused: shutting
+down the two GPU VMs removed $\sim$\$3{,}700/month on its own; the largest legacy
+GKE clusters and dozens of dead projects accounted for most of the rest. The net
+effect is a reduction from $\sim$\$35{,}158 to $\sim$\$3{,}500 per month
+($\approx$90\%) and, equally important, the elimination of single-vendor lock-in:
+the resulting stack runs on owned hardware, in another cloud, or air-gapped.
+
+% ============================================================================
+\section{Where the Savings Come From}
+% ============================================================================
+
+The reduction is not a one-time clean-up; it is structural, and it reproduces:
+
+\begin{itemize}
+  \item \textbf{No metered model markup.} Owned models (the Zen family) replace
+  per-token API calls, removing a recurring per-inference charge.
+  \item \textbf{No hyperscaler margin.} Self-hosting on owned hardware removes the
+  cloud provider's margin on compute, storage, and egress.
+  \item \textbf{Efficient transport.} The ZAP protocol's 91\% memory and 96\%
+  energy reductions and 30$\times$ throughput mean the same work needs far less
+  hardware (see the ZAP paper).
+  \item \textbf{Consolidation.} One coherent stack replaces a sprawl of projects,
+  clusters, and services---the single largest line item above was pure redundant
+  overhead.
+\end{itemize}
+
+Together these are the mechanism behind the roughly order-of-magnitude
+infrastructure savings, and they apply to any organization carrying a metered-API
+plus hyperscaler-sprawl cost structure.
+
+% ============================================================================
+\section{The Build: Consolidation, Not Volume}
+% ============================================================================
+
+The economics of \emph{running} the platform are only half the story; the economics
+of \emph{building} it are the other half---and here the measured story is
+\emph{doing more with dramatically less code}. The legacy estate was a sprawl of
+\textbf{200+ microservices} (a single legacy auth monolith alone fronted 391 route
+handlers; $\sim$80+ distinct deployable services, 49 of them active Node.js
+processes at the time of migration). The same agentic engineering stack that now
+runs the platform also built it, and the artifacts are small: \textbf{3 compiled Go
+binaries} (ATS / broker-dealer / transfer-agent) alongside $\sim$10 OSS platform
+services and 5 validator nodes. Measured git-over-git, the active codebase fell from
+\textbf{3{,}071{,}930} to \textbf{1{,}056{,}566} lines ($\approx$70\% less; roughly
+3.5\,M lines of dead code deleted):
+
+\begin{table}[h]
+\centering
+\small
+\begin{tabular}{p{0.40\textwidth} r r r}
+\toprule
+\textbf{Measure} & \textbf{Legacy} & \textbf{New stack} & \textbf{Change} \\
+\midrule
+Deployable services & 200+ & 3 Go binaries & $\sim$60$\times$ fewer \\
+Active lines of code (whole estate) & 3{,}071{,}930 & 1{,}056{,}566 & $\approx$70\% less \\
+Lines of code (trading/auth core) & $\sim$263{,}803 & $\sim$44{,}308 & $\sim$6$\times$ less \\
+Vendored dependencies (flagship svc) & 1.3\,GB & 0 & eliminated \\
+Provisioned cluster RAM & $\sim$1\,TB+ & $\sim$50\,MB working set & $\sim$99.5\% less \\
+Deploy artifact (flagship) & --- & 48\,MB binary & replaces 17+ services \\
+Deploy time & $\sim$1\,hr manual & $<$2\,min rolling & --- \\
+Cold start (per service) & $\sim$10\,s & $<$1\,s & $\sim$10$\times$ faster \\
+Automated tests (new stack) & n/a tracked & 700+ Go tests & --- \\
+\bottomrule
+\end{tabular}
+\caption{Measured engineering footprint, new stack vs.\ the legacy implementation it
+replaced, git-verified. The whole-estate line count fell from $\sim$3.07\,M to
+$\sim$1.06\,M active lines; the trading/auth core specifically went $\sim$6$\times$
+smaller. A single 48\,MB Go binary subsumes 17+ formerly separate services.}
+\end{table}
+
+This inverts the usual ``big system = big codebase'' intuition: agent-driven
+engineering produced a \emph{leaner} system than the one it replaced, which is why
+it is cheaper to run (fewer moving parts), cheaper to maintain (less code), and
+faster to deploy ($<$2\,min rolling deploys, versus $\sim$1\,hr manual or 15--30\,min
+canary before). The memory story is the same shape: the legacy fleet held
+$\sim$1\,TB+ of \emph{provisioned} cluster RAM (64 nodes $\times$ 18\,GB) against an
+application working set of roughly 10\,GB; the consolidated Go binary holds its
+working set in $\sim$50\,MB ($\approx$99.5\% less), and cold start dropped from
+$\sim$10\,s per Node.js service to $<$1\,s. On security, an internal source audit
+found \textbf{93 findings} across 127+ repositories (22 critical, 30 high, 32
+medium, 9 low) plus $\sim$780+ npm dependency vulnerabilities; the consolidated
+rebuild remediated that entire class to \emph{zero actionable} at the architecture
+level (header hardening, strict CORS allowlisting, JWKS-verified JWTs, secrets moved
+out of plaintext environment, and the 1.3\,GB vendored dependency tree---the source
+of most of the npm vulns---eliminated outright).
+
+% ============================================================================
+\section{The Compliance Bar}
+% ============================================================================
+
+The load-bearing proof point is that this lean, cheap-to-run system is not a
+prototype: it is a regulated securities venue---an SEC-registered alternative
+trading system with broker-dealer and transfer-agent functions---carried through
+\textbf{FINRA/SEC approval} and \textbf{SOC\,2} compliance, in record time, with a
+\textbf{small team}. Agent-driven engineering shipped and passed regulatory scrutiny
+in financial services, among the most compliance-heavy software environments that
+exists.
+
+% ============================================================================
+\section{Implications for Government Contractors}
+% ============================================================================
+
+The same motion transfers directly to defense and government modernization. A
+contractor with an existing, already-accredited software stack does not need to
+re-accredit from zero; the agentic stack can modernize that stack in place---to a
+post-quantum, sovereign, self-hostable footprint---while the consolidation cuts
+recurring infrastructure cost by an order of magnitude, shrinks the codebase that
+must be maintained and accredited, and removes single-vendor dependency. The wedge
+is low-friction (modernize what you already have, with proofs), the savings are
+immediate and structural, and the result is software the operator owns and can run
+where the data lives. A regulated financial platform is the existence proof;
+defense modernization is the same pattern.
+
+\paragraph{A note on figures.} Cost figures are drawn from the client's actual GCP
+billing-console data after promotional credits expired (a more defensible basis than
+list-price estimates); infrastructure, code, and security figures are drawn from
+internal infrastructure, code, and source-security audits. Line counts, service
+counts, and dependency sizes are measured (git-verified) where stated. Where a
+number is a forward target rather than a realized result (e.g.\ the $\sim$\$1{,}200/
+month consolidation floor) it is labeled as such; where a source labels a number
+projected or self-reported, we have not relied on it here. All identifiers are
+removed; the client is not named.
+
+\end{document}
@@ -0,0 +1,465 @@
+\documentclass[11pt,letterpaper]{article}
+\usepackage{hanzo-defense}
+
+\doctitle{Hanzo AI for Compliance:\\An OSS Cloud Built to Pass the Audit}
+\docid{HAI-DEF-2026-016}
+\docversion{Version 1.0}
+\docdate{2026}
+\docauthors{Zach Kelling --- Hanzo Team}
+\docorgs{Hanzo Industries\\[email protected]}
+
+\begin{document}
+\makecover
+
+\begin{abstract}
+Compliance is, in operational terms, an evidence-production problem. An auditor
+for SOC~2, an examiner for FINRA/SEC, or an assessor for a defense Authority to
+Operate (ATO) does not primarily ask whether a system \emph{could} be secure; they
+ask the operator to \emph{produce the artifacts} that demonstrate a control is
+designed and operating---access reviews, key-rotation records, immutable logs,
+change tickets, configuration baselines. Most stacks bolt auditing on after the
+fact, so producing those artifacts becomes months of manual screenshot-gathering,
+log-stitching, and spreadsheet reconciliation repeated at every cycle. This paper
+argues that Hanzo's sovereign open-source stack inverts that cost structure by
+emitting the evidence auditors ask for \emph{by construction}: a centralized
+identity and access layer (IAM) produces access-control evidence natively; a key
+management service (KMS) eliminates plaintext secrets and produces key-custody
+evidence; a cryptographically signed, on-chain command/audit log produces
+tamper-evident, non-repudiable audit records; reproducible builds and policy-as-code
+produce change-management evidence; and 50 machine-checked Lean~4 proofs plus NIST
+Known-Answer-Test validation of \fips{203/204/205} produce machine-checked
+cryptographic assurance rather than ``we tested it.'' We give the control-framework
+mapping from these native capabilities to the SOC~2 Trust Services Criteria, to
+FINRA/SEC recordkeeping, and to the NIST SP~800-53 control families (AC, AU, IA,
+SC, CM) that underpin RMF and the ATO process. We then report an anonymized case
+study in which this same stack carried a regulated securities platform through
+FINRA/SEC approval and SOC~2 with a small team---while a $200{+}$-microservice to
+3-binary consolidation shrank the very surface that had to be audited. Throughout,
+claims are kept careful: the stack \emph{provides evidence for} and \emph{maps to}
+controls; certification is an assessor's judgment, not a vendor's.
+\end{abstract}
+
+\paragraph{Executive Summary.}
+Passing an audit is mostly about producing proof. The painful part of SOC~2,
+FINRA/SEC, or a defense ATO is not deciding to be secure---it is assembling the
+mountain of evidence that shows, control by control, that the system is secure and
+stays that way: who can access what, where the secrets live and how often they
+rotate, an unalterable record of every privileged action, proof that the code in
+production is the code that was reviewed. When auditing is an afterthought, that
+evidence has to be reconstructed by hand every cycle, which is why compliance is
+expensive and recurring. Hanzo's stack is built so the evidence is a byproduct of
+running the system. Identity is centralized, so access reviews and least-privilege
+are queries, not archaeology. Secrets live in a key vault and are never in
+plaintext, so key-custody evidence exists by default. Every privileged action is
+cryptographically signed and written to an immutable, tamper-evident log, so the
+audit trail cannot be quietly edited---and the same property satisfies
+financial-recordkeeping rules that demand write-once records and supports
+non-repudiation. Builds are reproducible and policy is code, so change-control
+evidence is generated automatically. And the cryptography is not merely tested but
+\emph{proved}---machine-checked theorems re-verified on every commit. The net effect
+is that SOC~2, FINRA/SEC, and the RMF/ATO process become tractable: less code to
+assess, a smaller accreditation boundary, and an evidence pipeline that is collected
+continuously rather than re-earned from scratch each year. For a defense or
+government program, modernizing onto this stack means inheriting the audit pipeline,
+not building it.
+
+\tableofcontents
+\newpage
+
+% ============================================================================
+\section{Compliance Is an Evidence-Production Problem}
+% ============================================================================
+
+A control framework---SOC~2, FINRA/SEC recordkeeping, NIST SP~800-53 under the Risk
+Management Framework (RMF)---is a catalog of assertions a system is required to
+satisfy. An audit or assessment is the exercise of \emph{substantiating those
+assertions with artifacts}. The decisive distinction in practice is not between
+secure and insecure systems; it is between systems that can \emph{produce the
+evidence} of their controls on demand and systems that cannot. An assessor's day is
+spent asking ``show me'': show me the list of who has administrative access, show me
+that it was reviewed last quarter, show me that this secret was rotated, show me an
+unalterable record that this privileged action happened and who performed it, show
+me that the binary running in production is the artifact your pipeline built from
+reviewed source.
+
+When a stack is assembled from many independently-operated services with logging and
+identity bolted on afterward, answering ``show me'' is manual archaeology. Access
+lists are scattered across dozens of consoles; secrets are pasted into environment
+variables and config files; logs are mutable application logs spread across services
+with no integrity guarantee; the relationship between source, review, and the
+deployed artifact is reconstructed from memory. The result is the familiar
+compliance cost: a SOC~2 Type~II observation window plus weeks of evidence
+collection; a FINRA/SEC examination that demands recordkeeping the architecture was
+never designed to produce; an ATO package whose body of evidence (the security
+controls assessment) is assembled by hand. And because nothing about the system
+\emph{emits} this evidence, the cost recurs in full at every audit cycle and every
+re-authorization.
+
+The thesis of this paper is structural: if the stack is built so that the evidence
+auditors ask for is a \emph{native output} of normal operation, the cost collapses.
+The audit stops being a discovery project and becomes a query against artifacts the
+system already produces. Hanzo's stack is built this way deliberately, and the rest
+of this paper walks the specific capabilities, maps them to the frameworks, and
+shows---with an anonymized production case---what it does to the audit.
+
+% ============================================================================
+\section{Evidence by Construction}
+% ============================================================================
+
+The stack is consolidated around a small number of owned, open-source components.
+Each one, as a side effect of doing its job, emits a class of evidence that an
+auditor asks for. We take them in turn and name the control objective each supports.
+
+\subsection{Identity and Access (IAM): access-control evidence}
+
+All authentication and authorization route through one identity layer (Hanzo IAM)
+rather than per-service credentials. Authentication is centralized
+(OIDC/OAuth~2.1 with PKCE; one canonical set of endpoints); authorization is
+role- and scope-based; and because identity is a single source of truth rather than
+a federation of ad-hoc accounts, least-privilege is enforceable and \emph{auditable}.
+The evidence an assessor wants for access control---the complete roster of
+principals and their entitlements, the record of access grants and revocations, the
+periodic access review---are queries against one system rather than a reconciliation
+across many.
+
+This supports the SOC~2 Security (Common Criteria) logical-access criteria and maps
+directly to the NIST SP~800-53 \textbf{AC} (Access Control) and \textbf{IA}
+(Identification and Authentication) families: centralized account management, enforced
+least privilege, separation of duties expressed as roles, and unique attributable
+identities for every actor. Because there is one identity plane, an access review is
+\emph{produced}, not assembled.
+
+\subsection{Secrets and Keys (KMS): confidentiality and key-management evidence}
+
+Secrets never live in plaintext. A key management service (Hanzo KMS) holds
+credentials and cryptographic keys under centralized custody with rotation, and
+services obtain secrets at runtime rather than embedding them. There are no
+long-lived secrets in source, in container images, or in configuration. The evidence
+auditors request for confidentiality and key management---where keys live, who can
+reach them, how custody is separated, when each was rotated---is the KMS's normal
+bookkeeping.
+
+This supports the SOC~2 Confidentiality criteria and maps to the SP~800-53
+\textbf{SC} (System and Communications Protection) family, specifically the
+key-establishment and key-management controls (SC-12/SC-13) and protection of
+secrets at rest. The structural property---\emph{no plaintext secret anywhere in the
+pipeline}---is itself the control, and the KMS's rotation log is the evidence that it
+operates. A verification gate enforces the property mechanically: the build fails if a
+plaintext-secret pattern reappears, so ``no secrets in code'' is checked rather than
+asserted.
+
+\subsection{Immutable audit trail: audit-logging, integrity, and non-repudiation}
+
+This is the keystone. Every privileged action is cryptographically signed by the
+identity that performed it and written to an \emph{append-only, on-chain,
+tamper-evident} command/audit log. Two properties follow that ordinary application
+logging cannot provide:
+
+\begin{itemize}
+  \item \textbf{Tamper-evidence.} The log is hash-chained and consensus-anchored, so
+  any retroactive edit, deletion, or reordering is detectable. An auditor does not
+  have to trust that the log was not altered; the log's own structure demonstrates it.
+  \item \textbf{Non-repudiation.} Because each entry is signed by the acting
+  identity (post-quantum signatures; \S\ref{sec:pq}), the actor cannot later deny the
+  action, and a reviewer cannot forge one. The signature binds \emph{who} to
+  \emph{what} and \emph{when}.
+\end{itemize}
+
+This maps to the SP~800-53 \textbf{AU} (Audit and Accountability) family in full---
+audit event generation (AU-2), content of records including actor and outcome (AU-3),
+protection of audit information from modification (AU-9), and non-repudiation (AU-10)---
+and to the SOC~2 Security monitoring criteria and Processing Integrity. Crucially,
+the same immutability is exactly what financial recordkeeping rules require: the
+write-once, non-rewriteable, non-erasable (``WORM-like'') retention demanded for
+broker-dealer books and records is an emergent property of an append-only,
+hash-chained ledger, not a bolt-on archival appliance. One mechanism satisfies the
+defense integrity control \emph{and} the securities recordkeeping rule.
+
+\subsection{Post-quantum identity and transport: forward-looking confidentiality}
+\label{sec:pq}
+
+Identities, signatures on the audit log, and transport between services are
+post-quantum (ML-KEM for key establishment, ML-DSA for signatures; \fips{203/204}).
+The compliance-relevant point is durability of evidence: an audit record, a signed
+action, or an encrypted channel captured today must remain confidential and
+verifiable for the full retention horizon---which, for financial records and for
+classified material, is measured in years to decades. ``Harvest now, decrypt later''
+makes classical-only confidentiality a liability for any record with a long required
+life. Post-quantum identity and transport make the audit trail's signatures and the
+data's confidentiality resistant to a future quantum adversary, which is the
+forward-looking posture that CNSA~2.0 mandates for national-security systems and that
+a prudent long-retention financial archive should adopt. This supports the SC family's
+transmission-confidentiality and cryptographic-protection controls with algorithms
+chosen for the record's lifetime, not just today's threat.
+
+\subsection{Formal verification: machine-checked evidence, not ``we tested it''}
+
+Most software is trusted because it was tested and nothing broke. The cryptographic
+core here goes further: its security properties are proved as theorems and re-checked
+by a machine on every code change. The suite comprises \textbf{50 machine-checked
+Lean~4 proofs}, including \textbf{ML-DSA EU-CMA} unforgeability (\fips{204}) and
+\textbf{ML-KEM IND-CCA2} security (\fips{203}), alongside consensus safety/liveness,
+threshold-signature, and protocol-correctness proofs; complementary
+\textbf{NIST Known-Answer-Test (KAT)} validation covers all three post-quantum
+standards (\fips{203/204/205}). For an assessor this is a different \emph{kind} of
+evidence: not a test report asserting that some inputs produced expected outputs, but
+a machine-checked proof with an explicit, inspectable set of assumptions. A proof
+regression blocks the build, so the assurance is continuous rather than a point-in-time
+snapshot. This is the strongest available evidence for the SC family's cryptographic
+controls and for the ``correctly implemented'' burden in any cryptographic
+accreditation, and it is auditable end-to-end precisely because the stack is owned and
+open---there is no third-party black box whose internals are out of the prover's reach.
+
+\subsection{Reproducible builds, policy-as-code, and change control}
+
+The path from source to running artifact is itself evidence. Builds are reproducible
+and produced by a shared CI/CD pipeline; images are pinned to immutable,
+content-addressed tags (a semver tag or a commit-pinned \texttt{sha-} digest), never
+to a floating \texttt{:latest}; and deployment policy and infrastructure are
+expressed as code under version control. The consequence is that the relationship
+auditors probe for change management---reviewed source $\rightarrow$ built artifact
+$\rightarrow$ deployed instance---is a chain of immutable, attributable records rather
+than an after-the-fact reconstruction. Who changed what, who reviewed it, and exactly
+which artifact reached production are all recorded by the normal pipeline.
+
+This maps to the SP~800-53 \textbf{CM} (Configuration Management) family---baseline
+configuration (CM-2), change control (CM-3), and configuration of the deployed
+system---and to the SOC~2 change-management criteria. Because policy is code, the
+configuration baseline is the repository state, and any drift is a diff.
+
+% ============================================================================
+\section{Control-Framework Mapping}
+% ============================================================================
+
+Table~\ref{tab:mapping} maps each native capability to the SOC~2 Trust Services
+Criteria it provides evidence for, the NIST SP~800-53 control families it supports
+under RMF/ATO, and the corresponding FINRA/SEC recordkeeping relevance. The verbs are
+deliberate: a capability \emph{provides evidence for} or \emph{maps to} a control.
+Whether a control is satisfied is an assessor's determination on the specific
+deployment; the stack's contribution is to make the evidence native and the boundary
+small.
+
+\begin{table}[H]
+\centering
+\small
+\begin{tabular}{@{}p{3.0cm}p{3.1cm}p{2.0cm}p{4.0cm}@{}}
+\toprule
+\textbf{Native capability} & \textbf{SOC~2 TSC} & \textbf{800-53 family} & \textbf{FINRA/SEC \& ATO relevance} \\
+\midrule
+Centralized IAM (OIDC; RBAC; least privilege; access reviews)
+& Security (CC6 logical access)
+& AC, IA
+& Supervisory access controls; attributable identities for the ATO access-control assessment \\
+\addlinespace
+KMS (no plaintext secrets; central custody; rotation)
+& Confidentiality
+& SC (SC-12/13)
+& Protection of customer/non-public data; key-management evidence in the SCA \\
+\addlinespace
+Immutable, signed, on-chain audit log
+& Security (monitoring); Processing Integrity
+& AU (AU-2/3/9/10)
+& WORM-like books-and-records retention; non-repudiation of privileged actions \\
+\addlinespace
+Post-quantum identity \& transport (ML-KEM / ML-DSA)
+& Confidentiality
+& SC (SC-8/12/13)
+& Long-retention record durability; CNSA~2.0 forward posture \\
+\addlinespace
+Formal verification (50 Lean~4 proofs; NIST KAT)
+& Security; Processing Integrity
+& SC, SA
+& Machine-checked ``correctly implemented'' evidence for the SCA \\
+\addlinespace
+Reproducible builds; policy-as-code; pinned artifacts
+& Security; Availability (change mgmt)
+& CM (CM-2/3)
+& Change-control records; configuration baseline as code \\
+\addlinespace
+Consolidation (fewer services / smaller boundary)
+& All five (reduced scope)
+& All families (smaller boundary)
+& Smaller examination surface; smaller authorization boundary \\
+\bottomrule
+\end{tabular}
+\caption{Native stack capabilities mapped to SOC~2 Trust Services Criteria, NIST
+SP~800-53 control families (RMF/ATO), and FINRA/SEC recordkeeping relevance. ``Maps
+to / provides evidence for''---not a certification claim.}
+\label{tab:mapping}
+\end{table}
+
+\paragraph{Five criteria, one stack.} The SOC~2 Trust Services Criteria are Security,
+Availability, Confidentiality, Processing Integrity, and Privacy. The capabilities
+above touch all five: \emph{Security} via IAM, the audit trail, and reproducible
+builds; \emph{Confidentiality} via KMS and post-quantum transport; \emph{Processing
+Integrity} via the tamper-evident log and machine-checked proofs of the logic that
+moves records; \emph{Availability} via policy-as-code change management and a
+consolidated, self-hostable footprint; and \emph{Privacy} via centralized
+access control and confidentiality of non-public data. Because one set of mechanisms
+underlies all five criteria, the evidence collected once is reused across the report
+rather than re-gathered per criterion.
+
+\paragraph{The same evidence translates.} The reason one stack serves SOC~2,
+FINRA/SEC, and a defense ATO simultaneously is that the underlying control objectives
+overlap heavily---access control, confidentiality, audit integrity, change control,
+cryptographic correctness---and differ mainly in the framework's vocabulary and the
+assessor's authority. An append-only signed ledger is ``AU-9 protection of audit
+information'' to an RMF assessor and ``non-rewriteable record retention'' to a
+securities examiner; it is the same ledger. Centralized least-privilege identity is
+``AC-2/AC-6'' to one and ``supervisory and access controls'' to another; it is the
+same IAM. Producing the evidence once and presenting it through each framework's lens
+is the efficiency the consolidated stack creates.
+
+% ============================================================================
+\section{Case Study: One Stack Through FINRA/SEC and SOC~2}
+% ============================================================================
+
+The argument is not theoretical. The same stack carried a regulated securities
+platform---an SEC-registered alternative trading system (ATS) with broker-dealer and
+transfer-agent functions---through FINRA/SEC approval and SOC~2, with a small team, in
+record time. Two facts from that engagement matter for the thesis of this paper.
+
+\paragraph{The evidence was native.} The regulated entity ran on this stack's
+centralized IAM, its KMS (no plaintext secrets), and its immutable signed audit log.
+The recordkeeping obligations that fall on a broker-dealer and transfer agent---
+non-rewriteable books and records, an attributable trail of who did what to which
+record, controlled and reviewed access---were satisfied by capabilities the platform
+already had, not by a separate compliance system layered on top. The audit and the
+regulatory approval drew on artifacts the running system produced as a matter of
+course.
+
+\paragraph{Consolidation shrank what had to be audited.} In parallel, the platform's
+architecture was consolidated from \textbf{$200{+}$ microservices into 3 compiled Go
+binaries} (plus a small set of OSS platform services), collapsing roughly
+\textbf{3.07~million lines of code to about 1.06~million}---\emph{$\sim$3.5~million
+lines of dead code deleted}, around a 65--70\% reduction. The consolidated rebuild
+also remediated the security-finding backlog of the legacy estate (on the order of
+90+ findings) at the architectural level. This is the second, quieter half of why the
+audit was tractable: \emph{every line of code and every service is attack surface that
+an auditor and an accreditor must reason about}. Cutting the codebase by two-thirds and
+the runtime from a sprawl of services to three binaries shrinks the examination
+surface, the SOC~2 system description, and---for the defense analogue---the
+authorization boundary. Less code plus centralized IAM/KMS/audit is a smaller,
+cheaper, faster audit. The consolidation and the evidence-by-construction property are
+the same lever viewed from two sides: one reduces \emph{what} must be proven, the other
+makes the proof \emph{native}.
+
+\medskip
+\noindent\emph{Anonymization.} The regulated entity is intentionally unnamed; the
+point is the stack's properties, not the client. What transfers to any future program
+is the mechanism: a small team reached a regulated, audited production posture quickly
+because the stack produced the evidence and the consolidation shrank the surface.
+
+% ============================================================================
+\section{Continuous Compliance}
+% ============================================================================
+
+A SOC~2 Type~II report covers an observation window; an ATO is not a one-time event
+but a posture that must be \emph{maintained} under continuous monitoring; a
+broker-dealer's recordkeeping is examined repeatedly. The expensive failure mode is
+treating each cycle as a fresh discovery project. Because this stack emits evidence
+continuously, the posture is maintained rather than re-earned:
+
+\begin{itemize}
+  \item \textbf{Always-on collection.} The audit log is generated by operation, not
+  by an end-of-period scramble; access reviews are queries against live IAM state;
+  key-rotation records accrue from the KMS; build and deployment records accrue from
+  the pipeline. The body of evidence is a continuous stream.
+  \item \textbf{Continuous verification.} The Lean proofs and KAT vectors run on every
+  commit, so cryptographic assurance is re-established automatically and a regression
+  blocks deployment. Policy-as-code means configuration drift surfaces as a diff, not
+  as an audit finding months later.
+  \item \textbf{Agentic evidence assembly.} The same agentic engineering pipeline that
+  built the consolidated system can collect, organize, and map evidence to controls
+  continuously---turning the ongoing-authorization (cATO) ideal into routine output
+  instead of a periodic mobilization.
+\end{itemize}
+
+The effect on the ATO process specifically is that re-authorization draws on an
+evidence pipeline that never stopped running. The authorization boundary is smaller
+(consolidation), the controls produce their own evidence (by construction), and the
+evidence is current (continuous), which is precisely the posture continuous
+authorization is meant to reward.
+
+% ============================================================================
+\section{Why It Matters for Defense and Government}
+% ============================================================================
+
+A contractor or agency modernizing onto this stack inherits the evidence pipeline
+rather than building one. The same properties that make a commercial SOC~2 and a
+FINRA/SEC examination tractable are the properties an RMF assessment and an ATO
+package require: centralized least-privilege identity (AC/IA), no plaintext secrets
+and managed keys (SC), a tamper-evident non-repudiable audit trail (AU), reproducible
+builds and configuration-as-code (CM), and machine-checked cryptographic correctness
+(SC/SA). Because the stack is sovereign, open-source, and self-hostable, it can be
+deployed in the environments accreditation demands---on-premises, air-gapped, at the
+edge---without renting from a closed vendor, and an assessor can inspect the entire
+path the evidence takes rather than trusting a black box. The cryptography is
+post-quantum, so the records and identities survive the retention horizon that
+defense and financial archives both require.
+
+This compliance posture is one facet of a broader sovereign stack built by Hanzo
+AI---an American-owned applied-AI lab and venture studio (Techstars~'17, founded
+2014). Hanzo owns both halves of the modern trust problem: the frontier AI models
+(the \emph{Zen} family) and the production post-quantum cryptography that secures and
+signs the systems they run in. This matters for who a regulated or accredited operator
+can build on. U.S.\ frontier AI has consolidated into a closed commercial duopoly,
+while the broadly \emph{open} frontier model weights available today are largely of
+foreign origin---an untenable basis for a system that must be inspected, accredited,
+and run on sovereign infrastructure. Hanzo is the American open-source alternative
+that owns the model and the cryptography together, deployable without renting from the
+closed duopoly or depending on foreign open weights. The evidence-by-construction
+property documented here is the auditable backing for that claim: not a vendor
+assurance an accreditor must take on faith, but artifacts---signed logs, key-custody
+records, reproducible builds, machine-checked proofs---an accreditor can read.
+
+% ============================================================================
+\section{Honest Scope}
+% ============================================================================
+
+This is a capability paper, and the credible version is explicit about what the stack
+does versus what an assessor does. No overstatement:
+
+\begin{itemize}
+  \item \textbf{The stack provides evidence; it does not self-certify.} SOC~2 attestation
+  is issued by a CPA firm, a FINRA/SEC approval is a regulator's decision, and an ATO is
+  granted by an Authorizing Official. The stack's contribution is to make the evidence
+  native, current, and inspectable, and to shrink the boundary being judged---which is
+  what makes those determinations faster and cheaper, not automatic.
+  \item \textbf{Mapping is not equivalence.} A capability \emph{provides evidence for}
+  or \emph{supports} a control family; closing a specific control still requires the
+  operator to configure, document, and operate it for the assessed deployment. The
+  tables here are a starting correspondence, not a completed controls matrix.
+  \item \textbf{Formal verification has a stated boundary.} The 50 Lean proofs rest on
+  explicit cryptographic hardness axioms (standard practice), and model checking and
+  protocol analysis are on a published roadmap rather than complete. The assurance
+  boundary is the true one, not a marketing one.
+\end{itemize}
+
+The strategic point holds regardless of where any one line sits: because Hanzo owns
+and open-sources every layer the evidence runs through, the artifacts an auditor or
+accreditor needs are produced by the system itself and can be inspected end-to-end---
+which is the difference between an audit that is a discovery project and one that is a
+query.
+
+% ============================================================================
+\section{Conclusion}
+% ============================================================================
+
+Compliance is an evidence-production problem, and most stacks make it expensive by
+producing no evidence until an auditor asks. Hanzo's sovereign open-source stack
+inverts that: centralized IAM emits access-control evidence, KMS emits key-custody
+evidence, an immutable signed on-chain log emits tamper-evident and non-repudiable
+audit evidence, reproducible builds and policy-as-code emit change-control evidence,
+and 50 machine-checked proofs plus NIST KAT validation emit cryptographic assurance
+that is proved rather than asserted. The same evidence maps across SOC~2's five Trust
+Services Criteria, FINRA/SEC recordkeeping, and the NIST~800-53 families that
+underpin RMF and the ATO process---so one stack serves the commercial, financial, and
+defense frameworks at once. A production case shows it carrying a regulated securities
+platform through FINRA/SEC and SOC~2 with a small team, while a $200{+}$-microservice
+to 3-binary consolidation shrank the surface that had to be audited and accredited.
+For a defense or government program, the consequence is direct: modernize on this
+stack and inherit the audit pipeline---sovereign, auditable, post-quantum, and
+continuous---rather than rebuild it from scratch each cycle.
+
+\end{document}
@@ -1,4 +1,4 @@
-\documentclass[11pt,a4paper]{article}
+\documentclass[11pt,letterpaper]{article}
 \usepackage{hanzo-defense}

 \doctitle{Quantum-Resistant Counter-Exploitation:\\Confidential Compute and Coercion-Resistant\\Communications}
@@ -6,7 +6,7 @@
 \docversion{Version 1.0 --- February 7, 2026}
 \docdate{February 2026}
 \docauthors{Zach Kelling --- Hanzo Team}
-\docorgs{Hanzo Industries \quad Lux Industries \quad Zoo Labs Foundation\\[email protected]}
+\docorgs{Hanzo Industries\\[email protected]}

 \begin{document}
 \makecover
@@ -15,6 +15,9 @@
 We present a suite of counter-exploitation technologies providing quantum-resistant secure messaging, coercion-resistant governance, confidential computation on encrypted data, and post-quantum anonymous communication. The SessionVM delivers end-to-end encrypted messaging using ML-KEM-768 (\fips{203}) and ML-DSA-65 (\fips{204}) with fresh key encapsulation per message, achieving 526,000 messages per second with forward secrecy. ThresholdVM provides fully homomorphic encryption (FHE) with GPU-accelerated BFV/BGV/CKKS/TFHE schemes and threshold decryption ensuring no single party observes plaintext. LatticeLSAG ring signatures enable post-quantum anonymous group signing with linkability for double-action detection. Zero-knowledge proof systems provide privacy pools, range proofs, and confidential transactions. A multi-agent adversarial framework with 83 specialized agents enables automated red/blue team operations. Together, these capabilities prevent adversary exploitation of cryptographic, network, and AI systems while maintaining operational security in contested environments.
 \end{abstract}

+\paragraph{Executive Summary.}
+This is a toolkit for denying an adversary any use of what they intercept, capture, or coerce. If they record your messages, the encryption is quantum-resistant, so harvested traffic stays unreadable even against a future quantum computer; if they seize a key, fresh keys per message mean past communications remain sealed. If they pressure a person, the voting and governance schemes are built so no one can prove how they voted, removing the leverage behind coercion. Sensitive data can be computed on while still encrypted---no operator and no single machine ever sees it in the clear---and operators can authenticate and file reports anonymously, yet still be held accountable for duplicate or contradictory actions. For defense and intelligence users operating in contested or denied environments, the practical result is that compromise of a device, a key, or a person does not cascade into compromise of the mission.
+
 \tableofcontents
 \newpage

@@ -208,7 +211,7 @@ No single party ever sees plaintext:

 \subsection{GPU Acceleration}

-LuxCPP provides Metal and CUDA kernels for FHE operations:
+The Hanzo GPU kernel library provides Metal and CUDA kernels for FHE operations:
 \begin{itemize}
 \item NTT/iNTT forward and inverse transforms.
 \item Polynomial multiplication with modular arithmetic.
@@ -475,6 +478,12 @@ For compliance with lawful intercept requirements:
 \item Attestation protocol detects tampering via equivocation detection.
 \end{itemize}

+% ============================================================================
+\section{Strategic Context}
+% ============================================================================
+
+Counter-exploitation is where ownership of the full stack matters most: every layer described here---the messaging, the governance, the confidential compute, and the AI-driven adversarial defense---is built and controlled by Hanzo AI, an American-owned applied-AI lab and venture studio (Techstars '17, founded 2014) behind more than 100 venture-funded startups and several unicorns, led by a founder expert in both AI/ML and cryptography. The AI-powered components of this suite---the multi-agent red/blue framework, agent-consensus threat validation---depend on frontier models, and that is the strategic fault line. U.S.\ frontier AI has consolidated into a closed commercial duopoly, while the only broadly open frontier weights available today are largely of foreign origin; an organization whose mission is to deny adversary exploitation cannot reasonably build its active defenses on models it can neither inspect nor run in a denied environment. Hanzo is the American open-source frontier alternative: it owns both the Zen model family and the post-quantum cryptography underneath, so the adversarial-defense agents and the coercion-resistant primitives share one auditable, sovereign foundation that runs offline and at the edge---no rented API, no foreign dependency, nothing the adversary controls. This is operational rather than aspirational: the same agentic engineering stack delivered a FINRA/SEC-approved, SOC2 securities platform---a full ATS/BD/TA stack consolidated from 200+ microservices into 3 compiled binaries---to production with a small team, demonstrating that the agent orchestration invoked throughout this paper performs under real regulatory and reliability constraints.
+
 % ============================================================================
 \section{Conclusion}
 % ============================================================================
@@ -527,7 +536,7 @@ The integration of these capabilities into a unified architecture---where Sessio
 \section*{Reproducibility}
 \textbf{Source code.} \texttt{github.com/hanzoai/kms, hanzoai/iam} (commit \texttt{TBD}).\\
 \textbf{Build.} make build per component; integrated K8s deploy via kubectl kustomize.\\
-\textbf{Hardware tested.} Linux amd64/arm64; HSM integration tested with PKCS#11.\\
+\textbf{Hardware tested.} Linux amd64/arm64; HSM integration tested with PKCS\#11.\\
 \textbf{Standards referenced.} NIST SP 800-207 (Zero Trust), Shamir SSS, FIPS 140-3.\\
 \textbf{Contact.} [email protected].

@@ -1,4 +1,4 @@
-\documentclass[11pt,a4paper]{article}
+\documentclass[11pt,letterpaper]{article}
 \usepackage{hanzo-defense}

 \doctitle{Multi-Level Security and Cross-Domain Solutions\\via Homomorphic Policy Evaluation\\and Zero-Trust Fabric}
@@ -6,7 +6,7 @@
 \docversion{Version 1.0 --- February 18, 2026}
 \docdate{February 2026}
 \docauthors{Zach Kelling --- Hanzo Team}
-\docorgs{Hanzo Industries \quad Lux Industries \quad Zoo Labs Foundation\\[email protected]}
+\docorgs{Hanzo Industries\\[email protected]}

 \begin{document}
 \makecover
@@ -15,6 +15,9 @@
 We present a cross-domain solution (CDS) architecture where data transfer policies are evaluated on encrypted content using fully homomorphic encryption (FHE), ensuring the cross-domain guard never observes plaintext. The architecture integrates four components: (1) a zero-trust overlay network with identity-first micro-segmentation enforcing mandatory access controls at every hop; (2) an FHE policy evaluation engine (ThresholdVM) performing content inspection on ciphertexts using BFV/BGV/CKKS/TFHE schemes with GPU-accelerated NTT operations; (3) a key management system with Shamir-based root key distribution, per-organization encryption isolation, and HIPAA/SOX/SEC compliance controls; and (4) an organization-scoped identity and access management layer deriving security labels from JWT claims and enforcing them at the API gateway. The result is a multi-level security (MLS) architecture where data flows between security domains are cryptographically mediated, no single component has access to both plaintext and policy decisions, and all cross-domain transfers produce immutable audit records anchored to a post-quantum blockchain.
 \end{abstract}

+\paragraph{Executive Summary.}
+A cross-domain solution is the gatekeeper that decides what information may move between networks of different classification---for example, releasing an intelligence product from a Secret network to a coalition partner. Today that gatekeeper has to read the data in the clear to decide, which makes it the single most valuable target on the network: compromise it once and every cross-domain transfer is exposed. This architecture removes that weakness. The data stays encrypted the entire time; the gatekeeper checks it against release policy \emph{without ever decrypting it}, and the final release decision is split across a committee so no single operator or machine can be subverted to leak data. Every transfer leaves a tamper-proof, quantum-resistant audit record. For program offices and integrators running multi-level or coalition networks, the operational payoff is a guard that an adversary cannot turn into a data tap even with full physical access to it.
+
 \tableofcontents
 \newpage

@@ -129,10 +132,10 @@ The platform supports 4+ organizations with complete cryptographic isolation:
 \toprule
 \textbf{Organization} & \textbf{Root Key} & \textbf{Isolation Mechanism} \\
 \midrule
-hanzo & Separate AES-256 & KMS per-org encryption \\
-lux & Separate AES-256 & Separate key hierarchy \\
-zoo & Separate AES-256 & Org-scoped IAM policies \\
-pars & Separate AES-256 & Independent audit logs \\
+Org A & Separate AES-256 & KMS per-org encryption \\
+Org B & Separate AES-256 & Separate key hierarchy \\
+Org C & Separate AES-256 & Org-scoped IAM policies \\
+Org D & Separate AES-256 & Independent audit logs \\
 \bottomrule
 \end{tabular}
 \caption{Per-organization cryptographic isolation.}
@@ -147,7 +150,7 @@ Each organization has its own root encryption key, IAM policies, KMS secrets, an

 \subsection{ThresholdVM: Computation on Encrypted Data}

-ThresholdVM operates on the Lux T-Chain, providing FHE as a native virtual machine:
+ThresholdVM operates on the T-Chain, providing FHE as a native virtual machine:

 \begin{table}[H]
 \centering
@@ -196,7 +199,7 @@ TFHE & Boolean & Arbitrary policy Boolean circuits \\

 \subsection{GPU-Accelerated FHE Operations}

-LuxCPP provides Metal and CUDA kernels for FHE primitives:
+The Hanzo GPU kernel library provides Metal and CUDA kernels for FHE primitives:

 \begin{itemize}
 \item \textbf{NTT/iNTT}: Number Theoretic Transform for polynomial multiplication in $\mathbb{Z}_q[X]/(X^n+1)$.
@@ -285,7 +288,7 @@ Every cross-domain transfer produces an immutable audit record:
 \begin{itemize}
 \item \textbf{Record contents}: Source domain, destination domain, policy ID, decision (approve/deny), timestamp, data hash (not data), requestor DID.
 \item \textbf{Signature}: ML-DSA-65 (post-quantum) ensuring long-term non-repudiation.
-\item \textbf{Anchoring}: Record hash committed to Lux blockchain via Quasar consensus.
+\item \textbf{Anchoring}: Record hash committed to the Hanzo chain via Quasar consensus.
 \item \textbf{WORM guarantee}: Write-once-read-many with SHA-256 hash chain prevents retroactive modification.
 \end{itemize}

@@ -416,6 +419,12 @@ With GPU acceleration and pipelined evaluation:
 \item All cross-domain traffic audited with PQ-signed blockchain receipts.
 \end{itemize}

+% ============================================================================
+\section{Strategic Context}
+% ============================================================================
+
+This cross-domain architecture is one capability within a broader sovereign stack built by Hanzo AI---an American-owned applied-AI lab and venture studio (Techstars '17, founded 2014) behind more than 100 venture-funded startups and several unicorns, led by a founder with deep expertise in both AI/ML and cryptography. Hanzo owns both halves of the problem that cross-domain security demands: the frontier AI models (the Zen family) that drive content classification on encrypted data, and the production post-quantum cryptography that mediates the transfers. This matters for the multi-level and coalition mission specifically: U.S.\ frontier AI has consolidated into a closed commercial duopoly, while the only broadly \emph{open} frontier model weights available today are largely of foreign origin---an untenable basis for a guard that inspects classified traffic. Hanzo is the American open-source frontier alternative, offering models and cryptography that are sovereign, auditable end-to-end, and deployable in air-gapped or edge environments without renting from the closed duopoly or depending on foreign open weights. The same stack has been hardened in production at scale---the agentic engineering pipeline delivered a FINRA/SEC-approved, SOC2 securities platform (consolidated from 200+ microservices into 3 compiled binaries) to production with a small team---evidence that the cryptographic and AI components described here are operational engineering, not laboratory prototypes.
+
 % ============================================================================
 \section{Conclusion}
 % ============================================================================
@@ -447,7 +456,7 @@ This approach represents a paradigm shift in cross-domain security: instead of t

 \bibitem{cnsa2} NSA, ``CNSA Suite 2.0,'' 2022.

-\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Lux Industries, 2025.
+\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Hanzo, 2025.

 \bibitem{corona} ``Practical Two-Round Threshold Signature from LWE,'' IACR ePrint 2024/1113.

@@ -460,7 +469,7 @@ This approach represents a paradigm shift in cross-domain security: instead of t
 \end{thebibliography}

 \section*{Reproducibility}
-\textbf{Source code.} \texttt{github.com/luxfi/fhe, hanzoai/kms} (commit \texttt{TBD}).\\
+\textbf{Source code.} \texttt{github.com/hanzoai/fhe, hanzoai/kms} (commit \texttt{TBD}).\\
 \textbf{Build.} make build (Rust 1.78+, OpenFHE bindings); GPU NTT via Metal/CUDA.\\
 \textbf{Hardware tested.} Apple M2/M3 (Metal), NVIDIA A100/H100.\\
 \textbf{Standards referenced.} NIST FHE (BFV/BGV/CKKS/TFHE), HIPAA, SOX, SEC, MLS.\\
@@ -105,7 +105,7 @@
 \fancyhf{}
 \fancyhead[L]{\small\textit{\@hanzodoctitle}}
 \fancyhead[R]{\small\thepage}
-\fancyfoot[C]{\small\textsc{CONFIDENTIAL}}
+\fancyfoot[C]{\small\textsc{Hanzo Industries}\quad\textbar\quad papers.hanzo.ai}
 \renewcommand{\headrulewidth}{0.4pt}
 \renewcommand{\footrulewidth}{0.2pt}

@@ -116,7 +116,7 @@
 \newcommand{\@hanzodocid}{}
 \newcommand{\@hanzodocversion}{}
 \newcommand{\@hanzodocdate}{}
-\newcommand{\@hanzodocclass}{CONFIDENTIAL}
+\newcommand{\@hanzodocclass}{APPROVED FOR PUBLIC RELEASE}
 \newcommand{\@hanzodocauthors}{}
 \newcommand{\@hanzodocorgs}{}
 \newcommand{\@hanzodocabstract}{}
@@ -133,73 +133,52 @@
 % ============================================================================
 % Black coversheet
 % ============================================================================
+% Minimal Eames-style coversheet: H logo top-left, centered title, quiet footers.
 \newcommand{\makecover}{%
  \thispagestyle{empty}%
  \begin{tikzpicture}[remember picture,overlay]
    % Full black background
    \fill[black] (current page.south west) rectangle (current page.north east);
    %
-    % Classification banner — top
-    \node[white,font=\footnotesize\bfseries\sffamily,anchor=north]
-      at ([yshift=-0.5cm]current page.north) {\textls[200]{\@hanzodocclass}};
-    %
-    % Thin top rule
-    \draw[darkgray,line width=0.3pt]
-      ([yshift=-1.0cm,xshift=2.5cm]current page.north west) --
-      ([yshift=-1.0cm,xshift=-2.5cm]current page.north east);
-    %
-    % Document ID — upper right
-    \node[medgray,font=\scriptsize\ttfamily,anchor=north east]
-      at ([yshift=-1.3cm,xshift=-2.5cm]current page.north east) {\@hanzodocid};
-    %
-    % Hanzo logo — centered above title
-    \node[anchor=center] at ([yshift=5.5cm]current page.center)
+    % H logo — top left
+    \node[anchor=north west] at ([xshift=1.4cm,yshift=-1.4cm]current page.north west)
      {\IfFileExists{hanzo-logo-white.pdf}%
-        {\includegraphics[width=1.8cm]{hanzo-logo-white.pdf}}%
-        {}};
+        {\includegraphics[height=0.95cm]{hanzo-logo-white.pdf}}%
+        {\sffamily\bfseries\large\color{white}H}};
    %
-    % HANZO INDUSTRIES wordmark below logo
-    \node[white,font=\footnotesize\sffamily,anchor=center]
-      at ([yshift=4.0cm]current page.center) {\textls[250]{HANZO INDUSTRIES}};
+    % Document ID — top right, subtle
+    \node[white!30,font=\scriptsize\ttfamily,anchor=north east]
+      at ([xshift=-1.4cm,yshift=-1.65cm]current page.north east) {\@hanzodocid};
    %
-    % Title block — centered, no hyphenation
-    \node[white,font=\LARGE\bfseries\sffamily,text width=15cm,align=center,anchor=center]
-      at ([yshift=1.8cm]current page.center) {\hyphenpenalty=10000\exhyphenpenalty=10000\@hanzodoctitle};
+    % Title — centered, no hyphenation
+    \node[white,font=\fontsize{19}{24}\selectfont\bfseries\sffamily,text width=13.5cm,align=center]
+      at ([yshift=1.3cm]current page.center)
+      {\hyphenpenalty=10000\exhyphenpenalty=10000\@hanzodoctitle};
    %
-    % Thin center rule
-    \draw[medgray,line width=0.3pt]
-      ([yshift=0.2cm,xshift=3cm]current page.center) --
-      ([yshift=0.2cm,xshift=-3cm]current page.center);
-    %
-    % Technical White Paper label
-    \node[lightgray,font=\small\sffamily,anchor=center]
-      at ([yshift=-0.4cm]current page.center) {\textls[180]{TECHNICAL WHITE PAPER}};
-    %
-    % Version and date
-    \node[medgray,font=\small\sffamily,anchor=center]
-      at ([yshift=-1.1cm]current page.center) {\@hanzodocversion\quad\textbar\quad\@hanzodocdate};
+    % Thin rule below title
+    \draw[white!22,line width=0.3pt]
+      ([yshift=-1.2cm,xshift=-3.5cm]current page.center) --
+      ([yshift=-1.2cm,xshift=3.5cm]current page.center);
    %
    % Authors
-    \node[white,font=\small\sffamily,anchor=center]
-      at ([yshift=-2.6cm]current page.center) {\@hanzodocauthors};
+    \node[white!50,font=\fontsize{9}{12}\selectfont\sffamily]
+      at ([yshift=-2.0cm]current page.center) {\@hanzodocauthors};
    %
-    % Organizations
-    \node[medgray,font=\scriptsize\sffamily,text width=12cm,align=center,anchor=center]
-      at ([yshift=-3.4cm]current page.center) {\@hanzodocorgs};
+    % Version + date
+    \node[white!28,font=\fontsize{8}{11}\selectfont\sffamily]
+      at ([yshift=-2.7cm]current page.center) {\@hanzodocversion\quad\@hanzodocdate};
    %
-    % Bottom rule
-    \draw[darkgray,line width=0.3pt]
-      ([yshift=2.2cm,xshift=2.5cm]current page.south west) --
-      ([yshift=2.2cm,xshift=-2.5cm]current page.south east);
+    % Footer left — brand
+    \node[white!20,font=\fontsize{6.5}{8}\selectfont\sffamily,anchor=south west]
+      at ([xshift=1.4cm,yshift=1.1cm]current page.south west) {Hanzo Industries};
    %
-    % Distribution / handling caveat
-    \node[medgray,font=\scriptsize\sffamily,text width=13cm,align=center,anchor=south]
-      at ([yshift=1.0cm]current page.south)
-      {CONFIDENTIAL --- Not for public distribution.\\Handle in accordance with applicable regulations.};
+    % Footer center — public-release marker, quiet
+    \node[white!14,font=\fontsize{6.5}{8}\selectfont\sffamily,anchor=south]
+      at ([yshift=1.1cm]current page.south) {Approved for public release};
    %
-    % Classification banner — bottom
-    \node[white,font=\footnotesize\bfseries\sffamily,anchor=south]
-      at ([yshift=0.4cm]current page.south) {\textls[200]{\@hanzodocclass}};
+    % Footer right — suite pointer
+    \node[white!20,font=\fontsize{6.5}{8}\selectfont\sffamily,anchor=south east]
+      at ([xshift=-1.4cm,yshift=1.1cm]current page.south east) {papers.hanzo.ai};
  \end{tikzpicture}%
  \newpage
 }
@@ -1,4 +1,4 @@
-\documentclass[11pt,a4paper]{article}
+\documentclass[11pt,letterpaper]{article}
 \usepackage{hanzo-defense}

 \doctitle{Edge-Deployable AI/ML Framework for\\Disconnected Tactical Environments}
@@ -6,7 +6,7 @@
 \docversion{Version 1.0 --- January 29, 2026}
 \docdate{January 2026}
 \docauthors{Zach Kelling --- Hanzo Team}
-\docorgs{Hanzo Industries \quad Lux Industries \quad Zoo Labs Foundation\\[email protected]}
+\docorgs{Hanzo Industries\\[email protected]}

 \begin{document}
 \makecover
@@ -15,6 +15,9 @@
 We present an edge-deployable AI/ML framework designed for disconnected, degraded, and bandwidth-limited tactical environments. The system combines a Rust-native LLM inference engine supporting 15+ text and 16+ vision model architectures with aggressive quantization (2--8 bit) enabling deployment on hardware ranging from Apple Silicon laptops to embedded ARM processors. A family of 18 frontier models (0.8B--1T+ parameters) provides capability tiers from nano-scale edge inference to frontier reasoning. The ZAP zero-copy binary protocol achieves 11.5M transactions per second for AI agent coordination, while GPU-accelerated operations on Metal and CUDA provide real-time performance for cryptographic and neural network workloads. Multi-agent orchestration with 83 specialized agents enables autonomous analysis with 200--300 sequential tool calls. The framework operates fully offline with local model management, sandboxed execution, and no cloud dependencies.
 \end{abstract}

+\paragraph{Executive Summary.}
+This is AI that runs where the network does not---on a laptop, a vehicle, or a handheld at the tactical edge, with no link back to the cloud. It is built for forces and field teams operating in disconnected, degraded, or jammed conditions who still need real-time analysis, imagery and document exploitation, and decision support. The same family of models that powers data-center systems is compressed to fit the hardware on hand, so a single device can run capability tiers from a small embedded chip up to a frontier model on a server, choosing the largest model the available memory allows. Because everything runs locally, sensitive data never leaves the device, there is no dependency on a vendor's servers, and operation continues when communications are contested or absent. For program leaders, this means frontier-grade AI delivered as a self-contained, owned capability rather than a subscription to a remote service that fails the moment the link drops.
+
 \tableofcontents
 \newpage

@@ -31,6 +34,10 @@ Our framework addresses these constraints through three key design decisions:
 \item \textbf{Zero-copy protocols}: Sub-microsecond serialization for real-time agent coordination.
 \end{enumerate}

+\subsection{Strategic Context}
+
+The capability to run frontier models at the disconnected edge depends on owning the model itself, and that is the gap this framework fills. American frontier AI has consolidated into a closed monoculture---effectively two labs---whose models are reachable only as a metered cloud service; the only openly available frontier weights today are largely foreign. Neither option works at the tactical edge, where there is no cloud to call and foreign-origin weights are unacceptable. Hanzo, an American applied-AI lab founded in 2014 (Techstars '17) whose founder works at the frontier of both AI/ML and cryptography, is the American open-source frontier alternative: it builds the Zen model family (0.8B--1T+ parameters) with owned weights together with a production post-quantum crypto stack, so the same models can be quantized, inspected, and deployed onto hardware the operator controls---no per-token API markup, no hyperscaler dependency, no foreign weights. Owning the model and self-hosting it is also the principal lever for roughly an order-of-magnitude lower infrastructure cost at scale, since it removes both the API markup and the cloud-margin that a rented model carries on every inference.
+
 % ============================================================================
 \section{Hanzo Engine: Rust-Native Inference}
 % ============================================================================
@@ -186,7 +193,7 @@ MoE models activate only 2--8 experts per token from a pool of 16--384, providin
 \section{GPU-Accelerated AI/ML Operations}
 % ============================================================================

-\subsection{LuxCPP Kernel Library}
+\subsection{Hanzo GPU Kernel Library}

 \begin{table}[H]
 \centering
@@ -203,27 +210,27 @@ Quantization & FP quantization, blockwise FP8 \\
 Crypto & BLS, BN254, secp256k1, Ed25519, ML-DSA, NTT \\
 \bottomrule
 \end{tabular}
-\caption{LuxCPP GPU kernel categories.}
+\caption{Hanzo GPU kernel categories.}
 \label{tab:gpu-kernels}
 \end{table}

 \subsection{Unified C API}

-\begin{lstlisting}[language=C,caption={LuxCPP acceleration C API (excerpt).}]
+\begin{lstlisting}[language=C,caption={GPU kernel acceleration C API (excerpt).}]
 // Session management
-lux_session_t* lux_create_session(lux_device_t dev);
+hz_session_t* hz_create_session(hz_device_t dev);

 // Tensor operations
-lux_tensor_t* lux_matmul(lux_session_t* s,
-    lux_tensor_t* a, lux_tensor_t* b);
-lux_tensor_t* lux_attention(lux_session_t* s,
-    lux_tensor_t* q, lux_tensor_t* k,
-    lux_tensor_t* v, float scale);
+hz_tensor_t* hz_matmul(hz_session_t* s,
+    hz_tensor_t* a, hz_tensor_t* b);
+hz_tensor_t* hz_attention(hz_session_t* s,
+    hz_tensor_t* q, hz_tensor_t* k,
+    hz_tensor_t* v, float scale);

 // Crypto operations
-lux_tensor_t* lux_mldsa_verify(lux_session_t* s,
-    lux_tensor_t* pk, lux_tensor_t* msg,
-    lux_tensor_t* sig);
+hz_tensor_t* hz_mldsa_verify(hz_session_t* s,
+    hz_tensor_t* pk, hz_tensor_t* msg,
+    hz_tensor_t* sig);
 \end{lstlisting}

 % ============================================================================
@@ -290,7 +297,7 @@ result := bridge.CallToolByName(ctx,

 \subsection{GPU Cluster Coordination}

-ZAP's mDNS discovery (\texttt{\_lux-gpu.\_tcp}) enables automatic GPU node discovery for distributed inference and FHE operations. Direct zero-copy ciphertext handling enables GPU-to-GPU encrypted computation pipelines.
+ZAP's mDNS discovery (\texttt{\_hz-gpu.\_tcp}) enables automatic GPU node discovery for distributed inference and FHE operations. Direct zero-copy ciphertext handling enables GPU-to-GPU encrypted computation pipelines.

 % ============================================================================
 \section{Multi-Agent Orchestration}
@@ -405,9 +412,9 @@ When multiple agents or edge nodes produce LoRA updates from independent operati
 \section{In-Memory Graph Analytics}
 % ============================================================================

-\subsection{Lux GraphVM}
+\subsection{GraphVM}

-Lux GraphVM provides in-memory graph analytics optimized for intelligence workloads where relationship discovery across heterogeneous data sources is critical:
+The GraphVM provides in-memory graph analytics optimized for intelligence workloads where relationship discovery across heterogeneous data sources is critical:

 \begin{itemize}
 \item \textbf{Entity resolution}: Probabilistic matching across intelligence sources (HUMINT, SIGINT, OSINT) to unify identities despite name variations, transliterations, and deliberate obfuscation.
@@ -0,0 +1,337 @@
+\documentclass[11pt,letterpaper]{article}
+\usepackage{hanzo-defense}
+
+\doctitle{Confidential Computing by Default:\\An FHE-Native Chain and\\Agent Runtime}
+\docid{HAI-DEF-2026-014}
+\docversion{Version 1.0}
+\docdate{2026}
+\docauthors{Zach Kelling --- Hanzo Team}
+\docorgs{Hanzo Industries\\[email protected]}
+
+\begin{document}
+\makecover
+
+\begin{abstract}
+Every system that processes sensitive data has a moment where it holds the data
+in the clear---and that moment is the insider risk, the cross-domain leak, and the
+blast radius of every breach. Fully homomorphic encryption (FHE) removes that
+moment: computation runs directly on ciphertext, and only a threshold of keyholders
+can decrypt the result. This paper describes Hanzo's design for making FHE the
+\emph{default} mode of computation across the two layers that normally demand
+plaintext---a blockchain's state and rules, and an autonomous agent's actions---so
+that state stays encrypted on-chain, policies are evaluated over ciphertext, and
+agents act on data they are never able to read. We give the cryptographic basis
+(BFV/BGV/CKKS/TFHE with threshold decryption), the GPU acceleration that makes it
+practical, the post-quantum anchoring that protects it for the long term, the
+defense applications it unlocks, and an explicit, honest assessment of which
+components are production today versus an active research frontier.
+\end{abstract}
+
+\paragraph{Executive Summary.}
+Normally, to compute on data you must first decrypt it---so somewhere in every
+system there is a component holding the secret in the clear, and that component is
+what an adversary, an insider, or a subpoena goes after. FHE lets the computer do
+the work \emph{while the data stays encrypted}: it takes in ciphertext, produces a
+ciphertext answer, and never sees the plaintext. Hanzo pushes this idea through the
+whole stack. The blockchain stores encrypted state and can enforce rules on
+encrypted data; agents can act on encrypted data and return encrypted answers; and
+only a quorum of keyholders can ever decrypt---no single party holds the key. For
+defense this is directly useful: allies can compute a joint answer without sharing
+raw data, a cross-domain guard can decide whether something is releasable without
+seeing its content, and sensitive workloads can run on infrastructure you do not
+fully control without exposing the data to the host. FHE's historical objection is
+speed; the practical answer here is GPU acceleration plus running only the
+sensitive part of a computation under encryption. The result is a stack where
+confidentiality is the default state of data in use, not just data at rest or in
+transit.
+
+\tableofcontents
+\newpage
+
+% ============================================================================
+\section{The Plaintext Gap}
+% ============================================================================
+
+We protect data in two of its three states well and the third state badly. Data
+\emph{at rest} is encrypted on disk; data \emph{in transit} is encrypted on the
+wire. But data \emph{in use}---the moment a program actually computes on it---is
+almost always plaintext in memory. Every database query that filters records,
+every policy engine that decides access, every model that runs inference, every
+smart contract that checks a balance, does so on cleartext. That cleartext moment
+is the structural weakness behind a large share of real incidents: the compromised
+process, the malicious insider, the memory-scraping implant, the cross-domain
+guard that has to read the data to rule on it, the cloud host that can see its
+tenants' workloads.
+
+Confidential computing has tried to shrink this gap with hardware enclaves (trusted
+execution environments). Enclaves help, but they relocate trust rather than remove
+it: you must trust the silicon vendor, the attestation chain, and the absence of
+side channels, and the data is still plaintext \emph{inside} the enclave. Fully
+homomorphic encryption attacks the gap directly. With FHE the data is never
+decrypted to be computed on at all---not in the enclave, not in memory, nowhere.
+The computation is performed on ciphertext and yields a ciphertext result. The
+plaintext gap closes.
+
+% ============================================================================
+\section{FHE in One Page}
+% ============================================================================
+
+Fully homomorphic encryption is an encryption scheme with an extra property: there
+exist operations on ciphertexts that correspond to operations on the underlying
+plaintexts. Concretely, given encryptions of $a$ and $b$, anyone---without the
+key---can compute an encryption of $a+b$ and of $a\times b$. Addition and
+multiplication are a complete basis, so in principle any computable function can be
+evaluated homomorphically by expressing it as an arithmetic (or boolean) circuit.
+The party doing the computation learns nothing; only a holder of the secret key can
+decrypt the output.
+
+\paragraph{The scheme families and what each is for.}
+\begin{itemize}
+  \item \textbf{BFV / BGV} --- exact integer arithmetic. Right for counts, sums,
+  comparisons, exact matching, and policy predicates over integers.
+  \item \textbf{CKKS} --- approximate arithmetic over real/complex numbers, with
+  SIMD ``batching'' that packs thousands of values into one ciphertext. Right for
+  statistics, signal processing, and machine-learning inference.
+  \item \textbf{TFHE} --- fast boolean gates and programmable bootstrapping. Right
+  for branching, comparisons, and arbitrary logic, including data-dependent control
+  flow.
+\end{itemize}
+
+\paragraph{Bootstrapping.} Each homomorphic operation adds noise; after enough
+operations the noise would corrupt the result. \emph{Bootstrapping} refreshes a
+ciphertext to a low-noise state and is what makes encryption ``fully''
+homomorphic---it permits unbounded computation depth. Bootstrapping is the
+expensive step, and it is the principal target of the acceleration discussed in
+\S\ref{sec:speed}.
+
+\paragraph{Threshold decryption.} The secret key need not exist in one place. With
+\emph{threshold} FHE the key is split across $n$ parties so that any $t$ of them can
+jointly decrypt but no coalition smaller than $t$ can. Combined with FHE this gives
+a system in which \emph{no single party ever holds both the data and the ability to
+reveal it}---the computation runs blind, and revealing the answer requires a quorum.
+This property is what makes the design defensible for multi-party and adversarial
+settings.
+
+% ============================================================================
+\section{Confidential State: An FHE-Native Chain}
+% ============================================================================
+
+A blockchain is normally the \emph{opposite} of confidential: every validator
+re-executes every transaction against shared plaintext state, which is precisely
+why public chains leak everything. An FHE-native chain inverts this. State is
+stored as ciphertext; transactions carry encrypted inputs; and the state-transition
+rules are evaluated homomorphically, so validators advance the ledger
+\emph{without ever seeing the values they are agreeing on}.
+
+\begin{itemize}
+  \item \textbf{Encrypted state.} Balances, ownership records, order books,
+  classifications---whatever the application holds---live on-chain as ciphertext.
+  The authoritative record exists, is immutable and auditable, and is unreadable to
+  anyone without a decryption quorum.
+  \item \textbf{Rules on ciphertext.} A transfer rule such as ``permit only if the
+  sender's balance covers the amount'' is a comparison; under BFV/TFHE that
+  comparison is evaluated on the encrypted balance and encrypted amount, yielding an
+  encrypted yes/no that gates the state update. The rule is enforced without the
+  rule-evaluator learning the balance.
+  \item \textbf{Threshold-gated disclosure.} When a value must be revealed---a
+  settlement, an audit, a court order, a coalition release decision---a threshold of
+  keyholders cooperates to decrypt exactly that value, and the decryption itself is
+  recorded. Disclosure becomes an explicit, quorum-authorized, logged event rather
+  than a default.
+  \item \textbf{Post-quantum anchoring.} The chain's signatures and transport are
+  post-quantum (ML-KEM/ML-DSA), so the encrypted record and its provenance survive a
+  future quantum adversary---essential because ciphertext recorded immutably today
+  is exactly the ``harvest now, decrypt later'' target (see the full-spectrum cyber
+  and ZAP papers).
+\end{itemize}
+
+The chain thus provides a tamper-evident, post-quantum, immutable audit trail
+\emph{of encrypted facts}: you can prove what happened and in what order without
+ever exposing what the facts were, until a quorum decides otherwise.
+
+% ============================================================================
+\section{Confidential Action: FHE-Native Agents}
+% ============================================================================
+
+The second layer that normally demands plaintext is automation. An autonomous
+agent that triages intelligence, screens transactions, routes logistics, or
+enforces a policy has to ``see'' the data to act on it---and so the agent runtime
+becomes another plaintext concentration point, now with the additional risk that
+the model itself might memorize or exfiltrate. FHE breaks this too.
+
+An FHE-native agent operates on encrypted inputs and emits encrypted outputs. It
+can evaluate the encrypted state of the chain, apply encrypted rules, and produce
+an encrypted decision or an encrypted action---all without the agent operator (or
+the model host) ever seeing the plaintext. Where the agent must run a learned model
+rather than a fixed rule, CKKS-based encrypted inference lets a (suitably
+structured) model classify or score encrypted inputs and return an encrypted
+result. The agent is then \emph{operator-blind}: it does useful work on data it
+cannot read, on infrastructure that cannot read it either.
+
+This composes with Hanzo's broader agentic runtime (the agentic-AI and edge papers):
+the same orchestration of specialized agents and tool calls runs, but the data
+plane underneath it is ciphertext. Autonomy and confidentiality stop being a
+trade-off.
+
+% ============================================================================
+\section{Programmable Confidentiality: Rules and Policies on Ciphertext}
+% ============================================================================
+
+The unifying idea is that a \emph{rule} is just a function, and any function can in
+principle be evaluated under FHE. So the policies that govern a system---not only
+its data---can run on ciphertext. This is the capability the rest of the paper
+builds on, because most high-consequence decisions are policy decisions over
+sensitive inputs:
+
+\begin{itemize}
+  \item \textbf{Releasability} --- ``may this datum cross to that security domain /
+  that coalition partner?'' decided on the encrypted datum (see cross-domain paper).
+  \item \textbf{Eligibility / authorization} --- ``does this party satisfy the
+  conditions?'' decided without revealing the party's attributes.
+  \item \textbf{Thresholds and limits} --- ``is the aggregate over/under the line?''
+  decided without revealing the individual contributions.
+  \item \textbf{Matching} --- ``do these two sealed values correspond?'' (sealed-bid
+  auctions, private set intersection, deconfliction) decided without opening either
+  side.
+\end{itemize}
+
+In each case the \emph{decision} is computed and enforced while the \emph{inputs}
+remain encrypted, and only the (small, controlled) decision output is ever a
+candidate for threshold decryption. Confidentiality becomes programmable: you write
+the rule once and it runs blind.
+
+% ============================================================================
+\section{Defense Applications}
+% ============================================================================
+
+The combination of an encrypted ledger and operator-blind agents answers a set of
+defense problems that have no clean classical solution:
+
+\begin{itemize}
+  \item \textbf{Coalition analytics without disclosure.} Partners compute a joint
+  result---shared targets, overlapping indicators, combined logistics---over their
+  combined data while each party's raw data stays encrypted. Nobody surrenders
+  sources or methods to get the joint answer, and the chain records that the
+  computation occurred.
+  \item \textbf{Cross-domain transfer on ciphertext.} A guard evaluates a release
+  policy against encrypted content and decides movement between security levels
+  without ever seeing the content, removing the guard itself as a data tap.
+  \item \textbf{Private intelligence fusion.} Multi-source correlation runs while
+  the sources stay encrypted, so a breach of the fusion system does not expose the
+  underlying collection.
+  \item \textbf{Encrypted ML inference.} A model classifies encrypted imagery or
+  signals: the data owner never exposes the input and the model operator never sees
+  it---useful when the data is sensitive, the model is sensitive, or both.
+  \item \textbf{Encrypted command, targeting, and logistics state.} Orders,
+  target lists, and movement tables live as encrypted on-chain state with an
+  immutable, post-quantum audit trail; agents act on them under encryption; reveal
+  is quorum-gated and logged.
+  \item \textbf{Computation on untrusted infrastructure.} Sensitive workloads run on
+  contractor, coalition, or commercial-cloud hardware without exposing the data to
+  the host---widening where a mission can compute.
+\end{itemize}
+
+% ============================================================================
+\section{Why the Speed Objection No Longer Holds}
+\label{sec:speed}
+% ============================================================================
+
+FHE's reputation for impracticality is a decade out of date, and three things close
+the gap in this stack:
+
+\begin{enumerate}
+  \item \textbf{GPU acceleration.} The dominant cost in FHE is the
+  number-theoretic transform (NTT) at the heart of polynomial multiplication and
+  bootstrapping. These are massively parallel and map naturally onto GPUs; the same
+  native-GPU foundation that accelerates the chain's cryptography accelerates the
+  FHE layer, turning bootstrapping from seconds toward the practical range.
+  \item \textbf{Batching.} CKKS and BGV pack thousands of plaintext slots into one
+  ciphertext, so a single homomorphic operation does thousands of useful operations
+  at once---ideal for the vector and tensor workloads in analytics and inference.
+  \item \textbf{Selective FHE.} Most computations have a small sensitive core inside
+  a large non-sensitive shell. You do not run the whole program under FHE---only the
+  predicate or the field that must stay private. The expensive primitive is spent
+  precisely where it buys confidentiality and nowhere else.
+\end{enumerate}
+
+The honest framing is not ``FHE is now as fast as plaintext''---it is not---but
+``the workloads that matter for confidential rules, matching, gating, and bounded
+inference are now practical, and GPU acceleration keeps widening the set.''
+
+% ============================================================================
+\section{Key Custody Without a Single Point of Trust}
+% ============================================================================
+
+A confidentiality system is only as strong as its key handling. The design holds
+the decryption key nowhere: threshold decryption splits it $t$-of-$n$ across
+independent parties (validators, agencies, coalition members) so that decrypting
+any value requires an explicit quorum and no minority---and no single compromised
+host, insider, or seized server---can reveal anything. This is the structural
+answer to ``who can see the data?'': by construction, \emph{nobody}, until enough
+authorized parties agree, and that agreement is itself recorded on the chain.
+
+% ============================================================================
+\section{Composition With the Rest of the Stack}
+% ============================================================================
+
+FHE here is not a bolt-on library; it is one primitive in a stack Hanzo owns
+end-to-end, which is what makes the ``native'' claim real:
+
+\begin{itemize}
+  \item \textbf{Native-GPU chain} provides the encrypted, immutable, post-quantum
+  ledger and the GPU substrate the FHE layer rides on.
+  \item \textbf{Post-quantum transport and identity} (ZAP, ML-KEM/ML-DSA) protect
+  the ciphertext in motion and bind it to verifiable identities.
+  \item \textbf{Agentic runtime} supplies the operator-blind automation that acts on
+  the encrypted state.
+  \item \textbf{Owned models} (the Zen family) supply the inference that, under
+  CKKS, can run on encrypted inputs.
+\end{itemize}
+
+Because all four are owned and open, the confidentiality guarantee is auditable
+rather than asserted: a defense customer can inspect the whole path the data takes
+and confirm there is no point where it is silently in the clear.
+
+% ============================================================================
+\section{Honest Maturity Assessment}
+% ============================================================================
+
+This is a capability paper, and the credible version of it is explicit about what
+runs today versus what is an active frontier. No overstatement:
+
+\begin{itemize}
+  \item \textbf{Production-grade today:} the GPU-accelerated FHE primitives
+  (BFV/BGV/CKKS/TFHE), threshold decryption, the native-GPU post-quantum chain, and
+  the agentic runtime each exist and run. Bounded-depth confidential workloads
+  ---rule and policy predicates, comparisons, matching/deconfliction, aggregate
+  thresholds, and inference on suitably structured models---are practical now.
+  \item \textbf{Active frontier:} fully general, arbitrary-depth FHE-native
+  programmability at plaintext-class throughput is not solved---by anyone---and we do
+  not claim it. The performance envelope is widening (faster bootstrapping, better
+  GPU kernels, hybrid MPC/FHE designs), and the architecture is built so that
+  workloads move from ``frontier'' to ``practical'' as that envelope grows, without
+  redesign.
+\end{itemize}
+
+The strategic point stands regardless of where the line currently sits: Hanzo owns
+every layer the line runs through, so as FHE performance improves the gains land in
+a stack a customer already controls---rather than waiting on a closed vendor to
+expose the capability.
+
+% ============================================================================
+\section{Conclusion}
+% ============================================================================
+
+Confidentiality of data \emph{in use} is the unsolved third of the problem, and it
+is the one that matters most for coalition operations, cross-domain movement,
+intelligence fusion, and computing on infrastructure you do not own. FHE closes the
+plaintext gap by computing on ciphertext; threshold decryption removes the single
+point of trust; GPU acceleration and selective application make the important
+workloads practical; and post-quantum anchoring protects the encrypted record for
+the long term. Hanzo's contribution is to make this the default across a chain and
+an agent runtime it owns end-to-end, so that ``private ciphertext for every
+operation'' is an architectural property of the stack rather than a feature of one
+application. Compute on data you are not allowed to see---and let the rules,
+the ledger, and the agents all run blind.
+
+\end{document}
@@ -1,4 +1,4 @@
-\documentclass[11pt,a4paper]{article}
+\documentclass[11pt,letterpaper]{article}
 \usepackage{hanzo-defense}

 \doctitle{Machine-Checked Proofs and Automated Verification\\for Post-Quantum Distributed Systems}
@@ -6,7 +6,7 @@
 \docversion{Version 1.0 --- February 28, 2026}
 \docdate{February 2026}
 \docauthors{Zach Kelling --- Hanzo Team}
-\docorgs{Hanzo Industries \quad Lux Industries \quad Zoo Labs Foundation\\[email protected]}
+\docorgs{Hanzo Industries\\[email protected]}

 \begin{document}
 \makecover
@@ -15,6 +15,9 @@
 We present a comprehensive formal verification suite for a post-quantum distributed system encompassing blockchain consensus, threshold cryptography, fully homomorphic encryption, and cross-chain messaging. The suite comprises 50 machine-checked proofs in Lean~4 covering consensus safety and liveness, 18 cryptographic security reductions (including ML-DSA EU-CMA, ML-KEM IND-CCA2, and Corona lattice threshold unforgeability), 12 protocol correctness proofs, and 7 DeFi invariant proofs. Complementary tooling includes Halmos symbolic execution for EVM smart contracts, 23+ fuzz targets for parser and cryptographic implementations, and NIST Known Answer Test vector validation for all three \fips{203/204/205} algorithms. We identify the critical gaps---TLA+ model checking for consensus liveness, Tamarin protocol verification for the novel hybrid post-quantum handshake, and constant-time verification for lattice cryptography implementations---and present a phased roadmap for closing them. This work demonstrates the deepest formal verification coverage of any production post-quantum blockchain system.
 \end{abstract}

+\paragraph{Executive Summary.}
+Most software is trusted because it was tested and nothing broke. This work goes further: the core security claims are proved as mathematical theorems and re-checked by a machine on every code change, so a regression cannot ship undetected. The proofs cover the properties an accreditor actually asks about---that the system cannot reach two conflicting decisions, that the quantum-resistant cryptography is sound, that the money-handling logic stays solvent---and they target the new post-quantum standards mandated for national-security systems. For a program manager or accreditation authority, this is evidence that can go directly into an Authority-to-Operate package: not ``we tested it,'' but ``here is a machine-checked proof, and here is exactly the set of assumptions it rests on.'' The paper is candid about what is proved today versus what is on the roadmap (model checking and protocol analysis), so reviewers can see the true assurance boundary rather than a marketing one.
+
 \tableofcontents
 \newpage

@@ -24,7 +27,7 @@ We present a comprehensive formal verification suite for a post-quantum distribu

 Formal verification provides mathematical certainty that software behaves according to its specification. For defense systems where failure modes include loss of life, compromise of classified information, or mission failure, formal methods are not optional---they are essential.

-This paper documents the formal verification infrastructure supporting the Lux/Hanzo post-quantum distributed system, assesses its completeness, and presents a roadmap for achieving the level of assurance required for naval deployment.
+This paper documents the formal verification infrastructure supporting the Hanzo post-quantum distributed system, assesses its completeness, and presents a roadmap for achieving the level of assurance required for naval deployment.

 \subsection{Verification Layers}

@@ -61,11 +64,15 @@ Smart contracts & 3 & Halmos \\
 \label{tab:coverage}
 \end{table}

+\subsection{Strategic Context}
+
+Formal verification is where owning the whole stack pays off. Hanzo (American-owned, Techstars~'17, founded 2014) builds both the post-quantum cryptography and the frontier AI---the \emph{Zen} model family---that depend on the properties proved here, which is what makes a machine-checked claim meaningful: there is no third-party black box whose internals are out of reach of the prover. This matters because of where trustworthy AI now comes from. America's frontier AI has narrowed to a closed two-vendor duopoly, while the broad \emph{open} ecosystem---and therefore most openly auditable frontier weights---now sits offshore. A defense or regulated operator who needs to inspect, accredit, and run a system on sovereign infrastructure is forced to choose between renting from a closed American duopoly or depending on foreign open weights. Hanzo is the American open-source alternative that owns the model and the cryptography together; the verification suite documented here is the auditable evidence that backs that claim---formal proof an accreditor can read rather than a vendor assurance they must take on faith.
+
 % ============================================================================
 \section{Lean 4 Proof Library}
 % ============================================================================

-The proof library resides at \texttt{lux/formal/lean/} and contains 50 Lean~4 files organized by domain.
+The proof library resides at \texttt{hanzo/formal/lean/} and contains 50 Lean~4 files organized by domain.

 \subsection{Consensus Proofs}

@@ -157,7 +164,7 @@ All proofs follow a consistent structure:
 \item \textbf{Axioms}: Cryptographic hardness assumptions (Module-LWE, discrete log, hash collision resistance) are stated as Lean axioms. This is standard---proving these from first principles is open research.
 \item \textbf{Definitions}: Protocol state machines, message types, and security games formalized as Lean structures.
 \item \textbf{Theorems}: Security properties proved from axioms using \texttt{simp}, \texttt{omega}, \texttt{apply}, \texttt{induction}.
-\item \textbf{Correspondence}: Each \texttt{.lean} file has a matching \texttt{.tex} paper in \texttt{lux/papers/proofs/} documenting the proof in traditional mathematical notation.
+\item \textbf{Correspondence}: Each \texttt{.lean} file has a matching \texttt{.tex} paper in \texttt{hanzo/papers/proofs/} documenting the proof in traditional mathematical notation.
 \end{enumerate}

 Approximately 130 axioms across 50 files. The axioms encode the \emph{assumptions} under which the system is secure; the theorems prove that security \emph{follows} from these assumptions.
@@ -199,15 +206,15 @@ Halmos uses the Foundry test format, requiring no separate specification languag
 \toprule
 \textbf{Component} & \textbf{Location} & \textbf{Targets} \\
 \midrule
-CB58 encoding & \texttt{lux/crypto/cb58/} & 2 \\
-secp256k1 signatures & \texttt{lux/crypto/secp256k1/} & 3 \\
-IPA proofs & \texttt{lux/crypto/ipa/} & 2 \\
-BLAKE2b hashing & \texttt{lux/crypto/hash/blake2b/} & 1 \\
-BFT consensus & \texttt{lux/bft/} & 4 \\
-MerkleDB codec & \texttt{lux/node/x/merkledb/codec/} & 5 \\
-Compression & \texttt{lux/node/utils/compression/} & 3 \\
-RPC database & \texttt{lux/node/database/rpcdb/} & 2 \\
-Deque & \texttt{lux/node/utils/buffer/deque/} & 1 \\
+CB58 encoding & \texttt{hanzo/crypto/cb58/} & 2 \\
+secp256k1 signatures & \texttt{hanzo/crypto/secp256k1/} & 3 \\
+IPA proofs & \texttt{hanzo/crypto/ipa/} & 2 \\
+BLAKE2b hashing & \texttt{hanzo/crypto/hash/blake2b/} & 1 \\
+BFT consensus & \texttt{hanzo/bft/} & 4 \\
+MerkleDB codec & \texttt{hanzo/node/x/merkledb/codec/} & 5 \\
+Compression & \texttt{hanzo/node/utils/compression/} & 3 \\
+RPC database & \texttt{hanzo/node/database/rpcdb/} & 2 \\
+Deque & \texttt{hanzo/node/utils/buffer/deque/} & 1 \\
 \midrule
 \textbf{Total} & & \textbf{23} \\
 \bottomrule
@@ -224,15 +231,15 @@ Deque & \texttt{lux/node/utils/buffer/deque/} & 1 \\
 \toprule
 \textbf{Target} & \textbf{Location} & \textbf{Bug Class} \\
 \midrule
-ZAP deserializer & \texttt{lux/zap/} & Parsing crashes, buffer overflows \\
-ML-DSA sign/verify & \texttt{lux/crypto/mldsa/} & Malformed signature acceptance \\
-ML-KEM encaps/decaps & \texttt{lux/crypto/mlkem/} & Malformed ciphertext crashes \\
-Corona threshold & \texttt{lux/crypto/threshold/} & Malformed share acceptance \\
-BLS aggregation & \texttt{lux/crypto/bls/} & Rogue key attacks \\
-FHE ciphertext parsing & \texttt{lux/fhe/go/tfhe/} & Malformed ciphertext \\
-ZKVM proof verifier & \texttt{lux/node/vms/zkvm/} & Invalid proof acceptance \\
-RNS link protocol & \texttt{lux/node/network/dialer/} & Handshake state machine \\
-SessionVM messages & \texttt{lux/session/} & Message parsing \\
+ZAP deserializer & \texttt{hanzo/zap/} & Parsing crashes, buffer overflows \\
+ML-DSA sign/verify & \texttt{hanzo/crypto/mldsa/} & Malformed signature acceptance \\
+ML-KEM encaps/decaps & \texttt{hanzo/crypto/mlkem/} & Malformed ciphertext crashes \\
+Corona threshold & \texttt{hanzo/crypto/threshold/} & Malformed share acceptance \\
+BLS aggregation & \texttt{hanzo/crypto/bls/} & Rogue key attacks \\
+FHE ciphertext parsing & \texttt{hanzo/fhe/go/tfhe/} & Malformed ciphertext \\
+ZKVM proof verifier & \texttt{hanzo/node/vms/zkvm/} & Invalid proof acceptance \\
+RNS link protocol & \texttt{hanzo/node/network/dialer/} & Handshake state machine \\
+SessionVM messages & \texttt{hanzo/session/} & Message parsing \\
 \bottomrule
 \end{tabular}
 \caption{Proposed fuzz target expansion (9 new targets, bringing total to 32+).}
@@ -375,14 +382,14 @@ Ethereum (EF) & -- & TLA+ (Gasper) & Halmos & OSS-Fuzz \\
 Tendermint & -- & TLA+ (Apalache) & -- & go-fuzz \\
 Solana & -- & -- & -- & Limited \\
 Avalanche & -- & -- & -- & Limited \\
-\textbf{Lux (ours)} & \textbf{50 Lean 4} & \textbf{Planned} & \textbf{Halmos} & \textbf{23+ targets} \\
+\textbf{Hanzo (ours)} & \textbf{50 Lean 4} & \textbf{Planned} & \textbf{Halmos} & \textbf{23+ targets} \\
 \bottomrule
 \end{tabular}
 \caption{Formal verification comparison with major blockchain projects.}
 \label{tab:industry-comparison}
 \end{table}

-Lux is the only blockchain project with machine-checked proofs of post-quantum cryptographic properties. No other project has Lean~4 proofs of ML-DSA, ML-KEM, or lattice threshold signatures.
+Hanzo is the only blockchain project with machine-checked proofs of post-quantum cryptographic properties. No other project has Lean~4 proofs of ML-DSA, ML-KEM, or lattice threshold signatures.

 % ============================================================================
 \section{Defense Application}
@@ -467,7 +474,7 @@ For defense applications, this verification infrastructure provides the formal e
 \end{thebibliography}

 \section*{Reproducibility}
-\textbf{Source code.} \texttt{github.com/luxfi/consensus, luxfi/quasar} (commit \texttt{TBD}).\\
+\textbf{Source code.} \texttt{github.com/hanzoai/consensus, hanzoai/quasar} (commit \texttt{TBD}).\\
 \textbf{Build.} go test ./... and rust-based fuzzers via cargo test.\\
 \textbf{Hardware tested.} Linux amd64, deterministic test environment.\\
 \textbf{Standards referenced.} NIST IR 8214C (Threshold Crypto), LOKI consensus fuzzing.\\
@@ -1,4 +1,4 @@
-\documentclass[11pt,a4paper]{article}
+\documentclass[11pt,letterpaper]{article}
 \usepackage{hanzo-defense}

 \doctitle{FIPS 203/204/205 Compliant Cryptographic\\Architecture for Naval Information Dominance}
@@ -6,7 +6,7 @@
 \docversion{Version 1.0 --- January 22, 2026}
 \docdate{January 2026}
 \docauthors{Zach Kelling --- Hanzo Team}
-\docorgs{Hanzo Industries \quad Lux Industries \quad Zoo Labs Foundation\\[email protected]}
+\docorgs{Hanzo Industries\\[email protected]}

 \begin{document}
 \makecover
@@ -15,6 +15,9 @@
 We present a comprehensive cryptographic architecture implementing all three \nist{} post-quantum standards---ML-DSA (\fips{204}), ML-KEM (\fips{203}), and SLH-DSA (\fips{205})---integrated into a production blockchain consensus system with hybrid classical/quantum security. The Quasar consensus protocol achieves sub-second finality through dual-certificate blocks combining BLS12-381 aggregate signatures with Corona lattice-based threshold signatures, providing an attack window of $\leq$50~ms. We detail six threshold multi-party computation schemes (CGGMP21, FROST, LSS, BLS, SR25519, TFHE) operating over a zero-copy wire protocol, GPU-accelerated cryptographic operations on Metal and CUDA, fully homomorphic encryption via a dedicated virtual machine, and a comprehensive key management system with Shamir secret sharing, HSM integration, and HIPAA/SOX/SEC compliance controls. The architecture provides defense-in-depth against both current and quantum adversaries, with 17 formal cryptographic proofs supporting security claims.
 \end{abstract}

+\paragraph{Executive Summary.}
+A capable adversary is already recording encrypted traffic today to decrypt it later, once a quantum computer can break the classical cryptography that protects nearly all systems now in the field. This work is a complete, working cryptographic stack that closes that window: it implements all three of the U.S.\ government's new post-quantum standards (the NIST FIPS 203/204/205 algorithms that CNSA 2.0 mandates by 2030) and runs them in a live system rather than a slideware roadmap. It reaches a decision in under a second, refreshes its keys every few minutes so any single compromise exposes only minutes of data, and never reconstructs a full secret key in one place. For defense program leads and contractors, the takeaway is that the migration to quantum-resistant cryptography---usually framed as a multi-year future project---is here as deployed, tested infrastructure, with formal proofs behind the security claims and acceleration on commodity Apple and NVIDIA hardware.
+
 \tableofcontents
 \newpage

@@ -180,7 +183,7 @@ Flare & 5 & Certificate generation, DAG frontier \\
 \section{Threshold Multi-Party Computation}
 % ============================================================================

-The Lux MPC system provides distributed key generation and signing without ever reconstructing full private keys.
+The MPC system provides distributed key generation and signing without ever reconstructing full private keys.

 \subsection{Supported Schemes}

@@ -193,7 +196,7 @@ The Lux MPC system provides distributed key generation and signing without ever
 CGGMP21 & secp256k1 & Threshold ECDSA & 20+ \\
 FROST & Ed25519, Ristretto255 & EdDSA, SR25519 & Polkadot, Solana \\
 LSS & secp256k1 & Dynamic resharing & All ECDSA \\
-BLS & BLS12-381 & Consensus signing & Lux \\
+BLS & BLS12-381 & Consensus signing & Hanzo \\
 SR25519 & Ristretto255 & Substrate compat & Polkadot \\
 TFHE & Lattice & Threshold FHE & T-Chain \\
 \bottomrule
@@ -252,12 +255,12 @@ This eliminates external dependencies (NATS, Consul, Redis) and provides the sam

 \subsection{ThresholdVM Architecture}

-ThresholdVM provides FHE operations as a native virtual machine on the Lux T-Chain, enabling computation on encrypted data without decryption:
+ThresholdVM provides FHE operations as a native virtual machine on the T-Chain, enabling computation on encrypted data without decryption:

 \begin{itemize}
 \item \textbf{Schemes}: BFV (integer arithmetic), BGV (modular arithmetic), CKKS (approximate real), TFHE (Boolean circuits).
 \item \textbf{Threshold decryption}: $t$-of-$n$ parties must cooperate; no single entity sees plaintext.
-\item \textbf{GPU acceleration}: NTT/iNTT, polynomial multiplication, and TFHE bootstrap operations accelerated via LuxCPP Metal/CUDA kernels.
+\item \textbf{GPU acceleration}: NTT/iNTT, polynomial multiplication, and TFHE bootstrap operations accelerated via the Hanzo GPU kernel library's Metal/CUDA kernels.
 \item \textbf{EVM integration}: Precompiles at \texttt{0x0700}--\texttt{0x0703} (Fheos, ACL, InputVerifier, Gateway).
 \end{itemize}

@@ -283,7 +286,7 @@ The TFHE-KMS bridge enables encrypted policy evaluation:
 \section{GPU-Accelerated Cryptography}
 % ============================================================================

-LuxCPP provides GPU kernels for cryptographic operations across Metal (Apple Silicon), CUDA (NVIDIA), and WebGPU:
+The Hanzo GPU kernel library provides GPU kernels for cryptographic operations across Metal (Apple Silicon), CUDA (NVIDIA), and WebGPU:

 \begin{table}[H]
 \centering
@@ -302,7 +305,7 @@ FHE & TFHE bootstrap, BFV/CKKS modular polynomial ops \\
 \label{tab:gpu-crypto}
 \end{table}

-The stable C ABI (\texttt{lux-accel/c\_api.h}) enables FFI bindings from Go, Rust, and Python.
+The stable C ABI (\texttt{hz-accel/c\_api.h}) enables FFI bindings from Go, Rust, and Python.

 % ============================================================================
 \section{Zero-Knowledge Proof Systems}
@@ -540,7 +543,7 @@ Every discovered vulnerability and exploitation step is automatically mapped to
 \section{QuantumVM: Quantum Computing Operations}
 % ============================================================================

-QuantumVM is a dedicated virtual machine on the Lux Q-Chain that provides quantum key operations, quantum algorithm simulation, and hybrid quantum-classical workflow support as native blockchain primitives.
+QuantumVM is a dedicated virtual machine on the Q-Chain that provides quantum key operations, quantum algorithm simulation, and hybrid quantum-classical workflow support as native blockchain primitives.

 \subsection{Post-Quantum Key Operations}

@@ -606,6 +609,12 @@ QuantumVM operations are accessible from EVM smart contracts via precompiles at
 \label{tab:quantumvm-precompiles}
 \end{table}

+% ============================================================================
+\section{Strategic Context}
+% ============================================================================
+
+The post-quantum architecture detailed here is built and owned end-to-end by Hanzo AI, an American-owned applied-AI lab and venture studio (Techstars '17, founded 2014) responsible for more than 100 venture-funded startups and several unicorns, founded by an expert in both AI/ML and cryptography. Two facts make this relevant to national-security buyers. First, sovereignty of the cryptography itself: a post-quantum migration is only as trustworthy as the party that controls the implementation, and this stack is American-owned, auditable, and free of dependence on foreign or black-box components---the same standards (FIPS 203/204/205, CNSA 2.0) the U.S.\ government mandates, implemented by a U.S.\ party that can be inspected. Second, sovereignty of the AI that increasingly rides on top of that cryptography: U.S.\ frontier AI has narrowed to a closed commercial duopoly, while the only broadly open frontier weights available today are largely foreign, leaving regulated and defense buyers to either rent from the duopoly or take a dependency on foreign models. Hanzo is the American open-source frontier alternative---it owns both the Zen model family and this cryptographic stack, so the consensus, key-management, and confidential-compute layers above can be deployed offline, at the edge, and under full audit. That this is engineering rather than research is evidenced in production: the same agentic stack delivered a FINRA/SEC-approved, SOC2 securities platform---a full ATS/BD/TA stack consolidated from 200+ microservices into 3 compiled binaries---to production with a small team, and the efficiency primitives described here (the ZAP transport reaching roughly 11.5M transactions per second with order-of-magnitude memory and energy reductions versus JSON-RPC) translate directly into lower infrastructure cost and viable disconnected operation.
+
 % ============================================================================
 \section{Conclusion}
 % ============================================================================
@@ -637,7 +646,7 @@ The architecture is not theoretical---it is deployed, tested, and operational, w

 \bibitem{circl} Cloudflare, ``CIRCL: Interoperable Reusable Cryptographic Library,'' v1.6, 2024.

-\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Lux Industries, 2025.
+\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Hanzo, 2025.

 \bibitem{tfhe} I. Chillotti \etal, ``TFHE: Fast Fully Homomorphic Encryption over the Torus,'' JoC 2020.

@@ -654,7 +663,7 @@ The architecture is not theoretical---it is deployed, tested, and operational, w
 \end{thebibliography}

 \section*{Reproducibility}
-\textbf{Source code.} \texttt{github.com/hanzoai/agents, luxfi/zap} (commit \texttt{TBD}).\\
+\textbf{Source code.} \texttt{github.com/hanzoai/agents, hanzoai/zap} (commit \texttt{TBD}).\\
 \textbf{Build.} make build per component; OpenZiti overlay deployed via Helm.\\
 \textbf{Hardware tested.} Linux amd64/arm64; tested in air-gapped lab environments.\\
 \textbf{Standards referenced.} OpenZiti, NIST PQC, MITRE ATT\&CK.\\
@@ -0,0 +1,148 @@
+\documentclass[9pt,letterpaper]{extarticle}
+
+% ============================================================================
+% Hanzo Cloud for Reindustrialization --- shareable capabilities one-pager
+% Brand: Hanzo only. Monochrome. Links to the full suite on papers.hanzo.ai
+% ============================================================================
+\usepackage[T1]{fontenc}
+\usepackage[utf8]{inputenc}
+\usepackage{amsmath}
+\usepackage[margin=0.6in]{geometry}
+\usepackage{xcolor}
+\usepackage{graphicx}
+\usepackage{tikz}
+\usepackage{enumitem}
+\usepackage{microtype}
+\usepackage{qrcode}
+\usepackage[hidelinks]{hyperref}
+\usepackage{helvet}
+\renewcommand{\familydefault}{\sfdefault}
+
+\definecolor{hzblack}{RGB}{0,0,0}
+\definecolor{hzgray}{RGB}{90,90,90}
+\definecolor{hzrule}{RGB}{175,175,175}
+
+\pagestyle{empty}
+\setlength{\parindent}{0pt}
+\setlength{\parskip}{2.5pt}
+\setlist[itemize]{leftmargin=1.25em,itemsep=1.5pt,topsep=1.5pt,parsep=0pt}
+\newcommand{\rulen}{\textcolor{hzrule}{\rule{\linewidth}{0.7pt}}}
+\newcommand{\pl}[2]{\href{https://papers.hanzo.ai/#1}{\textbf{#2}}}
+
+\begin{document}
+
+% ---- Black header band with logo -------------------------------------------
+\noindent\begin{tikzpicture}
+  \fill[hzblack] (0,0) rectangle (\linewidth,2.05);
+  \node[anchor=west] at (0.35,1.18) {\includegraphics[height=0.92cm]{hanzo-logo-white.pdf}};
+  \node[white,anchor=west,font=\LARGE\bfseries] at (1.75,1.38) {Hanzo Cloud for Reindustrialization};
+  \node[hzrule,anchor=west,font=\small] at (1.78,0.66)
+    {Sovereign AI, robotics, spatial 3D \& post-quantum infrastructure for the American industrial base};
+  \node[white,anchor=east,font=\scriptsize] at (\linewidth-0.35,1.5) {papers.hanzo.ai};
+  \node[white,anchor=east,font=\scriptsize] at (\linewidth-0.35,0.5) {[email protected]};
+\end{tikzpicture}
+
+\vspace{7pt}
+
+\textbf{Hanzo Cloud is the sovereign AI operating layer for the new American industrial base} --- factories,
+robots, vehicles, sensors, drones, ships, and defense systems. We combine open-source AI infrastructure, spatial
+3D, robotics control, post-quantum cryptography, FHE, and low-latency on-chain coordination so industrial and
+defense operators can \textbf{build, automate, simulate, secure, and command} real-world systems --- from the
+factory floor to the contested edge --- without depending on closed, foreign, or hyperscaler-controlled AI.
+
+\vspace{3pt}\rulen\vspace{2pt}
+
+{\large\textbf{Why Hanzo}}
+\begin{itemize}
+  \item \textbf{Sovereign industrial cloud.} An open-source, self-hostable AI cloud --- agents, models, tools,
+  memory, IAM/KMS, audit, sandboxes, deployment, secure workflows --- running in cloud, factory, edge, or
+  air-gapped. Not just chatbot infrastructure.
+  \item \textbf{Spatial 3D + robotics.} Sits behind robotic cells, digital twins, spatial maps, autonomous
+  vehicles, drones, inspection, and simulation-to-field workflows --- exactly the Michigan industrial base of
+  vehicles, autonomy, robotics, and ground systems.
+  \item \textbf{Low-latency on-chain coordination.} Verifiable coordination \emph{for machines}: identity,
+  provenance, command logs, audit trails, access control, encrypted state, settlement, and trusted multi-party
+  workflows between humans, robots, contractors, factories, and battlefield nodes.
+  \item \textbf{Post-quantum + FHE-native security.} PQC secures comms and identity against future
+  cryptographic risk; FHE lets agents, rules, and workflows compute \emph{over ciphertext} --- coalition
+  analytics, cross-domain decisions, private supply-chain scoring, encrypted sensor fusion, private robotics
+  telemetry.
+  \item \textbf{Agentic engineering + cost collapse.} The same stack modernizes a contractor's software in
+  place --- fewer services, lower cloud cost, sovereign and auditable --- as proven below.
+\end{itemize}
+
+\vspace{2pt}\rulen\vspace{2pt}
+
+{\large\textbf{Built for physical industry}}
+\begin{itemize}
+  \item \textbf{Factory automation} --- agentic workflows for production, QA, maintenance, scheduling, inventory, and process optimization.
+  \item \textbf{Robotics \& autonomy} --- spatial 3D, simulation, perception pipelines, low-latency control, fleet coordination, and edge inference.
+  \item \textbf{Defense systems} --- secure command \& telemetry, post-quantum identity, FHE-protected workflows, DDIL operation, and air-gapped deployment.
+  \item \textbf{Industrial software modernization} --- collapse legacy cloud, services, CI/CD, observability, auth, data, and security into an owned OSS stack.
+  \item \textbf{On-chain machine coordination} --- tamper-evident logs, provenance, access control, encrypted state, tasking, settlement, and inter-org trust.
+\end{itemize}
+
+\vspace{2pt}\rulen\vspace{2pt}
+
+{\large\textbf{The proof}}\quad Founding CEO/CTO \textbf{Zach Kelling} was the \textbf{\#1 Anthropic user by
+token count worldwide in 2025} (claudecount.com). That throughput built --- with a small team on the owned OSS
+stack --- a \textbf{FINRA/SEC-approved, SOC\,2 securities exchange} on post-quantum crypto, a native-GPU
+blockchain, and FHE. Engaged for a narrow remediation scope, the team uncovered the real estate ---
+\textbf{200+ microservices} on Google Cloud --- and \textbf{consolidated it into 3 binaries}, deleting
+\textbf{3.5M lines of dead code} (3.07M${\rightarrow}$1.06M active) and closing \textbf{93 security findings}
+(22 critical). Cloud spend fell \textbf{${\sim}90\%$} (${\sim}\$35\text{K}\!\rightarrow\!{\sim}\$3.5\text{K}$/mo,
+${\approx}\$380\text{K}$/yr saved). Backed by production post-quantum (FIPS 203/204/205), 50 machine-checked
+proofs, and the ZAP transport at \textbf{11.5M tx/s} (91\% less memory, 96\% less energy than JSON-RPC).
+
+\vspace{2pt}
+{\footnotesize\textcolor{hzgray}{\textbf{By the numbers:}}\;
+\textbf{11.5M tx/s} transport $\cdot$ \textbf{2.2\,ns} parse $\cdot$ \textbf{91\%} less memory $\cdot$ \textbf{96\%}
+less energy $\cdot$ \textbf{30$\times$} throughput vs JSON-RPC $\cdot$ \textbf{$<$2\,min} rolling deploys $\cdot$
+one \textbf{48\,MB} binary replaces \textbf{17+} services ($\sim$27$\times$ smaller) $\cdot$ \textbf{$\sim$90\%}
+cloud-cost cut ($\approx$\$380K/yr) $\cdot$ \textbf{200+$\rightarrow$3} microservices $\cdot$ \textbf{3.5M} dead
+lines deleted $\cdot$ \textbf{93} security findings closed $\cdot$ \textbf{50} machine-checked proofs $\cdot$
+\textbf{FIPS 203/204/205} in production $\cdot$ offline on embedded ARM.}
+
+\vspace{3pt}
+\colorbox{hzblack}{\parbox{\dimexpr\linewidth-2\fboxsep}{\color{white}\small
+\textbf{For combat systems}, Hanzo is the secure coordination layer: spatial awareness, low-latency agent
+control, post-quantum identity, encrypted telemetry, FHE-protected decision rules, and auditable on-chain
+command history --- deployable at the edge when cloud links are degraded or denied.}}
+
+\vspace{4pt}\rulen\vspace{2pt}
+
+\begin{minipage}[t]{0.74\linewidth}
+{\large\textbf{The papers}}\quad\textcolor{hzgray}{\footnotesize free to read \& share at papers.hanzo.ai}\\[3pt]
+\textit{Start here:}\;
+\pl{hanzo-vs-claude}{Sovereign vs.\ Closed} \;\textbar\;
+\pl{hanzo-agentic-prowess}{Agentic Engineering at Regulated Scale} \;\textbar\;
+\pl{hanzo-cloud-economics}{Cloud Economics} \;\textbar\;
+\pl{hanzo-fhe-native}{Confidential Computing by Default (FHE)}\\[3pt]
+\textit{Depth:}\;
+\pl{hanzo-zap-protocol}{ZAP} \;\textbar\;
+\pl{hanzo-full-spectrum-cyber}{Full-Spectrum Cyber} \;\textbar\;
+\pl{hanzo-formal-verification}{Formal Verification} \;\textbar\;
+\pl{hanzo-agentic-ai}{Autonomous Agentic AI} \;\textbar\;
+\pl{hanzo-edge-ai-ml}{Edge AI/ML} \;\textbar\;
+\pl{hanzo-cross-domain}{FHE Cross-Domain} \;\textbar\;
+\pl{hanzo-assured-networking}{Assured Networking} \;\textbar\;
+\pl{hanzo-security}{Hanzo for Security} \;\textbar\;
+\pl{hanzo-compliance}{Hanzo for Compliance}
+\end{minipage}\hfill
+\begin{minipage}[t]{0.22\linewidth}
+\raggedleft
+\qrcode[height=1.5cm]{https://papers.hanzo.ai}\\[2pt]
+{\footnotesize\textcolor{hzgray}{scan for the suite}}
+\end{minipage}
+
+\vfill
+\rulen\vspace{1pt}
+\noindent\begin{minipage}{0.7\linewidth}
+\footnotesize\textcolor{hzgray}{\textbf{Hanzo Industries} --- American-owned applied-AI lab, Techstars~'17,
+founded 2014. Open-source $\cdot$ post-quantum $\cdot$ self-hostable. Approved for public release; distribution unlimited.}
+\end{minipage}\hfill
+\begin{minipage}{0.28\linewidth}
+\raggedleft\footnotesize\textbf{[email protected]}\\\textcolor{hzgray}{papers.hanzo.ai}
+\end{minipage}
+
+\end{document}
@@ -1,4 +1,4 @@
-\documentclass[11pt,a4paper]{article}
+\documentclass[11pt,letterpaper]{article}
 \usepackage{hanzo-defense}

 \doctitle{Quantum Key Distribution and Quantum Sensing\\Integration for Post-Quantum Blockchain\\Consensus and Threshold Cryptography}
@@ -6,7 +6,7 @@
 \docversion{Version 1.0 --- February 27, 2026}
 \docdate{February 2026}
 \docauthors{Zach Kelling --- Hanzo Team}
-\docorgs{Hanzo Industries \quad Lux Industries \quad Zoo Labs Foundation\\[email protected]}
+\docorgs{Hanzo Industries\\[email protected]}

 \begin{document}
 \makecover
@@ -15,6 +15,9 @@
 We present an architecture for integrating quantum key distribution (QKD) hardware and quantum sensing devices into a production post-quantum blockchain stack. The system extends five existing production components---QuantumVM (Q-Chain), the KEM cryptographic interface, RNS mesh transport, Sovereign KMS, and the Hanzo Zero Trust fabric---with QKD-derived key material and quantum sensor attestations. A novel \emph{triple-hybrid} key derivation combines classical Diffie-Hellman (X25519), post-quantum lattice encapsulation (ML-KEM-768, \fips{203}), and physics-layer QKD shared secrets via HKDF, ensuring link security if \emph{any one} of three independent foundations holds: elliptic curve hardness, Module-LWE hardness, or the laws of quantum mechanics. Quantum sensors---atomic clocks, magnetometers, and gravimeters---feed cryptographically attested measurements into the Q-Chain via a Sensor Oracle, stamped with dual BLS/Corona threshold signatures for immutable provenance. We specify ETSI GS QKD 014 and ITU-T Y.3800 compliant interfaces, analyze integration with threshold MPC signing ceremonies, and project a 3,000--5,000 line implementation leveraging existing production interfaces. No competing blockchain system offers production post-quantum consensus, let alone QKD or quantum sensing integration.
 \end{abstract}

+\paragraph{Executive Summary.}
+This paper is a \emph{design}, not a fielded product---it specifies how to extend an existing, in-production post-quantum system with two emerging quantum technologies, and estimates the work at roughly 3,000--5,000 lines of new code (see the roadmap table). The first technology, quantum key distribution, secures a communications link using the laws of physics: an eavesdropper cannot tap the channel without being detected. The design uses it as a \emph{third} independent lock layered on top of today's cryptography and the new quantum-resistant standards, so the link stays secure as long as any one of the three holds---belt, suspenders, and a physical law. The second, quantum sensing, lets devices that measure time, magnetic fields, or gravity with extreme precision sign their readings and anchor them to a tamper-evident record---useful for navigation and timing when GPS is jammed, and for detecting things (like submarines) that conventional sensors miss. The intended audience is defense and government technologists planning for the quantum era; the honest claim is that the production foundation it plugs into already exists, and this specifies the bridge to quantum hardware as that hardware matures.
+
 \tableofcontents
 \newpage

@@ -50,6 +53,10 @@ The architecture builds on five deployed systems:
 \item \textbf{QKD Network Manager}: ITU-T Y.3800 compliant key pool orchestration across multiple QKD links.
 \end{enumerate}

+\subsection{Strategic Context}
+
+The distinction this paper draws---between a deployed foundation and a specified extension---is itself the strategic point. The five systems in Section~1.1 (QuantumVM, the KEM interface, RNS mesh transport, the sovereign KMS, and the zero-trust fabric) are in production today; the QKD and quantum-sensing layers described here are a forward-looking architecture, projected at roughly 3,000--5,000 lines that implement existing interfaces without modifying the production code. Being able to make that separation credibly depends on owning the whole stack. Hanzo (American-owned, Techstars~'17, founded 2014) builds both the post-quantum cryptography in production and the \emph{Zen} frontier AI that runs on it, and its founder is a recognized expert in both AI/ML and cryptography---which is what lets a quantum-hardware bridge be specified against real, owned interfaces rather than sketched in the abstract. The wider context is sovereignty: with American frontier AI consolidated into a closed two-vendor duopoly and the open frontier ecosystem now largely offshore, Hanzo is the American open-source alternative that owns the model and the cryptography together. This roadmap extends that sovereign, auditable foundation toward the quantum era---honestly labeled as a roadmap, on top of a foundation that already runs.
+
 % ============================================================================
 \section{Quantum Key Distribution Integration}
 % ============================================================================
@@ -589,7 +596,7 @@ No competing blockchain or military networking system offers this combination of

 \bibitem{corona} ``Practical Two-Round Threshold Signature from LWE,'' IACR ePrint 2024/1113.

-\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Lux Industries, 2025.
+\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Hanzo, 2025.

 \bibitem{infleqtion} Infleqtion, ``Tiqker Quantum Atomic Clock,'' CES 2026.

@@ -598,7 +605,7 @@ No competing blockchain or military networking system offers this combination of
 \end{thebibliography}

 \section*{Reproducibility}
-\textbf{Source code.} \texttt{github.com/luxfi/crypto} (commit \texttt{TBD}).\\
+\textbf{Source code.} \texttt{github.com/hanzoai/crypto} (commit \texttt{TBD}).\\
 \textbf{Build.} cargo build --release; hardware integration TBD on QKD/atomic-clock partners.\\
 \textbf{Hardware tested.} QKD hardware: vendor-supplied; classical post-processing on x86\_64 Linux.\\
 \textbf{Standards referenced.} ETSI QKD, NIST PQC, FIPS 203/204.\\
@@ -0,0 +1,511 @@
+\documentclass[11pt,letterpaper]{article}
+\usepackage{hanzo-defense}
+
+\doctitle{Hanzo AI for Security:\\Automated, Agentic Security Auditing\\at Estate Scale}
+\docid{HAI-DEF-2026-015}
+\docversion{Version 1.0}
+\docdate{2026}
+\docauthors{Zach Kelling --- Hanzo Team}
+\docorgs{Hanzo Industries\\[email protected]}
+
+\begin{document}
+\makecover
+
+\begin{abstract}
+Security debt does not live in the system you were asked to look at; it lives in
+the systems you did not know existed. Modern software estates are sprawls of
+hundreds of microservices, dozens of repositories, and dependency trees no human
+has ever read end to end---and the vulnerabilities hide precisely in that sprawl:
+the forgotten service with a wildcard CORS policy, the credential committed to a
+\texttt{.env} four years ago, the auth bypass list that a database write can
+edit, the package with a published CVE that no audit ever ran against. This paper
+describes how Hanzo applies an agentic AI stack to the problem: a fleet of
+specialized review agents that fan out across an entire estate, discover its real
+extent, find vulnerabilities at a rate no human team can match, scan every
+dependency tree, and re-audit continuously as code changes---always with a human
+in the loop for triage and sign-off. We ground the description in a real
+engagement (anonymized): a FINRA/SEC-regulated securities platform that engaged
+for a narrow remediation scope and was found to be running more than 200
+microservices across 127+ repositories. Across eleven audit rounds the stack
+surfaced 143 findings (22 Critical), the estate's $\sim$780 dependency
+vulnerabilities were driven to zero actionable, and the platform was consolidated
+from 200+ services into three Go binaries---deleting roughly 3.5 million lines of
+dead code and, with it, most of the attack surface. The outcome was FINRA/SEC
+approval and SOC~2. We are explicit throughout about what the machine does versus
+what a human must still decide.
+\end{abstract}
+
+\paragraph{Executive Summary.}
+You cannot secure what you have not enumerated, and the hard part of real-world
+security is that nobody has enumerated the estate. A team asks for help hardening
+a handful of services and the actual footprint turns out to be hundreds of
+services across scores of repositories, most of them undocumented, several of them
+forgotten, all of them in scope for the regulator and the attacker even if they
+were out of scope for the conversation. Hanzo's answer is to point an agentic AI
+stack at the whole thing. Specialized agents---one reasoning about
+authentication, one about secrets, one about injection, one about access control,
+one about dependencies---run in parallel across every repository, build the map
+nobody had, and report findings far faster than a human auditor can read code.
+The machine is good at breadth, recall, and tirelessness; it is not the final
+authority. A human engineer triages every finding, discards the false positives,
+decides severity and exploitability, and signs off remediation. In the engagement
+this paper anonymizes, that pairing took a securities platform from 93 source-code
+findings (22 Critical, 30 High) across 127+ repositories and $\sim$780 dependency
+vulnerabilities (18 critical, 350+ high) to zero actionable dependency
+vulnerabilities and zero open critical or high findings over eleven rounds---while
+consolidating 200+ microservices into three compiled binaries and deleting
+$\sim$3.5 million lines of dead code, a reduction in attack surface that no amount
+of patching can equal. The same properties that made this possible---owned
+models, an open and auditable stack, secrets in a KMS, post-quantum identity, and
+a cryptographically signed, immutable audit trail---are exactly the properties a
+defense Authorization to Operate (ATO) and a continuous-authorization posture
+require.
+
+\tableofcontents
+\newpage
+
+% ============================================================================
+\section{The Problem: Security Debt Hides in the Sprawl}
+% ============================================================================
+
+A security review has an implicit assumption baked into it: that someone knows
+what is being reviewed. In a small, well-documented system that assumption holds.
+In the systems that actually run regulated businesses and critical
+infrastructure, it does not. These are estates---accreted over years by rotating
+teams, spread across many repositories, deployed as dozens or hundreds of
+microservices, wired together by webhooks and shared databases, and standing on
+dependency trees that pull in thousands of transitive packages. No single person
+holds the map. The org chart that built it has turned over. The documentation, if
+it exists, describes the system someone intended to build, not the one that is
+running.
+
+This is where vulnerabilities live. Not usually in the service everyone is
+watching---in the one nobody remembers:
+
+\begin{itemize}
+  \item \textbf{The forgotten service.} A proof-of-concept that quietly went to
+  production, an internal tool exposed to the public internet, a duplicate of a
+  service that was ``replaced'' but never decommissioned. It still has
+  credentials, still talks to the database, and is still in scope for an attacker.
+  \item \textbf{The credential in history.} An AWS key, a payment-processor
+  secret, an OAuth client secret, a personal access token---committed to a
+  \texttt{.env} or a build layer years ago, never rotated, still valid, sitting in
+  a git history that an attacker can clone.
+  \item \textbf{The structural auth flaw.} A bypass-route list loaded from a
+  mutable database table, so that any database write can create an authentication
+  bypass; a JWT verified through an asynchronous callback that can race the next
+  middleware; a tenant identity derived from a client-controllable header.
+  \item \textbf{The dependency CVE.} A published, well-known vulnerability in a
+  package like a common HTTP client, a JWT library, an ORM, or a web framework
+  ---trivially fixed by a version bump, but invisible because no one ever ran a
+  dependency audit across the estate in years of operation.
+  \item \textbf{The cipher that is not encryption.} Sensitive regulated data
+  ``protected'' by a reversible substitution scheme that a developer mistook for
+  encryption, propagated across many services, and that survived years of
+  operation because no review ever questioned it.
+\end{itemize}
+
+None of these are exotic. Every one of them is a finding a competent auditor would
+flag on sight---\emph{if} the auditor's eyes ever reached that file. The binding
+constraint is not auditor skill; it is auditor bandwidth against estate size. A
+human team can deeply review a handful of services in the time a quarter allows.
+An estate has hundreds. The math does not close, so coverage is sampled, sampling
+misses the forgotten service, and the breach---or the regulator---finds what the
+sample did not. The problem is fundamentally one of \emph{scale}: breadth of
+coverage, recall across an enormous surface, and the stamina to re-check
+everything every time the code moves. Those are exactly the properties a human
+team lacks and an agentic system has.
+
+% ============================================================================
+\section{Agentic Security Auditing}
+% ============================================================================
+
+Hanzo treats an audit not as a single review but as a swarm of them. The unit of
+work is one specialized agent assigned to one repository (or one service) with one
+analytical lens. Many such agents run concurrently, so the wall-clock time to
+sweep an estate scales with how many workers you are willing to run, not with how
+many repositories the estate contains. The model's job is breadth and recall; the
+human's job is judgment. The two are deliberately kept in separate lanes.
+
+\subsection{Specialized agents, run in parallel}
+
+A single model prompted to ``find security bugs'' is a generalist and behaves like
+one---shallow, distractible, prone to missing a whole class of issue while
+chasing another. The stack instead runs a set of agents each holding one threat
+model in working memory, so each pass is deep in one dimension rather than shallow
+in all of them:
+
+\begin{itemize}
+  \item \textbf{Authentication \& session.} Token issuance and verification,
+  expiry and rotation, algorithm pinning, bypass routes, rate limiting on auth
+  endpoints, OTP handling, fail-open versus fail-closed middleware.
+  \item \textbf{Secrets \& credentials.} Plaintext keys in environment files,
+  source, build layers, and manifests; hardcoded tokens and passphrases; secrets
+  reachable in client bundles; secrets that should live in a KMS.
+  \item \textbf{Injection \& output handling.} SQL/NoSQL built by string
+  concatenation, command injection, and cross-site scripting through unsanitized
+  rendering of user-controlled data.
+  \item \textbf{Access control \& tenancy.} Missing ownership checks (IDOR),
+  object lookups that resolve across tenant boundaries, authorization enforced in
+  the UI but not the API, header-driven tenant switching.
+  \item \textbf{Transport \& configuration.} CORS allowlisting (especially
+  wildcard-with-credentials), security headers (CSP, \texttt{X-Content-Type-Options},
+  HSTS), TLS posture, and webhook signature/replay protection.
+  \item \textbf{Dependencies \& supply chain.} The full transitive tree of every
+  package manifest, matched against published advisories, with a remediation path
+  (override, upgrade, replace, or remove) for each.
+\end{itemize}
+
+Because the agents share a finding schema---identifier, severity, location,
+category, evidence, suggested fix---their outputs merge into a single estate-wide
+ledger that deduplicates the same flaw recurring across services (the wildcard
+CORS that appears in a dozen places, the same vulnerable package in every tree)
+and makes the systemic pattern legible rather than buried in a hundred separate
+reports.
+
+\subsection{Automated discovery: building the map first}
+
+The first thing the stack produces is not a finding but an \emph{inventory}.
+Before reviewing anything, agents crawl the version-control organizations,
+enumerate every repository, classify each by language and stack, read whatever
+deployment configuration exists, and reconstruct the actual service graph---which
+services are live, which are duplicates, which are abandoned, what talks to what.
+This is the step a human team usually skips because it is tedious, and it is
+exactly the step that surfaces the forgotten service. In the engagement this paper
+describes, this discovery pass is what turned a ``narrow remediation'' into a true
+accounting of the estate: it found a footprint of more than 200 microservices
+across 127+ repositories where the engagement had been scoped to a handful. You
+cannot audit, and you certainly cannot get an ATO for, a system whose extent you
+have not established; automated discovery establishes it.
+
+\subsection{Dependency scanning across the whole tree}
+
+Dependency risk is the highest-leverage target for automation because it is pure
+breadth: every repository, every manifest, every transitive edge, matched against
+a moving database of advisories. A human will not do this across hundreds of
+repositories; a machine does it exhaustively and repeatably. The stack resolves
+each tree, identifies every package with a known advisory, and---critically---does
+not stop at a list. For each vulnerable package it determines the minimal action:
+a transitive \emph{override} to a patched version, a direct \emph{upgrade}, a
+\emph{replacement} of a deprecated or unmaintained package with a maintained
+equivalent, or \emph{removal} of a dependency that was dead weight pulling in a
+vulnerable transitive package. The residual---advisories with no upstream fix---is
+documented with an explicit reachability argument (why the affected code path is
+not exploitable in context) rather than silently ignored. ``Zero actionable''
+means every advisory has been either fixed or formally adjudicated, which is the
+state an auditor and a regulator will accept.
+
+\subsection{Continuous re-audit}
+
+An audit is a photograph; security is a film. A finding fixed today regresses
+tomorrow when someone reintroduces a wildcard CORS in a service the original sweep
+did not cover, or a dependency bump pulls a fresh CVE, or a refactor reopens a
+closed injection path. Because each agent run is automated and cheap relative to
+human review, the same sweep runs continuously---in CI on every change and on a
+schedule across the whole estate---so regressions are caught as events rather than
+discovered in the next annual assessment. Every closed finding becomes a standing
+regression check: the specific bypass that was fixed is asserted to stay fixed,
+the specific CORS origin is asserted to stay allowlisted, the specific package is
+asserted to stay above its patched version. This converts ``we audited it once''
+into ``it is audited on every commit,'' which is the substantive content of
+\emph{continuous authorization}.
+
+\subsection{Honest about the human in the loop}
+
+The machine is not the auditor of record, and claiming otherwise would be both
+false and dangerous. Automated static analysis over-reports: it flags
+string-built queries that are in fact parameterized, ``secrets'' that are test
+fixtures, and IDORs guarded by a check it could not see. It under-reports too:
+business-logic flaws, broken authorization semantics that are individually valid
+but collectively wrong, and abuse cases that require understanding intent are not
+reliably found by pattern-matching. So the division of labor is explicit. The
+agents deliver breadth: they read everything, miss little of the mechanical
+classes, and never get bored on repository two hundred. A human security engineer
+delivers judgment: triaging each finding, discarding false positives, confirming
+exploitability, setting severity, threat-modeling the critical paths by hand, and
+signing off remediation. The honest claim is not ``AI replaces the auditor.'' It
+is ``AI gives one auditor the reach of fifty, and the auditor still decides.'' The
+final sign-off in the case study was human, and the staged penetration re-tests
+that production money movement demanded were human; the machine made that human
+able to cover an estate that would otherwise have been impossible to cover.
+
+% ============================================================================
+\section{Case Study: From a Narrow Scope to a 200-Service Estate}
+% ============================================================================
+
+The following is drawn from a real engagement with a FINRA/SEC-regulated digital
+securities platform. All identifying details---company, product, people, services,
+repositories, domains---are removed; the numbers and the shape of the work are as
+they happened.
+
+\subsection{The scope that wasn't}
+
+The engagement began as a targeted vulnerability assessment of a small set of
+services. The automated discovery pass (\S2.2) immediately changed the picture: an
+organization-wide crawl enumerated an estate of \textbf{more than 200
+microservices across 127+ repositories}, spanning an API gateway, trading and
+matching engines, a custody/payments tier, KYC/identity services, a sprawl of
+frontends, and a long tail of proof-of-concept and duplicate repositories that
+were still live. The ``narrow scope'' was a keyhole view of an estate an order of
+magnitude larger---and, as is typical, the keyhole did not happen to be pointed at
+the worst of it.
+
+\subsection{What the swarm found}
+
+A parallel static-analysis pass---one worker per repository, with the specialized
+lenses of \S2.1---produced an internal source-code audit of \textbf{93 findings:
+22~Critical, 30~High, 32~Medium, 9~Low}, concentrated in the gateway, trading, and
+custody services. The findings were not subtle once seen; they were invisible only
+because no one had looked across the whole surface. By category:
+
+\begin{itemize}
+  \item \textbf{Authentication.} A bypass-route list loaded from a mutable
+  database table (any DB write could mint an auth bypass); JWT verification via an
+  async callback that could race the next middleware; tenant identity taken from a
+  client-controllable header, allowing tenant switching; tokens without expiry;
+  no rate limiting on OTP/credential endpoints; fail-open middleware that admitted
+  requests when the auth service was unreachable.
+  \item \textbf{Secrets.} Plaintext cloud keys, payment-processor secrets, and
+  database passwords committed to environment files across the custody and payment
+  tiers; an OAuth client secret shipped inside a frontend JavaScript bundle; a
+  hardcoded webhook secret in source; build-time tokens leaked into container
+  layers.
+  \item \textbf{Injection.} SQL built by string concatenation in a payments-rail
+  query path; cross-site scripting via unsanitized rendering of user-controlled
+  data in multiple frontends.
+  \item \textbf{Access control.} Missing ownership checks on order modification
+  (IDOR); object lookups that crossed tenant boundaries; withdrawal flows lacking
+  an approval gate; missing KYC and velocity gates on crypto withdrawals.
+  \item \textbf{Transport \& webhooks.} Wildcard CORS \emph{with credentials}
+  enabled across several services; missing or unverified webhook signatures on
+  inbound custody and payment events; missing security headers.
+  \item \textbf{Financial correctness.} Floating-point arithmetic on monetary
+  values---an integrity and compliance defect as much as a precision one.
+\end{itemize}
+
+A later forensic pass added the kind of finding that only a full-history,
+full-estate sweep surfaces---a class of cryptographic misuse, in which data was
+``protected'' by a scheme that was not in fact secure, that had propagated across
+multiple services and survived years of review because no prior audit ever reached
+every service. The specifics are immaterial here; the lesson is that estate-scale,
+full-history coverage finds what sampling structurally cannot.
+
+\subsection{The dependency debt}
+
+Running the dependency scanner (\S2.3) across the estate exposed the technical
+debt of a team that had shipped volume for years without ever running an audit.
+The full ecosystem carried \textbf{$\sim$780 known dependency vulnerabilities},
+including \textbf{18 critical and 350+ high-severity}. Narrowing to the eight core
+services, \textbf{141} vulnerabilities sat in their trees---published CVEs in
+exactly the load-bearing packages you would least want them in: the HTTP client,
+the JWT library, the ORM, the web framework. Every one was fixable; none had been
+fixed, because no one had looked.
+
+\subsection{Remediation to zero actionable}
+
+Remediation followed the discipline of \S2.3. The 141 vulnerabilities in the core
+services were driven to \textbf{0 actionable}, and the full $\sim$780-vulnerability
+ecosystem was driven to \textbf{0 actionable} as well---every advisory either
+fixed or formally adjudicated as unreachable. The mechanical work was exactly the
+catalog automation is built for: transitive overrides to patched versions,
+deprecated-package migrations (a v2 cloud SDK to its modular v3, an unmaintained
+HTML minifier to a maintained fork, an old crypto library swap that dropped a
+vulnerable transitive dependency), and removal of dead dependencies that existed
+only to pull in vulnerable transitive packages. The handful of residual advisories
+with no upstream fix were documented with reachability arguments, not buried.
+
+On the source-code side, the findings were closed across \textbf{eleven audit
+rounds}. Round one surfaced the initial 93; subsequent rounds drove remediation,
+caught regressions (including a reintroduced wildcard CORS found during a
+verification pass), hardened the multi-tenant authentication path, purged the
+legacy service framework, and re-verified each closed finding. Across all eleven
+rounds the series recorded \textbf{143 findings, 115 fixed}, with the remainder
+accepted or mitigated as medium/low items carrying no exploitable path. The
+remediation classes were the standard hardening moves, applied estate-wide rather
+than service-by-service:
+
+\begin{itemize}
+  \item Secrets moved out of plaintext environment files and into a KMS, with
+  machine-identity access rather than shared static credentials.
+  \item Wildcard CORS replaced by strict origin allowlists everywhere it appeared.
+  \item Security headers added; webhook ingress hardened with HMAC signatures plus
+  timestamp and nonce replay protection.
+  \item JWTs verified synchronously with a pinned algorithm, expiry, and rotation;
+  for the next-generation build, JWKS-verified tokens against a real identity
+  provider.
+  \item Access control corrected with explicit ownership checks and tenant-scoped
+  queries at the middleware and datastore layers.
+\end{itemize}
+
+\subsection{The real fix: deleting the attack surface}
+
+Patching findings hardens the code you keep. The larger security win was deciding
+how much code to keep at all. In parallel with remediation, the estate was
+consolidated: \textbf{200+ microservices collapsed into three Go binaries}, and
+the active codebase fell from \textbf{3.07~million lines to 1.06~million}
+---roughly \textbf{3.5~million lines of dead code deleted}, git-verified, with the
+superseded repositories archived. This is the most underrated security action
+available, because the cleanest defense against a vulnerability in a service is
+for that service not to exist. Each deleted service is one fewer credential to
+leak, one fewer dependency tree to patch, one fewer CORS policy to misconfigure,
+one fewer forgotten endpoint on the public internet. Less code is less attack
+surface, and a 70\% reduction in active code is a 70\% reduction in the places a
+flaw can hide---a result no patch campaign can match because it removes the
+substrate the flaws live in.
+
+\subsection{Outcome}
+
+The pairing of automated breadth and human judgment took the platform from 93
+source findings and $\sim$780 dependency vulnerabilities to zero open critical or
+high findings and zero actionable dependency vulnerabilities, on an estate it had
+not even fully enumerated at the start, while shrinking that estate by an order of
+magnitude. The platform achieved \textbf{FINRA/SEC approval and SOC~2}---the
+regulatory and audit outcomes that are the real test of whether security work was
+not just performed but \emph{evidenced}.
+
+% ============================================================================
+\section{Security by Construction in the OSS Stack}
+% ============================================================================
+
+Auditing finds the holes; architecture decides how many there are to find. The
+same Hanzo open-source stack that runs the agents is built so that whole classes
+of finding cannot occur, and so that the evidence an auditor needs is produced as
+a byproduct of normal operation rather than reconstructed after the fact. The case
+study's remediation was, in effect, a migration toward these properties.
+
+\begin{itemize}
+  \item \textbf{KMS for secrets.} Secrets live in a key-management service and are
+  delivered to workloads by machine identity, not committed to environment files,
+  source, or manifests. The single most common critical finding in the case study
+  ---plaintext credentials---is structurally prevented when there is no plaintext
+  credential to commit. Access is mnemonic-derived and consensus-authorized, with
+  no open fallback mode.
+  \item \textbf{IAM for identity.} Authentication and authorization run through one
+  identity provider over standard OIDC, with tokens verified against published
+  JWKS. Bespoke per-service auth---the source of the bypass-list, the
+  header-driven tenancy, and the race-prone verification in the case study---is
+  replaced by a single audited path, so there is one place to get right instead of
+  hundreds to get wrong.
+  \item \textbf{Post-quantum identity and transport.} Service identities and
+  inter-service transport use post-quantum primitives (ML-KEM for key
+  establishment, ML-DSA for signatures, NIST FIPS 203/204). Every service-to-service
+  call is mutually authenticated and forward-secret against a future quantum
+  adversary, closing the ``harvest now, decrypt later'' exposure on traffic and on
+  the audit record itself.
+  \item \textbf{Cryptographically signed actions.} Consequential actions---a
+  secret access, an administrative change, an agent's action---ride a signed
+  envelope binding the actor's identity, the operation, a timestamp, and a nonce,
+  signed with a post-quantum key. Authority is verifiable and non-repudiable: not
+  ``a log says this happened'' but ``this actor provably authorized this, and the
+  signature proves it.''
+  \item \textbf{Immutable on-chain audit trail.} Security-relevant events are
+  recorded to an append-only, tamper-evident ledger. The audit trail cannot be
+  edited or deleted after the fact---the precise property that books-and-records
+  and custody regulations demand, and the precise property an after-the-fact log
+  store cannot guarantee.
+\end{itemize}
+
+The throughline is that confidentiality, identity, authority, and auditability are
+\emph{architectural defaults}, not features bolted on per service. An estate built
+this way starts where the case-study estate finished, and the agentic auditor then
+has dramatically less to find---and what it does find, it finds against a system
+that is already producing the evidence to prove the fix.
+
+% ============================================================================
+\section{Why It Matters for Defense}
+% ============================================================================
+
+Defense and national-security systems face the estate-scale security problem in
+its most acute form: larger sprawls, longer lifetimes, higher consequences, and a
+formal accreditation regime that demands evidence, not assertion. The capability
+described here maps directly onto those requirements.
+
+\begin{itemize}
+  \item \textbf{ATO evidence.} An Authorization to Operate requires an enumerated
+  system boundary, an assessed control set, and a documented residual-risk
+  posture. Automated discovery produces the boundary (including the forgotten
+  services that would otherwise sit outside it), the agent swarm produces the
+  assessment at a coverage no sampling approach reaches, and the signed,
+  immutable audit trail produces the evidence---turning the accreditation package
+  from a periodic manual artifact into a continuously regenerated one.
+  \item \textbf{Supply-chain assurance.} The dependency scanner enumerates the
+  complete transitive software bill of materials, matches it against advisories,
+  and drives it to zero actionable with a documented adjudication for every
+  residual. This is the concrete substance behind software-supply-chain mandates
+  (SBOM, known-vulnerability remediation): not a one-time scan but a standing,
+  re-run guarantee.
+  \item \textbf{Continuous authorization.} The shift from periodic to continuous
+  re-audit is exactly the shift modern frameworks (cATO, ongoing authorization)
+  are pushing toward. Every closed finding becomes a standing regression check;
+  every commit is re-assessed; drift is an event, not a year-end surprise. The
+  authorization reflects the system as it is, not as it was at the last
+  assessment.
+  \item \textbf{Sovereign and auditable.} The entire stack---the review agents,
+  the models behind them, the KMS, the IAM, the post-quantum cryptography, the
+  ledger---is owned and open. It runs offline, at the edge, in a classified
+  enclave, with no dependency on a foreign or black-box service and no telemetry
+  leaving the boundary. A defense customer can inspect the auditor itself, which is
+  the only honest basis for trusting an auditor's output.
+\end{itemize}
+
+The deeper point the case study makes for a defense buyer is about
+\emph{consolidation as defense}. A 200-service estate reduced to three auditable
+binaries is not only cheaper to run; it is a fundamentally smaller thing to
+defend, accredit, and reason about. In a domain where every additional service is
+additional attack surface, additional accreditation scope, and additional
+supply-chain exposure, the ability to find what you have, prove it secure, and
+then make it radically smaller is itself a security capability.
+
+% ============================================================================
+\section{American Open Source for a Sovereign Security Posture}
+% ============================================================================
+
+The stack described here is built and owned end-to-end by Hanzo AI, an
+American-owned applied-AI lab and venture studio (Techstars~'17, founded 2014)
+responsible for more than 100 venture-funded startups and several unicorns,
+founded by an expert in both AI/ML and cryptography. Two facts make this relevant
+to a security and national-security buyer. First, sovereignty of the security
+tooling itself: an audit is only as trustworthy as the party that controls the
+auditor, and this stack---agents, models, key management, and cryptography---is
+American-owned, auditable, and free of dependence on foreign or black-box
+components, implemented to the same standards (FIPS 203/204/205, CNSA 2.0) the
+U.S.\ government mandates and inspectable by the party that has to rely on it.
+Second, sovereignty of the AI doing the work: U.S.\ frontier AI has narrowed to a
+closed commercial duopoly, while the only broadly open frontier weights available
+today are largely foreign, leaving regulated and defense buyers to either rent
+from the duopoly or take a dependency on foreign models. Hanzo is the American
+open-source frontier alternative---it owns both the Zen model family and this
+cryptographic stack, so the agents that read your code, the keys that protect your
+secrets, and the ledger that records your evidence can be deployed offline, at the
+edge, and under full audit, with nothing leaving your boundary. That this is
+engineering rather than research is evidenced in production by the case study
+itself: an American-owned agentic stack took a FINRA/SEC-approved, SOC~2 securities
+platform---an estate of 200+ microservices---to zero actionable dependency
+vulnerabilities and zero open critical findings, and consolidated it into three
+compiled binaries, with a small team.
+
+% ============================================================================
+\section{Conclusion}
+% ============================================================================
+
+Security debt hides in the part of the estate nobody is looking at, and the reason
+nobody is looking is that human review does not scale to hundreds of repositories
+and millions of lines. Hanzo's contribution is to make the looking scale: an
+agentic stack that first discovers the real extent of an estate, then sweeps it in
+parallel with specialized review agents, scans every dependency tree to zero
+actionable, and re-audits continuously as the code moves---always with a human
+engineer holding triage and sign-off. The anonymized case study is the proof: a
+narrow engagement that uncovered a 200+-service, 127+-repository estate; 143
+findings (22 Critical) surfaced over eleven rounds; $\sim$780 dependency
+vulnerabilities driven to zero actionable; the estate consolidated into three Go
+binaries with $\sim$3.5 million lines of dead code deleted; and FINRA/SEC approval
+plus SOC~2 as the result. The same stack that audits is built so that whole
+classes of finding cannot occur in the first place---secrets in a KMS, identity in
+one IAM, post-quantum transport, signed actions, an immutable on-chain trail---and
+all of it is American-owned, open, and sovereign. For defense, that is the
+combination the accreditation regime is asking for: enumerate what you have, prove
+it secure with evidence rather than assertion, keep proving it on every change,
+and make it smaller. Find everything; fix what matters; delete the rest; and let
+the auditor be a machine you are allowed to inspect.
+
+\end{document}
@@ -1,4 +1,4 @@
-\documentclass[11pt,a4paper]{article}
+\documentclass[11pt,letterpaper]{article}
 \usepackage{hanzo-defense}

 \doctitle{Automated Verification and Validation Framework\\with Digital Twin Environments}
@@ -6,7 +6,7 @@
 \docversion{Version 1.0 --- February 3, 2026}
 \docdate{February 2026}
 \docauthors{Zach Kelling --- Hanzo Team}
-\docorgs{Hanzo Industries \quad Lux Industries \quad Zoo Labs Foundation\\[email protected]}
+\docorgs{Hanzo Industries\\[email protected]}

 \begin{document}
 \makecover
@@ -15,6 +15,9 @@
 We present an integrated verification and validation (V\&V) framework combining continuous observability, behavioral analytics, ML pipeline orchestration, digital twin environments, and formal cryptographic proofs. The observability platform ingests logs, metrics, and distributed traces into a ClickHouse OLAP backend, with LLM-specific telemetry tracking token usage, cost, latency, and quality metrics across 100+ AI providers. Temporal workflows orchestrate LLM evaluation, trace clustering, and sentiment analysis, while Dagster DAGs manage ETL pipelines for training data preparation. A network simulation environment supports configurable topologies with 38 registered virtual machines, enabling mission rehearsal and system qualification. The framework includes 17 formal cryptographic proofs, 28+ consensus tests, and automated CI/CD with multi-platform builds. Anomaly detection, feature flag-controlled rollout, and A/B testing with statistical significance provide continuous data-driven decision support.
 \end{abstract}

+\paragraph{Executive Summary.}
+This is the test, evaluation, and monitoring layer that tells operators whether a complex AI and cryptographic system actually works---before it is fielded and continuously once it is. Three capabilities work together: full instrumentation, so every action the system takes is recorded and can be inspected after the fact; a high-fidelity ``digital twin'' that replicates the real deployment, so new builds and stressful conditions (jamming, link loss, hostile inputs) can be rehearsed safely before they reach the field; and automated checks---including machine-checked cryptographic proofs---that run on every change and block anything that regresses. For a program office, this is the qualification and continuous-assurance evidence a system needs to earn and keep an authorization to operate, with specialized tracking for AI workloads (cost, latency, output quality) that conventional IT monitoring does not capture. The capability is built to run where the system runs, including disconnected at the edge with store-and-forward when connectivity returns.
+
 \tableofcontents
 \newpage

@@ -31,6 +34,10 @@ This paper presents an automated V\&V framework built on three principles:
 \item \textbf{Digital twin fidelity}: System qualification occurs in high-fidelity simulated environments before live deployment.
 \end{enumerate}

+\subsection{Strategic Context}
+
+A verification and validation framework is only as credible as the systems it has actually carried into production under real scrutiny. Hanzo (American-owned, Techstars~'17, founded 2014) is an applied AI lab and venture studio behind 100+ venture-funded startups and multiple unicorns; its founder is a recognized expert in \emph{both} AI/ML and cryptography, and the company builds both the \emph{Zen} frontier model family and the post-quantum cryptographic stack it runs on. The same agentic engineering stack described in these papers delivered a securities trading platform---a full ATS/BD/TA stack consolidated from 200+ microservices into 3 compiled binaries---through FINRA/SEC approval and SOC2 audit into production, in record time with a small team. That is the operative proof point for test and evaluation: regulated, externally audited software shipped at scale, the same discipline a defense accreditation demands. It also anchors a broader position. With American frontier AI consolidated into a closed two-vendor duopoly and the open frontier ecosystem now largely offshore, Hanzo is the American open-source alternative that owns the model and the cryptography together---and the V\&V framework here is how that stack is qualified to run sovereign and disconnected, where the data lives, rather than rented from a black box.
+
 % ============================================================================
 \section{Observability Platform}
 % ============================================================================
@@ -185,7 +192,7 @@ Dagster manages ETL and data preparation workflows:
 \section{Digital Twin Environments}
 % ============================================================================

-\subsection{Lux Netrunner: Network Simulation}
+\subsection{Netrunner: Network Simulation}

 Netrunner provides configurable network simulation for system qualification:

@@ -419,7 +426,7 @@ We have presented an automated V\&V framework that provides continuous verificat

 \bibitem{k8s} Kubernetes Authors, ``Kubernetes: Production-Grade Container Orchestration,'' CNCF, 2024.

-\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Lux Industries, 2025.
+\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Hanzo, 2025.

 \bibitem{corona} ``Practical Two-Round Threshold Signature from LWE,'' IACR ePrint 2024/1113.

@@ -0,0 +1,184 @@
+\documentclass[11pt,letterpaper]{article}
+\usepackage{hanzo-defense}
+
+\doctitle{Sovereign vs.\ Closed: Hanzo AI versus\\Centralized Cloud AI for Defense and\\Regulated Workloads}
+\docid{HAI-DEF-2026-011}
+\docversion{Version 1.0}
+\docdate{2026}
+\docauthors{Zach Kelling --- Hanzo Team}
+\docorgs{Hanzo Industries\\[email protected]}
+
+\begin{document}
+\makecover
+
+\begin{abstract}
+We compare two structurally different ways to obtain frontier AI: a closed,
+centrally hosted model accessed as a metered cloud service (typified by
+Anthropic's Claude), and a sovereign, self-hostable stack with owned model
+weights (Hanzo). The distinction is not primarily one of model quality---closed
+frontier models are excellent---but of \emph{deployment model and control}.
+For defense and regulated workloads, the binding constraints are data residency,
+operation in disconnected and contested environments, supply-chain provenance,
+post-quantum security, auditability, and cost at scale. A closed cloud service
+cannot satisfy several of these by construction: it cannot run air-gapped, its
+weights cannot be inspected or owned, and sensitive data must leave the
+enclave to be processed. We argue that for these workloads the relevant choice
+is between foreign open-weight models and an American open-source alternative,
+and we position Hanzo as the latter---owning both the model (the Zen family)
+and the cryptography (a production post-quantum stack). We give a dimension-by-dimension
+comparison and a decision framework for when each model of consumption fits.
+\end{abstract}
+
+\paragraph{Executive Summary.}
+This is not a claim that our model is smarter than Claude. It is a claim about
+\emph{where} and \emph{how} you can run it. Claude is an excellent frontier model
+delivered as a managed cloud service: you call it over the internet, your data
+goes to the vendor, you cannot see or own the weights, and it cannot run on a
+disconnected device. That is the right product for many commercial uses and the
+wrong one for a workload that cannot leave a controlled environment. Hanzo is the
+opposite shape: open, owned-weight models you run on your own hardware---in a
+data center, on a vehicle, or air-gapped---with post-quantum security built in,
+your data never leaving, and cost driven down because you are not paying a
+per-token markup or a hyperscaler margin. America's frontier AI has narrowed to
+two closed labs; the only openly available frontier weights today are largely
+foreign. For defense and regulated buyers who need open, sovereign, controllable
+AI, that makes Hanzo the American alternative to both the closed duopoly and
+foreign open weights.
+
+\tableofcontents
+\newpage
+
+% ============================================================================
+\section{The Real Axis of Comparison}
+% ============================================================================
+
+Discussions of ``which AI is better'' usually compare benchmark scores. For
+commercial chat and coding that is a reasonable proxy. For defense and regulated
+deployment it is the wrong axis. A model that scores two points higher on a
+reasoning benchmark is of no use inside a controlled environment if it can only
+be reached by sending the data outside that environment.
+
+The decisive axis is the \emph{deployment and trust model}: who holds the weights,
+where inference physically runs, whether the data leaves the enclave, whether the
+system works without connectivity, what cryptography protects it, and what it
+costs at scale. On this axis a closed cloud service and a sovereign self-hosted
+stack are not competitors with different scores---they are different categories
+of thing. Claude is the leading example of the first category; Hanzo is built as
+the second.
+
+We state plainly what closed cloud AI does well: it is operationally simple
+(no infrastructure to run), it tracks the frontier of raw capability, and its
+provider invests heavily in alignment and safety research. None of that is in
+dispute. The argument here is narrow and structural: several requirements that
+are mandatory for defense and regulated workloads cannot be met by a model you
+do not hold and cannot run yourself.
+
+% ============================================================================
+\section{Dimension-by-Dimension}
+% ============================================================================
+
+\begin{table}[h]
+\centering
+\small
+\begin{tabular}{p{0.27\textwidth} p{0.32\textwidth} p{0.32\textwidth}}
+\hline
+\textbf{Dimension} & \textbf{Closed cloud AI (e.g.\ Claude)} & \textbf{Hanzo (sovereign OSS)} \\
+\hline
+Model weights & Not disclosed; not transferable & Owned (Zen family, 0.8B--1T+); inspectable \\
+Where inference runs & Vendor cloud only & Your hardware: data center, edge, air-gapped \\
+Your data & Leaves the enclave to the vendor & Never leaves; stays where it lives \\
+Disconnected / DDIL & Not possible (requires connectivity) & First-class (offline on embedded ARM) \\
+Provenance & Vendor-controlled & American-owned, full provenance \\
+Post-quantum security & Not a product property & Native (ML-KEM-768 + ML-DSA-65) \\
+Auditability & Black box & Open stack; cryptographically signed actions \\
+Customization & Prompting / limited fine-tune via API & Full fine-tune on your data, in your enclave \\
+Cost model & Per-token metered & Owned + self-hosted; no markup or cloud margin \\
+Lock-in & High (API + data gravity) & Low (you hold the stack) \\
+\hline
+\end{tabular}
+\caption{Closed cloud AI versus a sovereign self-hostable stack. The comparison
+is of deployment model, not of raw benchmark quality.}
+\end{table}
+
+\subsection{Data residency and the enclave boundary}
+The single most consequential difference is the enclave boundary. To use a closed
+cloud model, the data being reasoned over must cross the boundary to the vendor.
+For CUI, engineering files, procurement records, or operational data this is often
+simply prohibited. Hanzo runs the model inside the boundary, so the data never
+crosses it. This is not a policy preference that can be waived with a contract
+clause; it is a property of where computation physically happens.
+
+\subsection{Disconnected and contested operation}
+A cloud service is unavailable the moment the link drops or is jammed. At the
+tactical edge, on a ship, or in an air-gapped facility there is no link to call.
+Hanzo's models are quantized to run fully offline on hardware ranging from a
+laptop to an embedded processor, so capability persists in exactly the
+environments where a cloud service cannot operate at all.
+
+\subsection{Provenance and the supply chain}
+For an open, controllable alternative to a closed cloud model, today's practical
+options are foreign open-weight models or Hanzo. Defense buyers care about who
+produced the weights and whether they can be trusted and inspected. Hanzo's
+position is specific: an American-owned, open-source frontier stack with owned
+weights, so an organization can have open, auditable AI without depending on
+either the closed domestic duopoly or foreign-origin weights.
+
+\subsection{Post-quantum security}
+Security against a future quantum adversary is a property of the whole stack, not
+a feature of a chat API. Hanzo's transport, identity, and key management are
+post-quantum by construction (all three NIST standards in production, formally
+verified). A closed chat service does not expose this as something the customer
+controls.
+
+\subsection{Cost at scale}
+A metered API charges per token on every inference, forever, with the vendor's
+margin baked in. Owning the model and self-hosting removes both the per-token
+markup and the hyperscaler margin; combined with an efficient transport layer
+(the ZAP protocol's 91\% memory and 96\% energy reductions) this is the mechanism
+behind roughly an order-of-magnitude lower infrastructure cost at scale. A
+companion case study documents a regulated client whose cloud spend fell
+approximately 97\% after migrating to this stack.
+
+\subsection{Agentic throughput: one engineer, a team's output}
+A decisive data point sits behind this whole comparison. Hanzo's founding CEO/CTO,
+Zach Kelling, was---by public usage tracking (\texttt{claudecount.com})---the
+\textbf{\#1 user of Anthropic by token count worldwide in 2025}. That throughput was
+not spent on demos: on the flagship regulated production build, a single founding
+engineer, multiplied by the agentic stack, authored the substantial majority of the
+production code---thousands of commits in a matter of weeks---output that
+conventionally requires a sizable team. The point for this paper is what came next.
+That same throughput now runs on Hanzo's \emph{owned}, self-hostable stack rather
+than a metered cloud API. The capability that topped a closed provider's global
+usage is exactly the capability Hanzo packages as a sovereign, owned
+alternative---so a buyer gets the productivity without the per-token meter, the data
+egress, or the dependency. That is the comparison in one line: same frontier-grade
+agentic output, but owned instead of rented.
+
+% ============================================================================
+\section{When Each Model Fits}
+% ============================================================================
+
+This is a decision framework, not a verdict. Closed cloud AI is the right choice
+when the workload is non-sensitive, connectivity is reliable, operational
+simplicity outweighs control, and there is no requirement to own or inspect the
+model. A sovereign self-hosted stack is the right---often the only---choice when
+any of the following hold: the data cannot leave a controlled environment; the
+system must work disconnected or in contested conditions; provenance and
+auditability are required; post-quantum protection is mandated; or per-token cost
+at scale is untenable. Defense and regulated workloads concentrate in the second
+column. That is the gap Hanzo is built to fill.
+
+% ============================================================================
+\section{Conclusion}
+% ============================================================================
+
+The honest comparison is not ``Hanzo's model beats Claude.'' It is that a closed
+cloud model and a sovereign self-hostable stack are different categories, and the
+requirements of defense and regulated workloads---data residency, disconnected
+operation, provenance, post-quantum security, auditability, and cost---select the
+second category by construction. Within that category the choice narrows to
+foreign open weights or an American open-source alternative. Hanzo is built to be
+that alternative: own the model, own the cryptography, run it where the data
+lives.
+
+\end{document}
@@ -1,4 +1,4 @@
-\documentclass[11pt,a4paper]{article}
+\documentclass[11pt,letterpaper]{article}
 \usepackage{hanzo-defense}

 \doctitle{ZAP: Zero-Copy Application Protocol for\\Contested, Edge, and Bandwidth-Limited\\Military Environments}
@@ -6,7 +6,7 @@
 \docversion{Version 1.0 --- February 12, 2026}
 \docdate{February 2026}
 \docauthors{Zach Kelling --- Hanzo Team}
-\docorgs{Hanzo Industries \quad Lux Industries \quad Zoo Labs Foundation\\[email protected]}
+\docorgs{Hanzo Industries\\[email protected]}

 \begin{document}
 \makecover
@@ -15,6 +15,9 @@
 We present ZAP (Zero-copy Application Protocol), a high-performance binary serialization and RPC framework achieving 2.2~ns parse latency with zero memory allocations, 11.5 million transactions per second end-to-end, and 91\% memory reduction compared to JSON-RPC. ZAP provides two production implementations---Rust (AI agent communication, MCP gateway bridging) and Go (blockchain consensus wire protocol, VM-to-VM messaging)---sharing a common wire format with 16-byte headers and 8-byte aligned structs for direct pointer-arithmetic reads from network buffers. The protocol includes native post-quantum transport security (ML-KEM-768 + ML-DSA-65 hybrid handshake), decentralized identity via W3C DIDs derived from lattice public keys, distributed agent consensus with threshold voting, and mDNS-based ad-hoc network discovery. We analyze ZAP's suitability for contested electromagnetic environments, bandwidth-limited tactical links, GPU cluster coordination, and edge AI agent orchestration, demonstrating 96\% energy reduction and 30$\times$ throughput improvement over standard protocols under identical network conditions.
 \end{abstract}

+\paragraph{Executive Summary.}
+ZAP is the ``plumbing'' that lets AI agents, sensors, and computers talk to each other using far less bandwidth, memory, and power than today's standard formats. It matters most at the tactical edge: it moves the same information using roughly a tenth of the data, which both cuts the radio footprint an adversary can detect and lets coordination work over links as slow as an HF radio that ordinary protocols cannot use at all. Its security is post-quantum by design---traffic encrypted with ZAP stays protected even against a future quantum computer---and that protection is built into the protocol rather than bolted on. Concretely, it parses a message in 2.2 nanoseconds, handles 11.5 million transactions per second, and uses 91\% less memory and 96\% less energy than the common JSON-RPC approach, which on a battery-powered device translates directly into longer mission endurance. For program leaders, ZAP is the efficiency and security layer that makes real-time, machine-speed AI coordination feasible in contested, bandwidth-starved, and disconnected environments.
+
 \tableofcontents
 \newpage

@@ -177,7 +180,7 @@ The \texttt{zapc} compiler generates code for multiple target languages:

 \begin{itemize}
 \item \textbf{Rust}: Primary target, zero-copy readers and builders.
-\item \textbf{Go}: Used in Lux consensus and VM communication.
+\item \textbf{Go}: Used in Hanzo consensus and VM communication.
 \item \textbf{Python, TypeScript}: SDK generation for agent integration.
 \item \textbf{C, C++, Java}: Available for embedded and enterprise integration.
 \end{itemize}
@@ -235,8 +238,8 @@ AES-256-GCM & Session encryption & Key: 32 B \\
 The Rust implementation supports two backends with automatic fallback:

 \begin{enumerate}
-\item \textbf{luxcrypto-sys} (preferred): FFI binding to the Lux blockchain cryptographic library (CIRCL-based, CGO-optimized). Shared with consensus layer.
-\item \textbf{pqcrypto} (fallback): Pure Rust PQ implementations for environments without \texttt{libluxcrypto}.
+\item \textbf{Post-quantum crypto FFI library} (preferred): FFI binding to the Hanzo cryptographic library (CIRCL-based, CGO-optimized). Shared with the consensus layer.
+\item \textbf{pqcrypto} (fallback): Pure Rust PQ implementations for environments without the native crypto library.
 \item \textbf{x25519-dalek}: Classical ECDH (always present for hybrid mode).
 \end{enumerate}

@@ -405,9 +408,9 @@ ZAP nodes advertise services via mDNS with domain-specific service types:
 \toprule
 \textbf{Service Type} & \textbf{Purpose} \\
 \midrule
-\texttt{\_luxd.\_tcp} & Blockchain consensus nodes \\
-\texttt{\_lux-gpu.\_tcp} & GPU compute nodes \\
-\texttt{\_lux-vm.\_tcp} & Virtual machine endpoints \\
+\texttt{\_hzd.\_tcp} & Blockchain consensus nodes \\
+\texttt{\_hz-gpu.\_tcp} & GPU compute nodes \\
+\texttt{\_hz-vm.\_tcp} & Virtual machine endpoints \\
 \texttt{\_zap-agent.\_tcp} & AI agent endpoints \\
 \bottomrule
 \end{tabular}
@@ -427,7 +430,7 @@ ZAP implements W3C Decentralized Identifiers with three methods:

 \begin{itemize}
 \item \textbf{did:key}: Self-certifying from ML-DSA-65 public keys. No external registry required.
-\item \textbf{did:lux}: Anchored to Lux blockchain. Verifiable via consensus.
+\item \textbf{did:hanzo}: Anchored to the Hanzo chain. Verifiable via consensus.
 \item \textbf{did:web}: DNS-based for interoperability with existing PKI.
 \end{itemize}

@@ -529,7 +532,7 @@ ZAP's zero-copy design enables direct GPU ciphertext operations:
 \begin{lstlisting}[language=Go,caption={GPU FHE operation via ZAP.}]
 gpuNode := zap.NewNode(zap.NodeConfig{
    NodeID:      "gpu-node-1",
-    ServiceType: "_lux-gpu._tcp",
+    ServiceType: "_hz-gpu._tcp",
    Port:        7000,
 })

@@ -691,9 +694,15 @@ Minimal-dependency implementation for consensus and VM communication:
 \item \texttt{zap.go}: Zero-copy builder and parser (8.9~KB).
 \item \texttt{node.go}: mDNS discovery and async RPC (21.2~KB).
 \item \texttt{mcp/}: MCP bridge for 20+ tool servers.
-\item Single external dependency: \texttt{github.com/luxfi/mdns}.
+\item Single external dependency: \texttt{github.com/hanzoai/mdns}.
 \end{itemize}

+% ============================================================================
+\section{Strategic Context}
+% ============================================================================
+
+ZAP is the transport layer of an integrated, sovereign AI stack built by Hanzo, an American applied-AI lab founded in 2014 (Techstars '17) whose founder works at the frontier of both AI/ML and cryptography. American frontier AI has consolidated into a closed monoculture---effectively two labs reachable only as metered cloud services---while the only openly available frontier model weights today are largely foreign; Hanzo is the American open-source frontier alternative, owning both the model (the Zen family, 0.8B--1T+ parameters, with owned weights) and the cryptography (the production post-quantum stack ZAP is part of). That ownership is what lets the whole stack run sovereign and disconnected, where the data lives. ZAP also supplies a measurable piece of the economics: its 91\% memory and 96\% energy reductions and 30$\times$ throughput, combined with owned models (no per-token API markup) and self-hosting (no hyperscaler margin), are the mechanism behind roughly an order-of-magnitude lower infrastructure cost in aggregate. The efficiency is not academic---the same agent-driven stack this protocol carries was used to deliver a FINRA/SEC-approved, SOC2-compliant securities platform to production---a full ATS/BD/TA stack consolidated from 200+ microservices into 3 compiled binaries---in record time with a small team, showing the approach holds up under the demands of a regulated, audited domain.
+
 % ============================================================================
 \section{Conclusion}
 % ============================================================================
@@ -733,14 +742,14 @@ The protocol's 96\% energy reduction extends battery endurance on tactical devic

 \bibitem{circl} Cloudflare, ``CIRCL: Interoperable Reusable Cryptographic Library,'' 2024.

-\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Lux Industries, 2025.
+\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Hanzo, 2025.

-\bibitem{luxzap} Hanzo Team, ``Lux ZAP: Consensus Wire Protocol,'' Lux Industries, 2026.
+\bibitem{luxzap} Hanzo Team, ``ZAP: Consensus Wire Protocol,'' Hanzo, 2026.

 \end{thebibliography}

 \section*{Reproducibility}
-\textbf{Source code.} \texttt{github.com/luxfi/zap} (commit \texttt{TBD}).\\
+\textbf{Source code.} \texttt{github.com/hanzoai/zap} (commit \texttt{TBD}).\\
 \textbf{Build.} cargo build --release (Rust impl); go build ./... (Go impl).\\
 \textbf{Hardware tested.} Apple M-series, x86\_64 Linux + NVIDIA A100, ARM Cortex-A (edge).\\
 \textbf{Standards referenced.} Cap'n Proto wire spec, ML-KEM-768, ML-DSA-65 (FIPS 203/204), W3C DID.\\
@@ -0,0 +1,156 @@
+import { notFound } from 'next/navigation'
+import { Download, ArrowLeft, ExternalLink } from 'lucide-react'
+import { siteConfig } from '@/config/papers'
+import { Header } from '@/components/Header'
+import { Footer } from '@/components/Footer'
+
+const basePath = process.env.NEXT_PUBLIC_BASE_PATH || ''
+
+export function generateStaticParams() {
+  return siteConfig.papers.map((paper) => ({ slug: paper.id }))
+}
+
+export default async function PaperPage({
+  params,
+}: {
+  params: Promise<{ slug: string }>
+}) {
+  const { slug } = await params
+  const paper = siteConfig.papers.find((p) => p.id === slug)
+
+  if (!paper) {
+    notFound()
+  }
+
+  // External pdfUrl (http) stays as-is; site-hosted ('/pdfs/...') gets basePath.
+  const pdfHref = paper.pdfUrl.startsWith('http')
+    ? paper.pdfUrl
+    : `${basePath}${paper.pdfUrl}`
+
+  return (
+    <div className="min-h-svh flex flex-col">
+      <Header config={siteConfig} />
+
+      <main className="flex-1">
+        <div className="max-w-4xl mx-auto px-6 pt-12 pb-20">
+          <a
+            href={`${basePath}/`}
+            className="inline-flex items-center gap-1.5 text-sm text-muted-foreground hover:text-foreground transition-colors mb-8"
+          >
+            <ArrowLeft className="h-4 w-4" />
+            All papers
+          </a>
+
+          <article>
+            <header className="mb-8">
+              <time className="text-xs font-mono text-muted-foreground">
+                {new Date(paper.date).toLocaleDateString('en-US', {
+                  year: 'numeric',
+                  month: 'short',
+                })}
+              </time>
+              <h1 className="text-3xl md:text-4xl font-bold tracking-tight mt-2 mb-2">
+                {paper.title}
+              </h1>
+              <p className="text-lg text-muted-foreground">{paper.subtitle}</p>
+              <p className="text-sm text-muted-foreground/80 mt-3">
+                {paper.authors.join(' · ')}
+              </p>
+
+              <div className="flex flex-wrap gap-1.5 mt-4">
+                {paper.tags.map((tag) => (
+                  <span
+                    key={tag}
+                    className="px-2 py-0.5 text-[11px] font-mono bg-accent text-accent-foreground rounded"
+                  >
+                    {tag}
+                  </span>
+                ))}
+              </div>
+            </header>
+
+            <section className="mb-8">
+              <h2 className="text-sm font-semibold uppercase tracking-wide text-muted-foreground mb-2">
+                Abstract
+              </h2>
+              <p className="text-base text-foreground/90 leading-relaxed">
+                {paper.abstract}
+              </p>
+            </section>
+
+            <div className="flex flex-wrap gap-2 mb-8">
+              <a
+                href={pdfHref}
+                target="_blank"
+                rel="noopener noreferrer"
+                className="inline-flex items-center gap-1.5 px-4 py-2 text-sm font-medium bg-foreground text-background rounded-md hover:bg-foreground/90 transition-colors"
+              >
+                <Download className="h-4 w-4" />
+                Download PDF
+              </a>
+              <a
+                href={paper.githubUrl}
+                target="_blank"
+                rel="noopener noreferrer"
+                className="inline-flex items-center gap-1.5 px-4 py-2 text-sm font-medium border border-border rounded-md text-muted-foreground hover:text-foreground hover:border-foreground/30 transition-colors"
+              >
+                Source
+              </a>
+              {paper.latexUrl && (
+                <a
+                  href={paper.latexUrl}
+                  target="_blank"
+                  rel="noopener noreferrer"
+                  className="inline-flex items-center gap-1.5 px-4 py-2 text-sm font-medium border border-border rounded-md text-muted-foreground hover:text-foreground hover:border-foreground/30 transition-colors"
+                >
+                  LaTeX
+                </a>
+              )}
+            </div>
+
+            {paper.relatedLinks && paper.relatedLinks.length > 0 && (
+              <div className="mb-8 flex flex-col gap-1.5">
+                {paper.relatedLinks.map((link, i) => (
+                  <a
+                    key={i}
+                    href={link.url}
+                    target="_blank"
+                    rel="noopener noreferrer"
+                    className="inline-flex items-center gap-1.5 text-sm text-muted-foreground hover:text-foreground transition-colors"
+                  >
+                    <ExternalLink className="h-3.5 w-3.5" />
+                    {link.label}
+                  </a>
+                ))}
+              </div>
+            )}
+
+            <div className="rounded-lg border border-border/60 overflow-hidden bg-card">
+              <object
+                data={pdfHref}
+                type="application/pdf"
+                className="w-full h-[80vh]"
+                aria-label={`${paper.title} PDF preview`}
+              >
+                <div className="p-8 text-center text-sm text-muted-foreground">
+                  Preview unavailable in this browser.{' '}
+                  <a
+                    href={pdfHref}
+                    target="_blank"
+                    rel="noopener noreferrer"
+                    className="underline hover:text-foreground"
+                  >
+                    Download the PDF
+                  </a>
+                  .
+                </div>
+              </object>
+            </div>
+          </article>
+        </div>
+      </main>
+
+      <Footer config={siteConfig} />
+    </div>
+  )
+}
@@ -1,6 +1,8 @@
 import { FileText, ExternalLink } from 'lucide-react'
 import type { PaperConfig } from '@/config/papers'

+const basePath = process.env.NEXT_PUBLIC_BASE_PATH || ''
+
 interface PaperCardProps {
  paper: PaperConfig
 }
@@ -20,7 +22,9 @@ export function PaperCard({ paper }: PaperCardProps) {
        </div>

        <h2 className="text-base font-semibold mb-1 text-foreground group-hover:text-foreground/90">
-          {paper.title}
+          <a href={`${basePath}/${paper.id}/`} className="hover:underline">
+            {paper.title}
+          </a>
        </h2>

        <h3 className="text-sm text-muted-foreground mb-3">
@@ -39,6 +39,200 @@ export const siteConfig: SiteConfig = {
  accentColor: '#00D9FF',
  logo: '/logos/hanzo-logo.svg',
  papers: [
+    // --- Defense / Reindustrialization Papers ---
+    {
+      id: 'hanzo-security',
+      title: 'Hanzo AI for Security',
+      subtitle: 'Automated, Agentic Security Auditing at Estate Scale',
+      abstract: 'How an agentic stack discovers and remediates security debt across sprawling microservice estates. Case study: engaged for a narrow scope, the team uncovered a 200+ microservice estate, surfaced 93 findings (22 critical) across 127+ repositories plus 780+ dependency vulnerabilities, and remediated them to zero actionable while consolidating to 3 binaries — with security built into the OSS stack via KMS, IAM, post-quantum identity, signed actions, and an immutable on-chain audit trail.',
+      pdfUrl: '/pdfs/hanzo-security.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-security.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Security', 'Agentic AI', 'Audit'],
+    },
+    {
+      id: 'hanzo-compliance',
+      title: 'Hanzo AI for Compliance',
+      subtitle: 'An OSS Cloud Built to Pass the Audit',
+      abstract: 'The sovereign OSS stack produces audit evidence by construction — centralized IAM, KMS secrets custody, an immutable signed on-chain audit trail, post-quantum identity, and machine-checked proofs — mapping natively to SOC 2 Trust Services Criteria, NIST 800-53 control families, FINRA/SEC recordkeeping, and the defense ATO/RMF process, so compliance becomes evidence collection rather than months of manual work.',
+      pdfUrl: '/pdfs/hanzo-compliance.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-compliance.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Compliance', 'SOC 2', 'ATO'],
+    },
+    {
+      id: 'hanzo-vs-claude',
+      title: 'Sovereign vs. Closed',
+      subtitle: 'Hanzo AI versus Centralized Cloud AI for Defense and Regulated Workloads',
+      abstract: 'A dimension-by-dimension comparison of a closed, centrally hosted frontier model accessed as a metered cloud service against a sovereign, self-hostable stack with owned weights. For defense and regulated workloads the binding constraints are data residency, air-gapped operation, supply-chain provenance, post-quantum security, and cost at scale, with a decision framework for when each model of consumption fits.',
+      pdfUrl: '/pdfs/hanzo-vs-claude.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-vs-claude.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Sovereign AI', 'Post-Quantum', 'Open Weights'],
+    },
+    {
+      id: 'hanzo-agentic-prowess',
+      title: 'Agentic Engineering at Regulated Scale',
+      subtitle: 'Building a Post-Quantum, FHE-Native Securities Platform',
+      abstract: 'How an agent-driven team built a fully regulated securities venue on a foundation of production post-quantum cryptography, a native-GPU blockchain, and fully-homomorphic-encryption privacy, reaching production at the scale of tens of millions of lines of code with a small team and passing regulatory approval and SOC 2. Expands on the defense relevance of computing on data one is not permitted to see.',
+      pdfUrl: '/pdfs/hanzo-agentic-prowess.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-agentic-prowess.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Agentic AI', 'FHE', 'Post-Quantum'],
+    },
+    {
+      id: 'hanzo-cloud-economics',
+      title: 'Cloud Economics of a Sovereign OSS Stack',
+      subtitle: 'A Regulated Capital-Markets Migration Case Study',
+      abstract: 'Infrastructure economics of migrating a regulated capital-markets platform from a sprawling public-cloud footprint to a consolidated, self-hostable open-source stack. Documented spend reductions of 82% then 97% (roughly $408,000/year saved), with a decomposition of where the savings come from and an argument that the same mechanism applies directly to government-contractor and defense modernization.',
+      pdfUrl: '/pdfs/hanzo-cloud-economics.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-cloud-economics.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Cloud Economics', 'Sovereign Stack', 'OSS'],
+    },
+    {
+      id: 'hanzo-fhe-native',
+      title: 'Confidential Computing by Default',
+      subtitle: 'An FHE-Native Chain and Agent Runtime',
+      abstract: 'A design for making fully homomorphic encryption the default mode of computation across the two layers that normally demand plaintext: a blockchain\'s state and rules, and an autonomous agent\'s actions. State stays encrypted on-chain, policies are evaluated over ciphertext, and agents act on data they are never able to read, with a candid assessment of what is production today versus an active research frontier.',
+      pdfUrl: '/pdfs/hanzo-fhe-native.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-fhe-native.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'FHE', 'Confidential Computing', 'Post-Quantum'],
+    },
+    {
+      id: 'hanzo-zap-protocol',
+      title: 'ZAP: Zero-Copy Application Protocol',
+      subtitle: 'For Contested, Edge, and Bandwidth-Limited Military Environments',
+      abstract: 'A high-performance binary serialization and RPC framework achieving 2.2 ns parse latency with zero allocations, 11.5M transactions per second, and 91% memory reduction versus JSON-RPC. Includes native post-quantum transport security (ML-KEM-768 + ML-DSA-65), decentralized identity via W3C DIDs, threshold agent consensus, and mesh discovery, analyzed for contested electromagnetic environments and tactical links.',
+      pdfUrl: '/pdfs/hanzo-zap-protocol.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-zap-protocol.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Protocol', 'Post-Quantum', 'Edge'],
+    },
+    {
+      id: 'hanzo-full-spectrum-cyber',
+      title: 'Full-Spectrum Cryptographic Architecture',
+      subtitle: 'FIPS 203/204/205 Compliant Design for Information Dominance',
+      abstract: 'A cryptographic architecture implementing all three NIST post-quantum standards (ML-DSA, ML-KEM, SLH-DSA) integrated into a production blockchain consensus system with hybrid classical/quantum security and sub-second finality. Details six threshold MPC schemes over a zero-copy wire protocol, GPU-accelerated operations, an FHE virtual machine, and a key management system with Shamir secret sharing, backed by 17 formal cryptographic proofs.',
+      pdfUrl: '/pdfs/hanzo-full-spectrum-cyber.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-full-spectrum-cyber.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Post-Quantum', 'FIPS', 'Cryptography'],
+    },
+    {
+      id: 'hanzo-formal-verification',
+      title: 'Machine-Checked Proofs for Post-Quantum Systems',
+      subtitle: 'Automated Verification for Distributed Cryptographic Systems',
+      abstract: 'A formal verification suite for a post-quantum distributed system spanning consensus, threshold cryptography, FHE, and cross-chain messaging: 50 machine-checked Lean 4 proofs, 18 cryptographic security reductions, 12 protocol-correctness proofs, and 7 DeFi invariant proofs, plus symbolic execution, fuzz targets, and NIST KAT validation. Identifies the critical gaps and presents a phased roadmap for closing them.',
+      pdfUrl: '/pdfs/hanzo-formal-verification.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-formal-verification.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Formal Verification', 'Lean 4', 'Post-Quantum'],
+    },
+    {
+      id: 'hanzo-agentic-ai',
+      title: 'Agentic AI for Autonomous Cyber Operations',
+      subtitle: 'Multi-Domain Intelligence Fusion and Tactical Decision Support',
+      abstract: 'An agentic AI framework of 83 specialized agents and 15 orchestrators for autonomous cyber operations, intelligence fusion, and tactical decision support across a control plane, an agent SDK with native MCP integration, and a ZAP-based consensus protocol with post-quantum authentication. Agents execute 200--300 sequential tool calls and run fully disconnected on edge hardware using quantized Zen models.',
+      pdfUrl: '/pdfs/hanzo-agentic-ai.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-agentic-ai.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Agentic AI', 'Cyber Operations', 'Intelligence'],
+    },
+    {
+      id: 'hanzo-edge-ai-ml',
+      title: 'Edge-Deployable AI/ML Framework',
+      subtitle: 'For Disconnected Tactical Environments',
+      abstract: 'An edge-deployable AI/ML framework for disconnected, degraded, and bandwidth-limited environments, combining a Rust-native inference engine for 15+ text and 16+ vision architectures with aggressive 2--8 bit quantization across hardware from laptops to embedded ARM. A family of 18 models provides capability tiers from nano-scale edge inference to frontier reasoning, operating fully offline with sandboxed execution and no cloud dependencies.',
+      pdfUrl: '/pdfs/hanzo-edge-ai-ml.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-edge-ai-ml.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Edge AI', 'Quantization', 'Offline'],
+    },
+    {
+      id: 'hanzo-cross-domain',
+      title: 'Multi-Level Security and Cross-Domain Solutions',
+      subtitle: 'Homomorphic Policy Evaluation and Zero-Trust Fabric',
+      abstract: 'A cross-domain solution where data-transfer policies are evaluated on encrypted content using FHE so the guard never observes plaintext, integrating a zero-trust overlay with identity-first micro-segmentation, an FHE policy engine, Shamir-based key management, and org-scoped identity. Cross-domain transfers are cryptographically mediated and produce immutable audit records anchored to a post-quantum blockchain.',
+      pdfUrl: '/pdfs/hanzo-cross-domain.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-cross-domain.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Cross-Domain', 'FHE', 'Zero-Trust'],
+    },
+    {
+      id: 'hanzo-assured-networking',
+      title: 'Post-Quantum Resilient Mesh Networking',
+      subtitle: 'For Maritime and Tactical Edge Operations',
+      abstract: 'A post-quantum resilient networking architecture for maritime, tactical edge, and DDIL environments, integrating the Reticulum Network Stack as a native consensus transport over LoRa, packet radio, serial, and mesh topologies without centralized infrastructure or DNS. All sessions use hybrid post-quantum key exchange and authentication, with a zero-trust overlay and sub-second consensus finality over mesh networks.',
+      pdfUrl: '/pdfs/hanzo-assured-networking.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-assured-networking.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Mesh Networking', 'Post-Quantum', 'Maritime'],
+    },
+    {
+      id: 'hanzo-countermeasures',
+      title: 'Quantum-Resistant Counter-Exploitation',
+      subtitle: 'Confidential Compute and Coercion-Resistant Communications',
+      abstract: 'A suite of counter-exploitation technologies providing quantum-resistant secure messaging at 526,000 messages per second with forward secrecy, FHE with threshold decryption, post-quantum anonymous ring signatures with linkability, zero-knowledge privacy pools, and a multi-agent adversarial framework. Together these prevent adversary exploitation of cryptographic, network, and AI systems in contested environments.',
+      pdfUrl: '/pdfs/hanzo-countermeasures.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-countermeasures.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Counter-Exploitation', 'Post-Quantum', 'FHE'],
+    },
+    {
+      id: 'hanzo-quantum-sensing-qkd',
+      title: 'Quantum Key Distribution and Quantum Sensing Integration',
+      subtitle: 'For Post-Quantum Blockchain Consensus and Threshold Cryptography',
+      abstract: 'An architecture integrating quantum key distribution hardware and quantum sensors into a production post-quantum blockchain stack. A triple-hybrid key derivation combines classical Diffie-Hellman, lattice encapsulation, and physics-layer QKD secrets so link security holds if any one of three independent foundations holds. Quantum sensors feed cryptographically attested measurements on-chain via a sensor oracle with dual threshold signatures.',
+      pdfUrl: '/pdfs/hanzo-quantum-sensing-qkd.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-quantum-sensing-qkd.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'QKD', 'Quantum Sensing', 'Post-Quantum'],
+    },
+    {
+      id: 'hanzo-test-evaluation',
+      title: 'Automated Verification and Validation Framework',
+      subtitle: 'With Digital Twin Environments',
+      abstract: 'An integrated verification and validation framework combining continuous observability, behavioral analytics, ML pipeline orchestration, digital twin environments, and formal cryptographic proofs. Telemetry across 100+ AI providers feeds an OLAP backend, workflows orchestrate LLM evaluation, and a network simulation environment with 38 virtual machines enables mission rehearsal and system qualification with statistical decision support.',
+      pdfUrl: '/pdfs/hanzo-test-evaluation.pdf',
+      latexUrl: 'https://github.com/hanzoai/papers/blob/main/defense/hanzo-test-evaluation.tex',
+      githubUrl: 'https://github.com/hanzoai/papers',
+      date: '2026-01-01',
+      authors: ['Zach Kelling'],
+      tags: ['Defense', 'Test & Evaluation', 'Digital Twin', 'Observability'],
+    },
+
    // --- Hanzo Core Papers ---
    {
      id: 'aso',