What is crypto custody?

Crypto custody is an arrangement for controlling and safeguarding the keys, key shares or other authorization mechanisms used to manage crypto assets. The assets remain represented under a blockchain's rules. Custody concerns who can authorize a transaction, how that authority is protected and recovered, and how a service records and governs its use.

This is an operational definition, not a legal conclusion. Whether a particular arrangement is legally classified as custody, who owns an asset, how customer claims rank and which rules apply can depend on the jurisdiction, contract and account structure.

Custody begins with an authorization map

Many blockchains accept digital signatures as evidence that a key-controlled action has been authorized. Other accounts may use several keys, smart-contract rules or recovery roles. A custody design therefore needs an explicit map of:

• what onchain account or spending condition controls the asset;
• which keys, shares, roles or contracts can satisfy that condition;
• how many approvals are required and under which policy;
• who can change the policy, replace signers or start recovery; and
• which systems can construct, approve, sign and broadcast a transaction.

The wallet interface is only one component. The person who can view a balance or prepare a withdrawal may not control the signing authority. Conversely, a provider can control signing while never showing the underlying keys to the customer. NIST IR 8202 describes how private keys and signatures authorize blockchain transactions, while NIST IR 8301 distinguishes direct, third-party and partial custody models. NIST IR 8202 and NIST IR 8301

From a customer instruction to an onchain transaction

A managed custody workflow can include:

1. creating or assigning deposit addresses;
2. generating keys or key shares and recording their authorization roles;
3. attributing deposits to customer or internal accounts;
4. screening a withdrawal instruction against access and transaction policies;
5. constructing and independently verifying the destination, network, amount and fee data;
6. collecting the required approvals or shares;
7. signing and broadcasting the transaction; and
8. reconciling the blockchain result with internal records.

These stages can be split among staff, services and isolated environments. An online system may receive a request, a policy engine may approve it, and a separate signer may authorize only the resulting transaction digest. Separation can limit one component's authority, but it is effective only if credentials, approval channels and recovery paths are also separated.

A provider may maintain an internal ledger showing customer entitlements while controlling one or more onchain addresses. An internal transfer between customers may update that ledger without immediately creating an onchain transaction. The internal balance, the onchain address balance and the customer's contractual rights are different records that need reconciliation; none can be inferred completely from another.

Self-custody, third-party custody and divided control

Self-custody

In self-custody, the user controls the keys or account authorization arrangement rather than entrusting that authority to a service. This reduces dependence on a custodian for transaction approval, but backup, recovery and verification responsibilities remain with the user or the user's chosen setup. Losing all required authorization and recovery material can make the account inaccessible.

Third-party custody

In third-party custody, a provider controls the signing process or other authority needed to act on an account and processes customer instructions. The customer may use a service login without receiving the blockchain keys. Access and withdrawals then depend on the provider's controls, records, availability and contractual terms.

Shared or partial custody

Authority can be divided between a customer, provider or additional parties. The label “shared” is incomplete without the threshold and recovery rules. A 2-of-3 arrangement, for example, behaves differently depending on who holds each signer, whether one party can replace another and which approvals are required during recovery.

These models describe control, not product format. A mobile interface can connect to any of them, and a hardware signer can be used in self-custody or as one component of an institutional process.

Multisignature, threshold signing and smart accounts

Several mechanisms can distribute authority:

• Onchain multisignature requires multiple independently verifiable signatures or approvals under the account or script rules. The blockchain can often observe the authorization structure.
• Threshold cryptography divides signing capability into shares that jointly produce a signature. Depending on the scheme, the blockchain may see one ordinary-looking public key and signature rather than each share.
• Smart-contract accounts enforce authorization and recovery logic in code. They may support guardians, spending limits, session keys or other policies that do not map to one permanent private key.

These approaches have different failure and audit properties. A threshold number says how many shares are mathematically necessary, but not whether they are held by independent people, devices or organizations. A multisignature policy can still have a weak recovery path. A smart account can introduce contract, upgrade or governance dependencies. The mechanism name alone does not establish separation of duties.

Hot and cold describe access paths, not who has custody

Hot and cold storage answer how readily signing authority is connected to online systems:

• Hot signing keeps an authorization path available to online services, reducing operational delay but increasing exposure to software, credential and network compromise.
• Cold signing keeps key material or signing devices more isolated for longer periods, reducing some online exposure while adding physical access, transfer, verification and recovery procedures.

A custody platform can combine a limited hot path for routine processing with a more isolated path for other transactions. Cold storage does not prove that request intake, address verification, software updates, backups or recovery are secure. Likewise, hot storage does not describe who legally or operationally controls the account.

NIST SP 800-57 treats generation, storage, use, backup, recovery, revocation and destruction as distinct parts of a key lifecycle. The Bitcoin wallet guide illustrates one implementation pattern in which an online system prepares transactions and an offline wallet signs them. NIST SP 800-57 Part 1 and Bitcoin Developer Guide: wallets

Where a custody arrangement can fail

Custody reallocates risks; it does not remove them:

• Generation or backup failure: weak randomness, incomplete backups or loss of required shares can make authority unsafe or unavailable.
• Authorization compromise: an attacker or insider with enough credentials, shares or policy privileges may authorize an unwanted transaction.
• Transaction-substitution error: a legitimate approval process can sign the wrong network, destination, amount or contract instruction if verification is incomplete.
• Policy and recovery bypass: emergency, signer-replacement or account-recovery procedures can become a weaker route than ordinary signing.
• Software and infrastructure failure: wallet, node, policy-engine or reconciliation faults can delay, duplicate or misdirect processing.
• Record mismatch: internal entitlements can diverge from controlled onchain assets if deposits, withdrawals, fees or chain events are recorded incorrectly.
• Service dependency: outages, insolvency, freezes or contractual restrictions can affect access even when blockchain keys still exist.

No single public signal proves the whole system works. A cold-storage percentage does not describe recovery controls. A multisignature address does not show whether signers are independent. A proof-of-reserves result, considered on its own, does not establish the completeness of customer liabilities, legal asset segregation or each customer's withdrawal rights. Those questions require additional records, scope and assumptions.

What custody does not determine

Custody is not the same as wallet software, blockchain ownership or asset segregation:

• an application can display an account without controlling it;
• a service can control signing while pooling assets in addresses also used for other customers;
• separate addresses do not by themselves establish legally segregated assets; and
• controlling a key does not determine every contractual or beneficial-ownership question.

These distinctions are why technical architecture, internal accounting and legal terms need to be evaluated separately.

FAQ

Does a custodian store crypto assets offchain?

Blockchain state records the assets and onchain transactions. A custodian controls keys or other authorization mechanisms and may maintain a separate internal ledger. Some customer-to-customer transfers can be reflected internally before or without an immediate onchain transaction, depending on the arrangement.

Is a custodial wallet the same as any hosted wallet interface?

No. The relevant question is who controls the signing authority or account permissions. A hosted interface can display an account without holding its keys, while a provider can control signing through systems that are not visible in the interface.

Does cold storage remove custody risk?

No. Isolation can reduce some online attack paths, but physical security, transaction verification, staff access, backups, software integrity and recovery procedures still matter.

Related reading

Read about crypto wallets, private keys, public keys, seed phrases, hot wallets and cold wallets, or return to the Crypto Glossary.

For a broader comparison of wallet delivery and storage labels, see the existing OKX Learn article Types of crypto wallets. It is further reading, not an authoritative source for the custody definition above.

Sources

• NIST IR 8301: Blockchain Networks — Token Design and Management Overview — wallet, key-management and direct, third-party and partial custody models.
• NIST IR 8202: Blockchain Technology Overview — private keys, digital signatures and blockchain records.
• NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management — key lifecycle, protection, backup and recovery principles.
• Bitcoin Developer Guide: wallets — separation of online transaction preparation, offline signing and wallet backup.