A Bitcoin transaction can pass through several devices before it is ready for broadcast. Partially Signed Bitcoin Transactions, or PSBTs, give those devices a structured way to exchange the transaction and the information needed to review and sign it.
TL;DR: A PSBT is a coordination format, not a private key or a final payment receipt. It supports workflows involving offline devices and multiple signers, but each signer still needs to evaluate the transaction being authorized.
The format separates roles in the workflow
BIP 174 defines the original format and identifies roles such as creator, updater, signer, finalizer and extractor. One application can perform several roles, or different devices can divide them.
A connected wallet might construct a proposed transaction and gather information about the outputs being spent. An offline device can then inspect the package and add signatures. Other software can combine the results and produce the transaction that is eventually broadcast.
The benefit is interoperability: each participant has a common container for information rather than a proprietary exchange that works only inside one vendor’s application. Private signing material can remain on the device responsible for authorization.
Offline signing still requires meaningful review
The format carries data that helps a signer understand the transaction without directly consulting the full unspent-output set. That is useful for hardware and air-gapped wallets, but it does not make the proposed payment trustworthy simply because it arrived in a recognized file format.
In an illustrative business workflow, the computer assembling a payment could be different from the device approving it. The approving device needs to show enough information to verify the recipient, amount and change treatment. Otherwise, separating devices can move the signature without creating an independent check.
There is also a difference between a transaction being partially signed and being complete. A package may still need another participant, additional metadata or a finalization step. The interface should make that state clear instead of implying that every saved PSBT is ready to send.
Version support affects what devices can exchange
BIP 370 defines PSBT version 2, reorganizing information and supporting construction workflows in which inputs or outputs can be added under the format’s rules. The PSBT version is distinct from the version field of the Bitcoin transaction it describes.
BIP 371 adds fields for Taproot-related signing data and applies them to both PSBT versions 0 and 2. This is a useful reminder that compatibility has several dimensions: container version, supported spending conditions and the actual functions implemented by each wallet.
A product saying it supports PSBTs therefore does not establish that it can complete every possible PSBT workflow. Teams should test the combinations of wallets, devices and output types they intend to use before relying on them for an important transfer.
A completed signature is still separate from settlement
Once the necessary signatures and finalization are complete, the transaction can be extracted and submitted to the network. Signing alone does not establish that miners have included it or that the intended recipient has accepted the payment.
Operational records should preserve those distinctions. A treasury may want one record of internal authorization and another of broadcast and confirmation. Treating the signed file as the final receipt can obscure where a delayed transfer has actually stopped.
PSBTs are valuable because they make cooperation between Bitcoin tools explicit. Their strongest use is in a workflow that also makes review, signing progress and network completion explicit, so each participant knows what has been authorized and what remains to happen.
Written by the News Desk and edited by Samuel Rae.
Leave a Reply