Bitcoin custody mechanics

PSBT Signers Still Need Coordination

Updated 10 November 2026

That is a coordination gap. It is not a signature failure.

A complete PSBT is not the same as a finished transaction

Bitcoin's Bitcoin Core implementation uses Partially Signed Bitcoin Transactions, or PSBTs, to move an unsigned transaction between parties. The format carries the unsigned transaction, the redeem or witness data needed to spend relevant inputs, and the signatures that have been collected. In a multisig setup, one participant can build the package while another signs it, and the final broadcast waits until the required approvals exist.

The important distinction is between a transaction being ready for a vote and being ready for broadcast. A PSBT may contain enough information to inspect and sign, but another participant may still need to add a signature. If that participant reviews a stale construction, adds a valid signature, and sends it back, the coordinator may discover that the package no longer matches the transaction now being considered.

This is why a valid signature does not guarantee that a multisig transaction can be completed on schedule. The signatures must authorise the same transaction, and the coordinator must not substitute a newly constructed package without returning the change to the signers.

What a signer should inspect

The first review is of the transaction's inputs and outputs, not merely whether the PSBT contains a recognisable wallet or coordinator name. A signer should check that the expected coins are being spent and that the destination outputs match the intended payment. They should also check the fee, the locktime where relevant, and any timelock or other spending constraint attached to an input.

The second review is of what the transaction changes. A coordinator may have added an output, raised a fee, replaced an input or altered an amount. Such changes may be legitimate, especially when the original proposal has become unconfirmable, but they require renewed approval. A signature given to one transaction cannot authorise a different transaction.

For a Bitcoin transaction, inputs identify earlier outputs being consumed, while outputs assign value to new outputs. In a multisig wallet, the redeem script or witness script determines how many approvals and which keys are needed. The PSBT makes the proposed spending visible before final signature, but the workflow does not remove the need to compare that proposal with current wallet state.

Witness data matters too. A signer should be able to see the redeem or witness structure needed for the input, including the conditions required by the script. If a package arrives with no useful spending information, or if the relevant fields have been stripped, there may be nothing meaningful to review. The wallet should reconstruct the transaction in a form that the signer can evaluate before producing a signature.

Why signatures can arrive too late

Multisig coordination has several common failure points. The coordinator may distribute a PSBT, then change the fee or an output while waiting. A signer may sign a different version. Another required signer may be offline, use an outdated wallet state, or approve only the first version that reaches them. Each event can leave valid signatures spread across different transaction proposals.

Some of these are policy failures rather than cryptographic ones. The signature can be perfectly valid for the bytes it covers, yet unusable for the transaction selected for broadcast. This is the practical danger of treating a signature as an approval of a transaction description that the signer never actually checked.

Fee estimation creates another pressure. If a proposed transaction has waited in the mempool, a coordinator may decide that it needs a higher fee and rebuild it. The new PSBT can contain useful signatures, but a changed output or an added input usually requires fresh signatures. If the coordinator silently merges the new proposal with old approvals, the result may be rejected by the network or broadcast without the intended script validation.

Conversely, insisting on the original PSBT can also leave a transaction stuck. Bitcoin does not know that a multisig package was agreed among participants. It only sees the final transaction and its witnesses. A coordinator must balance the need for renewed consent against the risk that the proposal will become unconfirmable or that the relevant funds will be spent elsewhere.

The custody boundary is the approval

The safest boundary for a signer is the final transaction. The signer should know which wallet or account funds are leaving, which outputs will receive them, how much fee is being paid, and whether any input carries a locktime that could affect urgency. For a policy or corporate wallet, that boundary may also include the purpose of the payment, the approved counterparty and the acceptable fee range.

This review becomes more important when a PSBT travels through several systems. Passing it among a coordinator, a cold signer, a review interface and a broadcaster creates opportunities for version confusion. Each handoff should preserve the same unsigned transaction and make clear which fields are final. If a fee bump or replacement occurs, the new proposal should be labelled as a replacement and circulated for renewed signature collection.

Watch only coordination is not a substitute for checking the proposal. A wallet can display transaction details without holding the keys needed to sign. That separation can improve review, but it cannot establish that the people responsible for the keys have approved the same outputs and fee. The final signer still needs a reliable view of the transaction being authorised.

Hardware signing systems can help because the signing device can display the transaction being authorised. They do not remove the need to understand the destination, amount or fee, and they do not stop a coordinator from sending a different PSBT to each signer. The display must be read on the device rather than trusted from a message or screenshot.

A workable review rule

A practical rule is simple: change the transaction, renew the approval. If an input, output, amount, fee, locktime or script relevant to the spend changes, participants should treat the old signatures as belonging to an old proposal. The replacement can reuse parts of the construction, but the people who must authorise it need to see the replacement clearly.

That does not mean every harmless encoding difference should trigger panic. Wallets may represent equivalent scripts or sequence values differently while producing the same spending intent. The question is whether the final witness and transaction satisfy the agreed policy. A deterministic final transaction representation makes comparison easier, but software still needs to explain differences that alter what is being authorised.

Records should preserve the unsigned transaction, the relevant PSBT version, the signer set and the decision attached to it. The broadcaster should use only the final approved package. If the package is amended, the approval record should say that it was amended and should point to the new transaction rather than silently overwriting the earlier one.

That is a multisig control problem. It is not evidence that the keys are broken. Never paste a seed into a watch-only field.