What is a PSBT?

A "PSBT" (partially signed bitcoin transaction) is a portable file format that separates the job of building a transaction from the job of signing it.

PSBTs are used by "coordinator" software and signing devices to transfer transaction data between them. The coordinator software constructs the PSBT, then the signing device receives it, verifies the details on its own screen, and adds its signature. The PSBT carries all the information the signing device needs to do this without ever going online.

Every hardware wallet workflow covered in this category relies on PSBTs.

What is a PSBT and Why Does it Exist?

Before "BIP174" standardized the PSBT format in 2017, signing a Bitcoin transaction required the private key and the signing software to be on the same device. There was no standard format for handing an unsigned transaction to an offline device and receiving a signed one back.

PSBT solved this by creating a structured carrier format. The coordinator software builds the transaction and packages it into a PSBT file, along with all the supporting data the signing device needs. The signing device receives the PSBT, displays the transaction details independently on its own screen for verification, adds its signature once approved, and returns the modified PSBT. The private key never leaves the device. The coordinator never sees it.

You can think of a PSBT like a contract prepared by a law firm and sent to a client for signature. The firm drafts every detail and packages it to be sent to the client. The client reads it, signs it, and sends it back. In Bitcoin, the coordinator is the firm and the signing device is the signatory.

Prior to 2017, different wallet software and hardware used proprietary formats for this handoff. A Sparrow-constructed transaction could not be signed on a Trezor, or a Ledger-constructed one on a Coldcard, without some type of conversion. BIP174 standardised the format so that any BIP174-compliant coordinator can work with any BIP174-compliant signing device. This interoperability is why the Sparrow plus hardware wallet ecosystem functions as it does today.

How Does the PSBT Signing Workflow Work?

BIP174 defines six formal roles for the participants in a PSBT workflow. In practice, most setups compress these into two participants (the coordinator and the signing device), but the roles explain why the format is structured the way it is.

The six formal roles, in order:

1. Creator constructs the initial unsigned transaction structure and the empty PSBT shell.

2. Updater adds supporting data to each input and output, including UTXO information, derivation paths for the relevant keys, and redeem scripts where needed.

3. Signer is the hardware wallet. It receives the PSBT, verifies the transaction details on its own screen, and adds a partial signature to the per-input section.

4. Combiner merges multiple partially-signed PSBTs into one. In a 2-of-3 multisig workflow, each signing device returns its own partially-signed PSBT. The combiner produces a single PSBT containing all collected signatures.

5. Finalizer checks that all required signatures are present and prepares the transaction for broadcast.

6. Extractor generates the final network-serialized transaction from the finalised PSBT, ready to submit to the Bitcoin network.

In a typical single-signer hardware wallet setup, the coordinator plays Creator, Updater, Finalizer, and Extractor. The hardware wallet plays Signer. The Combiner role is not needed. The PSBT travels to the signing device unsigned and returns signed to the coordinator.

In multisig, the PSBT workflow is extended to accommodate multiple signers. The coordinator constructs the PSBT and passes it to the first signing device. That device verifies the transaction on its own screen and adds its signature. The partially-signed PSBT passes to the second signing device, which independently verifies and adds its own signature. The coordinator then combines the two partially-signed PSBTs and, once the threshold is met, finalizes and broadcasts.

The Combiner role is what makes multisig signing asynchronous. The two signing devices do not need to be present at the same time. Each signs its own copy of the PSBT independently and the coordinator assembles the result.

Air-gapped signing does not change the PSBT format. Whether the file travels over USB, MicroSD, NFC, or QR code, the data structure is identical. The physical channel changes. The format does not. See What is Air-Gapped Signing? for detail on how each channel works.

What Does a PSBT Actually Contain?

The PSBT is a binary file. It begins with a magic byte sequence, a fixed set of characters at the start of the file that identifies it as a valid PSBT so that any software reading it can confirm the format before parsing the rest of the data. That header is followed by structured data organized into three sections.

1. The global section holds the unsigned transaction itself and the PSBT version number. This is the skeleton of the transaction, holding the input references and output destinations without any signatures attached.

2. The per-input section has one entry for every transaction input. Each entry contains the UTXO being spent, the derivation path for the key needed to sign that input, any redeem script required for P2SH or multisig inputs, and, as signing progresses, the partial signatures from each signer.

3. The per-output section has one entry for every transaction output. This carries derivation paths for change addresses, and redeem scripts for any outputs going to multisig addresses.

A "UTXO" (unspent transaction output) is the Bitcoin balance record. When you receive Bitcoin, it is recorded as a UTXO, and then when you spend it, that UTXO is consumed as an input. The PSBT includes the full UTXO record for each input.

The UTXO data in the per-input section is the security-critical part. The signing device uses these values to calculate and display the actual amount being spent and the transaction fee. Without UTXO data, the device would see only abstract input references and could not show the user a meaningful spend amount. A malicious coordinator could inflate the fee by misrepresenting input values. The UTXO data allows the signing device to catch this independently, on its own screen, without trusting the coordinator's display.

The signing device is not taking the coordinator's word for what is being spent. It reads the UTXO data directly and computes the fee and spend amount independently.

What is the Difference Between BIP174 and BIP370?

"BIP174" (PSBT v0, 2017) defined the original standard for PSBTs. It established the six roles, the global/per-input/per-output structure, and the interoperability requirements that made cross-vendor signing workflows possible. It remains the dominant format in most current hardware wallet deployments.

"BIP370" (PSBT v2) extends the original format without replacing it. It splits the Creator role more cleanly, allowing transaction inputs and outputs to be added independently during construction rather than requiring the full transaction structure to be set before any data is added. It introduces per-input and per-output version fields, and improves handling of unconfirmed input chains.

The practical difference between these two for most users is minimal. Standard single-signer hardware wallet setups and 2-of-3 multisig workflows work correctly with BIP174. BIP370 becomes relevant for complex multi-party coordination, coinjoin-adjacent use cases, and scenarios where multiple participants need to contribute inputs interactively.

Coldcard devices support both PSBT v0 (BIP174) and PSBT v2 (BIP370), and uses the BBQR animated QR format to transmit large PSBTs across the air gap. Most major coordinator applications, including Sparrow, primarily use BIP174.