Institutional crypto custody is not simply “cold storage.” It is a control system for generating keys, authorizing transactions, segregating client assets, recovering from failures, reconciling records, and proving who can move value. A secure cryptographic design can still be undermined by weak governance, unclear legal title, concentrated vendors, or an operational process that fails during a market event.

Private keys determine who can authorize blockchain transactions. Legal custody determines which entity holds assets for whom, under what agreement, and with what obligations. Those layers often align, but not always. A client may have a contractual claim against a custodian that delegates key operations to a technology provider or subcustodian. A multisignature wallet may include keys controlled by several organizations.

Ask two parallel questions: who can technically move the asset, and who is legally responsible for safeguarding it? Then map the connection between them. The answer should cover subcustody, insolvency, errors, unauthorized transfers, and dispute resolution. A wallet address alone cannot establish the client’s legal rights.

Key generation and provenance

Security begins when keys are created. Institutions should document the hardware, software, entropy sources, physical environment, personnel, and ceremony used for generation. Hardware security modules, multiparty computation, and offline devices can protect key material, but their effectiveness depends on implementation and governance. A compromised random-number source or unverified device can defeat later controls.

Key provenance should be auditable without exposing secret material. Records can show which approved system generated each key, which policies applied, and whether test procedures succeeded. Changes in vendors or wallet architecture require controlled migration. An institution that cannot explain how a key came into existence has a weak foundation for every transaction signed by it.

Signing policies and separation of duties

A transaction policy can require several approvals based on asset, amount, destination, time, or risk score. One employee should not be able to create a withdrawal request, approve it, alter the allowlist, and release the transaction. Separation of duties reduces both fraud and accidental loss. It also creates evidence for auditors and investigators.

Multisignature and multiparty-computation systems distribute signing authority, but threshold numbers alone do not show independence. Three keys stored in the same cloud account or managed by the same team can fail together. Review geographic, technical, organizational, and vendor diversity. Emergency access should be possible without making routine controls meaningless.

Hot, warm, and offline tiers

Institutions often hold a small operational balance in systems capable of rapid signing and keep larger reserves behind slower controls. The names hot, warm, and cold are less important than the actual connectivity and approval path. An “offline” wallet whose recovery material is photographed, copied to a shared drive, or accessible to one insider is not meaningfully protected.

Tiering should reflect withdrawal needs, settlement deadlines, and the cost of delayed access. Rebalancing between tiers is itself a sensitive operation. Define limits, frequency, approval, destination verification, and monitoring. A liquidity plan should account for weekends, chain congestion, network upgrades, and emergency pauses.

Segregation and on-chain address structures

Assets can be held in individually assigned addresses, omnibus wallets, or a combination. Individual addresses can simplify attribution, while omnibus structures can improve operational efficiency and privacy. In either case, the custodian’s internal ledger must reconcile to on-chain balances and client entitlements.

On-chain segregation does not automatically produce bankruptcy segregation, and omnibus storage does not automatically mean client assets are commingled legally. Read the custody agreement and applicable law. Determine whether the custodian may lend, pledge, or rehypothecate assets and whether customer consent is required. The accounting and legal structure must support the public claims.

Deposits, withdrawals, and address risk

Deposit systems need network confirmation rules, chain-reorganization handling, token-contract validation, and screening for unsupported assets. Withdrawal systems need destination verification, allowlists, risk checks, fee management, and controls for address poisoning or clipboard substitution. Human-readable address books can reduce mistakes but create another database that must be protected.

Test transfers are useful for unusual destinations or new networks. Institutions should also consider whether a token has transfer restrictions, memo fields, destination tags, or smart-contract behavior. Sending the correct amount to a syntactically valid but operationally incompatible address can cause a loss that cryptography cannot reverse.

Recovery, continuity, and key loss

A custody system must survive staff turnover, hardware failure, site loss, vendor outage, natural disaster, and the unavailability of key personnel. Recovery materials should be redundant enough to prevent permanent loss but protected enough to prevent unauthorized reconstruction. Procedures need periodic testing under observation, not merely a sealed envelope that everyone hopes will work.

Business-continuity plans should cover blockchain-specific events: forks, validator incidents, congestion, halted withdrawals, contract migrations, token swaps, and airdrops. Decide in advance which assets and events the custodian supports. Silence can create disputes when clients expect a benefit that the operating model cannot safely claim.

Subcustody and vendor concentration

A named custodian may rely on wallet software, cloud providers, hardware vendors, transaction-screening firms, key-management specialists, and other custodians. Subcustody can expand geographic or asset coverage, but it can make responsibility harder to see. The institution should maintain a complete vendor map and understand which failures could affect several assets or accounts at once.

Review service-level agreements, audit rights, incident notification, data portability, exit assistance, and the ability to migrate keys or assets. Vendor lock-in becomes a risk when a custodian cannot move without operational disruption. Concentration also matters at the industry level: several providers may depend on the same cloud region or wallet technology.

Insurance is narrow and conditional

Insurance may cover specific theft events, employee dishonesty, or physical damage. It may exclude protocol failures, market losses, social engineering, unauthorized client instructions, or losses above an aggregate limit. The policyholder may be the custodian, not each client, and recovery can depend on deductibles, exclusions, and claims procedures.

Request a clear description of covered events, limits, allocation among clients, insurers, and policy periods. Treat insurance as one recovery resource rather than a substitute for prevention. A headline dollar amount can be misleading when compared with total assets held or when several clients share the same limit.

Proof, reconciliation, and reporting

Daily controls should reconcile blockchain balances, internal ledgers, pending deposits, pending withdrawals, fees, and client positions. Differences need escalation and aging rules. Signed-message proofs or proof-of-reserves techniques can demonstrate control of selected addresses, but they do not by themselves prove complete liabilities, legal ownership, or freedom from encumbrances.

Institutional reporting should identify asset, network, quantity, valuation source, transaction status, and relevant restrictions. Auditors need access to policies, logs, approvals, vendor reports, and exception handling. A transparent custody operation can explain not only where assets are, but also how each material movement was authorized.

Counterparty and insolvency analysis

Custody agreements should state the client’s property interest, the custodian’s permitted use, subcustodian authority, governing law, and treatment after insolvency. Operational segregation is helpful, but enforceability depends on contracts and law. Clients should understand whether they would seek return of specific property or file a general claim.

The SEC investor bulletin on holding securities explains traditional distinctions between direct registration, street name, and physical certificates. Crypto custody uses different technology, but the underlying lesson is relevant: the form in which an asset is held affects rights, records, and intermediary exposure. Product-specific legal review remains essential.

An institutional review checklist

Control the keys

Document generation, storage, signing thresholds, administrative access, transaction policy, recovery, and testing. Confirm independence among approvers and resilience against common-mode failure.

Control the legal chain

Identify the contracting custodian, every subcustodian, asset segregation, permitted use, insolvency treatment, insurance, and dispute forum. Reconcile those terms with marketing statements.

Control operations

Review reconciliations, incident history, business continuity, vendor concentration, network support, reporting, audit evidence, and migration plans. Size balances according to the weakest control and the time needed to recover or transfer assets.

Bottom line

Institutional custody combines cryptography, operations, law, and counterparty management. Cold storage is useful but incomplete. Strong custody demonstrates how keys are generated, how transactions are approved, how client entitlements reconcile to on-chain assets, how recovery works, and what happens if a provider fails. The best review follows every authority and dependency from the investment committee to the final signature on the blockchain.