Collaborative Custody is an arrangement in which an owner and another person or service help secure bitcoin. In a common model, the owner holds enough keys to pay independently while the service helps when something goes wrong. That independence must follow from the wallet’s actual rules, not just a product name.
Peter manages his bitcoin with his own wallet. What worries him is losing a device or backup. A wallet is an application or device for receiving and sending bitcoin. Signing here means using a private key, a secret numerical value, to create verifiable proof of authorization for a payment. Others can check the signature without knowing that secret. Unchained describes a 2-of-3 arrangement: a payment needs signatures from two of three keys. Peter holds A and B; the service holds C. The valid combinations are A+B, A+C and B+C; C alone is insufficient. Requiring several signatures is called Multisig. Peter can pay without the service and ask for help if one key is lost. Two devices restored from the same Seed Phrase, the same word-based backup, do not provide independence: exposure of that shared secret compromises both. [1] [4] [8]
As long as Peter has usable A+B and complete wallet records, a service outage does not by itself prevent payment. With only A left, he needs the service for A+C. Its outage or refusal to sign can then block recovery. If both A and B are lost, C alone cannot save him. Independent exit and assisted recovery therefore need separate tests. Casa’s instructions for recovery without its infrastructure also explicitly assume that its service key is unavailable. The exact procedure and equipment depend on the product; the word “collaborative” does not tell you what they are. [1] [6]
Peter has his backups, but a replacement app still needs to know which wallet to reconstruct. A conventional 2-of-3 requires the public keys of all three participants, including the service, and the rules for using them. Public keys verify signatures; private keys create them. An Output Descriptor is a machine-readable description of that configuration, including address derivation. Two personal Seed Phrase backups cannot supply the provider’s missing public key. Peter saves and checks the export while the service is available. Before sharing it, he checks its contents: the general descriptor format can contain private keys too. [4] [5]
A coordinator assembles the transaction information; a signer holds a key that approves it. PSBT, the format described in BIP 174, carries an unfinished transaction and its supporting data between software and devices. Creating the file does not supply a missing signature. A coordinator without a key can still cause harm by proposing a different recipient. Before signing, check the address, amount, fee and change—the remainder returned to your wallet. A Hardware Wallet helps separate the key from the computer; security still depends on what its screen lets Peter verify and what he actually approves. [2] [3]
A mistake can happen before the first payment, while the app is constructing the shared wallet. BIP 129 describes exchanging keys and configuration so participants can compare the signing threshold, included keys and first address. This includes the script type, which expresses spending conditions, and derivation paths used to generate further keys. Tampered settings can redirect deposits. The document does not itself cover tamper-resistant device storage or subsequent verification of receiving and change addresses. Supporting the standard is therefore not a certification of the whole product’s security. [2]
An XPUB is an extended public key used to derive public keys for a wallet branch. Knowing these details and the configuration may let a provider follow addresses and payments without enough signatures to spend. Linking them to an account in the client’s name creates another connection. Privacy and spending authority are separate questions. The claim that a service cannot pay alone also has conditions: it might acquire another of Peter’s keys or trick him into signing a harmful transaction. Limiting the provider’s authority reduces some risks without removing all of them. [2] [4]
Peter loses a key and creates a replacement in the app. That does not invalidate the old key for earlier deposits. A transaction output records an amount and the conditions for spending it later. Those deposits exist as UTXOs, unspent transaction outputs with their own spending conditions. With conventional Multisig, he must create new conditions and move the relevant funds into them in a confirmed transaction. He then checks what remains at the old addresses. Changing an account password or key label is no substitute for that transfer. Configuration and family instructions must also be updated, or heirs may follow a plan that no longer matches the funds. [4] [9]
A useful rehearsal uses a separate test wallet. Peter imports the saved configuration into compatible software, compares addresses and checks that he can sign with his own keys without the original service. Watch-only mode displays addresses and balance but does not prove the ability to sign. Caravan is an open-source coordinator; support for the particular format and devices still needs checking. Assisted recovery, an unavailable key, fees and change belong in the rehearsal too. The result should be understandable, recorded instructions with software versions, rather than reassurance from a balance on a screen. [3] [6] [7]
For the clearest picture, read this entry together with Multisig, Self-custody, Output Descriptor, PSBT, Bitcoin Inheritance Plan, Counterparty risk. The reverse links also lead from Bitcoin Inheritance Plan, Institutional custody.