mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
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]>
182 lines
6.8 KiB
TeX
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.
|
|
|
|
%% =====================================================================
|