Bitcoin custody mechanics

Bitcoin Multisig Roles Still Need Coordination

Updated 12 November 2026

That is coordination. It is not separation of trust. Bitcoin multisig can divide roles across people and machines, yet every policy, signing and review role still has to be joined correctly before a valid transaction exists.

Descriptors split the roles

Bitcoin multisig used to be associated with a relatively narrow division between wallet software and the people holding spending keys. Descriptor wallets and modern wallet interfaces now express that division more directly. One participant can hold a complete set of public keys and enforce the spending policy. Another can build or review a transaction. A third can hold only a limited signing capability. The resulting multisig output still requires the threshold specified by the script.

The important point is that role separation changes custody mechanics, not the rules of the output. If a 2 of 3 multisig requires two valid signatures, one signer cannot spend alone. A policy holder cannot release funds by approving a different transaction unless the relevant private key signs that transaction. A watch only participant can see the script and derive the relevant addresses, but cannot authorise spending without access to a signing key.

Descriptor records make those distinctions easier to preserve. They can encode the multisig script, derivation paths, key identifiers and the roles assigned to participants. That reduces the chance that a coordinator imports an address without understanding its constraints. It does not remove the need to agree which keys exist, which parties hold them, and what conditions must be satisfied before signing.

See the Bitcoin descriptor wallet documentation for the broader descriptor model. The technical capability is mature. The operational process around it remains the weak point.

Policy is not a signature

A policy role can be powerful without being able to spend. A participant with the public keys and complete script information can determine whether a proposed transaction matches a rule such as a fixed destination, a permitted amount or a specific spending path. That participant might also be the system that coordinates transaction construction.

This is useful because the party enforcing policy need not be the same party holding a private key. It can review an unsigned transaction, reject one that violates policy and approve one that passes. However, a policy approval is not a signature. It does not make a transaction valid on the Bitcoin network.

That distinction matters when several teams use separate systems. The policy engine may accept a transaction because its outputs match the rule. The coordinator may serialise and distribute it. The signers may sign it. If any stage uses different derivation paths or an incomplete script, the pieces can fail to join. The failure may look like a signing problem even though the actual defect is a mismatch in metadata.

Organisers should therefore validate the full multisig script before approving anything. The descriptor documentation in Bitcoin Core describes how wallets represent keys and scripts together. The review should confirm that the policy applies to the exact script policy will govern, not merely to a familiar address label.

Watch only still has a job

A watch only role can provide the clearest view of a multisig arrangement without receiving signing authority. It can display balances, derive receive addresses and inspect an output’s script. Depending on the wallet and data shared with it, it may also build or coordinate transactions.

Watch only access is therefore not necessarily passive. The role may be assigned to someone responsible for treasury operations, an auditor, a coordinator or a policy controller. That participant can see whether a proposed spend fits the rules and can help prepare it. What the participant cannot do is create the required signatures alone.

This separation creates a clean control boundary. A coordinator can move a transaction through review without holding a complete signing set. The signers can inspect the final transaction and apply their own approval controls. Yet the boundary can be misunderstood. If a signer receives only an address, a message or a partially serialised transaction, there may be no reliable way to know which multisig script and derivation path are in use.

Wallet developers have addressed this with PSBT version 0 and PSBT version 2. These standards carry the script and key information needed for participants to inspect and sign the same transaction. They support the coordination model, but they do not certify that every participant understands the policy or that every signer has checked the destination.

The signer remains accountable

The final layer is human or machine controlled signing authority. A signer with one key in a 2 of 3 multisig can still cause a spend when combined with another authorised signer. This is why descriptor support does not justify treating every participant as interchangeable.

Some signers may be legal approvers, some may be technical operators and others may be recovery participants. Each role should have a defined job. One participant may verify policy. Another may coordinate transaction construction. Another may hold the cold key. The number of roles can exceed the number of signatures required.

The dangerous assumption is that splitting a multisig among several systems automatically reduces risk. It can, but only if the divisions are meaningful. Giving the policy holder and the signer identical access defeats the purpose of the separation. Giving multiple people the same key also creates correlated risk. The output accepts signatures, not intentions, so duplicate custody can be invisible in the script while remaining obvious in the key management process.

Operational controls should therefore record who exercised each role. For every proposed spend, the record should show the multisig script, the approved outputs, the policy result, the signers and the final serialised transaction. The Bitcoin network will verify the script and signatures. It will not verify why the signatures were given.

Recovery needs a separate rehearsal

Multisig recovery is where role assumptions often fail. A complete key set may be distributed across several locations, but that does not prove that the owners can reconstruct the same script at the right derivation paths. Hardware wallets, signing devices and software interfaces can express compatible descriptors differently.

Recovery should be tested before the multisig is used for material value. The test should not begin with the seed phrase. It should begin with the descriptor, public key identifiers, derivation paths, script type and threshold. Each participant should confirm that the information matches the intended output. Then the owners should rehearse producing and verifying a transaction in a harmless environment.

A final drill should restore access without treating a seed as transport for the entire arrangement. A signer needs to know which key is theirs, which derivation path applies and which multisig output must be reconstructed. The policy holder needs to know the exact script. The coordinator needs the same network parameters and script context as the signers.

The Bitcoin Core documentation on transaction traffic is not a recovery guide, but it illustrates the wider point: participants must exchange enough transaction context to operate on the same object. Multisig recovery succeeds when the reconstruction process is tested as a complete workflow, not when each key holder merely confirms that a seed works.

A hard warning for every role

The growing use of descriptor wallets makes Bitcoin multisig more expressive, not less demanding. Roles can now be clearer, exports can be more portable and transaction review can be separated from signing. The cryptography can enforce the threshold. It cannot enforce whether the right transaction was reviewed or whether the right people received the final instruction.

Treat every unsigned transaction as a custody decision. Verify the network, script, derivation path, amount and destination before approval. Keep the policy, coordination and signing roles distinct where the arrangement requires it. Then rehearse recovery before an emergency makes the assumptions permanent.

Never paste a seed into a watch-only field.

Sources and current context

This account treats the October 2026 wallet landscape as an operational development rather than a new Bitcoin consensus rule. Descriptor wallets, PSBTs and multisig scripts have been available for years. What continues to change is the quality of role assignment, transaction coordination and recovery tooling around them.

The relevant references are therefore implementation specifications and wallet documentation rather than claims that a particular commercial wallet has solved multisig coordination. Commercial interfaces change quickly. The script requirements do not.