You have a key. So does someone on another continent. So does a third person whose time zone you've never quite worked out. None of you will ever be online at the same moment, and none of you trusts a single key to move the funds alone. For years, coordinating that signing process meant passing raw, partially-complete transaction blobs between devices with no standard way to attach the context each signer needed to verify what they were actually signing. One wrong byte, one missing input detail, and the whole thing collapsed silently.

BIP-174, which defined the Partially Signed Bitcoin Transaction (PSBT) format, solved that. It is a container format, not a new transaction type. Think of it as a legal docket traveling between counsel: each party adds their endorsement, and the file always tells the next reader exactly what has been executed and what remains outstanding.

What rides inside the envelope

A PSBT bundles several things that used to travel separately. The unsigned transaction sits at the top. Attached to each input are the previous output details (so a signing device can verify it is spending what it believes it is spending), the redeem script or witness script for multisig, and any signatures collected so far. Each signer reads what is there, adds their piece, and passes it on.

The format is deliberately modular. Hardware wallets, air-gapped laptops, and coordinator software can each handle a different role without needing to understand the full flow.

Here is a concrete walk-through. Priya and David run a 2-of-3 multisig treasury, with a third key held by their auditor. The coordinator, a laptop running Sparrow Wallet, builds the unsigned transaction, wraps it in a PSBT, and exports it. Priya's air-gapped machine imports the file via SD card, checks the destination address and fee against her own records, signs with her key, and exports the updated PSBT. David does the same, independently, on a separate device. The coordinator receives both returned PSBTs and performs the combiner role: it merges the two partial signatures into one file. Two of the three required signatures are now present. The coordinator finalizes the transaction, strips the metadata that was only needed for signing, and broadcasts the clean result.

The auditor's key was never needed. Neither Priya nor David had to be online at the same time. The coordinator never touched a private key.

A Coldcard receiving a PSBT by SD card and returning it the same way is not an edge case. It is the intended architecture, and it works precisely because the format is self-describing enough that the hardware device does not need to understand the coordinator's role to do its own job correctly.

The part that catches people off guard

The format does not enforce policy. Full stop. It does not know you wanted 2-of-3. It will not warn you if a signer provides a signature that fails to match the script. That enforcement lives in the Bitcoin consensus rules and in whatever coordinator software you are using. PSBT is a transport layer, not a policy engine, and a sloppy implementation can still produce a malformed final transaction that the network will reject without ceremony.

There is also a meaningful subtlety around Segwit inputs worth laying out carefully, because the two readings of the behavior are easy to conflate. Pre-Segwit inputs require the signing device to trust the input value reported by the PSBT, because the device cannot independently verify the full previous transaction in all contexts. Segwit inputs commit the value into the signature hash itself, so the device can verify it cryptographically. When a hardware wallet warns you about unverified input amounts, that is the distinction it is flagging. It is not paranoia. It is the protocol being precise about what it can and cannot prove.

So: should that warning concern you? Yes, if you are signing a pre-Segwit input on an air-gapped device and you have not verified the PSBT's reported amounts through a separate channel. No, if your inputs are Segwit and the device is doing the math itself.

PSBT version 2, defined in BIP-370, extended the format to allow inputs and outputs to be added incrementally, rather than requiring the transaction structure to be locked before signing begins. That matters for more complex protocols. Version 0 covers the overwhelming majority of multisig use cases in practice.

The real achievement here is not glamorous. It is interoperability, and the industry badly undervalues it. Before PSBT, a Coldcard and a Trezor coordinating on the same multisig wallet was a bespoke integration problem, the kind that required reading both vendors' documentation and hoping the edge cases matched. After PSBT, any software that speaks the format can hand off to any other. Walled gardens became participants in a common protocol.

For anyone running a self-custodied multisig setup, that interoperability matters more than almost any other technical property. The key risk in multisig is not usually cryptographic. It is operational: the wrong software, the incompatible format, the signer who cannot reconstruct the signing flow two years later when the funds actually need to move. PSBT does not eliminate that risk. But it shrinks it considerably by making the process legible to any conforming tool, not only the one you happened to use on setup day. The format that lets you sign on a Tuesday without the other parties present is also the format that lets you sign on a different device, in a different year, without starting over.