A Bitcoin PSBT is a container that lets wallets and signers exchange an unfinished transaction plus the metadata needed to sign it. It is useful when one device constructs the payment, another keeps the private keys, or several people must approve the same spend.

A PSBT is not a transaction waiting in the Bitcoin mempool. Even after it has enough signatures, it must be finalized and extracted before a network transaction can be broadcast.

What PSBT contains

BIP 174 defines the Partially Signed Bitcoin Transaction format. The container carries:

  • the unsigned transaction;
  • information about the outputs being spent;
  • scripts and public-key details needed by signers;
  • partial signatures as they are added;
  • per-output information that helps identify recipients and change;
  • fields used during finalization.

The format separates transaction coordination from private-key custody. An online computer can prepare the payment while an offline hardware wallet inspects and signs it.

That separation reduces exposure, but it does not make every PSBT safe. A signer must still verify destinations, amounts, fees and change on a trusted display.

The six roles

BIP 174 names roles that describe the workflow. A single wallet can perform several of them.

Creator

The Creator proposes the unsigned transaction: which inputs will be spent and which outputs will receive value. At this stage the PSBT may lack the UTXO and script details a signer needs.

Updater

The Updater adds metadata about the coins being spent, scripts, derivation paths and other information. A signer needs enough information to calculate the transaction and understand what its signature authorizes.

Signer

A Signer checks the transaction and adds signatures for inputs controlled by its keys. If it cannot sign, BIP 174 says it must not add a partial signature.

The signer is the security boundary. It should display the external recipient, the amount, the fee and the change destination. Blindly signing a PSBT defeats the point of isolating keys.

Combiner

A Combiner merges information from separate PSBTs for the same unsigned transaction. This lets two signers work in parallel and return their own copies.

Combining does not mean choosing between conflicting payments. The copies must refer to the same underlying unsigned transaction.

Finalizer

The Finalizer turns the partial signatures and script information into the final scriptSig or scriptWitness for each input.

A PSBT can contain all required signatures and still be unfinalized. That distinction explains why some wallet screens show a fully signed PSBT that is not yet ready to broadcast.

Extractor

The Extractor removes the completed network transaction from a fully finalized PSBT. The resulting raw transaction can then be submitted to the Bitcoin network.

A two-signer example

Imagine a 2-of-3 treasury wallet:

  1. an online coordinator creates a payment and adds UTXO metadata;
  2. signer A verifies the recipient, amount, fee and change, then signs its inputs;
  3. signer B independently verifies the same details and signs another copy;
  4. the coordinator combines the two PSBTs;
  5. the finalizer builds the required witness data;
  6. the extractor produces the raw Bitcoin transaction;
  7. the coordinator broadcasts it.

The third key never needs to participate. It remains available for recovery according to the wallet’s policy.

This differs from a watch-only wallet, which can track addresses and prepare spending information but does not possess the private keys needed to sign.

What an offline signer must know

An offline signer does not query the Bitcoin network directly, so the PSBT must carry the information needed to evaluate the inputs.

BIP 174 defines witness and non-witness UTXO fields. The specification discusses why some wallets require the full previous transaction even for SegWit inputs: the signer needs reliable amounts for the inputs when assessing fees and resisting tampering.

Do not strip fields merely to shorten a QR code or file. Let the signing device decide which information it requires.

Change deserves the same scrutiny as the payment

Per-output data can help a signer determine which output returns change to the wallet. If malware replaces the change address, the transaction can pay the visible recipient correctly while sending the remainder to an attacker.

A signer should verify:

  • the external output;
  • every change output;
  • the total input value;
  • the transaction fee;
  • the fee rate where the device provides it;
  • whether an unexpected output or script appears.

Small-screen devices may abbreviate information. Review the wallet’s documentation so you know what the display proves and what it omits.

Moving a PSBT does not move bitcoin

PSBTs are commonly moved by file, QR code, USB device or an animated QR sequence. Transferring the container does not broadcast a transaction or move funds.

However, a PSBT may reveal wallet metadata, public keys, derivation information and transaction plans. Treat it as sensitive financial data even though it should not contain private keys.

Use a trusted transfer path and confirm that the signer parsed a PSBT rather than an unrelated file or raw transaction.

Combining is not finalizing

Three commands often get confused:

  • combine: merge compatible metadata and signatures;
  • finalize: construct the finished unlocking data for each input;
  • extract: produce the raw network transaction.

Bitcoin Core’s PSBT documentation maps these actions to RPCs such as combinepsbt and finalizepsbt. The exact command and behavior depend on the wallet and Bitcoin Core version.

A tool that says “complete” may mean all required signatures are present, while another means the raw transaction has been extracted. Check the state explicitly before broadcast.

Failure cases to test

A multisig or hardware-wallet workflow should be rehearsed with small values before it is needed under pressure.

Test:

  • one signer is unavailable;
  • two signers return copies in a different order;
  • the PSBT lacks required UTXO information;
  • a device rejects an unknown derivation path;
  • one output is changed after the first signature;
  • the fee becomes unreasonable;
  • the file is corrupted during transfer;
  • signatures are present but finalization fails;
  • the extracted transaction is decoded before broadcast.

Do not assume the recovery key works because it exists. Verify the recovery procedure without exposing the key.

Sources and version note

This guide was checked on October 28, 2026 against BIP 174 and Bitcoin Core’s current PSBT how-to. Wallet interfaces and RPCs vary by version; read the documentation for the exact software and hardware signer in use.