Custody Architecture in Digital Asset Markets

In digital asset markets, custody is the decisive operating decision. The difference between a credible institution and an exposed one is rarely the asset it holds — it is how that asset, and the keys that control it, are held. This note sets out how we think about custody architecture: as an operating model to be designed, not a product to be bought.

Custody is an operating model, not a product

It is tempting to treat custody as procurement: choose a provider, sign a contract, move on. In practice, custody touches key management, access control, transaction policy, accounting, audit, and continuity. Each of those is an operating decision, and together they define how an organization actually functions.

Framing custody as a product hides this. It encourages institutions to evaluate vendors on features rather than to design the model they need. The more useful question is not "which provider?" but "what operating model are we trying to run, and which arrangement supports it?"

The custody spectrum

Custody arrangements sit on a spectrum, and there is no universally correct point on it.

• Self-custody offers maximum control and removes counterparty dependence. The cost is concentrated responsibility: the organization owns every operational and recovery burden itself.
• Institutional custody distributes that burden to a provider with dedicated infrastructure. The trade is counterparty, contractual, and concentration risk, and a degree of dependence on the provider's controls.
• Hybrid models combine elements of both — for example, self-custody for some assets and institutional custody for others, or shared-control arrangements. Most real institutions land somewhere in this middle ground.

The right point on the spectrum depends on an organization's risk tolerance, scale, technical capability, and obligations. The architecture should follow from those, not from a vendor's default.

The custody stack

Whatever the model, custody can be examined as a stack of layers, each with its own decisions and failure modes:

1. Key generation — how keys are created, and the entropy and ceremony behind them.
2. Key storage — hardware security modules, multi-party computation, or multisignature schemes, each with distinct trade-offs.
3. Access and authorization — who can act, under what policy, and with what approvals.
4. Transaction signing — how transactions are constructed, reviewed, and signed.
5. Segregation and accounting — how assets are separated and reconciled against records.
6. Recovery and continuity — what happens when people, systems, or providers fail.

Weakness at any layer undermines the others. Strong storage with weak authorization is still weak; robust signing with no recovery plan is fragile.

Operational risk controls

Around the stack sit the controls that make custody defensible:

• Segregation of duties, so that no single person can move assets alone.
• Policy and quorum approvals, so that transactions are governed by explicit, enforced rules.
• Monitoring and audit, so that activity is visible and records survive scrutiny.
• Disaster recovery and continuity, built on the assumption that failure will eventually happen.
• Insurance considerations, understood precisely — what coverage does and does not address.
• Vendor and counterparty due diligence, applied to every party the model depends on.

These controls are unglamorous, and they are where credibility is actually established.

Failure modes are operational, not cryptographic

A common misconception is that custody failures are primarily cryptographic — that the risk is a broken algorithm. In practice, the failures that matter are overwhelmingly operational: a key generated insecurely, an approval process that can be bypassed, a recovery plan that was never tested, a provider whose controls were assumed rather than verified.

This is why we treat custody as architecture and process rather than as a technology choice. The cryptography is usually the strongest part of the system. The weakest parts are the human and operational ones around it.

Evaluating a custody model

A custody model can be examined through a short set of questions:

• How are keys generated and stored, and who has verified it?
• Who can authorize a transaction, and what prevents a single party from acting alone?
• How are assets segregated and reconciled, and how often?
• What is the recovery plan if a key holder, system, or provider becomes unavailable — and has it been exercised?
• For institutional custody: what exactly is the provider responsible for, and what remains the organization's responsibility?

The aim is not to reach a single right answer, but to surface where a model is strong and where it is merely assumed to be.

Conclusion

Custody architecture is where digital asset operations succeed or fail. Designed as an operating model — with deliberate choices across the stack and disciplined controls around it — custody becomes defensible. Treated as a product to be procured, it becomes a source of hidden risk. Our research focuses on making those choices explicit, so that custody can withstand the scrutiny institutional participation demands.