Bitcoin PSBT Workflow Guide: Partially Signed Transactions

What Is a PSBT?

A Partially Signed Bitcoin Transaction (PSBT) is a standardized binary format defined in BIP 174 that allows multiple parties to collaboratively construct and sign a Bitcoin transaction without exposing private keys. Before PSBTs, there was no universal way to pass an unsigned transaction between wallets, coordinators, and signing devices. Each tool used its own proprietary format, making interoperability painful.

PSBTs solve this by defining a container that carries everything a signer needs: the unsigned transaction, previous UTXO data, redeem scripts, witness scripts, BIP 32 derivation paths, and partial signatures. The format separates transaction construction from signing, enabling workflows where an online watch-only wallet creates the transaction and an offline cold storage device signs it.

PSBT Roles and Workflow

BIP 174 defines six operator roles that process a PSBT in sequence. A single entity can fill multiple roles (and often does), but the separation matters for security-critical setups like multisig coordination and air-gapped signing.

The data flow is linear: Creator → Updater → Signer(s) → Combiner (if multiple signers) → Finalizer → Extractor → broadcast. For a deeper look at how Bitcoin transactions move from creation to confirmation, see our transaction lifecycle guide.

Multisig Coordination with PSBTs

The primary use case for PSBTs is coordinating multisig transactions where multiple parties must sign before funds can move. Here is a step-by-step 2-of-3 multisig workflow:

1. Three participants (Alice, Bob, Carol) each hold a key. A 2-of-3 script descriptor is created and imported into a coordinator wallet such as Sparrow or Specter.
2. Alice wants to send funds. The coordinator constructs a PSBT with inputs from the multisig address and the desired outputs. The Updater adds UTXO data, redeem/witness scripts, and derivation paths for all three keys.
3. Alice signs the PSBT with her hardware wallet. The PSBT now contains one partial signature.
4. The partially signed PSBT is sent to Bob (via file, QR code, or network). Bob verifies the transaction details on his device and signs. The PSBT now contains two partial signatures, meeting the 2-of-3 threshold.
5. The Finalizer constructs the complete witness data and the Extractor produces a raw transaction for broadcast.

Alternatively, Alice can send unsigned copies to both Bob and Carol in parallel. Each signs independently, and the Combiner merges the two PSBTs before finalization. Use our multisig planner to evaluate different quorum configurations.

PSBT Binary Format

Every PSBT starts with the 5-byte magic header 0x70736274ff: the first four bytes spell "psbt" in ASCII, followed by separator byte 0xff. This ensures non-PSBT parsers reject the data immediately. The body consists of three map types: one global map, followed by one input map per transaction input and one output map per output.

Each map is a sequence of key-value pairs terminated by a 0x00 byte. Keys consist of a compact-size length, a type byte, and optional key data. Values use the same compact-size length prefix. Within a map, each full key (type + keydata) must be unique and keys must appear in ascending byte order.

Transport formats: PSBTs are commonly Base64-encoded for text transmission, or encoded as animated QR codes using the Uniform Resource (UR) standard from Blockchain Commons for air-gapped devices. SD cards and NFC are also used for hardware wallet communication.

Key Use Cases

Hardware Wallet Signing

PSBTs enable a clean separation between transaction construction and signing. A watch-only wallet on an internet-connected computer builds the PSBT, then transfers it to an offline signing device via USB, SD card, QR code, or NFC. The device signs without ever exposing seed phrases or private keys to the network. This air-gapped workflow is the standard for self-custody setups. For hardware device comparisons, see our hardware wallet comparison.

CoinJoin and Collaborative Transactions

CoinJoin protocols combine inputs and outputs from multiple users into a single transaction to improve privacy. PSBTv2 (BIP 370) is particularly well-suited for this because it allows inputs and outputs to be added after initial creation. Wasabi Wallet uses the WabiSabi protocol for coordinator-facilitated CoinJoins, and Payjoin (BIP 78) uses PSBTs as the interchange format between sender and receiver.

Lightning Channel Funding

LND supports opening Lightning channels via PSBT, allowing external wallets (including hardware wallets) to fund channel opens. This enables cold storage-backed Lightning channels where the funding transaction is signed by an air-gapped device. The signed PSBT must only be published by the Lightning node in the proper funding flow order: publishing it independently can lock funds in a 2-of-2 multisig with no cooperative recovery path.

Tool Compatibility Matrix

PSBT support is now near-universal across Bitcoin tooling. The following matrix covers the most widely used software wallets, coordinators, and hardware devices.

Use our PSBT inspector to decode and analyze any PSBT, or the transaction decoder to examine the finalized raw transaction.

PSBTv0 vs PSBTv2 (BIP 370)

BIP 370 introduced PSBTv2 to address the primary limitation of the original format: once the Creator sets the global unsigned transaction in PSBTv0, inputs and outputs cannot be added or removed. This makes v0 unsuitable for interactive protocols where participants need to contribute inputs (CoinJoin, Payjoin).

PSBTv2 removes the global unsigned transaction entirely. Instead, transaction data is decomposed into individual fields in per-input maps (PSBT_IN_PREVIOUS_TXID, PSBT_IN_OUTPUT_INDEX, PSBT_IN_SEQUENCE) and per-output maps (PSBT_OUT_AMOUNT, PSBT_OUT_SCRIPT). A new PSBT_GLOBAL_TX_MODIFIABLE bitfield controls whether inputs and outputs can still be added. PSBTv2 also introduces a new Constructor role responsible for adding inputs and outputs.

PSBTv2 is intentionally incompatible with PSBTv0. There is no version 1: version numbers jump from 0 to 2. Not all tools support v2 yet, so verify compatibility before using it in production workflows.

Taproot and PSBTs (BIP 371)

BIP 371 extends the PSBT format to support Taproot (BIP 341/342) transactions. It adds new input fields for Schnorr signatures: key path signatures (PSBT_IN_TAP_KEY_SIG), script path signatures (PSBT_IN_TAP_SCRIPT_SIG), leaf scripts (PSBT_IN_TAP_LEAF_SCRIPT), and Taproot-specific BIP 32 derivation data (PSBT_IN_TAP_BIP32_DERIVATION). The internal key (PSBT_IN_TAP_INTERNAL_KEY) is required because the output key is tweaked with the Merkle root per BIP 341, and signers need the original internal key to determine whether they can sign.

New output fields (PSBT_OUT_TAP_INTERNAL_KEY, PSBT_OUT_TAP_TREE, PSBT_OUT_TAP_BIP32_DERIVATION) allow coordinators to describe P2TR change outputs so that signers can verify change addresses belong to the same wallet. For background on Taproot's design, see our Taproot and Schnorr signatures explainer.

Security Considerations

PSBTs improve security by separating construction from signing, but they do not guarantee transaction integrity by themselves. Every signer must independently verify transaction details (outputs, amounts, change addresses, fees) before signing. A compromised coordinator could alter outputs between signing rounds.

A historical fee attack exploited the fact that SegWit signing only requires the witness UTXO (amount + scriptPubKey), not the full previous transaction. An attacker could lie about the input amount, tricking signers into overpaying fees. Hardware wallets now mitigate this by requiring the full non-witness UTXO even for SegWit inputs: Trezor enforces this since firmware 1.9.1/2.3.1, and Ledger shows a warning if full UTXO data is missing.

PSBTs have no built-in encryption or authentication. The binary data is plaintext, so the transport layer must handle confidentiality if transaction details are sensitive. For sighash type considerations, see our sighash types reference.

PSBT-Related BIPs

The PSBT ecosystem has expanded beyond the original BIP 174. The following specifications build on the format for advanced use cases:

• BIP 174: original PSBT format (v0), universally adopted since Bitcoin Core v0.17
• BIP 370: PSBTv2 with mutable inputs/outputs for collaborative protocols
• BIP 371: Taproot PSBT fields for Schnorr signatures and script trees
• BIP 372: pay-to-contract tweak fields for PSBT
• BIP 373: MuSig2 PSBT fields for n-of-n Schnorr multisignatures
• BIP 375: silent payment support in PSBTs (merged 2025)

For programmable spending conditions beyond standard multisig, see our guides on Bitcoin Script programmability and Miniscript spending policies.

Frequently Asked Questions

What does PSBT stand for in Bitcoin?

PSBT stands for Partially Signed Bitcoin Transaction. It is a binary format defined in BIP 174 that allows a Bitcoin transaction to be constructed by one party and signed by one or more others. The "partially signed" designation means the PSBT can carry zero, some, or all required signatures at any point in its lifecycle.

How do I create a PSBT in Bitcoin Core?

Use walletcreatefundedpsbt to create a PSBT with automatic input selection and change output creation. For manual control, use createpsbt to specify exact inputs and outputs, then utxoupdatepsbt to add UTXO metadata. Sign with walletprocesspsbt, merge multiple signatures with combinepsbt, and finalize with finalizepsbt which returns the broadcast-ready hex transaction.

Which hardware wallets support PSBTs?

All major hardware wallets support PSBTs: Coldcard (SD card, NFC, QR), Trezor (USB), Ledger (USB, Bluetooth), BitBox02 (USB), Foundation Passport (SD card, QR), SeedSigner (QR), Blockstream Jade (USB, Bluetooth, QR), and Keystone (QR). The transfer method varies by device: air-gapped wallets like Coldcard, Passport, and SeedSigner use SD cards or QR codes, while USB-connected devices like Trezor communicate directly with coordinator software.

What is the difference between PSBTv0 and PSBTv2?

PSBTv0 (BIP 174) stores a complete unsigned transaction in the global map, which cannot be modified after creation. PSBTv2 (BIP 370) removes this global transaction and decomposes it into per-input and per-output fields, allowing participants to add inputs and outputs after initial creation. This makes PSBTv2 suitable for collaborative protocols like CoinJoin and Payjoin where multiple parties contribute UTXOs. PSBTv2 also introduces the Constructor role and a modifiability bitfield.

Can PSBTs be used for multisig wallets?

Yes. Multisig coordination is the primary use case for PSBTs. In an m-of-n setup, a coordinator creates the PSBT and distributes it to signers. Each signer adds their partial signature independently. The Combiner merges all copies, and once the threshold is met, the Finalizer produces the broadcast-ready transaction. Tools like Sparrow, Specter Desktop, and Nunchuk serve as multisig coordinators that manage this workflow. See our multisig setup comparison for coordinator options.

Are PSBTs safe to share?

PSBTs contain transaction details and public key information but never contain private keys. Sharing a PSBT reveals which UTXOs you are spending, the destination addresses, and your extended public key derivation paths. This is a privacy consideration, not a security risk to your funds. A recipient cannot steal funds from a PSBT: they can only add their own signature if they hold a required key.

How do PSBTs work with Taproot transactions?

BIP 371 adds Taproot-specific fields to the PSBT format. For key path spends, the signer produces a Schnorr signature stored in PSBT_IN_TAP_KEY_SIG. For script path spends, the leaf script and control block are included alongside per-leaf signatures in PSBT_IN_TAP_SCRIPT_SIG. The internal key (PSBT_IN_TAP_INTERNAL_KEY) is required because the output key visible on-chain is tweaked per BIP 341.

This guide is for informational purposes only and does not constitute financial or security advice. PSBT tooling and BIP specifications evolve over time. Always verify tool compatibility and review transaction details on your signing device before approving any transaction. Data is based on publicly available specifications and documentation.