Glossary

Split Custody

Split custody divides control of cryptocurrency keys across multiple parties or devices so no single entity can unilaterally move funds.

Key Takeaways

  • Split custody distributes cryptographic key material across multiple parties, devices, or locations so that no single entity can unilaterally move funds. It sits between self-custody and full third-party custody on the control spectrum.
  • Three primary mechanisms implement split custody: multisig (multiple independent keys with on-chain enforcement), multi-party computation (distributed key shares that sign without ever assembling the full key), and Shamir's Secret Sharing (a single key split into shares that must be recombined).
  • Split custody eliminates single points of failure for both theft and loss: an attacker must compromise multiple keys, and losing one key does not mean losing funds permanently.

What Is Split Custody?

Split custody is a key management architecture that divides control of cryptocurrency private keys across two or more independent parties, devices, or locations. Spending requires cooperation between a threshold of keyholders, preventing any single entity from moving funds alone. The term is sometimes used interchangeably with collaborative custody or shared custody.

The motivation is straightforward: pure self-custody puts all responsibility on the user (lose your seed phrase, lose your bitcoin), while full third-party custody introduces counterparty risk (exchange hacks, insolvency, withdrawal restrictions). Split custody occupies the middle ground, combining the sovereignty of self-custody with the safety net of distributed key management.

For a comprehensive comparison of where split custody fits among other custody models, see the Bitcoin custody solutions comparison.

How It Works

Split custody can be implemented through several cryptographic techniques, each with distinct tradeoffs in security, flexibility, and complexity.

Multisig (Multi-Signature)

The most established approach uses multisig wallets, where the spending condition is encoded directly into the Bitcoin Script. An m-of-n multisig requires m signatures from n total keys to authorize a transaction.

A typical 2-of-3 split custody arrangement distributes keys as follows:

  1. User Key 1: stored on a hardware wallet controlled by the user
  2. User Key 2: stored on a separate device (mobile app, second hardware wallet)
  3. Recovery Key: held by the custody provider as a backup for key loss scenarios

The user can spend independently using their two keys without provider involvement. If the user loses one key, the provider's recovery key can assist. The provider alone cannot move funds because they hold only one of three keys.

# Example: creating a 2-of-3 multisig address in Bitcoin
# Three independent public keys from three separate devices
createmultisig 2 '["pubkey_user_device1", "pubkey_user_device2", "pubkey_provider"]'

# Spending requires signatures from any 2 of the 3 keys
# User can sign alone (device1 + device2) or with provider help

Multi-Party Computation (MPC)

MPC wallets take a fundamentally different approach: the full private key is never created, stored, or assembled at any point. Instead, each participant holds a key share, and a distributed signing protocol produces valid signatures without any party ever seeing the complete key.

MPC offers two advantages over native multisig: threshold policies can be adjusted without changing the wallet address, and MPC signatures are indistinguishable from single-key signatures on-chain (reducing fees and improving privacy). The tradeoff is cryptographic complexity: multiple MPC protocol vulnerabilities have been disclosed, and there is no single agreed-upon standard. For a detailed comparison, see the MPC vs. multisig custody analysis.

Shamir's Secret Sharing (SSS)

Shamir's Secret Sharing splits an existing secret into n shares where any t shares can reconstruct it, while t-1 shares reveal nothing about the original. The secret is embedded as the constant term of a random polynomial, and shares are points on that polynomial recovered via Lagrange interpolation.

SSS is primarily used for backup distribution rather than signing. Unlike MPC, the key must be reassembled on a single device to produce a signature, creating a temporary single point of failure at signing time. Trezor's SLIP39 standard implements SSS for seed backup with support for up to 16 shares and customizable thresholds. For more detail, see the Shamir backup guide.

The Custody Spectrum

Split custody occupies the middle of a spectrum ranging from no key control to full key control:

ModelKey ControlExample
Exchange custodyCustodian holds all keysCoinbase, Kraken
Multi-institution custodyKeys distributed across independent custodiansOnramp (BitGo + Coincover)
Split / collaborative custodyUser holds majority keys; provider assistsCasa, Unchained, Bitkey
Single-sig self-custodyUser holds one key, full controlHardware wallet + seed backup
Multisig self-custodyUser holds all keys across multiple devicesUser-managed 2-of-3

The key distinction for split custody: the user retains spending authority (they hold enough keys to transact independently), while the provider's key exists solely for recovery and co-signing scenarios. This separates it from multi-institution custody, where the custodians collectively control funds on the user's behalf.

Implementations

Casa

Casa offers 2-of-3 multisig on its Standard plan and 3-of-5 on its Premium plan. Keys are distributed across a mobile device (with cloud backup), a hardware wallet, and a Casa Recovery Key held offline. Casa cannot access funds unilaterally and provides inheritance planning through its Covenant feature.

Unchained Capital

Unchained coined the term "collaborative custody" for its 2-of-3 multisig model where the client holds two keys and Unchained holds one. The client retains unilateral spending authority. Unchained layers financial services (loans, trading, IRAs) on top of the collaborative custody foundation.

Bitkey

Built by Block, Bitkey uses 2-of-3 multisig distributed across a mobile key, a dedicated hardware device, and a server key. The server key enables phone-only transactions for convenience and assists with recovery if the user loses a device. Bitkey is designed for mainstream adoption with no seed phrases required.

Spark's Cooperative Signing Model

Spark uses a distinct form of split custody built on FROST threshold signatures. The architecture uses a 2-of-2 structure: one key belongs to the user, and Spark Operators collectively hold the other via FROST distributed signing. No single operator possesses the complete operator key share, creating a 1-of-n trust model where only one honest operator is needed to protect user funds.

When funds transfer between users on Spark, operators generate fresh cryptographic material for the recipient and destroy the old key matching the sender. This provides perfect forward security: even if operators are later compromised, they cannot affect completed transactions. Pre-signed exit transactions allow users to broadcast to Bitcoin L1 at any time without operator cooperation, preserving self-custody guarantees. For a deeper look, see the Spark protocol overview.

Use Cases

  • Personal bitcoin storage: individuals who want stronger protection than a single hardware wallet but do not want to manage a full multisig setup themselves. A collaborative custody provider holds a recovery key as a safety net.
  • Business treasury management: companies that need separation of duties so no single employee can move corporate crypto holdings. Split custody enforces multi-party approval at the cryptographic level.
  • Inheritance planning: split custody enables inheritance workflows where heirs can access funds with provider assistance after the primary keyholder is no longer available, without the provider having unilateral access during the keyholder's lifetime.
  • Institutional custody: regulated entities use MPC or multisig split custody to satisfy qualified custodian requirements while maintaining operational flexibility. Providers like Fireblocks and BitGo serve this segment.
  • Layer 2 protocols: systems like Spark use cooperative signing between users and operators to enable fast off-chain transactions while preserving the option to exit to Bitcoin L1 unilaterally.

Risks and Considerations

Provider Dependency

In collaborative custody models, the provider holds a recovery key. If the provider shuts down or becomes unreachable, recovery from key loss becomes harder. This risk is mitigated when the user holds enough keys to spend independently (2-of-3 where the user holds 2), but the recovery safety net disappears.

MPC Protocol Vulnerabilities

Multiple vulnerabilities have been found in MPC implementations, including BitForge (2023) and TSSHOCK (2023). MPC protocols lack a single agreed-upon standard, and their cryptographic complexity makes auditing difficult. Multisig, by contrast, relies on well-understood Bitcoin Script primitives that have been battle-tested for over a decade.

On-Chain Privacy and Fees

Native multisig transactions reveal the quorum structure on-chain, exposing the spending policy publicly. They also require larger transactions (more signatures), increasing fees. Taproot and FROST mitigate both issues: cooperative spends using key-path spending are indistinguishable from single-signature transactions and pay standard fees. For more on how Schnorr signatures enable this, see the FROST deep dive.

Operational Complexity

Managing multiple keys across multiple devices and locations is inherently more complex than single-key custody. Users must track hardware wallets, secure backups for each key, and maintain the multisig configuration (output descriptors). Losing the configuration data can make recovery difficult even if individual keys survive.

SSS Reconstruction Risk

Shamir's Secret Sharing requires reassembling the full key on a single device to sign, creating a temporary window where the complete secret exists in one place. This makes SSS less suitable for ongoing signing operations and better suited to backup scenarios where reconstruction is rare.

Split Custody vs. Alternatives

FactorSplit CustodySelf-CustodyFull Custody
Single point of failureEliminatedYes (one key)Yes (custodian)
Recovery from key lossProvider can assistSeed phrase onlyCustodian handles
Counterparty riskLimited (provider cannot spend)NoneFull
Operational complexityModerateLowLow (outsourced)
Inheritance supportBuilt-in with providerManual setup requiredCustodian-dependent

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.