Skip to content
Back to skills

Psbt Flows

ASecurity

PSBT 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.

  • 31 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 8, 2026
ai-agentsexpressdebugging

Security analysis

A100/100

Scanned September 22, 2026

npx -y skills add claude-dev-suite/claude-dev-suite --skill psbt-flows --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Psbt Flows?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Psbt Flows
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/claude-dev-suite-psbt-flows/badge)](https://www.skillsdirectory.com/skills/claude-dev-suite-psbt-flows)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: bitcoin-hardware-psbt-flows
description: |
  PSBT 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.
allowed-tools: Read, Grep, Glob
---

# PSBT Signing Flow Patterns

A summary of how PSBTs flow through different hardware wallet
transports.

## Flow types

### USB direct (online signer)
```
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.

### microSD airgap (true offline)
```
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.

### QR airgap (animated QR / BCUR)
```
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.

### NFC tap
```
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.

## Coordinator role

For multisig, a **coordinator** wallet handles:
1. Build PSBT.
2. Send to signer 1, get partial sig.
3. Send to signer 2, get partial sig.
4. Combine + finalize.
5. Broadcast.

Coordinators:
- **Sparrow Desktop** — best for cross-vendor multisig.
- **Specter Desktop** — multisig + multiple HW.
- **Caravan** — web-based multisig.
- **Bitcoin Core** with HWI external signer — but HWI entered a
  maintenance-only wind-down in August 2026 (no new features, no new
  devices, repo to be archived once a drop-in replacement is ready),
  so weigh it before building on it: [hwi/SKILL.md](../hwi/SKILL.md).

## PSBT versions

- v0 (BIP174): widely supported; still the safe interop default as of
  September 2026.
- v2 (BIP370): required for the silent-payment fields below. Coldcard
  has parsed v2 since firmware 5.2.0 (October 2023); Sparrow made v2
  its internal PSBT representation in 2.4.0 (February 2026).

For multi-device multisig, **all** signers must agree on PSBT version
or coordinator transcodes between them.

## Silent payments (BIP352) on hardware

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.

### Sending: BIP375

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:

- Fail if any input spends a segwit version > 1 output.
- SIGHASH_ALL only — output scripts are derived from the number and
  position of the codes, which NONE/SINGLE would let move.
- No signature until every silent-payment output has a computed
  `PSBT_OUT_SCRIPT`; whoever fills those in must clear the Inputs
  Modifiable and Outputs Modifiable flags.

### Spending: BIP376

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.

### Why an airgapped signer can sign but cannot scan

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.

### Shipping support (as of September 2026)

- **BitBox02** firmware v9.21.0 (September 2024) — sending to BIP352
  addresses. The device returns a 33-byte ECDH share plus a 64-byte
  DLEQ proof over its own USB protocol so the host can re-derive and
  check the generated output; the same construction BIP375 later
  standardised as PSBT fields.
- **Sparrow** 2.3.0 (October 2025) — sending to silent-payment
  addresses; 2.4.0 (February 2026) — BIP375 PSBT fields and DLEQ
  proof verification for hardware-wallet sends; 2.5.0 (May 2026) —
  silent-payment *receiving* wallets, including airgapped hardware
  signers.

BIP374, BIP375, BIP376 and BIP392 are all still **Draft** status as of
September 2026.

## Cross-vendor multisig

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:
- Have its xpub at the declared path.
- Match key origin fingerprint.
- Recognize the wallet policy (Ledger requires explicit registration
  with HMAC).

## Common pitfalls

- **PSBT missing data**: device rejects if `non_witness_utxo` or
  `tap_internal_key` missing for the input type.
- **Path mismatch**: device can't find the key for declared
  derivation.
- **Multi-vendor wallet policy registration**: Ledger requires
  explicit wallet-policy + HMAC registration before multisig signing.
- **Stale PSBT**: signer signed an old version; coordinator must
  reconcile.
- **Silent-payment PSBT downgraded to v0**: the BIP375/BIP376 fields
  are v2-only, so a coordinator that transcodes down silently drops
  the ECDH shares, DLEQ proofs and tweaks.
- **Air-gap delays**: long PSBTs via QR/SD take minutes; users
  abandon.

## See also

- [hwi/SKILL.md](../hwi/SKILL.md)
- [multi-vendor-multisig/SKILL.md](../multi-vendor-multisig/SKILL.md)
- [../wallets/hd/SKILL.md](../../wallets/hd/SKILL.md)
- [../../protocol/psbt/SKILL.md](../../protocol/psbt/SKILL.md)
- [../../privacy/silent-payments/SKILL.md](../../privacy/silent-payments/SKILL.md)

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…