bitcoin-hardware-psbt-flowsPSBT signing flow patterns across HW vendors: USB direct, microSD airgap, QR airgap, NFC, multi-device coordination, silent-payment PSBT fields (BIP375/BIP376). USE WHEN: designing HW signing UX, debugging cross-device PSBT flow, supporting multi-vendor multisig or silent payments.
Independent GitHub snapshot · Automated classification · Original documentation governs
A summary of how PSBTs flow through different hardware wallet transports.
Host wallet ──── PSBT ────► HW (via USB)
◄── signed PSBT
Wallets: Trezor, Ledger, BitBox02, Coldcard via USB, Jade USB, Keystone (charging only).
Pro: fastest. Con: USB connectivity = potentially compromised host.
Host wallet → save PSBT to SD → eject → insert into HW → sign on
HW → eject → insert into Host
Wallets: Coldcard, Passport Core, Jade (with SD), Keystone.
Pro: no USB connection; truly airgapped. Con: SD card handling overhead.
Host wallet displays animated QR → HW reads via camera
→ HW signs → HW displays animated QR → Host reads
Wallets: Passport Core, Coldcard Q, Jade, Keystone, SeedSigner, Krux. Passport Prime scans QR too, but its USB-C data port, NFC and Bluetooth are all live (as of September 2026), so QR on Prime is a transport, not an airgap.
Pro: no physical connection. Con: scan time for big PSBTs.
BCUR (Blockchain Commons UR Format) is the standard encoding for multi-frame QR. Compatible wallets must understand BCUR.
Host (phone) → NFC tap to HW → HW signs → NFC tap back
Wallets: Coldcard Mk4 / Q, some others. Not Passport: Core has no radios at all (power-only USB-C, QR + microSD), and Prime's NFC carries only its Shamir backup KeyCards, not PSBTs (as of September 2026).
Pro: convenient with Android. Con: iOS NFC limited; PSBT size limits.
For multisig, a coordinator wallet handles:
Coordinators:
For multi-device multisig, all signers must agree on PSBT version or coordinator transcodes between them.
Three BIPs carry silent payments into the hardware signing path. All of their new fields are PSBTv2-only — BIP375 and BIP376 both mark them as requiring exclusion from v0.
BIP375 ("Sending Silent Payments with PSBTs", number assigned January 2025) lets a PSBT name a recipient by silent-payment code rather than by script, because the output script cannot be computed until every input is known.
PSBT_OUT_SP_V0_INFO = 0x09 — 33-byte scan key + 33-byte spend key.
PSBT_OUT_SCRIPT becomes optional when this is present.PSBT_OUT_SP_V0_LABEL = 0x0a — label index, so a signer can verify
that a silent-payment output is its own change.PSBT_IN_SP_ECDH_SHARE = 0x1d / PSBT_GLOBAL_SP_ECDH_SHARE = 0x07
— a*B_scan for one input, or for the sum over all eligible inputs.PSBT_IN_SP_DLEQ = 0x1e / PSBT_GLOBAL_SP_DLEQ = 0x08 — a 64-byte
BIP374 discrete-log-equality proof for the matching ECDH share.The DLEQ proof is what makes this safe on a device: a signer that does
not hold every input key can still verify the other signers' shares
before it computes and commits to PSBT_OUT_SCRIPT. Extra signer
rules that trip devices:
PSBT_OUT_SCRIPT; whoever fills those in must clear the Inputs
Modifiable and Outputs Modifiable flags.BIP376 ("Spending Silent Payment outputs with PSBTs", assigned February 2026, merged to the BIPs repo April 2026) covers the other direction:
PSBT_IN_SP_TWEAK = 0x20 — the 32-byte tweak recovered during
scanning.PSBT_IN_SP_SPEND_BIP32_DERIVATION = 0x1f — fingerprint + path for
the 33-byte spend key. It cannot reuse
PSBT_IN_TAP_BIP32_DERIVATION, whose keydata is a 32-byte x-only
key.The signer derives d = (b_spend + tweak) mod n, negates d if d*G
has an odd y-coordinate, and must fail if x(d*G) does not equal
the output key P in the witness UTXO — the tweak comes from the
Updater, and signing on an unverified one produces a valid signature
for a key the device does not control. Finalizers strip
PSBT_IN_SP_TWEAK and PSBT_IN_SP_SPEND_BIP32_DERIVATION once
PSBT_IN_FINAL_SCRIPTWITNESS is built.
The BIP376 tweak is handed to the device. Recovering it means
scanning the chain with the scan private key, which an offline signer
cannot do. BIP392 (sp() output descriptors, merged March 2026)
encodes the split directly: its spscan key expression holds the scan
private key plus the spend public key — exactly a watch-only
coordinator — while spspend holds both private keys. So the
coordinator scans and supplies tweaks; the hardware signer only ever
sees a spend-key derivation and a 32-byte tweak that it re-verifies.
BIP374, BIP375, BIP376 and BIP392 are all still Draft status as of September 2026.
Best practice: use descriptors with key origins:
wsh(sortedmulti(2,
[fp1/48'/0'/0'/2']xpub1.../<0;1>/*,
[fp2/48'/0'/0'/2']xpub2.../<0;1>/*,
[fp3/48'/0'/0'/2']xpub3.../<0;1>/*
))#chk
Each signer's device must:
non_witness_utxo or
tap_internal_key missing for the input type.