Timechain Wiki

PSBT and wallet descriptors

15 min read

PSBT (Partially Signed Bitcoin Transactions, BIP-174) and wallet descriptors are the unglamorous infrastructure that makes modern self-custody — particularly multisig and air-gapped signing — practical. PSBT is a standardized format for passing a not-yet-signed transaction between signing devices: one drafts it, each hardware wallet adds its signature, the fully-signed result is broadcast. This is what enables multi-vendor multisig and QR-code-only signing. Wallet descriptors are a standardized way of describing "this wallet is a 2-of-3 multisig built from these three extended public keys on this derivation path." Without the descriptor, holding all three seeds is not sufficient to reconstruct a multisig — the descriptor is the assembly instruction. For multisig setups it is a first-class backup artifact: an attacker with only the descriptor cannot spend funds, so it doesn't need full seed-level protection, but losing it can turn recovery from difficult into impossible. Keep copies with each key backup and with any collaborative partner.

Why this note matters

PSBT and descriptors are infrastructure rather than primary security features. They are easy to underweight — until a holder loses one and realizes it was load-bearing. The note matters because:

  • It establishes the descriptor as a first-class backup artifact for multisig setups. The synthesis is direct: losing the descriptor can turn multisig recovery from difficult to nearly impossible.
  • It explains the PSBT flow that underlies multi-vendor multisig and air-gapped signing. Holders adopting these configurations need to understand the mechanism, not just the buttons.
  • It surfaces the descriptor-as-disclosure-artifact question — descriptors contain xpubs, which can be used to monitor the wallet’s on-chain activity. The discipline around descriptor storage is different from seed storage.

What this is

PSBT (BIP-174)

PSBT is a standardized binary format for representing a Bitcoin transaction at various stages of signing. The lifecycle:

  1. Creator — a wallet (typically the coordinator) constructs an unsigned transaction structure, including inputs, outputs, and metadata needed for signing.
  2. Updater — additional information is added (UTXO data, derivation paths, scripts).
  3. Signer — each signing device receives the PSBT, identifies inputs it can sign, produces signatures, and updates the PSBT with them.
  4. Combiner — multiple signed PSBTs (from different signers) are merged into one PSBT containing all signatures.
  5. Finalizer — once enough signatures are present (e.g., 2-of-3 for multisig), the PSBT is converted to a final raw transaction.
  6. Extractor — the final transaction is extracted and broadcast.

In practice, the holder rarely sees these stages explicitly. The wallet software hides them. What the holder does see:

  • The coordinator (Sparrow, Specter, Nunchuk, Casa app, Unchained app, etc.) builds the transaction and displays a PSBT
  • The PSBT is transferred to a hardware wallet (via USB, QR code, microSD)
  • The hardware wallet displays the transaction, the holder confirms, the device signs
  • The signed PSBT goes back to the coordinator
  • For multisig, the process repeats with a second device
  • The coordinator finalizes and broadcasts

PSBT is the format that makes this multi-step, multi-device flow possible. Without PSBT (and its predecessors), each signing device would need to communicate directly with the others, requiring matched-vendor setups and substantially more coordination infrastructure.

Wallet descriptors

A wallet descriptor is a string that completely describes how to derive a wallet’s addresses from one or more extended keys. Examples:

  • wpkh([fingerprint/derivation-path]xpub.../0/*) — a native SegWit single-sig wallet
  • wsh(multi(2,[fp1/path]xpub1/0/*,[fp2/path]xpub2/0/*,[fp3/path]xpub3/0/*)) — a 2-of-3 multisig
  • tr([fingerprint/derivation-path]xpub.../0/*) — a Taproot single-sig wallet

The descriptor specifies:

  • The script type (P2WPKH, P2WSH, P2TR — i.e., what addresses the wallet generates)
  • The signing requirement (single-sig, multisig with threshold and ordering)
  • The extended public keys involved (xpubs, with their fingerprints and derivation paths)
  • The receive/change branch structure

A descriptor does not contain private keys. It cannot spend. But it fully specifies the wallet, allowing any compatible software to derive the same addresses, monitor on-chain activity, and (when combined with the private keys’ signatures) build valid spending transactions.

Why descriptors matter for multisig

For single-sig wallets, descriptors are mostly invisible. The wallet software constructs the descriptor from standard derivation paths; the holder doesn’t need to think about it.

For multisig, descriptors are load-bearing. The wallet is defined by:

  • Three (or N) extended public keys
  • A threshold (2-of-3, 3-of-5, etc.)
  • A specific ordering of the keys (in some multisig conventions)
  • A specific derivation path
  • A specific script type (the most common is P2WSH native-SegWit multisig; Taproot multisig is emerging)

Without the descriptor, holding all three seed phrases is not sufficient to reconstruct the wallet. The holder (or heir) would need to:

  • Determine which derivation path was used (BIP-48 paths are common but several variants exist)
  • Determine the script type (P2WSH? P2SH-P2WSH?)
  • Determine the key ordering (lexicographically sorted? holder-defined order?)
  • Determine the threshold (was it 2-of-3 or 3-of-5?)

Each variable is a brute-force search. With several unknowns combined, recovery becomes a non-trivial forensic exercise that may cost more in time and expert fees than it saves over having backed up the descriptor.

The synthesis is explicit: for any multisig setup, the wallet descriptor is a first-class backup artifact. It belongs with each key backup, with any collaborative partner, and ideally with the inheritance documentation.

When to use this

PSBT and descriptors are not “used” in the sense of being adopted — they are part of any modern Bitcoin wallet’s operation. The relevant question is which workflows expose the holder to them explicitly.

PSBT is explicit in:

  • Air-gapped signing (QR-only or SD-card-only workflows)
  • Multi-vendor multisig (different hardware wallets cooperating)
  • Coordinator-based workflows (Sparrow, Specter, Nunchuk, Casa, Unchained apps)
  • Cross-platform signing (mobile coordinator + desktop verification)

Descriptors are explicit in:

  • Setting up any multisig wallet
  • Recovering a multisig wallet to a new device
  • Migrating between coordinator software
  • Inheritance scenarios
  • Watch-only wallet setups (importing a descriptor without private keys)

For single-sig hardware-wallet users who stick to one vendor’s companion app, PSBT and descriptors operate invisibly. For anyone running multisig or air-gapped signing, they are load-bearing.

How it works in practice

PSBT flow for air-gapped signing

  1. The coordinator (Sparrow, Specter, Nunchuk on desktop) constructs the transaction. It generates a PSBT.
  2. The PSBT is displayed as a QR code (or written to a microSD card).
  3. The holder scans the QR code with the hardware wallet (or inserts the microSD).
  4. The hardware wallet displays the transaction details. The holder verifies addresses and amounts on the device screen.
  5. The holder confirms. The hardware wallet signs the PSBT internally.
  6. The signed PSBT is displayed as a QR code on the hardware wallet (or written back to microSD).
  7. The coordinator reads the signed PSBT.
  8. For multisig, the process repeats with another device.
  9. The coordinator finalizes the transaction and broadcasts it.

The pattern preserves the air gap: no direct USB or network connection between the hardware wallet and the coordinator. PSBT is the format that travels via QR or SD card.

PSBT flow for multi-vendor multisig

The same flow, but each signing device may be a different vendor. A 2-of-3 multisig could use:

  • Coldcard (key 1) — signs via microSD or QR
  • BitBox02 (key 2) — signs via USB
  • Foundation Passport (key 3) — signs via QR

The coordinator handles the format conversion between transport mechanisms. Each device signs the PSBT according to its own conventions; the signatures aggregate cleanly because PSBT is a vendor-neutral format.

Descriptor backup discipline

The descriptor is a string. It can be:

  • Written down by hand (long but feasible — typical multisig descriptors are 200–500 characters)
  • Printed and stored with seed backups
  • Saved as a file on durable media (USB drive with redundancy, etched into metal)
  • Held by a collaborative partner (most providers store the descriptor as part of their service)

The synthesis recommendation: store the descriptor alongside each seed backup. If a key is recovered from its location, the holder finds the descriptor with it. For collaborative custody, the partner holds a copy by default — but the holder should also retain an independent copy to preserve sovereign recovery.

Watch-only wallets via descriptors

A common operational pattern: the holder imports the descriptor into a watch-only wallet (Sparrow’s wallet view, BlueWallet’s watch-only mode) on a network-connected device. The watch-only wallet shows balances and transaction history without ever having access to private keys.

This is operationally valuable: the holder can monitor cold-storage balance from a phone without exposing keys. It also has a privacy implication: anyone with the descriptor can see the wallet’s on-chain activity.

Tradeoffs and considerations

The descriptor is sensitive but not seed-sensitive

An attacker with the descriptor alone cannot spend funds. They can:

  • See the wallet’s balance
  • See the transaction history
  • Derive future addresses
  • Correlate the wallet across services (privacy implication)

They cannot:

  • Sign transactions
  • Move funds in any way
  • Access the underlying private keys

The descriptor’s protection level should be lower than seed protection but higher than ordinary documents. It is roughly comparable to financial-account-statement sensitivity — not catastrophic if exposed, but worth not leaving in obvious places.

The asymmetric protection enables practical patterns: the descriptor can be stored in a password manager (safe enough for its sensitivity level), with each key backup (so finding any key also finds the descriptor), or with a trusted partner (lawyer, executor, collaborative-custody provider).

PSBT files can leak metadata

A PSBT file contains the transaction structure, including:

  • Inputs (the UTXOs being spent — which reveals the wallet’s holdings to anyone seeing the PSBT)
  • Outputs (the destinations)
  • Derivation paths (which can leak wallet structure)
  • Sometimes UTXO commitments and other metadata

This matters for two scenarios:

  • In-transit PSBT exposure — a PSBT sent via email or cloud storage during signing exposes the wallet’s structure. Air-gapped signing via QR or SD card avoids this.
  • Discarded PSBT files — a PSBT saved to disk and then deleted may be recoverable from drive sectors. For substantial holdings, treat PSBTs as ephemeral and ensure they don’t persist after signing.

For most personal-use cases this is minor. For privacy-conscious holders, the PSBT handling discipline matters.

Descriptor format is evolving

Multiple descriptor formats exist:

  • Output descriptors (BIP-380 family) — the modern standard, used by Bitcoin Core and most contemporary wallets
  • Bitcoin Core wallet descriptors — the original implementation, mostly aligned with BIP-380
  • Vendor-specific formats — some hardware wallets and coordinators have historically used proprietary formats; most have migrated to output descriptors

For multisig descriptors specifically, the format and quirks vary slightly between coordinators. Best practice: store the descriptor in the canonical output-descriptor format (BIP-380), which is the format Sparrow, Specter, Bitcoin Core, and most modern tools all consume.

The “miniscript” expansion

Miniscript is a higher-level expression language for Bitcoin scripts, used in some advanced descriptors to express conditions like time locks, conditional spending paths, and recovery clauses. It is becoming part of the descriptor standard.

For most personal-use multisig, miniscript is invisible. For configurations involving time locks (e.g., “anyone can spend after 5 years if no signature is provided”), miniscript is the descriptor language that expresses the conditions.

Coordinator compatibility

A multisig wallet built with one coordinator (e.g., Sparrow) can be imported into another (e.g., Specter, Nunchuk) if the descriptor is portable. In practice, most coordinators are now interoperable for output-descriptor multisig — but the holder should test this before committing to a coordinator for substantial holdings.

The discipline: don’t be locked to one coordinator. Store the descriptor independently of any specific coordinator’s wallet file. Verify that the wallet can be reconstructed in at least one alternative coordinator.

Comparison with alternatives

PSBT and descriptors don’t really have alternatives — they are infrastructure layers. The question is whether to use them well or poorly.

PracticeCoordinator supportHardware compatibilityRecovery viability
BIP-174 PSBT (standard)UniversalUniversal modern hardwareStrong
Pre-PSBT vendor formatsLegacy onlyLimitedWeak — migration needed
BIP-380 output descriptorsModern coordinatorsUniversal modern hardwareStrong
Vendor-specific multisig configsCoordinator-lockedVendor-lockedWeak — reconstruction difficult
Bitcoin Core wallet.datBitcoin Core onlyIndirect via descriptorsMedium — requires importing
Hand-written derivation-path notesNoneNoneVariable — depends on completeness

The take: use standard PSBT (BIP-174) and standard output descriptors (BIP-380). Store the descriptor explicitly. Verify cross-coordinator portability for substantial holdings.

Tiered recommendations

Tier 0: No descriptor concerns. Single-sig hot wallet operates without explicit descriptor handling.

Tier 1 (50K, single-sig hardware): Descriptor is automatically generated by the wallet. For peace of mind, the holder may export the descriptor and store it alongside the seed backup — but for standard single-sig, recovery from seed alone is straightforward across compatible wallets.

Tier 2 (1M+, multisig): Descriptor is load-bearing. Export the descriptor at wallet setup. Store a copy alongside each seed backup. If using collaborative custody, confirm the partner retains a copy. Test descriptor-only recovery at least once (import descriptor into a fresh coordinator, verify addresses match).

Tier 3 (>$1M, multisig with geographic distribution): Same as Tier 2, with additional rigor: descriptor copies in multiple locations; format verification (BIP-380 canonical); cross-coordinator portability verified; descriptor included in inheritance documentation with clear instructions.

In all tiers running multisig, the principle is: a multisig setup with lost descriptor is a recovery problem most holders cannot solve without expert help.

Common pitfalls

Lost descriptor on a self-managed multisig. The most consequential pitfall. Three seed phrases backed up cleanly; descriptor discarded after setup. Recovery requires reconstructing the wallet’s derivation path, script type, and key ordering through search.

Coordinator-specific wallet files only. Saving the wallet only as a Sparrow .json or a Specter wallet.json ties recovery to that coordinator’s continued availability. Export the descriptor in canonical format and store it independently.

Descriptor stored only on a network-connected device. A descriptor in a cloud-synced password manager is fine for sensitivity; a descriptor on a network-connected device that is otherwise the only copy is a single-point-of-failure for the descriptor’s role.

Treating PSBT files as documents. PSBTs in cloud-synced folders, email attachments, or saved-and-forgotten downloads leak metadata. For air-gapped signing, transfer via QR or SD card; don’t persist PSBT files.

Using non-standard derivation paths or script types. A multisig with non-standard paths can be recovered only with explicit knowledge of those paths. Stick to BIP-48 paths and P2WSH (or P2TR for Taproot multisig) script types unless there is a specific reason not to.

Ignoring miniscript. For configurations with timelocks, conditional spending, or recovery clauses, the descriptor includes miniscript expressions. Holders adopting these configurations should verify that the coordinator and hardware wallets they use support the miniscript features in question.

Skipping descriptor cross-coordinator verification. Assume the wallet works because the original coordinator shows the right balance. Then discover at recovery time that the descriptor’s format is subtly incompatible with the available recovery coordinator.

Descriptor stored without context. Heirs find a 400-character string and have no idea what it is. The descriptor should be accompanied by minimal instructions: “this is the wallet configuration; import it into a coordinator (Sparrow, Specter, Nunchuk, etc.) to view the wallet.”

Tooling and resources

The synthesis document (canonical for the section):

  • Bitcoin Self-Custody & Security: A Synthesis of Contemporary Best Practices, LegacyCipher discussion, April 2026 — descriptor treated as a first-class backup artifact for multisig.

Underlying specifications:

  • BIP-174 — Partially Signed Bitcoin Transactions, Andrew Chow (2017). The PSBT format.
  • BIP-380 family — Output Script Descriptors, Andrew Chow et al. The descriptor specification.
  • BIP-48 — Multi-Script Hierarchy for Multi-Sig Wallets, Fontaine, Marek Palatinus, Andrew Chow. The standard derivation paths for multisig.
  • BIP-322 — Generic Signed Message Format (related but distinct, used for signed-challenge messages).

Coordinator software:

  • Sparrow Wallet — desktop, full-featured, multisig-capable, BIP-380 descriptor native
  • Specter Desktop — desktop, multisig-focused, BIP-380 descriptor native
  • Nunchuk — desktop and mobile, full-featured, BIP-380 native
  • Bitcoin Core (built-in) — for the deeply technical; full descriptor support
  • Casa app — proprietary but standards-compatible
  • Unchained app — proprietary but standards-compatible

Primary practitioner sources:

  • Andrew Chow — author of PSBT and the output-descriptor specifications; primary technical reference
  • Unchained — practitioner-oriented descriptor handling guides
  • Lopp — Multisig Hardware Signing Performance reports (covers PSBT processing performance)

As of 2026-05-14: PSBT (BIP-174) is stable and universally supported. Output descriptors (BIP-380 family) are the modern standard and widely supported in active development; some older or legacy coordinators may still use earlier descriptor formats. New multisig setups should use BIP-380 output descriptors.

Open questions for further development

  • How does the post-Taproot multisig landscape change descriptor handling? Taproot’s MAST (Merklized Alternative Script Trees) and Schnorr signatures introduce new descriptor patterns; the operational practice is still settling.
  • The miniscript expansion enables time-locked recovery and conditional spending paths. Should these be treated as part of the basic configuration ladder, or are they advanced enough to live in a separate cluster?
  • What is the right framework for assessing coordinator longevity risk? Sparrow, Specter, Nunchuk, and Bitcoin Core are all viable for descriptor-import recovery — but specific coordinator behaviors and quirks may differ. Should the framework recommend a “test recovery in alternative coordinator” practice as part of the setup checklist?
  • The descriptor-storage question — where to keep the descriptor — is unsettled in the synthesis. Different practitioners recommend different patterns. Should the framework codify a specific recommendation, or is the right answer holder-dependent?

The framing lenses:

Other storage and key concept notes:

Multisig and collaborative custody — where descriptors matter most:

Hardware wallets:

Operational discipline:

Inheritance:

The principal technical references:

The sub-MOC home:

Graph View

Backlinks