Custody answers a practical question: who controls the keys or authorization needed to move bitcoin?
In a custodial account, a company or service controls those keys. The customer sees an account balance and can request a withdrawal, but the service decides whether and how the on-chain transaction is created.
In self-custody, the user or a user-defined setup controls the keys needed to authorize spending. The setup may involve one device, several keys, multiple people, a collaborative service, or a combination of tools. The common feature is that spending does not depend entirely on one custodian approving a withdrawal from its own wallet.
Self-custody is not a product category, a moral label, or a promise of safety. It is a custody arrangement with particular benefits, responsibilities, and failure modes.
Custody is about authorization
Bitcoin ownership is represented through spendable transaction outputs. Spending an output requires satisfying its locking conditions, usually with one or more valid signatures.
The party that controls the required private keys can authorize that spend. This is why custody is fundamentally about control of authorization, not about who installed an app or who appears as the account holder.
A person can use a wallet interface without controlling the underlying keys. A company can call an account a wallet while holding all spending authority. A user can also control keys through a setup that depends on software, hardware, backups, coordinators, or other people.
The interface matters, but it does not define custody by itself.
A custodial balance is a claim on a service
When a person deposits bitcoin with a custodian, the custodian usually combines or manages funds through its own wallet system. The customer's displayed balance is an internal record showing what the service owes or permits the customer to withdraw.
That arrangement may provide support, password recovery, account controls, compliance services, or simplified transactions. It also creates counterparty risk. The service may be hacked, become insolvent, freeze withdrawals, make an accounting error, change its rules, or be compelled to restrict access.
A customer may have a legal or contractual claim, but not direct cryptographic control of the relevant Bitcoin outputs.
This distinction does not make every custodian unsafe or every self-custody setup sound. It identifies where the spending authority and recovery process reside.
Self-custody shifts the failure boundary
Direct key control can reduce the risk that one company loses, freezes, or mismanages the bitcoin. It also removes some of the support that a company account can provide.
A self-custody wallet may not have a password-reset department capable of restoring access. If the required keys and recovery information are lost, the network cannot create a replacement. If secret material is exposed, another party may be able to spend the funds. If a transaction is authorized incorrectly, there may be no institution with authority to reverse it.
The risk has not disappeared. It has moved.
Self-custody replaces some counterparty dependence with operational responsibility. Whether that tradeoff is appropriate depends on the amount at risk, technical ability, recovery needs, privacy concerns, threat model, and personal circumstances.
Self-custody is a spectrum of arrangements
The phrase self-custody can suggest one person holding one key on one device. That is only one arrangement.
A single-signature arrangement requires one authorized signature for each applicable spending path. A hierarchical deterministic wallet may still derive many distinct signing keys over time, but one signer or one underlying recovery arrangement controls them. This can be relatively simple to understand and recover, while the signer and recovery information may remain concentrated points of failure.
A multisignature setup can require a threshold of several keys. A two-of-three arrangement, for example, may allow spending when any two of three authorized keys sign. This can reduce dependence on one device or one backup, but it adds coordination, configuration, compatibility, and recovery complexity.
A collaborative arrangement may distribute keys between the user and one or more service providers. The user may retain enough control to prevent unilateral spending by the service, while the service helps with coordination or recovery. The exact rights and dependencies depend on the threshold, key locations, software, policies, and contract.
Some arrangements use time delays, inheritance procedures, organizational approvals, or geographically separated signers. These designs solve different problems. They should not all be treated as equivalent forms of self-custody.
Single-signature arrangements
A single-signature setup can be appropriate when simplicity is the main priority and the risks are understood.
The wallet may derive many addresses and signing keys from one underlying backup. That does not mean every address uses the same private key. Hierarchical deterministic wallets can derive a tree of related keys from seed material.
The main advantage is a smaller coordination burden. The user needs to understand one wallet arrangement and preserve the information required to recover it.
The main weakness is concentration. Loss or exposure of the key material, backup, or required recovery information can become decisive. A device failure may be manageable if the backup is correct and compatible. A backup failure may not be.
Single-signature does not mean careless, and multisignature does not automatically mean secure. Each arrangement must be evaluated against its own threat model.
Multisignature arrangements
Multisignature uses a spending condition that requires a defined threshold of multiple keys.
This can reduce some single points of failure. One lost device may not prevent recovery. One compromised key may not be enough to spend. Several people or locations can share authorization responsibility.
The added resilience comes with added information requirements. Recovery may depend not only on seed material, but also on the full wallet configuration, public keys, key origins, derivation paths, script type, threshold, and signer order. The participants need compatible tools and a clear process for verifying the setup.
A misconfigured multisignature wallet can produce addresses that signers do not recognize or cannot later reconstruct. A coordinator can provide incorrect transaction information. A service used for collaboration may become unavailable. Signers can lose track of which backup belongs to which wallet.
Standards such as Partially Signed Bitcoin Transactions, output script descriptors, and Bitcoin Secure Multisig Setup can improve interoperability and verification. They do not remove the need to understand what must be preserved.
Hardware signing devices reduce specific risks
A hardware signing device is designed to keep private keys in a restricted signing environment. It can receive transaction information from another device, show details for approval, and return signatures without directly exporting the private keys.
This can reduce exposure to malware on a general-purpose computer or phone. It does not eliminate every risk.
The device may display incomplete or misleading information if the surrounding software constructs a confusing transaction. The user may fail to verify the destination or amount. Firmware, manufacturing, transport, initialization, and update processes create supply-chain and implementation dependencies. The device can be damaged or lost. Recovery material can be exposed even when the device remains secure.
The meaningful question is which risks the device reduces and which risks remain elsewhere in the setup.
Backup, recovery, and testing are separate concerns
A backup preserves information needed to recover access. Recovery is the process of using that information with compatible tools and the correct wallet configuration. Recovery testing checks whether the process works before an emergency.
These are related but distinct.
Many wallets present a sequence of words, often called a seed phrase or recovery phrase. BIP 39 defines one mnemonic system, but not every wallet uses BIP 39. A phrase may be combined with a passphrase, derivation scheme, account index, script type, or multisignature configuration.
A backup can be complete for one wallet and incomplete for another. A phrase that recreates the key tree may still fail to identify the expected addresses if the restoring wallet uses different derivation or script assumptions. A multisignature setup may require public configuration data from the other signers.
Testing can reveal missing information, but a careless test can also expose secrets or create confusion. The method should match the setup and avoid turning a backup check into a new security problem.
Device security is not backup security
The device used for daily access and the backup used for recovery face different risks.
A phone or computer may be exposed to malware, theft, remote access, weak authentication, or accidental deletion. A hardware signer may be exposed to physical tampering, malicious firmware, a deceptive host interface, or loss.
A backup may be exposed to fire, water, copying, photography, coercion, poor labeling, accidental disposal, or discovery by someone who should not have access.
Protecting one layer does not automatically protect the others. A strong device cannot compensate for a plainly exposed recovery phrase. A durable backup cannot prevent a user from authorizing a malicious transaction. A multisignature threshold cannot help if all backups are stored together and compromised at once.
Privacy, physical security, and inheritance are separate layers
Self-custody decisions also affect information beyond the keys.
A wallet connected to a third-party server may reveal addresses or transaction relationships. A watch-only setup may improve operational separation while exposing public wallet data to whoever operates the server. Address reuse can make activity easier to connect.
Physical security concerns who can access devices, backups, or locations. It also includes the risk of drawing attention to the existence or value of a custody setup.
Inheritance asks whether another person can identify the assets, understand the wallet arrangement, find the required information, and act without exposing it prematurely. A technically secure setup that no successor can recover may fail its continuity goal.
These concerns interact, but solving one does not solve all of them. A custody plan should name the problem it is designed to address.
Collaborative custody changes, rather than removes, trust
Some setups combine user-controlled keys with a service that coordinates transactions, holds one key, assists recovery, or enforces policies.
This can reduce the chance that one lost key causes total loss. It can also add a service dependency. The provider may learn wallet information, become unavailable, change fees, restrict access, or fail to support a future recovery process.
The threshold determines whether the service can spend alone, block spending, or merely assist. The software and recovery documentation determine whether the user can continue without the service.
Collaborative custody should be described by its actual key and authorization structure. The label does not tell the whole story.
A threat model keeps the decision grounded
A threat model is a defined view of the assets, adversaries, capabilities, failure modes, and assumptions relevant to a security decision.
For self-custody, useful questions include:
- What amount and time horizon are involved?
- Which failures are most plausible: theft, loss, coercion, device compromise, service failure, or user error?
- Who needs access now, and who may need access later?
- What technical procedures can the participants perform reliably?
- Which dependencies are acceptable?
- What information must remain private?
- How will the arrangement be maintained as devices, software, and people change?
A setup designed for an experienced organization may be inappropriate for a first-time user. A simple setup may be more robust than a complex one that no participant can recover correctly.
No custody arrangement is universally correct. The goal is not maximum complexity. It is a setup whose tradeoffs are understood and whose procedures can be followed.
Self-custody without mythology
Self-custody can provide direct control and reduce reliance on a custodian. It does not remove trust from software, hardware, standards, documentation, communication, or human judgment.
It can reduce one single point of failure while creating several coordination points. It can improve privacy in one arrangement and weaken it in another. It can make inheritance more deliberate or more difficult.
The useful distinction is not responsible people versus irresponsible people, or freedom versus failure. It is where authorization sits, which dependencies remain, and what recovery process exists.
The next guide turns from custody structure to transaction practice. How to Send and Receive Bitcoin explains the checks involved in generating receiving information, reviewing a destination, authorizing a spend, broadcasting a transaction, and waiting for confirmation.