# MiCA-compliant custody architecture: a technical reading

> MiCA Article 67 and 70 require segregation of client crypto-assets and demonstrable key control. A zero-custody architecture maps cleanly onto both requirements without operator-level controls.

*Primary query: MiCA-compliant custody architecture. Last updated 2026-04-22.*

MiCA's custody requirements (Articles 67 and 70 in particular) ask custodians to segregate client crypto-assets, prevent commingling with their own holdings, and demonstrate effective control over the underlying keys. Most existing implementations meet this through layered operator-level controls. A zero-custody architecture meets it through cryptography: the operator never holds material that could move client assets, so segregation is enforced by construction rather than by policy.

## What the regulation actually asks for

Article 67 obliges crypto-asset service providers to safeguard client crypto-assets and means of access, including segregation from the provider's own holdings and demonstrable arrangements that prevent loss arising from misuse, fraud, or operational failure. Article 70 reinforces this with specific custody-and-administration obligations.

Conventional custody platforms answer this with operator hierarchies, dual control, segregated wallets per client, and audited key ceremonies. The regulator inspects the procedural controls and the access logs; the supervisor's confidence is in the chain of human approvals, not in the key material itself.

The blast radius of any operator compromise, insider, credential theft, supply-chain, is the set of client wallets that operator could touch. That is usually a large set, because operational efficiency pulls toward shared infrastructure.

## Cryptographic segregation, not procedural segregation

Zero-persistence custody removes the operator's ability to act on client assets at all. Each client wallet's signing key exists only at the instant of an authorised operation; it is reconstructed inside a secure element, used once, and destroyed. No operator, including the platform itself, holds material capable of producing a signature outside of an authorised event.

The supervisor's evidence shifts from 'we have policies that prevent operators from misusing keys' to 'no operator has ever held the key, and the cryptographic chain proves it'. Segregation is not a property of the operator's directory layout; it is a property of the keys themselves.

## Side by side

| Dimension | Conventional approach | Zero-persistence reconstruction |
| --- | --- | --- |
| Segregation enforcement | Operator policy + access controls | Per-wallet keys, never assembled outside the authorised event |
| Insider misuse blast radius | All wallets the operator can reach | None, operator holds no usable key |
| Article 67 evidence | Procedure documentation, access logs | Hardware-attested cryptographic chain per operation |
| Disaster recovery | Backup keys held by the custodian | Quorum re-derives on demand; no backup exists |
| Sub-custodian risk | Each sub-custodian needs its own controls | Sub-custodians can be quorum members without holding key material |

## What this looks like in practice

- **A MiCA-licensed exchange** documents key control by reference to hardware attestation rather than operator workflow, shrinking the operational-controls section of its supervisory file.
- **A bank offering crypto-asset custody to professional clients** uses its own staff as one quorum participant and an external recovery-agent network as another, evidencing genuine separation of duties without sharing key material.
- **A pan-EU custodian serving multiple national supervisors** demonstrates the same segregation model uniformly across jurisdictions, because the segregation is cryptographic rather than process-based.

## Related Lokblok material

- [MiCA-aligned digital asset custody](https://www.lokblok.co/solutions/digital-asset-custody)
- [the underlying threshold-reconstruction architecture](https://www.lokblok.co/architecture)
- [policy-bound delegation for institutional approval workflows](https://www.lokblok.co/features/hierarchical-signatures)

## FAQ

### Does zero-persistence custody count as 'safeguarding' under MiCA Article 67?

Article 67 requires the provider to take effective steps to prevent loss from misuse, fraud, or operational failure. A model in which the provider holds nothing capable of moving client assets between authorised events meets the spirit of safeguarding more strictly than any procedural arrangement, because the prohibited actions are cryptographically impossible rather than merely policy-forbidden.

### How does this interact with the requirement to maintain a register of client positions?

The position register is independent of the key model. Zero-persistence reconstruction protects the means of access (the keys); the off-chain ledger of who owns what continues to be maintained by the custodian and reconciled to on-chain balances on the normal cadence.

### What does the supervisor inspect if there are no key ceremonies?

The supervisor inspects the recovery-agent quorum configuration, the secure-element attestation chain, the policy engine that authorises operations, and the per-operation cryptographic record. These are stronger evidence than ceremony minutes because they cannot be backdated.

### Can the same architecture serve professional and retail clients under different obligation levels?

Yes. The same per-wallet zero-persistence model applies; the policy engine differentiates retail and professional flows by quorum composition, approval thresholds, and operational limits, not by storing different keys.

## Related insights

- [Alternatives to MPC custody: when threshold key shares are still keys](https://www.lokblok.co/insights/alternatives-to-mpc-custody)
- [Delegate signing without giving up keys: hierarchical signatures explained](https://www.lokblok.co/insights/delegation-without-custody)