Files
zeekayandHanzo Dev 70f6883235 Restore the regulated-markets papers; Lux holds the licences
A July commit removed eight papers on the premise "no license — DEX/non-custodial
only". That premise is wrong: Lux operates an ATS, a broker-dealer, a transfer
agent and a bank, and this material is resold at lux.financial. The merge that
brought main in preserved the removal because the commit stated a reason, which
is how a stale reason outlives the fact it rested on.

Back, at the versions main carried — main never received the removal, so its
copies are the later ones: the ATS architecture, the security-token standard,
smart order routing, institutional custody, MPC custody, post-quantum securities,
the SSB partnership and the CoinBridge brief. 83 files.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-30 15:58:05 -07:00

182 lines
6.8 KiB
TeX

\section{Compliance Map}
\label{sec:compliance}
%% =====================================================================
The architecture is built so that each significant compliance
framework maps to a small number of architectural elements. This
section gives that map. It is not a substitute for a SOC 2 readiness
assessment, but it is the input to one.
\subsection{FIPS 140-2 Level 3 (Tier 1 and Tier 2)}
\begin{itemize}[nosep]
\item Every signing component (Tier 1 cold and Tier 2 warm) is FIPS
140-2 Level 3 minimum (Utimaco SR-Se200 carries Level 4 physical)
\cite{nist-fips140-2,thales-luna7,utimaco-secsr,aws-cloudhsm,gcp-cloudhsm,yubihsm2}.
\item FIPS 140-3 substitutions \cite{nist-fips140-3} are accepted
where the validation is current; the architecture accepts both
generations during the FIPS 140-2 sunset window.
\item Tier 3 hot-tier KMS-backed CMKs use FIPS 140-2 Level 3 HSMs
behind AWS KMS and GCP KMS multi-tenant boundaries; the policy
constraint (per-day cap, time-lock) compensates for the multi-tenant
substrate.
\end{itemize}
\subsection{NIST SP 800-57 Key Management}
NIST SP 800-57 Part 1 Rev. 5 \cite{nist-sp800-57} is the canonical
reference for key-management lifecycle. The architecture's mapping:
\begin{table}[h]
\centering
\small
\begin{tabular}{p{4cm}p{10cm}}
\toprule
\textbf{SP 800-57 phase} & \textbf{Implementation} \\
\midrule
Generation &
Witnessed DKG ceremony (Section~\ref{sec:ceremony}); no aggregate
secret ever exists \\
Distribution &
Shares never leave their HSM boundary; distribution is by Feldman
VSS within the ceremony \\
Storage &
HSM-resident; tamper-evident, non-extractable \\
Use &
Threshold signing only; no plaintext key export under any policy \\
Refresh &
Proactive CGGMP21 refresh on the per-tier cadence
(Section~\ref{sec:ops}) \\
Revocation / destruction &
Vendor zeroisation procedure on hardware retirement; M-Chain ledger
records destruction event \\
Recovery &
Sealed-envelope 3-of-3 Shamir recovery passphrase \\
\bottomrule
\end{tabular}
\caption{SP 800-57 mapping.}
\label{tab:sp800-57}
\end{table}
\subsection{SOC 2 Type II}
The Trust Services Criteria \cite{soc2} relevant to custody operations
are CC1 (control environment), CC2 (communication and information),
CC3 (risk assessment), CC4 (monitoring), CC5 (control activities),
CC6 (logical and physical access), CC7 (system operations), CC8
(change management), and CC9 (risk mitigation). The mapping:
\begin{itemize}[nosep]
\item \textbf{CC6.1 (logical access).} Two-person rule, role
separation (Section~\ref{sec:ops}); IAM-managed access with quarterly
reviews.
\item \textbf{CC6.4 (physical access).} Tier IV DC for the on-prem
HSM, SCIF for the airgap vault, biometric+PIN entry, tamper-evident
seals on transport media.
\item \textbf{CC7.2 (anomaly detection).} M-Chain ledger anomaly
queries on every signing event; daily reconciliation.
\item \textbf{CC8.1 (change management).} Firmware-update policy
(Section~\ref{sec:hsm}); CGGMP21 share-refresh cadence; allowlist
change review.
\end{itemize}
The architecture is compatible with a SOC 2 Type II audit period of
twelve months and is designed to pass a Type II audit on first
attempt; first-year audit cost is approximately \$150{,}000.
\subsection{ISO 27001:2022}
The ISO 27001:2022 ISMS controls Annex A maps as follows
\cite{iso27001}:
\begin{itemize}[nosep]
\item A.5 (organisational): custody policy, witness role, audit
cadence.
\item A.6 (people): two-person rule, background checks on every
custody operator, training cadence.
\item A.7 (physical): SCIF, Tier IV DC, biometric access.
\item A.8 (technological): HSM-resident keys, threshold signing,
M-Chain audit log.
\end{itemize}
\subsection{CCSS Level 3}
The CryptoCurrency Security Standard \cite{ccss} Level 3 is the
highest level and is the appropriate target for an eight-billion-dollar
custodian. CCSS Level 3 requirements and mapping:
\begin{table}[h]
\centering
\small
\begin{tabular}{p{4.5cm}p{9cm}}
\toprule
\textbf{CCSS aspect} & \textbf{Implementation} \\
\midrule
1. Key/seed generation &
Witnessed DKG with hardware attestation
(Section~\ref{sec:ceremony}) \\
2. Wallet creation &
Threshold MPC; aggregate key never exists \\
3. Key storage &
Multiple-environment, multi-vendor HSMs; offline storage on cold
tier; geographic separation \\
4. Key usage &
Threshold $t$-of-$n$; multiple operators required for every signing \\
5. Key compromise procedure &
Documented incident-response runbook with proactive refresh and full
re-DKG paths (Section~\ref{sec:dr}) \\
6. Keyholder grant/revoke procedures &
Quarterly access review; hardware-attested termination \\
7. Third-party audits &
SOC 2 Type II, ISO 27001 surveillance, CCSS audit (annual) \\
8. Data sanitisation policy &
Vendor zeroisation on retirement; M-Chain destruction event \\
9. Proof of reserve &
Daily on-chain reconciliation against M-Chain ledger \\
10. Audit logs &
Hash-chained M-Chain log signed BLS + ML-DSA \\
\bottomrule
\end{tabular}
\caption{CCSS Level 3 mapping.}
\label{tab:ccss}
\end{table}
\subsection{Regional Frameworks}
\begin{itemize}[nosep]
\item \textbf{MiCA (EU) \cite{mica}.} The fund's EU-domiciled feeder
qualifies for CASP licensing under MiCA; the architecture meets MiCA
Article 67 (segregation), Article 68 (custody policy), and Article 70
(safekeeping records) by design.
\item \textbf{MAS PSN02 (Singapore) \cite{mas-psn02}.} The Singapore
share custodian (warm-tier $\mathbf{w}_2$ in asia-east1) is
engineered for MAS DPT licence terms: in-jurisdiction key custody,
SOC 2 attestation, segregated client funds, and travel-rule
integration via Chainalysis KYT \cite{chainalysis}.
\item \textbf{NYDFS BitLicense (US) \cite{nydfs-bitlicense}.} If the
US-domiciled vehicle elects BitLicense rather than OCC trust charter,
the architecture meets 23 NYCRR 200.7 (custody and protection of
customer assets) and 200.16 (cybersecurity).
\item \textbf{OCC trust charter (US) \cite{occ-trust}.} The
Anchorage-style OCC national trust charter is supported; the
architecture's hardware attestations and multi-jurisdiction
shares satisfy OCC Interpretive Letter 1170 fiduciary custody
expectations.
\item \textbf{12 CFR \S225 (US bank holding companies).} Where
the institutional client is a bank holding company, the architecture
is configured to meet Federal Reserve Regulation Y custody
requirements, including separately identifiable safekeeping records.
\end{itemize}
\subsection{Insurance}
The architecture is insurable. Lloyd's-syndicate-backed crime-and-specie
policies for digital-asset custody are written against CCSS Level 3
posture; the typical 2026-vintage policy provides up to \$500M per
incident on first-loss for cold-tier coverage and reduced limits for
warm and hot tiers. The \$8B AUM is not insurable as a single tower;
it is layered across multiple syndicates.
%% =====================================================================