Crypto custody & compliance · engineering reference
Custody is the control system around a signing primitive: asset float, policy, people, evidence, recovery, and a ledger that still balances when a facility or vendor disappears.
Custody is not one vault. It is a set of tiers holding different balances at different speeds, wrapped in a control system: who may approve what, how the keys were created, who can change the rules, and what happens when a facility or a vendor disappears.
It is an inventory problem, not a security instinct. Model withdrawal demand over the time it takes to replenish from cold, then size the float against the tail of that distribution. Expected loss from a hot compromise scales with the balance, while delayed withdrawals and the cost of each cold retrieval push the other way.
It is the ordered rule set deciding which transactions are allowed and how many approvals each needs. Rules evaluate first-match, so an over-broad rule high in the list silently shadows everything below it, and a missing terminal default-deny rule turns the whole thing into a suggestion engine.
Named roles, an offline room, verified devices, recorded video, and an independent witness who holds no key. The step people skip is verifying the address from the backup material and running a test recovery before any real funds arrive.
The CryptoCurrency Security Standard: the crypto-specific control standard with a public levelled structure covering key generation, storage, usage, compromise policy, and audit logs. The crosswalk further down maps each requirement to an architectural decision.
If you remember one lineA control the system does not enforce is not a control. If an administrator can quietly edit the policy, the policy is decorative.
Worked from the float example below. Recompute every figure from your own observed withdrawals and replenishment lead time.
The correct hot amount is a demand quantile over replenishment lead time, not “5% of AUC.” Every tier needs a documented loss bound and a tested way back.
| Tier | Automation | Target | Transfer gate | Verdict |
|---|---|---|---|---|
| Hot | Continuous | Lead-time withdrawal demand | Default-deny policy + velocity | LIMIT EXPOSURE |
| Warm | Workflow | Replenishment buffer | Human quorum + delayed destinations | CONDITIONAL |
| Cold | Ceremony | Reserve | Offline independent key holders | ISOLATED |
| Deep cold | Retrieval | Long-horizon reserve | Geographic quorum + multi-day process | DIVERSE |
Automation and exposure fall left to right; latency and gate strength rise. Each tier needs a documented loss bound and a tested way back.
Percentages are outputs of demand and loss models, not universal best practices.
| Tier | Purpose | Typical latency | Approval | Network exposure | Loss bound |
|---|---|---|---|---|---|
| Hot | Automated withdrawals | Seconds–minutes | Policy + automated signer | Online | Strict balance and velocity cap |
| Warm | Human-gated replenishment | Minutes–hours | 2-person quorum | Connected only for workflow | Per-transfer and daily cap |
| Cold | Reserve | Hours–day | Independent key holders | Air-gapped ceremony | Facility/quorum loss tolerance |
| Deep cold | Long-horizon reserve | Days | Geographic retrieval quorum | Offline, distributed | Catastrophic correlated-event bound |
Worked result: the stated profile produces a $3.2M hot target. Recompute from observed withdrawals, replenishment lead, and incident conditions.
Cover withdrawals during replenishment lead time at a chosen service level, then cap exposure above that target.
Concrete use: Mean daily BTC demand $2.0M, one-day replenishment lead, 99th-percentile one-day demand $3.2M: set hot target S=$3.2M, not a portfolio percentage.
Failure mode: Normal-distribution shortcuts understate fat-tail withdrawal runs.
Trigger warm/cold replenishment before available hot inventory reaches expected lead-time demand.
Concrete use: With $2.0M mean lead-time demand and $1.2M safety stock, reorder at s=$3.2M and replenish to a separately governed S.
Failure mode: Counting pending deposits as available can postpone replenishment until failure.
Each asset has distinct demand, finality, fee, halt, and replenishment behavior.
Concrete use: USDC payment float may turn daily while an illiquid governance token remains entirely cold.
Failure mode: Portfolio-wide percentages hide the one chain that cannot replenish during an outage.
Minimize expected compromise loss + delayed-withdrawal cost + ceremony cost.
Concrete use: Compare $3.2M hot exposure with an estimated incident loss fraction against the measurable cost of one delayed day and each cold pull.
Failure mode: False precision in compromise probability is worse than sensitivity ranges.
Rules match subject, source, destination, asset, amount, time, and action in a documented order.
Concrete use: Deny unknown destinations first; allow routine USDC only after KYT and velocity gates; route $250k+ to 2-of-3 approval.
Failure mode: A broad allow above a narrow deny turns rule order into a bypass.
A newly allowlisted destination cannot receive funds until an observation window passes.
Concrete use: Require 48 hours plus out-of-band confirmation before first transfer; alert on creation and activation.
Failure mode: Instant allowlisting makes a stolen admin session equivalent to key theft.
Aggregate amount and count over overlapping windows by user, asset, destination, and risk domain.
Concrete use: Cap $50k/hour and $200k/24h, with sub-$10k structuring still aggregating.
Failure mode: Calendar-day resets invite an attacker to straddle midnight.
Changing authorization logic is itself a high-risk custody operation.
Concrete use: Require two administrators from separate roles and a 24-hour delayed activation for production rule changes.
Failure mode: A mutable policy controlled by one admin is decorative.
Emergency bypass is narrow, expiring, visible, and separately authorized.
Concrete use: Open a 30-minute route for one predeclared destination with a maximum amount and after-action review.
Failure mode: Permanent emergency roles become the normal attack path.
A ceremony is executable procedure. If a step lacks owner, evidence, abort condition, and recovery, it is prose.
CCSS v9.0 was published December 17, 2024 and organizes ten aspects across two domains. This table is an engineering navigation aid, not normative requirement text; use C4's current standard for assessment.
| Current aspect | Level I intent | Level II direction | Level III direction | Architecture evidence |
|---|---|---|---|---|
| CCSS 1.01 Key Material Generation. Security rests on two properties: confidentiality (no unintended party ever reads or copies the material) and unpredictability (a nondeterministic source no one can guess). An automated signing agent that receives key material generated elsewhere must get it over a CCSS-compliant channel, with the origin copy securely erased afterward. | Approved entropy and controlled generation | Stronger separation and validation | Highest-assurance ceremony evidence | DKG / ceremony script + entropy attestation |
| CCSS 1.02 Wallet Generation. Wallets are single-key (JBOK) or deterministically derived from one master seed; either way the aspect is engineering for integrity against lost/stolen/compromised key material and for confidentiality of the address-to-owner link. | Correct, verified wallet construction | Independent verification | Comprehensive control evidence | Two-device address derivation and sign/verify test |
| CCSS 1.03 Key Material Storage. Operational key material is encrypted at rest; a backup exists independently (paper, digital, or metal), is protected against environmental risk (fire, flood) and access-controlled, and above Level I is kept geographically separate from the operational copy and tamper-evident. | Protected storage | Distributed, access-controlled storage | Highest isolation and resilience | Tier topology + geographic inventory |
| CCSS 1.05 Key Material Usage. Signing happens only inside the CCSS Trusted Environment, isolated from other OS/application processes (HSM or TEE), gated by 2+ authentication factors, with fund destination and amount verified over an Approved Communication Channel before the key is ever used. | Controlled signing | Stronger authorization and isolation | Comprehensive transaction controls | Policy engine + decoded intent + audit log |
| CCSS 2.04 Key Compromise Documentation. A written Key Compromise Policy per key classification, executed over Approved Communication Channels with actors identified by role (not name) so a backup handler can always step in. Level III requires an annually tested, documented rehearsal with remediation tracked back into the policy. | Documented response | Tested and role-assigned response | Mature evidence and exercise | Freeze, rotate/reshare, investigate, notify |
| CCSS 1.04 Key Material Access. Covers onboarding and offboarding of key holders: a documented least-privilege checklist for every grant/revoke, requests carried over an Approved Communication Channel, and (Level III) an audit trail attested by the personnel who performed each step — so a departure never leaves live signing authority behind. | Controlled lifecycle | Dual-control changes | Auditable, rehearsed lifecycle | Joiner/mover/leaver + quorum-change ceremony |
| CCSS 2.02 Log and Monitor. Audit trails cover actions inside the Trusted Environment, are backed up to a separate server, and are monitored with alerting on suspicious activity. Level III adds continuous, real-time monitoring of both confirmed and unconfirmed blockchain state for anomalous behavior. | Security-relevant records | Monitoring and protected retention | Comprehensive review and evidence | External append-only signing and policy logs |
| CCSS 2.01 Security Tests/Audits. Escalates from an information-security expert embedded across design/build/deploy, to independent vulnerability and penetration testing, to a recurring SOC 2/ISAE 3402/ISO 27001-grade audit (minimum yearly) — plus a separate smart-contract code-audit track for any contract stakeholders interact with on the production network, with medium+ findings resolved before deployment. | Independent review | Broad scope and remediation | Sustained assurance | Audit exact signer/policy release + track closure |
| CCSS 1.06 Data Sanitization Documentation. A policy and procedure set conforming to NIST SP 800-88 for sanitizing or destroying any media that ever held key material, read and understood by every staff member with key-material access. Level III adds an audit trail naming who sanitized what, and with which tool. | Secret-bearing media disposal | Verified procedures | Comprehensive evidence | Crypto erase, device destruction, witness log |
| CCSS 2.03 Governance and Risk. A named executive owns system security in writing; a documented threat model identifies attack paths, sets the residual-risk bar, and drives review/testing cadence; vendor and service-provider security is vetted before engagement and re-reviewed at least annually (more often per the threat model). | Threats and controls identified | Periodic assessment | Mature continuous treatment | Threat model sets review and test cadence |
Regulatory status changes. Links below point to primary text checked August 2026; obtain jurisdiction-specific counsel for applicability.
| Framework / rule | What it answers | What it does not answer | Current engineering hook |
|---|---|---|---|
| CCSS v9.0 | Crypto-system controls across 10 aspects | Enterprise control completeness by itself | Map every aspect to evidence |
| SOC 2 Type II | Control design + operation over a period | Specific crypto key architecture | Scope signer, policy, ledger, provider, DR |
| ISO/IEC 27001 | Information-security management system | Wallet correctness or asset existence | Risk treatment, supplier and incident processes |
| NIST SP 800-57 | Key-management lifecycle terminology | Chain-specific custody design | Generation, activation, rotation, revocation, destruction |
| NYDFS custody guidance | Segregation, separate accounting, limited use, disclosure | A universal global custody rule | Ledger/on-chain segregation and reconciliation |
| MiCA Article 75 | EU CASP custody policy, register, statements, return and segregation | Technical control implementation | Client position register and operational segregation |
Failures that pass a vendor demo. Expand each for the control and the reason it fails.
A round portfolio percentage ignores demand and replenishment lead time.
Concrete use: Calculate per-asset base stock and sensitivity.
Failure mode: Market moves can double fiat exposure without any operational change.
The attacker who controls admin can immediately cash out.
Concrete use: Alert and hold new destinations 48 hours.
Failure mode: Out-of-band checks after transfer are forensics, not prevention.
Presence of sealed media says nothing about correctness or current metadata.
Concrete use: Restore annually and verify the first address.
Failure mode: Discovering a bad backup during disaster converts outage to permanent loss.
A level or report is evidence about scoped controls, not immunity from loss.
Concrete use: Track scope, exclusions, period, tested version, and remediation.
Failure mode: A vendor badge does not transfer your policy and ledger responsibilities.
Recovery objectives apply to authorization and signing, not merely the web/API tier.
Concrete use: Exercise loss of one site and one key holder; measure time to a valid canary signature and intact audit trail.
Failure mode: A restored database with no quorum is still a custody outage.
Initiator, approver, policy admin, signer admin, key holder, and auditor are conflict domains.
Concrete use: Prohibit one identity from changing a destination rule and satisfying its transfer quorum.
Failure mode: Two accounts owned by one person do not create dual control.
Exit must recreate shares, paths, addresses, policy, pending state and evidence.
Concrete use: Restore in an isolated alternate site annually and reconcile a canary address.
Failure mode: A share without derivation metadata may not restore the portfolio.
Crime, specie, and cyber policies contain peril, hot/cold, location, sublimit, exclusion, and allocation terms.
Concrete use: Map each tier and subcontractor to the schedule and model loss above each sublimit.
Failure mode: “Insured up to $X” rarely means every client receives X.
Operational and volatile claims were checked against these first-party documents on 2026-08-31. Examples are illustrative controls, not legal, investment, or vendor-selection advice.