Abstract
Partially Signed Bitcoin Transactions have been the coordination mechanism for multi-party and hardware-wallet-assisted signing since BIP-174 shipped in 2017. BIP-370, which specifies PSBT version 2, addressed structural limitations in the original format that made it awkward to construct transactions incrementally and impossible to represent certain taproot-era constructs cleanly. Adoption across hardware wallet vendors and coordinator software has been uneven. This post examines what PSBT v2 changed, where the ecosystem stands heading into 2026, and what gaps remain for multisig coordinators building on the format.
What BIP-370 Actually Changed
The core change in PSBT v2 is the separation of transaction construction from transaction signing. In PSBT v0, the unsigned transaction had to be finalized before inputs and outputs could be assigned their per-input and per-output maps. This made incremental construction workflows, where different parties add inputs at different times, technically valid but awkward to represent. PSBT v2 introduces explicit input and output count fields and removes the requirement for a fully formed unsigned transaction in the global map. Inputs and outputs are added as independent maps, and the transaction is only assembled at finalization. This matters concretely for protocols like PayJoin v2, where a receiver needs to inject an additional input after the sender has constructed their portion, and for descriptor-based wallets building complex spending conditions over multiple signing rounds.
Taproot and Tapscript Representation
PSBT v2 also adds first-class fields for taproot constructs: the PSBT_IN_TAP_KEY_PATH_SIG field for key-path spends, PSBT_IN_TAP_SCRIPT_PATH_SIG for script-path signatures, and fields for the control block and leaf scripts needed to reconstruct the Merkle proof. PSBT v0 had no native way to represent these, forcing tooling authors to use proprietary extension fields or wrap taproot data awkwardly. The Ledger Bitcoin app as of firmware 2.x and the Coldcard Mk4 firmware 6.x both added PSBT v2 support through 2024 and 2025, covering most of the taproot field set. Foundation Devices Passport and BitBox02 support followed on similar timelines.
Where Coordinator Software Lags
Hardware wallet support has matured faster than coordinator tooling. Sparrow Wallet and Nunchuk both support PSBT v2 for their primary workflows, but library-level support varies. The bitcoinlib Python library added v2 parsing in a 2024 release but does not yet expose the full construction API for incremental input addition. The rust-bitcoin crate has more complete support and is the basis for several Lightning and DLC coordination tools. The gap matters most for teams building custom multisig coordinators: they frequently discover that a hardware wallet firmware accepts a v2 PSBT but their coordinator library serializes v0, resulting in silent downgrade or rejection depending on the device’s strictness setting. Explicit version negotiation between coordinator and signer is not standardized, which remains a genuine interoperability friction point.
Practical Guidance for Integrators
Teams integrating PSBT v2 should validate against the BIP-370 test vectors published in the Bitcoin repository before testing against physical devices. The version byte in the global map (key 0x00, value 0x02000000) is the first thing strict parsers check. When constructing PSBTs programmatically, prefer rust-bitcoin or the Go btcsuite/btcd implementation for v2 compliance. If coordinating with multiple hardware wallet models, maintain a compatibility matrix that tracks which firmware versions accept v2 and which silently downgrade: the behavior on version mismatch is not consistent across vendors and can produce confusing signing failures in mixed-firmware multisig setups.