Digital asset custody means controlling the private keys that authorize transfers. Custody models, key management, and how to choose build or buy.
Digital asset custody represents the core of any financial application's decisions with respect to risk, regulation, and architecture. The private keys required to allow transactions on the blockchain are in fact the asset, and not the tokens that represent them.
Most teams find out too late that they have chosen a wallet library or vendor contract that significantly impacts the custody of their users' crypto assets. Custody dictates licenses required, liability in case something goes wrong, and handling of typical transactions as well as disasters. We will go through the various layers of this decision starting with the basics of crypto key management and then the practical cost of MPC wallet infrastructure that you can build in-house.
Digital asset custody architecture determines who controls the private keys of a client's digital assets and therefore who will be held liable for losses of their funds.
The custody model also affects which licenses an entity needs to hold. For example, an EU entity will fall under MiCA's CASP framework, whereas a US broker-dealer will be subject to a number of controls-based tests. Importantly, liability for lost funds follows key control.
Reversing out of any particular custody architecture decision is likely to be difficult and to require movement of private keys, rebuilding of wallet flows and re-licensing within different jurisdictions. That risk makes a decision on this front especially significant compared to (for example) choosing a different payments processor or migrating to a different cloud region.
When conducting a custody models comparison, it becomes clear that choosing between different approaches requires trade-offs with respect to control, cost and compliance that need to be made early on in the architecture of a fintech or exchange.
This self-custody model gives the platform complete control over the transactions and therefore removes the counterparty risk but shifts the full operation of the product to the product team (key generation, storage, signing, etc., including all disaster recovery).
A third-party custodian, such as BitGo, Copper or Anchorage Digital, holds the user's keys on behalf of the customer. Although this exposes the customer to the risk of the custodian becoming a counterparty to the customer, losing keys or locking the customer into the vendor's services, the solution satisfies the licensing requirements that apply to safekeeping client assets in many jurisdictions.
The hybrid model typically uses an in-house hot wallet for retail transactions and then sends larger balances to a licensed, third-party custodian for the user. This setup allows fast transaction processing while spreading large amounts of cash held in settlement to external infrastructure that is purpose-built for such large sums.
Decisions about the signing primitive used for crypto key management have far reaching implications for support of individual chains, transaction throughput and operational complexity.
The typical operation of an HSM (for crypto key management) is to store key material in tamper-evident enclaves within certified hardware. Operational activities such as key rotation and disaster recovery typically require physical access to the HSMs for which the corresponding processes are usually managed by dedicated infrastructure teams.
A multi-sig wallet would enforce certain on-chain policies (e.g. 2-of-3 for Bitcoin), but would be visible to everyone on the blockchain and cost a constant amount of money for every transaction. Coverage would likely be chain specific.
MPC wallet infrastructure is structured in such a way that all key shares are distributed such that no single point holds the complete key. We compare the key signing primitives, protocols and providers in more detail in our MPC wallet development guide.
| MPC (TSS) | Multi-sig | HSM | TEE | |
|---|---|---|---|---|
| Where the key lives | Split into shares across parties, never assembled | Several full keys, one per signer | One full key inside certified hardware | One full key inside an isolated enclave |
| Where the policy is enforced | Off-chain, in the signing layer | On-chain, in a contract or script | Off-chain, in the device and its operators | Off-chain, inside the enclave |
| On-chain footprint | Standard single signature | Visible contract or script | Standard single signature | Standard single signature |
| Chain coverage | Any chain with a supported curve | Depends on native support or contracts | Depends on curves the device supports | Any chain |
| Main risk | Bugs in the protocol implementation | Contract bugs, lost keys per signer | Single key, operator and physical access | Enclave flaws, trust in one hardware vendor |
| Typical fit | Exchanges, fintechs, institutional custody | DAOs and protocol treasuries | Banks, cold storage, regulated custody | Consumer embedded wallets |
Most production stacks combine them rather than picking one. A common pattern is MPC for hot and warm tiers, HSM-backed cold storage, and multi-sig only where on-chain transparency is required.
The wallet tier architecture for distribution of custody risk across 3 levels of operation for fast withdrawal and risk mitigation.
Hot wallets hold the small share of assets under custody that is needed for day to day withdrawals; warm storage, typically backed by HSMs, is used for large withdrawals from institutional customers and can process these within a few minutes while avoiding cold wallet processing latency; crypto cold storage holds the balance offline.
An automated sweep policy must be a policy that can be audited. The thresholds that trigger the sweep, the quorum of people that must approve the release of assets, and the destination wallet(s) that the assets are released to must all be immutable at runtime to prevent tampering.
Processes for key reconstruction must be tested annually in a simulated disaster situation. Currently, most teams document the process but never actually test it in full.
Governance failures, not failures in cryptography, are behind most of the losses institutions suffer when they hold digital assets.
These RBAC crypto implementations separate the signing authority from administrative functions at the infrastructure level. An operator role should not hold both a set of keys and the ability to change policy for a given account.
A policy engine at the signing layer, for example, can enforce a set of rules for outgoing transactions, such as a maximum spending velocity per hour for each wallet cluster, and destination whitelists to prevent insider threats even when API keys are compromised.
An audit trail logging system captures all signing events and policy change events. These events are stored in a tamper-evident storage system. Governance frameworks for custody such as SOC 2 Type II and ISO 27001 require such a setup from day one and not as an after-thought for an audit.
Compliance requirements impact custody architecture as much as the underlying cryptographic primitives.
MiCA treats the custody and administration of crypto-assets on behalf of clients as a regulated crypto-asset service, which requires authorisation as a CASP in the EU. In the United States there is no single custody rule for digital assets, and the regulatory picture is still moving, so the practical question for architecture is the same one regulators keep returning to: which party can move the funds on its own.
Omnibus wallets pool client money in one address, making auditing much easier but hard to prove compliance with segregation requirements. Segregated wallet-per-user is more compliant, but for a neobank with 500,000 customers this setup needs to scale with an appropriate HD wallet strategy to handle the explosion of wallets.
The Travel Rule VASP obligations as set out by FATF require the transfer of originator and beneficiary information on transfers above certain local thresholds. In order to automatically fulfill these obligations with compliance tooling, the corresponding per-transaction metadata hooks need to be exposed by the asset segregation implemented in the system.
Of all the different decisions you can make about the infrastructure you build for a crypto product, the build vs buy custody question is likely to have the greatest impact on cost, time-to-market and regulatory exposure.
Production-grade MPC from scratch typically takes 12 to 24 months to build out, a dedicated cryptography team, and recurring third-party audit costs. We consider this scope to be within the reach of only the very largest of exchanges, or extremely well-capitalized fintechs.
A custody API such as offered by Fireblocks or Copper gives very fast time to market. This type of setup, however, tends to have very poor scalability in terms of per-transaction pricing and also typically forces data residency restrictions on regulated entities.
The practical decision for most fintechs will be to layer a licensed MPC (Multi-Party Computation) layer on top of their custom compliance and approval engine. When evaluating providers of such a layer key criteria include key-share ownership, signing latency SLAs, chain coverage, vendor certifications etc. plus exit portability clauses.
Most issues with the custody of digital assets originate from operational flaws, not failures of the cryptography.
The most common form of failure in a custody architecture is a single internet-connected signer with no quorum requirement. This is essentially a hot wallet with no safety net and exposes the entire key in the event of a single point of failure in that path.
There is substantial cryptographic debt that will harden into a serious vulnerability, which will remain active for longer than is acceptable, when early implementations of key rotation are not treated as a high priority.
Crypto incident response runbooks need to deal with key compromise, signer node failure, vendor outage and regulatory freeze orders separately, each requiring a different response playbook.
The stage of the product determines which measures of custody are practical, affordable and adequate to the risk actually encountered.
We rarely believe it is necessary to implement cryptographic infrastructure when a qualified third-party custodian offers a documented API to the MVP-stage fintech (e.g. Anchorage, Fordefi).
The unit-economics problem with a SaaS custodian finally surfaces when wallet scaling hits the limits of the per-transaction fee model. It is time to consider alternative models, such as MPC wallet development or white-label infrastructure.
Institutional clients as well as regulators demand proof of key ownership, timestamped logs and sufficient disaster recovery tests for crypto custody solutions. Such proof must be designed into the architecture from the start and not added as an afterthought.
Custody architecture for digital assets is a complex interplay of key management, regulation and product design. The choice between self-custody, third-party and hybrid models determines both risk and user experience. The trade-off between building in-house and buying a service is not purely a cost issue and is influenced by the capabilities of the founding team and CTO, time-to-market pressures, and the product's current stage of development. Mapping out the relevant governance policies before choosing the underlying infrastructure is key to avoiding the most costly mistakes in custody. For those looking to drill deeper into the practical scope of custody, our crypto wallet development services page outlines the key factors in more detail and explores what this means in terms of real build time and integrations.
For early-stage exchanges, it is common to use a hybrid model. The storage of cold assets is handled by a licensed third-party custodian, whereas so-called hot wallets for the other assets are managed by the team themselves. A fully proprietary storage system for in-house management is usually beyond the reach of early product teams, given the necessary amount of engineering manpower and corresponding compliance and regulatory expertise required. By partnering with a suitable institutional digital asset custody provider for early stages, you limit your exposure to counterparty risk significantly.
Multi-sig-based wallets have the signing quorum visible and verifiable on the blockchain (i.e. the number of signatures needed to spend funds). MPC (Multi-Party Computation) wallets on the other hand, distribute the key shares across all parties involved and sign off-chain through MPC-computed-sigs, offering chain-agnostic functionality and reduced disclosure of metadata associated with operations.
Building your own in-house solution makes sense only if you have a truly unique use case that no vendor can offer you, a very mature security engineering team and you are large enough to be squeezed by the vendor's fees over a three-to-five year time horizon. Most product teams underestimate how much work compliance, auditing and key ceremonies involve. Doing a rigorous build-vs-buy analysis and taking the total cost of ownership into account is much harder than just looking at the initial development cost.
A digital asset custodian is a regulated business that safekeeps crypto assets on behalf of clients. Because the assets themselves live on a blockchain, what the custodian actually holds and protects is the private keys that authorize transfers.
It depends on whether the fintech can move client funds on its own. A firm that controls the keys is normally the one that needs the licence, while a firm that routes client assets to a licensed custodian may not. The answer is jurisdiction specific and worth confirming with counsel before launch.
