Digital Asset Custody
Digital Asset Custody: Why Key Ownership Is the Only Question That Matters
Most custody solutions protect your assets from hackers. Fewer protect them from the provider holding your keys.
The Key Ownership Problem
Every digital asset custody pitch starts the same way: air-gapped hardware, institutional-grade security, SOC 2 compliance. The threat model is always external: hackers, network attacks, social engineering. The pitch assumes the provider is the solution.
But for most institutional custody arrangements, the provider holds some or all of the key material. That means the provider can, in principle, do what hackers could only dream of: move your assets without your keys, freeze access unilaterally, or simply fail to return funds during a dispute.
This is not a theoretical risk. Exchange collapses, provider insolvencies, and regulatory freezes over the past few years have consistently shown that custody risk is structural. Who holds the key shares determines who has real control.
The guide below covers how to read custody models honestly, what the alternatives actually look like, and why non-custodial MPC changes the custody arrangement itself, beyond the security layer.
What Is Digital Asset Custody?
Digital asset custody refers to how private keys, the credentials that authorize transactions on a blockchain, are generated, stored, and controlled. Custody gets sold as a product category. In practice, it describes who holds real authority over an asset.
In traditional finance, custody means a regulated third party holds securities on a client's behalf. In digital assets, custody is more literal: whoever controls the private key controls the asset. There is no bank to call, no settlement layer to dispute, and no custodian liability framework with real teeth. Once a private key authorizes a transaction, it executes.
What Tokenized Real-World Assets Are and Why Custody Matters →Key Takeaways
Custody is a key control question, not a security feature question
All serious custody providers have strong external security. The differentiating factor is who controls the private key material and under what conditions.
Three models cover most of the market
Custodial wallets, multisig self-custody, and MPC wallets each make different tradeoffs on key control, operational flexibility, and provider dependency.
Custodial MPC and non-custodial MPC are not the same thing
In custodial MPC, the provider holds one or more key shares and must participate in every transaction. In non-custodial MPC, the provider generates zero key material — and cannot authorize, freeze, or recover funds unilaterally.
Provider dependency is the underpriced risk
Most institutions price hacking risk carefully and underestimate provider risk: what happens when the custody provider is acquired, regulated, or goes insolvent.
Governance infrastructure matters as much as key storage
Approval workflows, multi-party sign-off, and audit trails are not optional features — they are the operational core of any institutional custody setup.
Exit architecture should be specified before onboarding
Can you export key material, migrate to a different provider, or continue operating if the custody provider shuts down tomorrow? If the answer is unclear, it belongs in the contract.
The Three Custody Models
Most institutional custody arrangements fall into one of three models. Each makes a different claim about who holds real authority.
Custodial Wallets
Provider holds keysThe provider generates and holds the private key on the client's behalf. The client has a balance in the provider's system, not direct on-chain access. This is the model used by most exchanges. It is operationally simple but concentrates all key risk with the provider. Client access depends entirely on the provider staying solvent and cooperative.
Self-Custody Wallet vs Exchange Wallet: What's the Difference? →Multisig Self-Custody
Client holds keys — complex to operateMultiple keys are generated, each held by a different party (typically a combination of internal signers and an external guardian). A transaction requires a threshold of signatures — for example, 2 of 3 or 3 of 5. The client retains genuine key control, but multisig has operational friction: on-chain signature coordination is slow, each blockchain needs its own multisig contract, and key management becomes complicated as teams and policies evolve.
What Is a Self-Custody Wallet? A Comprehensive Guide for Crypto-Related Businesses →MPC Wallets (Custodial vs. Non-Custodial)
Depends on who holds the sharesMulti-Party Computation splits key generation and signing across multiple parties using cryptography, without any single party ever holding the complete private key. This sounds non-custodial, but the critical question is whether the provider holds any of the key shares. In custodial MPC, the provider holds one or more shares and must participate in every transaction. In non-custodial MPC, the provider contributes computation only during initial setup and holds nothing afterward. The security architecture is similar. The custody arrangement is fundamentally different.
Where Custody Breaks Down
The five failure modes below are not edge cases. They have each occurred in documented custody arrangements. Understanding them is how institutions avoid building the wrong structure.
1. Shared key control creates a shared veto
When the provider holds a key share, they can refuse to participate in a signing ceremony, effectively freezing assets without touching them. This may happen in a dispute, a regulatory action against the provider, or an acquisition where the new owner declines to honour legacy agreements. The client has custody on paper, not in practice.
2. Provider dependency concentrates counterparty risk
Even well-run custody providers can be acquired, change their pricing model, pivot their product, or be forced offline by their regulators. Institutions that have not specified what happens to key material in these scenarios discover — usually during the event — that the contract did not protect them.
3. Regulatory actions can freeze assets without notice
If a custody provider is subject to a regulatory freeze, seizure order, or sanctions designation, assets held under their key control may become inaccessible — regardless of whether the client is the regulated party. This risk is greatest when the provider holds key shares directly.
4. Provider-owned audit trails create opacity
In many custodial arrangements, the transaction log and approval records live inside the provider's system. The client can query them, but cannot own them independently. This becomes a problem during compliance audits, disputes, and M&A due diligence — when access to the provider may be restricted at exactly the moment the records are most needed.
5. Exit requires provider cooperation
Migrating away from a custody provider is operationally trivial in non-custodial models — the client controls the keys and can move them at will. In custodial and custodial MPC models, migration requires the provider to actively participate: releasing key shares, transferring balances, and coordinating settlement. Providers with commercial incentives to retain clients have no obligation to make this easy.
Five Requirements Any Institutional Custody Setup Must Meet
Strip away the marketing language and institutional custody requirements reduce to five things. Any custody solution that cannot answer each one clearly is not ready for institutional use.
Key sovereignty
The institution controls the key material — not jointly with the provider, not subject to provider participation. When the provider is offline, the institution can still authorize transactions independently.
Programmable approval governance
Multi-party sign-off, configurable approval thresholds, and role-based permissions that match internal treasury and compliance workflows. Governance rules should be enforced at the system level, not managed through manual processes.
Institution-owned audit trails
Every approval step, signing event, and policy override recorded in a log the institution owns and can export independently — not accessible only through the provider's dashboard.
Operational continuity
The custody setup continues to function if the provider changes ownership, faces regulatory action, or goes offline. This requires either full key portability or a documented contingency that does not depend on provider cooperation.
Clean exit architecture
The path from this provider to the next one is defined before onboarding. Key export format, migration timeline, and any provider-specific dependencies are documented — not discovered during a forced migration.
How MPC Works
Multi-Party Computation is a cryptographic technique that allows multiple parties to jointly compute a function (in this case, generating or signing with a private key) without any single party ever seeing the complete key. The key never exists as a whole; it is generated, used, and rotated in distributed fragments.
In a standard MPC signing ceremony, each party performs local computation on their key share and combines the outputs into a valid signature. The private key itself is never reconstructed at any point in this process. This is different from multisig, where each party signs independently with a full key and the blockchain verifies the set of signatures.
Hot vs Cold Wallets: An Institutional Guide →The security improvement is real: MPC eliminates the single point of failure that comes with holding a complete private key. But MPC is a signing mechanism, not a custody model. The custody question is: where do the shares live, and who controls them?
In custodial MPC, the provider holds one or more key shares on their infrastructure. Every transaction requires the provider to participate in the signing ceremony. The provider's participation is technically mandatory — and their servers are live infrastructure that can be shut down, seized, or taken offline. The MPC architecture protects against external attackers. It does not protect against the provider.
In non-custodial MPC (the model CoinsDo uses), the provider contributes to the initial key generation ceremony and then retains nothing. All key shares are held by the client across their own infrastructure. Subsequent signing ceremonies happen between the client's own signers. The provider's role after setup is operational: infrastructure, API access, governance tooling. Not cryptographic. The provider cannot unilaterally authorize, block, or recover a transaction.
The Non-Custodial Difference
CoinsDo's Wallet-as-a-Service infrastructure is built on non-custodial MPC. When a client deploys wallets through the CoinsDo platform, the key generation ceremony produces shares that are distributed to the client's own systems. CoinsDo does not retain a copy of any share. It cannot authorize transactions, it cannot freeze assets, and it cannot access client funds under any operational circumstance.
The architecture is built this way from the ground up. The platform handles the operational layer: multi-chain wallet generation, approval workflow enforcement, transaction routing, audit logging — without ever holding the cryptographic material that would give it custody. Clients get institutional-grade infrastructure without transferring the custody risk that comes with it.
For institutions building crypto payment rails, treasury infrastructure, or white-label wallet products, this distinction changes the risk calculation. The provider can be changed, audited, or challenged without the institution losing access to its own assets. That kind of independence is harder to build on top of a custodial arrangement than to design into the infrastructure from the start.
See how the full WaaS platform works →Three Reasons to Consider a Non-Custodial Digital Asset Management Solution →Use Cases
The right custody architecture depends on what the institution is doing with the assets. These four scenarios show how non-custodial MPC applies across different operational contexts.
Crypto Exchange or Trading Platform
Problem
Client deposit wallets are held custodially, creating concentrated key risk. A regulatory action or provider outage can freeze withdrawals even when client assets are technically intact.
Solution
Non-custodial MPC wallets for deposit and withdrawal accounts. The exchange controls all key shares. Approval workflows enforce withdrawal limits, counterparty screening, and multi-signer sign-off without provider participation.
Impact
Exchange retains full operational control of client funds regardless of provider status. Regulatory actions against the infrastructure provider do not propagate to client assets.
Payment Service Provider
Problem
High-frequency settlement requires fast transaction authorization at scale. Standard multisig introduces latency. Custodial models create dependency on provider availability for every transaction.
Solution
MPC wallets with configurable approval policies allow high-frequency transactions to process without manual sign-off on every transfer, while larger or unusual transactions route to multi-party approval queues.
Impact
Settlement throughput scales without expanding the attack surface. Policy-based automation reduces operational overhead while preserving governance controls where they matter.
Gaming or Web3 Platform
Problem
In-game asset wallets need to be created at scale — millions of wallets across multiple chains — while keeping user funds non-custodial and minimizing friction for withdrawals.
Solution
Programmatic wallet generation via API, with embedded approval logic for in-platform actions. Users hold key shares for their own wallets; the platform retains no custody over user assets.
Impact
Platform liability is reduced. Regulatory classification of in-game assets is simplified because the platform is not a custodian. Users retain genuine ownership of digital items.
Enterprise Treasury
Problem
A corporate treasury holding digital assets across multiple blockchains needs institutional-grade governance: segregated accounts, approval hierarchies matching corporate policy, and independent audit trails for reporting.
Solution
Non-custodial MPC wallets with role-based approval workflows configured to match internal sign-off thresholds. Audit logs exported to internal compliance systems. Key material held entirely within corporate infrastructure.
Impact
Treasury operations comply with internal governance frameworks. Audit logs are owned by the institution, not dependent on provider access. Migration to a different provider does not require key reconstruction.
Digital Asset Custody Readiness Checklist
Before selecting a custody provider, these six questions should have clear, documented answers. Vague responses or deferred answers are informative in themselves.
Does the provider hold any key shares after setup?
If yes, this is a custodial arrangement regardless of the marketing language. Clarify the exact scenarios in which the provider can refuse to participate in a signing ceremony.
What happens to key material if the provider shuts down?
Ask for the documented contingency plan. If it requires provider cooperation to migrate, ask what happens if that cooperation is withheld during insolvency proceedings.
Can you run a signing ceremony without the provider's infrastructure?
In non-custodial MPC, the answer is yes. In custodial MPC, the provider's servers are a required technical dependency, not a convenience layer.
Who owns the audit logs?
Can you export complete transaction and approval records to your own systems independently, or is access mediated through the provider's dashboard?
How do approval governance rules work?
Are approval policies enforced at the cryptographic level (meaning they cannot be bypassed without a key share) or at the application level (meaning provider admins could override them)?
What does a clean exit look like?
Request the migration documentation before signing. If it does not exist, ask for it to be created as a contract exhibit. If the provider declines, that is a custody risk indicator.
Conclusion
Digital asset custody is a solved problem at the security layer. Hardware security modules, air-gapped signers, and institutional-grade infrastructure are standard across serious providers. The unsolved problem is structural: most custody solutions require the institution to trust the provider with some degree of key control.
Non-custodial MPC removes that dependency at the architectural level. The provider builds and maintains the infrastructure. The client holds the keys. The provider can be changed, audited, or challenged without the institution needing its cooperation to access its own assets.
For institutions with real regulatory exposure, governance obligations, or operational scale, this difference is not marginal. It is the difference between custody and outsourced key control dressed as custody.
Frequently Asked Questions
Digital Asset Custody
What is the difference between custodial and non-custodial digital asset custody?
Is MPC the same as self-custody?
How does non-custodial MPC compare to multisig?
What happens to my assets if my custody provider goes insolvent?
What governance controls should an institutional custody setup include?
How does CoinsDo's custody model work?
About this guide
This guide was written by the CoinsDo team based on direct experience building non-custodial MPC wallet infrastructure for exchanges, payment providers, and institutional treasury teams. It reflects operational knowledge from deploying custody solutions across multiple blockchain networks and regulatory environments — not vendor marketing material.
