Katkat
Back

Design a Digital Asset Custody Service

Anchorage DigitalSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question tests your ability to design a high-security, distributed system for managing digital asset custody, focusing on secure key storage, transaction authorization, and auditability.

Problem Statement

Design a digital asset custody service for institutional clients. Unlike a retail crypto wallet, this service must support high-volume transactions, multi-signature approval workflows, and strict regulatory compliance (e.g., audit trails, KYC integration).

Functional Requirements

  • Clients can deposit and withdraw supported digital assets (e.g., BTC, ETH).
  • Transactions must require M-of-N multi-signature authorization.
  • The system must support real-time balance tracking and account management.
  • A secure, immutable audit log of all administrative and transactional actions.

Non-Functional Requirements

  • Security: Keys must never exist in plaintext in memory or on disk (consider HSMs or Multi-Party Computation).
  • Reliability: High availability for balance inquiries and transaction initiation.
  • Consistency: Strong consistency for asset state to prevent double-spending.

Deliverables

  1. A high-level architecture diagram describing the components (e.g., API Gateway, Signing Service, Blockchain Gateway).
  2. A data model for tracking accounts, transaction states, and authorization policies.
  3. A description of the transaction signing lifecycle from initiation to blockchain inclusion.
  4. Trade-offs between using hardware security modules (HSMs) vs. Multi-Party Computation (MPC) for private key management.

Hints

Hint 1

Consider decoupling the transaction submission service from the high-security signing service to minimize the attack surface.

Hint 2

Think about how to represent the multi-signature policy in the database: should it be hardcoded or configurable per client?

Hint 3

For the signing process, investigate how threshold signature schemes can ensure that no single server or administrator holds a complete private key.

Follow-up questions

  • How would you handle a scenario where an institutional client loses their primary signing device or administrator access?
  • How does your design ensure that the system can verify the authenticity of a transaction before it is submitted to the public blockchain network?
  • If the service needs to support a new blockchain with a different address format, what parts of the system would require modification?