HSM-Backed Cold Custody Wallet Platform

Problem

As a crypto exchange serving retail and institutional customers, CoinDCX needed an institutional-grade cold custody layer to protect long-term reserves at scale. Hot wallet systems alone could not meet the security bar: exchange breaches and insider threats make online key storage a persistent risk, and regulators expect demonstrable controls over customer assets. Private keys had to stay inside a hardened trust boundary, withdrawals required multi-party authorization, and business policies (allowlists, limits, routing rules) had to be enforced consistently and auditable across 100K customers and 10K daily deposit and withdrawal transactions.

Security architecture

The design followed the same principles described in Square's Subzero documentation for HSM-backed Bitcoin cold storage: keep reserve funds offline where possible, protect keys inside FIPS-grade HSMs, and treat every outbound transfer as a privileged operation.

CoinDCX's implementation applied that onion model to a multi-asset exchange context - hot systems handled operational throughput while cold paths guarded signing keys and enforced policy before any withdrawal was approved.

Subzero is Square's published open-source reference for HSM-backed cold storage; CoinDCX was a separate production implementation built for multi-asset exchange custody at scale. The patterns align, but the systems are distinct.

• Offline cold reserve separated from hot operational wallets to shrink attack surface and theft risk.
• HSM-backed key protection: FIPS-certified hardware guards private key material against external and insider threats.
• Multi-party signing ceremony required before funds leave cold storage.
• Policy enforcement inside the trust boundary: allowlists, limits, and routing rules validated at the HSM/cold layer, not only in application code.
• Defense in depth (onion model): multiple independent security layers rather than a single control.
• Online/offline isolation: strict separation between hot operational systems and the cold signing environment.
• Encrypted backup and key recovery via HSM key-sharing for wallet restore.

Platform design

Services were split by responsibility rather than monolith size. Java handled core custody orchestration and integration with existing exchange systems. Go backed latency-sensitive and security-critical paths. Node.js supported API and workflow surfaces that needed fast iteration.

Deposits followed the hot operational path: online systems recorded intent, updated balances, and triggered monitoring. Withdrawals crossed into the cold path only after policy evaluation and multi-sig quorum, keeping signing keys isolated from day-to-day exchange traffic.

• Deposit pipeline: online systems record intent; cold layer confirms and signs when required.
• Withdrawal pipeline: policy check, multi-sig quorum, HSM signing, then broadcast from controlled egress.
• Rule engine: declarative policies for limits, destinations, asset types, and approval thresholds.
• Observability: structured audit events for compliance review and incident response.

Policy and compliance

Subzero enforces business logic inside offline HSMs - for example, restricting outbound transfers to approved destinations. CoinDCX's rule engine served a similar role at exchange scale: policies were data-driven, versioned, and evaluated in ~30ms at request time without a code deploy per rule change.

Every policy evaluation and authorization decision produced structured audit events, giving compliance and security teams a complete record for review and incident response.

• Generic rule engine avoided one-off code changes for each new custody policy.
• Symmetric and asymmetric cryptography, hashing, and signature verification underpinned authorization decisions.
• Separation of duties between operations, security, and engineering for sensitive configuration changes.

Approach

• Architected the custody platform across Java, Node.js, and Go - matching each runtime to orchestration, API, and performance-sensitive signing paths.
• Integrated HSM-backed key management so private key material never left the hardware trust boundary, aligned with industry cold-storage patterns such as Square's Subzero HSM model.
• Implemented multi-signature withdrawal workflows requiring coordinated approval before funds could leave cold storage.
• Built a generic rule engine with ~30ms response time so custody policies could be updated without shipping new application code for every rule change.
• Separated online operational flows (deposits, balance updates, monitoring) from offline or cold signing paths to reduce blast radius.
• Enforced destination and policy checks at the custody layer - a defense-in-depth model where HSM and rule logic validate transactions before signing.
• Designed audit trails and operational visibility across deposit, withdrawal, and policy evaluation so security and support teams could trace every decision.
• Delivered for high availability so custody services remained reliable under daily production load.

Outcome

• Custody platform supported 100K customers with 10K daily crypto deposit and withdrawal transactions at high availability.
• Rule engine evaluated policies in ~30ms, enabling real-time enforcement without blocking user flows.
• HSM and multi-signature architecture met cold-storage security requirements for exchange-grade custody.
• Configurable business rules reduced time to adapt custody policy compared to hard-coded application changes.
• Structured audit trails gave security and compliance teams end-to-end traceability across deposits, withdrawals, and policy decisions.
• Engineering teams could operate hot and cold paths independently while preserving a consistent, auditable policy surface.