Follow a partially signed Bitcoin transaction through preparation, signing and finalization, with a worked fee example and clear privacy boundaries.
Pass a transaction between different tools
A wallet that selects coins does not always hold the keys that sign them. A hardware signer may hold one key, while a desktop wallet knows the transaction history and another participant supplies a second signature. A partially signed Bitcoin transaction, or PSBT, packages transaction information so these tools can cooperate.
The package can contain an unsigned transaction, information about previous outputs, scripts, key origins and signatures. It is not a new kind of on-chain transaction. The network eventually receives a normal serialized Bitcoin transaction after the relevant inputs have been finalized.
Separate the roles
The BIP 174 workflow distinguishes creation, updating, signing, combining, finalization and extraction. One application can perform several roles. In a multisig arrangement, participants may work on separate copies, which can later be combined when they describe the same intended transaction.
The signer should not treat the preparing computer as trustworthy merely because the file format is recognized. It must validate the previous-output information and check the spending policy, destination, fee and any change it is expected to recognize.
Read the arithmetic before signing
An illustrative two-input payment
The proposed inputs are 80,000 and 50,000 sats. The outputs are 100,000 sats to the destination and 28,000 sats to change. Total input is 130,000 sats; total output is 128,000 sats; the proposed fee is 2,000 sats. If the destination was meant to receive 10,000 sats, a syntactically valid PSBT does not fix that mistake.
Change recognition depends on wallet policy and derivation information, not just a label added by the computer preparing the PSBT. A compromised coordinator could describe an attacker's address as change. A suitable signer checks that claim against policy it already knows.
Understand what travels with the file
An unsigned PSBT is not normally enough to spend coins without the required signatures. However, it can reveal transaction plans, wallet paths and financial information. A PSBT containing enough signatures, or its finalized equivalent, may enable somebody else to broadcast the intended payment. Treat that as an operational boundary, not an encrypted-message guarantee.
Use a transfer process supported by the participating wallets. QR codes and removable media are transport methods; they do not automatically establish authenticity or prevent malicious data from reaching a parser.
Finalization is not confirmation
After signing, finalization builds the required script or witness data for each input. Extraction produces the transaction that can be submitted to the network. Neither step guarantees relay, mining or final settlement. Inputs might already be spent, fees may be unsuitable, or another transaction may conflict.
Once broadcast, check the actual transaction ID and its current status. Use the transaction decoder for public raw transaction data; do not upload private wallet material or assume it is a PSBT signing service.
The useful separation is simple: preparation chooses what to pay, inspection checks the proposal, signatures authorize spending, and confirmation records acceptance in a block.
Sources and further reading
Key takeaways
- PSBT exchanges transaction metadata between tools; the final on-chain transaction uses normal Bitcoin serialization.
- The signer must inspect destination, fee and wallet policy rather than trust labels.
- A fully authorized package may be broadcast by someone who receives it; protect transaction privacy.
Common questions
Is a PSBT always unsigned?
No. It can contain no signatures, some signatures or enough data to finalize a transaction.
Does finalizing a PSBT make the payment confirmed?
No. Relay, mining and confirmation happen after a transaction is extracted and broadcast.