PSBT Explained: How an Unsigned Bitcoin Transaction Travels Between Wallets

The problem PSBT solves

A Bitcoin transaction is signed by whoever controls the coins it spends. That creates an awkward split in practice: the machine that holds the keys is often offline, and the machine that knows the UTXOs, the change address and the fee is often online. Before PSBT, each wallet had its own way of passing an unsigned transaction to a signer, and two wallets from different vendors frequently could not complete the handoff at all.

BIP-174’s motivation is exactly that: unsigned or partially signed transactions were implementation-dependent, which made it hard for people using different wallet software to pass the same transaction around, sign it and combine the signatures. PSBT standardises the container.

The format’s abstract is precise about what it is for: it holds the information necessary for a signer to produce signatures, and it holds the signatures for an input while the input does not have a complete set. The signer can be offline because all necessary information is in the transaction file.

What is actually inside the file

A PSBT is not a transaction with some signatures missing. It is a set of key-value maps, each terminated by a 0x00 byte, prefixed by a magic number:

<psbt>       := <magic> <global-map> <input-map>* <output-map>*
<magic>      := 0x70 0x73 0x62 0x74 0xFF
<global-map> := <keypair>* 0x00
<input-map>  := <keypair>* 0x00
<output-map> := <keypair>* 0x00

The magic bytes spell psbt followed by 0xFF, which is why a base64-encoded PSBT usually begins with cHNidP. The global map carries data that applies to the whole transaction, such as the unsigned transaction itself in version 0, the PSBT version, and extended public keys. Each input map carries what a signer needs for that input: the UTXO being spent, the redeem script or witness script, derivation paths, the sighash type and any partial signatures already collected. Each output map carries the data needed to verify where the coins are going, including the output’s script and derivation paths.

The separation is the point. A signer can be given the whole PSBT and still only use the parts relevant to the inputs it controls; a coordinator can combine two signed PSBTs without needing either signer’s keys.

The six roles, and why the boundaries matter

BIP-174 defines the roles precisely, and the definitions are the best description of what a PSBT workflow is supposed to guarantee.

• Creator creates the PSBT, places the unsigned transaction in it, and creates empty input and output fields.
• Updater adds information it has access to: the UTXO for an input, redeem scripts, witness scripts and BIP-32 derivation paths.
• Signer accepts only a PSBT, uses only the UTXOs provided in it, verifies the data before signing, and adds only partial signatures. If it cannot sign, it must not add a partial signature.
• Combiner merges signatures and other data from multiple PSBTs for the same transaction.
• Input Finalizer constructs the final scriptSig or scriptWitness for each input once the required signatures are present.
• Transaction Extractor assembles the network-serialised transaction from the finalised PSBT.

A wallet can perform several roles at once — a software wallet is commonly Creator, Updater, Combiner, Finalizer and Extractor, while a hardware wallet is the Signer — but the roles exist because the trust assumptions differ. The signer is the only role that touches a private key. The coordinator is the only role that needs to know about all the inputs. The extractor is the only role that produces something a node will accept.

The checks a signer is required to make

The most security-relevant part of BIP-174 is not the encoding; it is the list of things a signer must verify before producing a signature.

For a non-witness input, the signer must verify that the txid of the non-witness UTXO matches the txid specified in the unsigned transaction. For a witness input, it must verify that the witness script, if provided, matches the hash specified in the UTXO or the redeem script, and that the redeem script, if provided, matches the hash in the UTXO.

The BIP then adds a note that explains a failure mode most users have never heard of: the BIP-143 sighash algorithm has a known issue where an attacker could trick a user into sending Bitcoin to fees if they can convince the user to sign a malicious transaction multiple times, because the amounts in PSBT_IN_WITNESS_UTXO of other segwit inputs can be modified without affecting the signature for a particular input. The mitigation many wallets adopt is to require the full previous transaction, so the amounts of the other inputs cannot be tampered with.

That is why a hardware wallet sometimes asks for more than the PSBT. It is not being difficult; it is closing the gap that the format itself documents.

Version 0 and version 2

BIP-174 defines version 0. Its global unsigned transaction is fixed, which means inputs and outputs cannot be added after the PSBT is created. For a simple send, that is fine. For a CoinJoin, where participants add inputs over time, or for a fee-bump workflow, it is a limitation.

BIP-370 defines PSBT version 2. It moves the transaction data into per-input and per-output fields, requires PSBT_GLOBAL_VERSION to be present and set to 2, and requires PSBT_GLOBAL_UNSIGNED_TX to be excluded. The result is a PSBT whose inputs and outputs can be added after creation. Both versions are marked Deployed in the BIP repository, and a wallet that supports only version 0 will reject a version 2 file rather than silently misread it.

The practical consequence is compatibility, not security. A PSBT carries its version, and the roles have to agree on it. If a coordinator builds version 2 and a signer only understands version 0, the failure is at the signer, before any signature exists.

Reading a PSBT before signing

The format makes a transaction inspectable, but inspection is not automatic. A signer that displays only an address and an amount is using the PSBT’s data to render a summary, not to prove that the summary is complete.

Three habits close most of the gap:

1. Check the fee, not just the outputs. The difference between inputs and outputs is the fee. A PSBT with a correct-looking output and an enormous fee is still a valid PSBT.
2. Check the change output. A change address that the wallet does not recognise is the signature of a compromised coordinator. The derivation path in the output map is what lets the signer verify it.
3. Check the network and the script type. A mainnet transaction signed for a testnet wallet, or a script type the signer did not expect, should stop the flow rather than produce a signature the coordinator may not be able to use.

These are the same questions a hardware wallet asks when it shows a transaction, and they are the reason clear signing versus blind signing matters more in a PSBT workflow than in a single-wallet one: the machine that signs is not the machine that built the transaction, so the display is the only place the two can disagree visibly.

Where PSBT fits in a wallet setup

PSBT is the transport that makes a watch-only setup possible. The online wallet holds the xpub and the UTXO set, builds the transaction and finalises it; the offline device holds the key and signs. Neither needs the other’s secret, and the file can move by USB, SD card, QR code or a network message.

The same transport is what makes multisig practical. Each signer returns a partially signed PSBT, the combiner merges them, and the finaliser produces a transaction with the required number of signatures. The threshold rules themselves are a property of the script, not of the PSBT; our guide to multisig thresholds and signer custody covers who can move funds once the script is satisfied.

The derivation paths inside the PSBT connect it to the wallet’s key hierarchy. Why one seed can produce different addresses on different wallets is covered in wallet derivation paths, and what a hardware device does and does not protect against is covered in what a hardware wallet does and does not protect against.

Risk note. The format, role definitions, signer checks and version rules in this article were read from BIP-174 and BIP-370 on 2026-11-02. PSBT implementations vary in which optional fields they include and which checks they enforce; the specification states the minimum, not the whole of what a good signer should display. Nothing here is investment advice.