For institutions that must hold keys under hardware and regulatory control, custody moves into HSMs and qualified custodians without changing how settlement verifies authorization.
Institutions elect a custody tier that matches their regulatory obligations while presenting the same post-quantum signatures to the ledger.
Signing keys are generated and confined to a hardware security module the institution controls. The platform submits digests to be signed and receives signatures back, never the key material itself.
A regulated custodian holds and operates the signing keys on the institution's behalf under a defined mandate. The custody boundary and its legal responsibilities are explicit and auditable.
Whichever tier is chosen, authorization reaches the ledger as an ML-DSA-65 signature over the same domain-separated payload. Custody arrangement is an operational choice, not a change to settlement semantics.
Different asset classes or mandates can be bound to different custody tiers within one institution. A single owner may self-custody treasury positions while routing tokenized fund shares through a custodian.
The HSM boundary is the enforcement point: private material is created, stored, and exercised without ever appearing in application memory.
Post-quantum signing keys are generated inside the HSM and marked non-exportable. There is no operational procedure that emits the private key in cleartext outside the module.
The platform presents a digest and a policy context; the module returns a signature or a denial. Application servers hold signing sessions, never keys, so a host compromise cannot exfiltrate signing capability.
Key activation and administrative operations require multiple authenticated officers. No single operator can unlock or use an institutional signing key alone.
Physical or logical tamper events zeroize sensitive material per the module's certified profile. The failure mode is loss of signing capability, not silent key exposure.
Institutional custody adds an authorization layer that decides which transactions are even eligible to be signed.
Each signing request is evaluated against counterparty allowlists, value thresholds, asset scope, and time-of-day windows before it reaches the HSM. Out-of-policy requests are refused and recorded.
High-value or high-risk transitions require a configurable quorum of institutional approvers, each authenticating independently. The signature is only requested once the approval threshold is met.
The roles that initiate a transaction, approve it, and administer keys are separated by design. No single identity can originate and authorize the same transfer.
Per-key limits bound how much can be authorized within a window, containing the blast radius if an operator credential is abused before the anomaly is caught.
Institutions and their regulators can reconstruct who approved what, on which hardware, under which policy.
Every approval carries the authenticated identity, timestamp, and the exact terms approved. The record ties a specific person to a specific authorization, not to a generic sign-off.
Custody and signing events are written to the same hash-chained ledger as settlement, so operational actions inherit the same tamper-evidence as the transactions they authorize.
Each institution's keys live in its own logical partition. One institution's custody operations cannot observe or influence another's, even on shared infrastructure.
Custody activity can be exported with the public keys, signatures, and policy decisions needed for an external auditor to verify conduct independently of platform trust.