Custody & Key Management
TL;DR
- Custody is the foundation of any exchange — if you can't secure assets, nothing else matters. Every major exchange failure traces back to a custody breakdown.
- Wallet architecture is tiered: cold (80-95% of assets, air-gapped), warm (5-15%, semi-automated), hot (2-5%, instant liquidity). The percentages are a risk management decision, not a technical one.
- Multisig requires M-of-N independent signatures on-chain. Simple and auditable, but blockchain-specific and operationally rigid.
- MPC (multi-party computation) splits a single key into shares that never recombine — signatures happen off-chain, work across all blockchains, and the quorum can be rotated without changing the address. This is where the industry has moved.
- HSMs (hardware security modules) provide tamper-resistant key storage. FIPS 140-2 Level 3 is the industry standard. Modern setups run MPC key shards inside HSMs.
- Signing ceremonies for cold wallets are physical, multi-person events with air-gapped devices, quorum requirements, and audit trails.
- Proof of Reserves uses Merkle trees to let users verify their balances are backed, but it has real limitations — it doesn't prove the absence of liabilities.
- Every major custody failure — Mt. Gox, QuadrigaCX, FTX, Bitfinex, Ronin — was preventable with proper key management practices.
1. Why Custody Is the Foundation
An exchange is, at its core, a custodian. Users deposit assets, trade against each other, and withdraw. Every step assumes the exchange actually has the assets it claims to have — and can move them when requested.
This is the trust assumption. And it's been violated repeatedly.
The history of crypto is littered with exchanges that got the trading engine right, the UI right, the marketing right — and then lost everything because they couldn't secure private keys. Mt. Gox handled 70% of all Bitcoin transactions in 2013. It didn't matter. 850,000 BTC gone.
Custody isn't a feature. It's the prerequisite. Everything else — matching engines, margin systems, liquidation engines — is built on top of the assumption that the underlying assets are safe and accessible.
The core challenge is a tension:
Security <————————————> Availability
(lock everything down) (move funds instantly)Lock keys in a vault with no network connection and you're secure but can't process withdrawals. Put keys on a hot server and you can move funds in milliseconds but you're one exploit away from catastrophe. Every exchange architecture is a set of compromises along this spectrum.
2. Hot, Warm, and Cold Wallet Architecture
Exchanges solve the security-availability tension by splitting assets across multiple tiers, each with different security properties and access speeds.
The Three Tiers
┌─────────────────────────────────────────────────────┐
│ COLD STORAGE (80-95%) │
│ Air-gapped devices, vault, signing ceremonies │
│ Access time: hours to days │
│ Use: bulk reserves, long-term holdings │
├─────────────────────────────────────────────────────┤
│ WARM WALLETS (5-15%) │
│ Networked but behind approval policies │
│ Access time: minutes to hours │
│ Use: refilling hot wallets, large withdrawals │
├─────────────────────────────────────────────────────┤
│ HOT WALLETS (2-5%) │
│ Fully automated, connected to internet │
│ Access time: seconds │
│ Use: user withdrawals, operational liquidity │
└─────────────────────────────────────────────────────┘Hot Wallets
Hot wallets are the exchange's operational float. They hold enough to process normal withdrawal demand — typically 2-5% of total assets. Keys are loaded in memory on networked servers, enabling fully automated signing.
The security model relies on:
- Rate limiting: maximum withdrawal amount per time window
- Anomaly detection: flag unusual withdrawal patterns
- Auto-sweep: periodically move excess funds to warm/cold storage
- Address whitelisting: only send to pre-approved addresses for large amounts
If a hot wallet is compromised, the loss is bounded by its balance. This is the design. You accept that hot wallets are the highest-risk tier and limit exposure accordingly.
Warm Wallets
Warm wallets sit in the middle. They're networked (not air-gapped) but require multi-party approval before signing. Common configurations:
- 2-of-3 approval required for any transaction
- Time-delayed execution (e.g., 15-minute hold before signing)
- Dollar thresholds that escalate approval requirements
- Geographic distribution of approvers
Warm wallets serve as the refill mechanism for hot wallets. When the hot wallet drops below a threshold, an automated request triggers the warm wallet flow. A human (or multiple humans) approve, and funds move.
Cold Storage
Cold storage is the vault. The vast majority of exchange assets — 80-95% — should sit here. Cold storage keys exist on devices that have never been connected to the internet. Transactions are constructed offline, signed on air-gapped hardware, and broadcast from a separate, online machine.
Cold storage characteristics:
| Property | Detail |
|---|---|
| Network connectivity | None (air-gapped) |
| Key storage | HSMs, hardware wallets, or paper in bank vaults |
| Access time | Hours to days (requires signing ceremony) |
| Typical signers | 3-of-5 or higher quorum |
| Physical security | Bank vaults, geographic distribution |
| Audit trail | Video recording, witness logs, dual control |
The inconvenience is the point. If it's hard for authorized personnel to access, it's even harder for an attacker.
Rebalancing
Exchanges continuously monitor tier balances and rebalance:
If hot_wallet_balance < low_threshold:
trigger warm → hot refill (requires M-of-N approval)
If hot_wallet_balance > high_threshold:
auto-sweep excess to warm storage
If warm_wallet_balance < low_threshold:
initiate cold → warm signing ceremonyThe thresholds are tuned based on historical withdrawal patterns, time of day, and market conditions. During high volatility (when withdrawals spike), the hot wallet threshold might be temporarily raised.
3. Multi-Signature Schemes
How Multisig Works
Multisig is the simplest form of distributed key management. Instead of one private key controlling a wallet, the blockchain itself enforces that M-of-N keys must sign a transaction before it's valid.
Example: a 2-of-3 multisig wallet has three independent private keys. Any two of them must produce valid signatures for a transaction to be accepted by the network.
Key A (CEO) ──┐
├──→ 2-of-3 Multisig Address ──→ Withdrawal TX
Key B (CTO) ──┤ (enforced on-chain)
│
Key C (CFO) ──┘This eliminates single points of failure. No single person can unilaterally move funds. If one key is compromised, the attacker still needs a second key. If one key is lost, the remaining two can still recover funds.
Common M-of-N Configurations
| Configuration | Use Case | Trade-off |
|---|---|---|
| 2-of-3 | Small teams, hot wallets | Low threshold, fast operations |
| 3-of-5 | Warm wallets, medium security | Balanced security/availability |
| 4-of-7 | Cold storage | High security, tolerate multiple key losses |
| 5-of-8 | High-value cold storage | Maximum resilience |
Shamir's Secret Sharing (SSS)
Before multisig existed natively on blockchains, the alternative was Shamir's Secret Sharing, invented by Adi Shamir in 1979. SSS splits a single secret (a private key) into N shares such that any K shares can reconstruct the original, but K-1 shares reveal nothing.
The math is elegant. The secret is encoded as the constant term of a random polynomial of degree K-1. Each share is a point on that polynomial. Since K points uniquely determine a polynomial of degree K-1 (via Lagrange interpolation), any K shares can reconstruct the secret. With fewer than K shares, there are infinitely many polynomials that fit — so no information leaks.
Secret s = 42 (constant term)
Polynomial: f(x) = 42 + 7x + 3x² (degree 2, so threshold = 3)
Share 1: f(1) = 52
Share 2: f(2) = 68
Share 3: f(3) = 90
Share 4: f(4) = 118
Any 3 shares → reconstruct f(x) → recover s = 42
Any 2 shares → infinitely many possible polynomials → s could be anythingCritical limitation of SSS: the secret must be reconstructed in one place to sign. During that reconstruction moment, the full private key exists in memory on a single device. That's a vulnerability window that multisig and MPC eliminate entirely.
Multisig Limitations
- Blockchain-specific: Bitcoin has native multisig (P2SH, P2WSH). Ethereum supports it via smart contracts (Gnosis Safe). But each chain implements it differently, and some chains don't support it at all.
- On-chain overhead: multisig transactions are larger (multiple signatures) and cost more in gas/fees.
- Rigid quorum: changing the M-of-N configuration requires creating a new wallet and migrating all assets.
- Transparency: the multisig structure is visible on-chain, revealing your security model to attackers.
4. MPC Wallets (Multi-Party Computation)
Why MPC Is Replacing Multisig
MPC solves every limitation of multisig while preserving the core benefit — no single party ever holds the complete key.
In an MPC wallet, the private key is never assembled. Not during creation, not during signing. Instead:
Key generation: multiple parties run a distributed key generation (DKG) protocol. Each party ends up with a key share. The full private key is never computed — it exists only as a mathematical relationship between the shares.
Signing: when a transaction needs to be signed, the parties run a threshold signature protocol. Each party contributes their share to produce a single, standard cryptographic signature. The shares never leave their respective holders.
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Party A │ │ Party B │ │ Party C │
│ Share a │ │ Share b │ │ Share c │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└──────────────┼──────────────┘
│
Threshold Signature
Protocol (off-chain)
│
▼
Single standard signature
(indistinguishable from
a normal single-key sig)MPC vs. Multisig: Side by Side
| Property | Multisig | MPC |
|---|---|---|
| Key existence | N independent full keys | Key never assembled; only shares exist |
| Signature output | Multiple signatures on-chain | Single standard signature |
| Blockchain support | Chain-specific | Blockchain-agnostic (ECDSA, EdDSA) |
| On-chain footprint | Larger TX, higher fees | Standard TX size, normal fees |
| Quorum rotation | New wallet + asset migration | Refresh shares, same address |
| Privacy | Multisig structure visible on-chain | Looks like a normal single-sig wallet |
| Operational flexibility | Fixed M-of-N | Dynamic policies, role-based approval |
Threshold Signature Schemes (TSS)
The specific MPC protocol used for signing is called a Threshold Signature Scheme. The most widely deployed are:
- GG18/GG20 (Gennaro-Goldfeder): the original practical threshold ECDSA protocol. Used by early MPC custody providers.
- CGGMP21 (Canetti-Gennaro-Goldfeder-Makriyannis-Peled): improved version with identifiable aborts — if a party misbehaves during signing, you can identify who did it.
- MPC-CMP (Fireblocks): proprietary improvement on CGGMP with faster signing rounds.
Key Refresh
One of MPC's killer features is key refresh. The parties can run a "refresh" protocol that generates new shares for the same underlying key. The old shares become useless. The wallet address doesn't change. This means:
- Regular rotation schedules (e.g., monthly share refresh)
- Immediate invalidation if a share is suspected compromised
- Personnel changes don't require moving assets to a new address
5. Hardware Security Modules (HSMs)
What They Are
An HSM is a dedicated physical device designed to securely store cryptographic keys and perform signing operations. The key material lives inside the HSM and, by design, cannot be extracted — even by the device's administrators.
Think of it as a tamper-proof safe that can do math. You send it a transaction to sign, it signs it internally, and returns the signature. The private key never leaves the device.
FIPS 140-2 Security Levels
The Federal Information Processing Standard (FIPS) 140-2 defines four levels of security for cryptographic modules. This is the standard exchanges reference when describing their HSM infrastructure.
| Level | Requirements | Physical Security |
|---|---|---|
| Level 1 | Approved cryptographic algorithms | None beyond production-grade components |
| Level 2 | Tamper evidence (seals, coatings) | Evidence of physical intrusion (doesn't prevent, just detects) |
| Level 3 | Tamper resistance + detection + response | Attempts to access keys trigger automatic key zeroization |
| Level 4 | Environmental failure protection | Protects against voltage/temperature attacks; highest physical security |
Level 3 is the industry standard for crypto exchanges. At this level, the HSM actively defends itself — if someone tries to physically tamper with the device (drill into the casing, probe the circuits), it detects the intrusion and wipes the key material before it can be extracted.
Level 4 adds protection against environmental attacks (manipulating temperature or voltage to cause the device to leak information), but the incremental cost is significant and the threat model is exotic enough that most exchanges stop at Level 3.
Note: FIPS 140-2 has been superseded by FIPS 140-3 as of 2019, with a transition period ongoing. New certifications are being issued under 140-3, but most existing exchange infrastructure still references 140-2 Level 3 certifications.
How Exchanges Use HSMs
Modern exchange architecture puts HSMs at every tier:
┌─────────────────────────────────────────┐
│ COLD STORAGE │
│ HSM in bank vault (air-gapped) │
│ Connected only during signing ceremony │
├─────────────────────────────────────────┤
│ WARM WALLETS │
│ Networked HSM in secure data center │
│ Policy engine gates signing requests │
├─────────────────────────────────────────┤
│ HOT WALLETS │
│ HSM cluster in exchange infrastructure │
│ Auto-signs within policy limits │
└─────────────────────────────────────────┘The most advanced setups combine MPC with HSMs: each MPC key share lives inside its own HSM. The MPC signing protocol runs between HSMs, so key shares are never exposed to general-purpose compute environments.
Major HSM Vendors
| Vendor | Product | Notes |
|---|---|---|
| Thales | Luna Network HSM | Widely used in financial services |
| Utimaco | CryptoServer | Popular in European markets |
| Futurex | Vectera Plus | Focus on payment and crypto |
| AWS | CloudHSM | Cloud-based, FIPS 140-2 Level 3 |
| Fortanix | DSM | Software-defined HSM using Intel SGX |
6. Signing Ceremonies
A signing ceremony is the physical, multi-person process of authorizing transactions from cold storage. It's deliberately slow, deliberately inconvenient, and deliberately witnessed.
What Happens During a Cold Wallet Signing
┌─────────────────────────────────────────────────────┐
│ SIGNING CEREMONY │
│ │
│ 1. Transaction is prepared on an online machine │
│ (destination, amount, fee — no keys involved) │
│ │
│ 2. Transaction data transferred to air-gapped │
│ device via QR code or USB (never network) │
│ │
│ 3. Quorum of signers assembles physically │
│ (e.g., 3 of 5 key holders) │
│ │
│ 4. Each signer authenticates to their HSM/device │
│ and reviews the transaction independently │
│ │
│ 5. Each signer produces their partial signature │
│ │
│ 6. Signatures are combined (multisig) or │
│ MPC protocol produces final signature │
│ │
│ 7. Signed transaction transferred back to │
│ online machine via QR/USB │
│ │
│ 8. Transaction broadcast to blockchain │
│ │
│ 9. Ceremony logged: who, what, when, where │
└─────────────────────────────────────────────────────┘Quorum Requirements
Typical cold storage quorum policies scale with transaction value:
| Transaction Value | Typical Quorum | Time Delay |
|---|---|---|
| < $100K | 2-of-3 (warm wallet, no ceremony needed) | Minutes |
| $100K - $1M | 3-of-5 signers | 1-4 hours |
| $1M - $10M | 4-of-7 signers + compliance review | 4-24 hours |
| > $10M | 5-of-8 signers + board notification | 24-72 hours |
Physical Security Controls
Signing ceremonies enforce:
- Dual control: no single person can access a signing device alone. Two or more people must be present to open the vault.
- Geographic distribution: key holders are in different physical locations (and sometimes different countries). This prevents coercion — an attacker would need to simultaneously compromise multiple locations.
- Air gap enforcement: signing devices have never been connected to a network. Transaction data moves via QR codes or verified USB drives.
- Video recording: the entire ceremony is recorded for audit purposes.
- Tamper-evident storage: HSMs and hardware wallets are stored in tamper-evident bags with unique serial numbers. Before each ceremony, the seal integrity is verified.
- Limited access: cameras and personal devices may be restricted during the ceremony to prevent key material leakage.
- Change management: every ceremony follows a pre-approved runbook. Deviations require additional authorization.
7. Institutional Custody Providers
Most exchanges don't build their entire custody stack from scratch. They use institutional custody platforms that provide the infrastructure — MPC protocols, HSM management, policy engines, and compliance tooling — as a service.
Provider Comparison
| Provider | Technology | Differentiator | Regulation |
|---|---|---|---|
| Fireblocks | MPC-CMP + SGX enclaves | Transfer network (800+ counterparties), fastest integration | SOC 2 Type II |
| Copper | MPC | ClearLoop off-exchange settlement | UK FCA registered |
| BitGo | Multisig + MPC | $250M insurance, regulated qualified custodian | NY Trust Charter, SOC 2 |
| Anchorage Digital | MPC | First OCC-chartered crypto bank | Federal bank charter |
| Coinbase Prime | Cold storage + hot | Trade without moving out of custody | NY Trust Company |
Fireblocks
Fireblocks has become the default infrastructure layer for institutional crypto operations. Their core offering:
- MPC-CMP protocol: a proprietary threshold signature protocol that improves on academic MPC schemes with faster signing (under 1 second).
- Intel SGX enclaves: MPC key shares run inside secure enclaves, adding a hardware layer of protection.
- Policy engine: configurable rules for approvals, whitelisting, velocity limits.
- Transfer network: a pre-authenticated network of 800+ counterparties (exchanges, OTC desks, banks) that eliminates the need to verify deposit addresses.
Over $6 trillion in digital assets have been transferred through Fireblocks. It's used by exchanges, banks, hedge funds, and payment companies.
Copper ClearLoop
Copper's unique proposition is off-exchange settlement. ClearLoop allows institutional traders to trade on partner exchanges (Binance, OKX, Deribit, etc.) without actually depositing funds on the exchange:
- Assets stay in Copper custody
- Trading positions are mirrored on the exchange
- Only net settlement amounts move between Copper and the exchange
- Counterparty risk is dramatically reduced
This solves the "exchange risk" problem — after FTX, institutions are reluctant to leave large balances on exchanges. ClearLoop lets them trade without that exposure.
BitGo
BitGo was one of the first institutional custody providers (founded 2013). Key attributes:
- Originally built on multisig, now also offers MPC
- $250M insurance policy through Lloyd's of London
- Regulated as a qualified custodian under South Dakota trust charter
- Went public on NYSE in January 2026
- Serves over 1,500 institutional clients
- Offers both hot and cold custody with configurable policies
Anchorage Digital
Anchorage holds the distinction of being the first (and as of 2025, one of very few) federally chartered crypto bank in the United States:
- OCC national trust bank charter (granted January 2021)
- Federal supervision provides a level of regulatory credibility that state charters don't
- Full MPC infrastructure with biometric authentication
- Staking, governance, and lending services alongside custody
- Primary clients: institutions requiring a U.S.-regulated qualified custodian
Coinbase Prime
Coinbase Custody (the custody arm of Coinbase Prime) is regulated as a New York limited purpose trust company:
- Segregated cold storage with insurance
- Allows institutions to trade on Coinbase exchange directly from custody
- Staking services for proof-of-stake assets
- One of the largest custodians by AUM — custodian for many Bitcoin ETFs
- SOC 1 Type II and SOC 2 Type II certified
8. Proof of Reserves
After FTX collapsed in November 2022, "Proof of Reserves" (PoR) became the industry's primary transparency mechanism. The idea: cryptographically prove that an exchange holds at least as many assets as it owes to users.
How It Works
PoR has two components:
1. Proving liabilities (what the exchange owes)
The exchange takes a snapshot of all user balances and constructs a Merkle tree:
Root Hash
/ \
Hash AB Hash CD
/ \ / \
Hash A Hash B Hash C Hash D
| | | |
User A User B User C User D
0.5 BTC 1.2 BTC 0.3 BTC 2.1 BTCEach leaf node contains a hashed version of: hash(user_id + salt + balance). The salt ensures privacy — other users can't reverse the hash to learn your balance. The tree is hashed upward until a single root hash represents the sum of all balances.
Individual verification: any user can verify their balance was included by checking their leaf against the Merkle root. The exchange provides a "Merkle proof" — the minimal set of hashes needed to recompute the path from your leaf to the root.
2. Proving assets (what the exchange actually holds)
The exchange demonstrates control of on-chain addresses by:
- Publishing wallet addresses and their balances (anyone can verify on-chain)
- Signing a message with each wallet's private key to prove ownership
- An independent auditor verifies:
total on-chain assets >= Merkle root total
Who Does It Well
| Exchange | Approach | Frequency |
|---|---|---|
| Binance | Merkle tree + on-chain proof, zk-SNARKs for non-negative balances | Periodic |
| Kraken | Independent auditor (CF Benchmarks), Merkle tree proof | Semi-annual |
| OKX | Merkle tree + zk-STARKs, open-source verifier | Monthly |
| Bitget | Merkle tree, 200%+ reserve ratio published | Monthly |
| Backpack | On-chain verifiable reserves | Ongoing |
Limitations
PoR is better than nothing, but it has real gaps:
Point-in-time snapshot: an exchange could borrow assets to pass the audit, then return them afterward. PoR doesn't prove continuous solvency.
Doesn't capture liabilities: an exchange might hold $5B in crypto but owe $7B in corporate debt, user obligations, or off-chain derivatives. Basic PoR doesn't show the full picture.
Off-chain assets are hard to verify: fiat balances, bank loans, and inter-company transfers aren't on a blockchain. You have to trust the auditor.
Exclusion attacks: an exchange could omit certain users from the Merkle tree to understate liabilities. If those users don't independently check, nobody catches it.
No proof of exclusive ownership: signing a message proves you know the private key — but it doesn't prove no one else also knows it, or that the assets aren't pledged as collateral elsewhere.
zk-SNARKs and zk-STARKs address some of these issues (particularly proving all balances are non-negative without revealing individual amounts), but they don't solve the fundamental problem of off-chain liabilities.
9. Historical Custody Failures
Every major exchange disaster is, at its core, a custody failure. Understanding what went wrong is the best way to understand why the security practices described above exist.
Mt. Gox (2011-2014) — $473M stolen
What happened: Mt. Gox, based in Tokyo, handled roughly 70-80% of all Bitcoin transactions at its peak. Between 2011 and 2014, hackers systematically drained 850,000 BTC (worth ~$473M at the time; worth over $50B at Bitcoin's all-time high).
Root cause: catastrophically poor key management. Mt. Gox kept the majority of its Bitcoin in a single hot wallet with no proper cold storage segregation. The private keys were stored on internet-connected servers without HSMs or multisig. An attacker gained access to the wallet's private key and siphoned funds over years without detection.
Lesson: no segregation between hot and cold storage, no monitoring of outflows against expected balances, no multi-party signing. The most basic custody controls would have prevented this.
Bitfinex (2016) — $72M stolen
What happened: on August 2, 2016, hackers stole 119,756 BTC ($72M at the time) from Bitfinex. The exchange used a 2-of-3 multisig setup with BitGo as a co-signer.
Root cause: the attacker (later identified as Ilya Lichtenstein) compromised Bitfinex's internal systems and found a way to bypass BitGo's independent co-signing. A critical implementation error: Bitfinex placed two of the three keys on the same infrastructure. The attacker gained access to security tokens that let him manipulate withdrawal limits, then submitted over 2,000 withdrawal transactions that appeared legitimate to BitGo's system.
Lesson: multisig is only as strong as the separation between key holders. If two keys live on the same device or network, you effectively have 1-of-1. Bitfinex also failed to implement operational controls recommended by BitGo.
QuadrigaCX (2019) — $190M lost
What happened: QuadrigaCX, Canada's largest exchange at the time, collapsed after its founder Gerald Cotten died unexpectedly in December 2018. The company claimed Cotten was the sole holder of cold wallet keys, and that $190M in customer assets were irrecoverably locked.
Root cause: single point of failure. One person held the keys. No backup key holders, no dead man's switch, no corporate key management policy. Subsequent investigation revealed that Cotten had been misusing customer funds well before his death — the cold wallets were largely empty.
Lesson: custody must never depend on a single individual. M-of-N quorums exist specifically to prevent this. QuadrigaCX also illustrates why Proof of Reserves matters — had customers been able to verify on-chain balances, the fraud would have been detected years earlier.
FTX (2022) — $8B+ in customer funds misused
What happened: FTX, then the third-largest exchange globally, filed for bankruptcy in November 2022. Customer deposits had been secretly transferred to Alameda Research (a trading firm also controlled by founder Sam Bankman-Fried) and used for speculative trading, venture investments, and personal expenses. An additional ~$400M vanished from exchange wallets the night of the bankruptcy filing.
Root cause: this wasn't a hack — it was fraud enabled by nonexistent custody controls. FTX had no board oversight of asset movements, no segregation of customer and corporate funds, no independent custody infrastructure. Bankman-Fried used a backdoor in FTX's accounting system to move billions without triggering internal alerts.
Lesson: custody controls aren't just about stopping external attackers. They must also constrain insiders. Proper custody means: segregated wallets for customer and corporate funds, multi-party approval for large movements, independent custodians, and real-time reconciliation between claimed balances and on-chain holdings.
Ronin Bridge (2022) — $620M stolen
What happened: on March 23, 2022, attackers (later attributed to North Korea's Lazarus Group) stole 173,600 ETH and 25.5M USDC from the Ronin Network bridge (used by the Axie Infinity game). The theft wasn't detected for six days.
Root cause: the Ronin bridge used a 5-of-9 validator multisig. The attackers compromised five validator keys — four belonging to Sky Mavis (the company behind Axie Infinity) and one from the Axie DAO. Sky Mavis had given the Axie DAO a temporary allowlist to sign transactions on its behalf (to handle heavy load), and that access was never revoked.
Lesson: validator key concentration defeats the purpose of multisig. If one entity controls enough keys to meet the threshold, the "multi" in multisig is theater. Also: temporary access must have automatic expiration, and anomaly detection should flag large outflows even if the signatures are technically valid.
Summary Table
| Incident | Year | Amount Lost | Root Cause |
|---|---|---|---|
| Mt. Gox | 2011-2014 | $473M (850K BTC) | Single hot wallet, no cold storage |
| Bitfinex | 2016 | $72M (120K BTC) | Multisig keys on same infrastructure |
| QuadrigaCX | 2019 | $190M | Single person held all keys |
| Ronin Bridge | 2022 | $620M | Validator key concentration (5/9 keys in one entity) |
| FTX | 2022 | $8B+ | No custody controls, insider fraud |
10. Regulatory Requirements
Custody regulation for crypto assets is still evolving, but several frameworks have solidified.
United States
SEC Custody Rule (Advisers Act Rule 206(4)-2)
Registered investment advisers (RIAs) must hold client assets with a "qualified custodian" — a bank, broker-dealer, futures commission merchant, or certain foreign financial institutions. The question for crypto: which entities qualify?
- State-chartered trust companies (like BitGo under South Dakota, Coinbase under New York) generally qualify
- Anchorage Digital's OCC national bank charter provides the strongest federal qualification
- The SEC proposed expanding the custody rule in 2023 to cover all assets (including crypto), but the rulemaking remains pending
SAB 121 and SAB 122
In 2022, SEC Staff Accounting Bulletin 121 (SAB 121) required companies that custody crypto to book those assets as liabilities on their own balance sheets. This made crypto custody economically impractical for banks (massive capital requirements). On January 23, 2025, the SEC rescinded SAB 121 and issued SAB 122, which allows custodians to apply standard accounting rules (GAAP/IFRS) to determine whether custodied assets belong on their balance sheet. This removed the primary barrier to bank participation in crypto custody.
State Trust Charters
Several states have created crypto-friendly charter frameworks:
| State | Charter Type | Notable Holders |
|---|---|---|
| New York | Limited Purpose Trust Company | Coinbase Custody, Gemini, Paxos |
| South Dakota | Trust Company | BitGo |
| Wyoming | Special Purpose Depository Institution (SPDI) | Kraken Financial, Custodia Bank |
| Nebraska | Digital Asset Depository Institution | Telcoin |
New York's framework is the most established. A NY limited purpose trust company can exercise fiduciary powers that a BitLicense holder cannot — a significant advantage for institutional custody.
Wyoming's SPDI charter is unique: it requires 100% reserves against deposits (no fractional reserve banking) and explicitly authorizes digital asset custody. Wyoming SPDIs may be able to operate in other states without additional licenses, though this hasn't been fully tested.
European Union — MiCA
The Markets in Crypto-Assets Regulation (MiCA) became fully effective on December 30, 2024. For custody, MiCA establishes:
- Authorization requirement: custody and administration of crypto-assets on behalf of clients is a regulated service. Only authorized Crypto-Asset Service Providers (CASPs) can provide it.
- Segregation: customer assets must be segregated from the CASP's own assets.
- Liability: CASPs are liable for loss of custodied assets, including from cyber incidents, unless they can prove the loss arose from external events beyond reasonable control.
- Governance: fit-and-proper requirements for management, robust organizational framework, business continuity plans.
- Outsourcing: CASPs can delegate custody functions but remain fully responsible. The sub-custodian must meet the same standards.
- Transitional period: some existing providers have until as late as June 30, 2026, to fully comply, depending on member state implementation.
Best Practices Beyond Regulatory Minimums
Regulation sets floors, not ceilings. The best exchanges go further:
| Practice | Regulatory Requirement? | Industry Best Practice |
|---|---|---|
| Multi-party signing (MPC/multisig) | Generally not specified | Universal among top exchanges |
| HSMs for key storage | Not mandated in most jurisdictions | Standard for any exchange >$100M AUM |
| Geographic distribution of keys | Not required | Common for cold storage |
| Proof of Reserves | Not required (except in some jurisdictions) | Increasingly expected post-FTX |
| Independent custody audit | Required for RIAs (SEC) | Recommended annually |
| Insurance on custodied assets | Not universally required | Available through Lloyd's, Aon, Marsh |
| Real-time reconciliation | Not specified | Essential for detecting commingling |
| Segregated customer wallets | Required (MiCA, most jurisdictions) | Non-negotiable |
The arc of crypto custody bends toward professionalization. The Wild West era — where one person on a laptop controlled billions in customer assets — is over. Modern custody combines layered wallet architecture, MPC cryptography, hardware security modules, physical signing ceremonies, independent audits, and regulatory oversight. None of these layers are optional. Each exists because an exchange, at some point, proved what happens without it.