How Does Bitcoin Custody Work?

By Blockstream Engineering · Last updated June 2026

What Is Bitcoin Custody?

In traditional finance, custody is an administrative function. A bank holds your dollars, a broker holds your shares, and regulatory frameworks define the obligations of each custodian. You own the asset on paper, but a third party controls access to it in practice.

Bitcoin custody is fundamentally different. Bitcoin has no registrar, no transfer agent, no central ledger maintained by an institution. Ownership is defined by one thing: control of the private key that can authorize a transaction. If you control the key, you control the bitcoin. If someone else controls the key, they control the bitcoin. There is no institution to appeal to, and once a transaction is authorized it cannot be reversed.

Key-based ownership creates both a powerful form of sovereignty and a serious responsibility. The same property that makes Bitcoin resistant to seizure and censorship also means that a lost key is lost bitcoin, permanently. An estimated 3 to 4 million bitcoin (about 14 to 19 percent of the 21 million total supply) are believed to be permanently inaccessible due to lost private keys; Chainalysis estimated around 3.7 million as of 2020.

Custody, then, is the most consequential decision in Bitcoin security. It determines who can spend your bitcoin, what conditions must be met before a transaction is authorized, and what happens if a key is lost, stolen, or compromised.

This article covers custody from an individual holder's perspective: how to control your own keys and choose a setup that fits the amount you hold. Businesses and institutions build on these same fundamentals with multi-party governance, qualified custodians, and compliance controls, covered separately in How Do Businesses and Institutions Take Custody of Bitcoin?

Under the Hood: The UTXO Ownership Model

Bitcoin does not use account balances the way a bank does. Instead, ownership is tracked through unspent transaction outputs (UTXOs). When someone sends you bitcoin, the network creates a UTXO: a specific amount of bitcoin locked to a script condition (called a scriptPubKey) that typically requires a valid signature from the corresponding private key to spend. Your "balance" is the sum of all UTXOs whose spending conditions your keys can satisfy.

Each UTXO is independent. A wallet holding 1.5 bitcoin might actually hold three separate UTXOs: one of 0.8 BTC received on Monday, one of 0.5 BTC received last month, and one of 0.2 BTC received as change from a previous transaction. When you spend, the wallet selects enough UTXOs to cover the amount plus the fee, constructs a transaction that consumes those UTXOs entirely, sends the intended amount to the recipient, and returns any excess to a change address you control. The consumed UTXOs are destroyed, and new UTXOs are created for the recipient and for your change.

This model has a direct implication for custody: controlling a private key does not give access to an "account." It gives the ability to satisfy the spending conditions of specific UTXOs on the blockchain. Custody infrastructure must track which UTXOs belong to which keys and which derivation paths, especially in institutional settings where multiple accounts, multiple signers, and segregation requirements apply.

Keys: The Foundation of Custody

Every Bitcoin address corresponds to a cryptographic key pair: a private key and a public key. Understanding how these keys work, how they are generated, and how they are managed is the starting point for understanding custody.

Private Keys and Public Keys

A private key is a 256-bit number, essentially a very large random number. It looks something like this in hexadecimal:

e9873d79c6d87dc0fb6a5778633389f4453213303da61f20bd67fc233aa33262

This number is the secret. Whoever knows this number can spend the bitcoin associated with it. The private key must be kept secret, backed up securely, and never exposed to an internet-connected device unless absolutely necessary (and ideally, never at all).

A public key is derived mathematically from the private key using elliptic curve multiplication. This is a one-way operation: the public key can be computed from the private key, but the private key cannot be reverse-engineered from the public key. The public key (or a hash of it) forms the basis of a Bitcoin address, which can be shared openly for receiving bitcoin.

The relationship works like a mailbox. The Bitcoin address (derived from the public key) is the slot where anyone can drop in bitcoin. The private key is the key that opens the box. Without it, the bitcoin sits there, visible on the blockchain but entirely inaccessible.

Key Generation: Entropy and Randomness

The security of a private key depends entirely on the quality of randomness used to generate it. A 256-bit key space contains roughly 10⁷⁷ possible keys, a number comparable to the estimated number of atoms in the observable universe. Brute-forcing a properly generated key is computationally infeasible.

But "properly generated" is the critical qualifier. If the random number generator is predictable, biased, or flawed, the effective key space shrinks, sometimes catastrophically. This is why modern Bitcoin wallets use cryptographically secure random number generators that pull entropy from hardware-level sources: thermal noise, interrupt timing, CPU jitter, and other physical processes that resist prediction.

Most wallets today follow BIP-39, which converts the raw entropy into a human-readable recovery phrase (typically 12 or 24 words drawn from a standardized 2,048-word list). This recovery phrase encodes the entropy that generates the master private key, from which all subsequent keys in the wallet are derived using a hierarchical deterministic (HD) structure defined by BIP-32. The result is that a single recovery phrase can regenerate an entire wallet with all its addresses and keys.

Key Management at Scale (Institutional)

For individuals, key management typically means writing a recovery phrase on paper or metal and storing it securely. For institutions managing hundreds of millions of dollars in bitcoin, the requirements are categorically different.

Hardware security modules (HSMs) are purpose-built devices that generate, store, and use cryptographic keys in tamper-resistant hardware. When a signing request arrives, the HSM performs the cryptographic operation internally and returns only the signed transaction. The private key never leaves the device in exportable form. These HSMs achieve FIPS 140-2 Level 3 or Level 4 certification, meaning they resist physical tampering, environmental attacks, and side-channel analysis.

Key ceremonies are formal, audited procedures for generating new keys or reconstituting key material. A typical key ceremony involves multiple authorized personnel, each holding a portion of the key or a separate authentication credential, gathering in a physically secured room with no network connectivity. The ceremony is recorded and witnessed, with documentation kept for compliance purposes. Every step follows a pre-approved script.

Geographic distribution adds physical separation as a security layer. An institution might store key material across three or more data centers in different cities, states, or countries. No single location holds enough material to authorize a transaction independently. This defends against natural disasters, facility compromises, and jurisdictional risks.

Multi-Party Computation (MPC)

MPC takes a fundamentally different approach to key security. Instead of generating a complete private key and then splitting it into shares, MPC distributes the key generation process itself across multiple independent parties. Each party contributes randomness to a joint computation, and at the end, each party holds a share of the key, but no party (and no single device) ever possessed or computed the full private key at any point.

When a transaction needs to be signed, the parties engage in a multi-round cryptographic protocol that produces a valid signature without ever reconstructing the full key. Each party uses its share to contribute a partial computation, and the protocol combines these into a final signature that is indistinguishable from a standard single-key signature on the blockchain.

MPC offers a distinct advantage for institutions: it eliminates the single-point-of-failure risk that exists during traditional key generation. There is no moment where the full key exists in one place. The trade-off is protocol complexity and the need for reliable communication channels between the parties each time a transaction is signed.

Signatures: How Keys Authorize Transactions

A private key, on its own, does nothing. It becomes useful only when it produces a digital signature that authorizes a Bitcoin transaction. The signature proves to the network that the holder of the private key has approved the transfer without revealing the private key itself.

ECDSA Signatures

Bitcoin launched with the Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve. ECDSA has been the workhorse of Bitcoin signing since the genesis block in 2009.

The signing process works as follows: the wallet software constructs a transaction (specifying inputs, outputs, amounts, and fees), hashes it, and passes the hash to the signing device along with the private key. The algorithm produces a signature, a pair of numbers (r, s), that anyone can verify using the corresponding public key. The verification proves two things: that the signer possessed the private key, and that the transaction has not been modified since it was signed.

ECDSA signatures are 70-72 bytes each (variable-length DER encoding), and each input in a transaction requires its own signature. For standard singlesig transactions, this is straightforward. For multisig, the transaction must include multiple ECDSA signatures (one per required signer), which increases transaction size and, consequently, the fee.

Schnorr Signatures

The Taproot upgrade (activated in November 2021 via BIP 340, BIP 341, and BIP 342) introduced Schnorr signatures to Bitcoin. Schnorr offers several mathematical properties that ECDSA lacks, the most significant being linearity: Schnorr signatures can be added together.

This linearity enables key aggregation. Multiple signers can combine their public keys into a single aggregated public key and produce a single aggregated signature that is valid for that combined key. On the blockchain, this aggregated signature looks identical to a standard single-key signature. The result is smaller transactions, lower fees, and improved privacy, because external observers cannot distinguish a multisig spend from a singlesig spend.

Schnorr signatures are 64 bytes each (smaller than ECDSA), and because key aggregation collapses multiple signatures into one, the efficiency gains compound in multisig setups. When all signers cooperate, a MuSig2 key-path spend (which is n-of-n) occupies the same blockchain space as a singlesig transaction. A true threshold scheme like 3-of-5 requires either FROST (still maturing in Bitcoin tooling) or a Tapscript fallback using multiple script leaves, each containing a different 3-of-5 combination. The key-path spend only applies when all five signers participate; the threshold cases fall back to Tapscript, which is still more efficient than legacy P2SH multisig but not identical in size to singlesig.

Hardware Signing and Institutional Security

For both individual and institutional users, the most security-critical moment in the custody lifecycle is the signing operation. This is the instant when the private key is actively used, and it is the moment of greatest vulnerability.

A hardware wallet like the Jade Plus stores your private key on a dedicated device with air-gapped QR code signing, ensuring the key never touches an internet-connected device. The transaction is constructed on the companion app, displayed as a QR code, scanned by the Jade Plus camera, signed internally, and returned as a signed QR code. At no point does the private key leave the device.

For institutions, the same principle applies at a larger scale. HSMs perform signing inside FIPS-certified tamper-resistant hardware. Access to the HSM requires multi-factor authentication, and signing operations are governed by policy engines that enforce approval workflows, spending limits, time-locks, and role-based permissions. The HSM logs every operation for audit trails.

Custodial vs. Self-Custodial

Every custody arrangement falls somewhere on a spectrum between two poles: a third party holds your keys (custodial), or you hold your own keys (self-custodial). Each model carries distinct trade-offs in security, convenience, sovereignty, and risk.

Custodial: A Third Party Holds Your Keys

When you buy bitcoin on an exchange and leave it there, the exchange holds the private keys. You have an account balance displayed on a screen, but you do not have direct control over the bitcoin itself. The exchange can freeze your account, restrict withdrawals, or lose your funds through a hack, insolvency, or regulatory action.

The history of Bitcoin is littered with custodial failures. Mt. Gox collapsed in 2014 with approximately 850,000 bitcoin reported missing (about 200,000 were subsequently recovered, leaving a net loss of ~650,000 BTC). QuadrigaCX collapsed in 2019 after its founder died; an Ontario Securities Commission review later found the platform had operated as a fraud, leaving roughly $190 million in customer funds unrecoverable. FTX imploded in 2022 when customer funds were misappropriated. Each reinforced the maxim: "Not your keys, not your bitcoin".

Custodial arrangements are not inherently bad. They make sense when regulatory requirements demand them (as with ETFs and certain fund structures), when an organization lacks the technical expertise for self-custody, or when convenience outweighs the counterparty risk for small amounts. The key is understanding what you are giving up: direct control over your bitcoin, and the ability to move it without anyone's permission.

Self-Custodial: You Hold Your Own Keys

Self-custody means you control the private keys directly. No third party can freeze your funds, deny a withdrawal, or lose your bitcoin through their own mismanagement. You have full sovereignty over your assets.

The Blockstream app provides a self-custodial wallet that supports Bitcoin, Liquid, and Lightning from a single interface. For cold storage, it connects to the Jade Plus hardware wallet for air-gapped signing. For everyday transactions, it functions as a standalone wallet with built-in fiat-to-bitcoin purchases and cross-layer swaps.

Self-custody also means full responsibility. If you lose your recovery phrase and your signing device fails, there is no customer support line to call. If you send bitcoin to the wrong address, there is no reversal. The security of your bitcoin depends entirely on how well you manage your keys, your backups, and your operational security.

Benefits and Trade-offs

Singlesig vs. Multisig

Once you decide to hold your own keys, the next question is how many keys should be required to authorize a transaction. This is the choice between singlesig and multisig.

Singlesig: One Key, One Signature

A singlesig setup requires a single private key to authorize a transaction. One key controls the bitcoin. If you have the key, you can spend it. If someone else gets the key, they can spend it. If the key is lost, the bitcoin is gone.

Singlesig is simple, fast, and suitable for most individual users. A hardware wallet stores the private key, the user backs up the recovery phrase, and transactions require a single signing step. The attack surface is minimal: protect one key, protect one backup.

The downside is a single point of failure. If an attacker gains access to the private key (through physical theft of the hardware wallet, discovery of the recovery phrase, or a compromised signing environment), they have everything they need to drain the wallet. Nothing else stands between the attacker and the funds, because no second factor or co-signer is required to approve the spend.

Multisig: Distributed Signing Authority

Multisig (short for multisignature) requires m-of-n private keys to authorize a transaction. For example, a 2-of-3 multisig requires any two of three keys to sign. One key alone cannot move the funds.

Requiring more than one key eliminates the single point of failure. An attacker who compromises one key still cannot spend the bitcoin. A user who loses one key still has two remaining keys to recover and move the funds to a new multisig setup. The security model is built on redundancy and distribution.

Common configurations include:

• 2-of-3: The most popular configuration for individuals and small businesses. Provides a good balance of security and usability. Lose one key and you can still spend. Compromise one key and the attacker still cannot spend.
• 3-of-5: Used by organizations and high-net-worth holders. More resistant to both loss and compromise, but requires coordinating three signers for every transaction.
• 2-of-2: Requires both keys for every transaction. Strong security, but no redundancy. Losing either key means losing access.

Singlesig vs. Multisig Trade-offs

Multisig at Institutional Scale

For institutions, multisig is as much a governance mechanism as a security feature. A corporate treasury holding bitcoin needs policies that prevent any single employee, officer, or director from unilaterally moving funds. Multisig enforces this at the Bitcoin protocol level.

M-of-n configurations for treasury management. A common institutional setup is 3-of-5, where five key holders (e.g., CFO, CEO, General Counsel, Board Chair, and an external auditor) each hold one key, and any three must sign to authorize a transfer. This mirrors the dual-control and separation-of-duties principles in traditional treasury management, but enforced cryptographically rather than by policy alone.

Key holder selection. The choice of who holds keys is a governance decision with security implications. Key holders should be in different reporting lines (to prevent collusion), different physical locations (to prevent simultaneous compromise), and ideally different jurisdictions (to prevent a single legal order from compelling all signers). Succession planning must account for key holder departures, incapacitation, and death.

Geographic distribution. Institutional multisig keys are typically stored in different physical locations: separate offices, bank vaults, or dedicated key storage facilities. A 3-of-5 setup with keys in New York, London, Singapore, Zurich, and Toronto ensures that no single jurisdictional action, natural disaster, or facility breach can compromise enough keys to move funds.

Blockstream Enterprise provides institutional custody infrastructure with multisig governance, configurable Spend and Workspace Policies, role-based access controls across seven roles, and a cryptographic audit trail with on-chain verifiable reserves. The platform enables organizations to define custom approval policies (e.g., transfers above a threshold require three of five officers), set per-transaction and time-based spending limits, and maintain a complete record of every signing request and approval.

Collaborative Custody

Collaborative custody occupies a middle ground between full self-custody and full third-party custody. The defining feature: the user holds enough keys to spend independently, while a service provider holds a key that acts as a recovery backstop or co-signing partner.

How It Works

The most common model is a 2-of-3 multisig where the user holds two keys and the service provider holds one. Under normal operation, the user signs transactions with their two keys and the provider's key is never used. If the user loses one of their keys, the provider can co-sign with its key to help the user recover funds and migrate to a new setup.

This structure preserves a core self-custody property: the user can always spend without the provider's permission (they hold two of the three required keys). The provider cannot spend unilaterally (they hold only one key). The relationship is asymmetric by design: the user has sovereignty, and the provider has a limited recovery role.

Benefits

• Self-sovereignty with a safety net. The user maintains full control. The provider offers recovery assistance without gaining spending authority.
• Reduced single-point-of-failure risk. Even in a singlesig-like user experience, the multisig structure means that one compromised key does not equal lost funds.
• Guided onboarding. For users new to self-custody, a collaborative model provides a bridge between the simplicity of a custodial exchange and the full responsibility of independent multisig.

Trade-offs

• Provider dependency for recovery. If the provider goes out of business and the user has lost one of their own keys, the backup path disappears. Users should verify the provider's key can be exported or that a dead-man's-switch mechanism exists.
• Privacy considerations. The provider may see transaction details or metadata associated with co-signing requests, depending on the implementation.
• Cost. Collaborative custody services typically charge monthly or annual fees, adding an ongoing expense that pure self-custody does not require.

Collaborative Custody for Institutions

The collaborative model scales to institutional use by adjusting the m-of-n configuration and adding governance layers. An institution might use a 3-of-5 multisig where the institution holds three keys (distributed across officers in different locations) and the custody provider holds two keys (as a recovery and compliance backstop).

In this arrangement, the institution can always spend with its three keys. The provider cannot spend with its two keys alone. But if the institution loses one key, it can work with the provider (2 institutional + 1 provider = 3 of 5) to recover. This model lets institutions maintain sovereignty while meeting board-level expectations for disaster recovery and operational resilience.

The provider in an institutional collaborative model is often also a compliance layer, maintaining audit logs, enforcing AML/KYC checks on counterparties, and handling regulatory reporting. The cryptographic structure ensures these compliance functions cannot be used to freeze or seize the institution's funds unilaterally.

Comparing Custody Methods

The right custody method depends on who you are, how much bitcoin you hold, and what trade-offs you are willing to accept. The table below compares the five most common approaches across the factors that matter most.

Technical Due Diligence for Institutions

Choosing a custody solution is one of the most consequential infrastructure decisions an institution will make. Unlike switching a SaaS vendor, migrating between custody providers involves moving private key material, a process with real operational risk.

What Teams Should Understand Before Custody Evaluation

Before evaluating custody providers, an institution's technical and compliance teams should establish baseline literacy in the following areas:

• Key lifecycle management. How keys move through generation, storage, use, rotation, and retirement. Every custody architecture makes choices at each stage, and those choices create specific risk profiles.
• Signing policy enforcement. Whether policies (spending limits, time-locks, multi-approver requirements) are enforced at the application layer, at the HSM layer, or at the Bitcoin protocol layer (via multisig scripts). Application-layer enforcement can be bypassed if the application is compromised. Protocol-layer enforcement cannot.
• Recovery and disaster planning. What happens if a key is lost, a signer is incapacitated, or the custody provider ceases operations. The recovery model should be tested (via tabletop exercises, at minimum) before it is needed.
• Audit and compliance infrastructure. What records the custody system produces, how those records map to regulatory requirements (SOC2, SOX, MiCA), and whether the audit trail is tamper-evident.

A CTO's Guide to Custody Architecture

For technical leaders evaluating custody solutions, the architecture questions matter more than the marketing claims. Focus on these areas:

Key generation. Where does entropy come from? Is key generation performed inside certified hardware (HSM, secure enclave), or in software on a general-purpose server? Can you verify the randomness quality? Can you audit the key generation process?

Key storage. Where does the key material reside at rest? Is it in an HSM with FIPS 140-2 Level 3+ certification? Is it encrypted? What is the key-encryption-key (KEK) hierarchy? Who has access to the KEK?

Signing architecture. Is signing performed inside tamper-resistant hardware, or does key material get loaded into memory on a general-purpose server for signing? What happens if the signing server is compromised? Is there air-gapping between the transaction construction environment and the signing environment?

Policy engine placement. Does the custody platform enforce policies (quorum requirements, spending limits, whitelists) before the key material is accessed, or after? If the policy engine runs on the same server as the signing logic, a single compromise can bypass both. Separation of concerns matters.

Network architecture. What is the attack surface between the public internet and the signing infrastructure? How many network hops, firewalls, and access control layers separate an external attacker from the signing keys? Is the signing environment on an air-gapped network?

Questions to Ask Custody Providers

These questions cut through vendor marketing and reveal the actual security posture:

1. Can we verify key generation independently? Can we participate in or observe the key ceremony? Can we independently verify that the keys were generated with sufficient entropy inside certified hardware?
2. Where are policies enforced? Are approval quorums and spending limits enforced at the protocol level (multisig), at the HSM firmware level, or at the application level? What happens if the application layer is compromised?
3. What is the disaster recovery model? If your company ceases operations, how do we recover our bitcoin? Is there a dead-man's-switch? Can we export our key material or reconstitute it from backup shares?
4. What does your insurance cover? Does the policy cover theft via insider attack? Does it cover loss due to software bugs? What is the coverage limit, and how does it compare to assets under custody?
5. What audit certifications do you hold? SOC1? SOC2 Type II? Can we review the auditor's report, including any exceptions or qualifications?
6. How do you handle key rotation? Can keys be rotated without moving funds to new addresses? What is the operational procedure for removing a compromised key from a multisig quorum?
7. What is the signing latency? From approval to broadcast, how long does a transaction take? For time-sensitive operations (e.g., collateral calls), is there an expedited signing path? What security trade-offs does that path involve?
8. Can we self-host components? Can we run our own signing infrastructure while using your policy engine, or vice versa? What components are modular?

Frequently Asked Questions

What happens if I lose my private key?

If you have a recovery phrase backup, you can regenerate your private key and restore access to your bitcoin using any compatible wallet software. If you have lost both the private key (or signing device) and the recovery phrase, and you are using a singlesig setup, the bitcoin is permanently inaccessible. This is why recovery phrase backup is the most critical step in self-custody. In a multisig setup, losing one key does not mean losing access, as long as enough remaining keys exist to meet the signing threshold.

Is self-custody safer than keeping bitcoin on an exchange?

Self-custody eliminates counterparty risk (exchange hacks, insolvency, fraud, account freezes) but introduces personal responsibility risk (lost keys, compromised backups, operational errors). For users who follow sound key management practices, self-custody is the more secure option. The vast majority of large-scale bitcoin losses have resulted from custodial failures (Mt. Gox, FTX, QuadrigaCX), not from well-executed self-custody.

Do I need multisig, or is singlesig enough?

For small amounts and everyday spending, singlesig with a hardware wallet provides strong security with minimal complexity. As the value of your holdings increases, multisig becomes more appropriate because it eliminates the single point of failure. There is no universal threshold, but many security-conscious holders transition to multisig once their holdings represent a significant portion of their net worth. For institutions, multisig is effectively mandatory for governance and risk management reasons.

What is the difference between MPC and multisig?

Both MPC and multisig distribute signing authority across multiple parties, but they do so at different layers. Multisig is enforced at the Bitcoin protocol level: the blockchain itself verifies that the required number of signatures have been provided. MPC is enforced at the cryptographic computation level: multiple parties collaborate to produce a single valid signature, and the blockchain sees only a standard single-key transaction. Multisig provides on-chain transparency and verifiability. MPC provides on-chain privacy and smaller transactions. The trade-off is that MPC's security depends on the correct implementation of the multi-party protocol, while multisig's security is enforced by Bitcoin's consensus rules.

Can an institution do self-custody, or do they need a qualified custodian?

An institution can absolutely self-custody bitcoin. Many Bitcoin-native companies, mining operations, and corporate treasuries hold their own keys using multisig with geographic distribution and formal key management procedures. However, regulated entities (registered investment advisers, funds, certain fiduciaries) may be required by law to use a qualified custodian. The SEC's custody rule and similar regulations in other jurisdictions define when a qualified custodian is mandatory. Even when not legally required, some institutions prefer a qualified custodian for the operational support, insurance, and compliance infrastructure it provides.

How does Bitcoin ETF custody work?

A Bitcoin ETF issuer contracts with a qualified custodian to hold the underlying bitcoin. The custodian generates and stores private keys in cold storage, typically using HSMs with geographic distribution and multi-party signing ceremonies. Investors buy and sell ETF shares through a brokerage, but they never interact with the bitcoin directly. They cannot withdraw bitcoin from the ETF; they can only redeem shares for cash. The bitcoin itself is held by the custodian under a custodial agreement with the ETF issuer.

What is the difference between custodial and self-custodial bitcoin?

In custodial bitcoin, a third party (an exchange or qualified custodian) holds the private keys and controls the funds on your behalf. You see an account balance, but you cannot move the bitcoin without the custodian's permission, and you inherit their risk of hacks, insolvency, or account freezes. In self-custodial bitcoin, you hold the private keys directly, usually on a hardware wallet, so no one can freeze or seize your funds. The trade-off is responsibility: with self-custody, your recovery phrase is the only backup, and a lost key with no backup means lost bitcoin.

What is the safest way to store bitcoin?

For most individuals, the safest practical approach is self-custody with a hardware wallet that keeps the private key offline and a recovery phrase backed up securely (ideally on metal, in more than one location). A singlesig hardware wallet such as Jade Plus protects against online theft while staying simple to manage. As holdings grow, a 2-of-3 multisig removes the single point of failure, because losing or compromising one key no longer puts the funds at risk. There is no universal answer: the right setup balances the value held, technical comfort, and the realistic threats, from online attackers to physical loss.