PSBT explained: Partially Signed Bitcoin Transactions

A PSBT (Partially Signed Bitcoin Transaction) is a standard file format, defined in BIP 174, for a transaction that isn't fully signed yet. It carries the unsigned transaction plus everything a signer needs to check and sign it: the coins being spent, scripts and key paths. That lets one program build a transaction, a hardware wallet or other signers sign it, and another program broadcast it, even if they come from different makers.

Updated 2026-10-20 · 8 min read

What is a PSBT?

Signing a Bitcoin transaction needs more than the transaction itself. A signer has to know the amount and script of every coin it spends, which of its keys to use, and for multisig, the full script. Before PSBTs, every wallet passed this around in its own format, so mixing software and devices from different vendors was hard.

BIP 174, written by Ava Chow in 2017, defines one extensible format for this. Its acknowledgements credit Pieter Wuille with suggesting the format and coming up with the name. A PSBT is a container: it starts as an unsigned transaction with some metadata, collects signatures as it moves between participants, and ends as a complete transaction ready to broadcast.

PSBTs are what make these workflows interoperable:

• Hardware wallets: your computer builds the transaction, the device checks and signs it.
• Air-gapped signing: the PSBT moves by QR code or memory card to a device that never connects to the internet.
• Multisig: each cosigner adds a signature to the same PSBT.
• Collaborative transactions such as CoinJoin and payjoin (BIP 78), where several people contribute inputs.

The PSBT roles

BIP 174 splits the process into roles. One program can play several, but each role has strict rules about what it may do:

PSBT version 2 adds a seventh role, the Constructor, which adds inputs and outputs after creation.

How a PSBT moves through a hardware wallet signing

A typical single-signature spend with a hardware signer:

1. Create and update. The wallet software on your computer picks coins and outputs, then fills in each input's previous output and the derivation path of the key that controls it. It also marks change outputs with their derivation paths.
2. Transfer. The PSBT goes to the signing device over USB, by QR code or on a memory card.
3. Check and sign. The device uses only the data in the PSBT. It verifies that the scripts match the coins being spent, recognizes its own change outputs from their key paths, and shows you the destination, amounts and fee. If you approve, it adds a signature.
4. Return, finalize and extract. The signed PSBT goes back to the computer, which finalizes the inputs, extracts the transaction and broadcasts it.

The Signer rules in BIP 174 are designed so the device "should not need any additional data sources". It doesn't have to trust the computer for amounts or keys, only check what is in the file.

Why some signers want the full previous transaction

For SegWit v0 inputs, BIP 174 notes a known weakness of the BIP 143 signing algorithm: an attacker who convinces you to sign a malicious transaction more than once could trick you into paying excessive fees, because the amounts of other inputs aren't covered by each signature. To guard against this, many signers ask for the full previous transaction (PSBT_IN_NON_WITNESS_UTXO) even for SegWit inputs, which is why PSBTs can carry both UTXO types. Taproot signatures (BIP 341) commit to the amounts of all inputs, which removes this problem for Taproot spends.

What's inside a PSBT: the format

A PSBT is a binary file made of key-value maps:

<magic bytes> <global map> <one map per input> <one map per output>

• Magic bytes: 0x70 0x73 0x62 0x74 0xFF, the ASCII letters "psbt" followed by 0xFF. The 0xFF makes sure no ordinary transaction parser mistakes a PSBT for a transaction, and vice versa.
• Each map is a list of records, ended by a 0x00 byte.
• Each record is a key (length, type, key data) and a value (length, value data). The type says what the record is.

Some important record types in version 0:

Signers ignore record types they don't understand and pass them through unchanged. That is what lets later BIPs add fields without breaking older software. A version field (PSBT_GLOBAL_VERSION) exists for changes that can't be handled that way.

How PSBTs are encoded: .psbt files and Base64

BIP 174 allows two representations: a binary file with the .psbt extension, or a Base64 text string. Because every PSBT starts with the same magic bytes, Base64 PSBTs always begin with the characters cHNidP8. If you see that at the start of a long string, it's a PSBT.

A PSBT contains no private keys. It can still contain privacy-sensitive information, such as your extended public keys and derivation paths, and once fully signed it can be broadcast by anyone who has it.

PSBT v0 vs PSBT v2 (BIP 370)

The original format, now called version 0, stores the whole unsigned transaction in one global field. Once created, nobody can add an input or output. BIP 370, also by Ava Chow, defines PSBT version 2, which removes the global transaction and stores each part in its own map:

• Global: transaction version, a fallback lock time, input and output counts, and a "modifiable" flag that says whether inputs or outputs may still be added.
• Per input: the previous transaction ID and output index, the sequence number, and any lock time the input requires.
• Per output: the amount (PSBT_OUT_AMOUNT) and the script (PSBT_OUT_SCRIPT).

This makes v2 suitable for transactions built by several parties, such as CoinJoins, where each participant adds their own inputs and outputs. It also means all the information about an input or output is in one place. The lock time is computed from what the inputs require. BIP 174 vs BIP 370 compares the two versions in detail.

Taproot fields (BIP 371)

Taproot uses Schnorr signatures and hides scripts in a tree, so the original fields weren't enough. BIP 371 adds fields that work in both v0 and v2:

• PSBT_IN_TAP_KEY_SIG (0x13) for a key-path signature, and PSBT_IN_TAP_SCRIPT_SIG (0x14) for script-path signatures.
• PSBT_IN_TAP_LEAF_SCRIPT (0x15) and PSBT_IN_TAP_MERKLE_ROOT (0x18) for the script tree.
• PSBT_IN_TAP_INTERNAL_KEY (0x17) and PSBT_IN_TAP_BIP32_DERIVATION (0x16) for keys and their paths.
• Output fields for the internal key, the script tree and key paths, so a signer can verify Taproot change.

MuSig2 fields (BIP 373)

MuSig2 (BIP 327) lets several people sign for one aggregate Taproot key, but it needs an extra round: each signer first shares a public nonce, then a partial signature. BIP 373, by Ava Chow, adds fields for this: the participants' public keys (PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS), each signer's public nonce (PSBT_IN_MUSIG2_PUB_NONCE) and partial signatures (PSBT_IN_MUSIG2_PARTIAL_SIG). The PSBT therefore passes between the signers twice. See the multisig guide for how MuSig2 fits with other multisig designs.

Silent payments and PSBTs (BIPs 375 and 376)

Silent payments (BIP 352) create the recipient's output from the sender's input keys, so the output script can't be known until all inputs are fixed and their keys are available. Two proposals extend PSBT v2 to handle this:

• BIP 375, sending: an output can carry the recipient's silent payment keys instead of a script. Each signer adds an ECDH share for the inputs it controls, with a BIP 374 DLEQ proof that lets other participants check the share was computed correctly without seeing any private key. Once every eligible input has a share, the output script is computed, and only then are signatures added.
• BIP 376, spending: adds the tweak (PSBT_IN_SP_TWEAK) and spend key derivation path a signer needs to sign for a silent payment output it received.

PSBTs for multisig coordination

PSBTs are the standard way to coordinate a multisig spend. The coordinator creates and updates the PSBT, including the witness script and every cosigner's key paths. Each cosigner signs on its own device and returns its copy. Signers can work at the same time on separate copies; the Combiner merges them, and BIP 174 specifies that merging is order-independent when there are no conflicting fields. BIP 174 includes a worked 2-of-3 multisig example. The multisig guide covers setup and backups.

Air-gapped workflows

Because a PSBT holds everything a signer needs, a signing device never has to see the internet. A common pattern is:

1. A watch-only wallet, which holds only public keys or a descriptor, builds the PSBT.
2. The PSBT is moved to the offline device as a QR code (sometimes split across several frames) or a file on a memory card.
3. The device shows the transaction details, signs, and returns the signed PSBT the same way.
4. The online wallet finalizes and broadcasts.

The protection only works if you read what the device shows: the destination address, the amount and the fee. A compromised computer can put anything in a PSBT; the signer's screen is the place to check it.