A PSBT carries context, not private keys
A raw unsigned transaction does not always contain enough information for an offline signer to calculate fees, identify the previous outputs or understand the intended wallet policy. BIP174 defines a keyed container that can carry the unsigned transaction plus UTXO, derivation, script and signature data.
The container may include sensitive wallet metadata, but it must never contain a seed or private key. Treat a PSBT as untrusted input until a signer has independently parsed and displayed the transaction it represents.
Roles form a controlled pipeline
The original PSBT workflow describes creator, updater, signer, combiner, input finalizer and transaction extractor roles. One application may perform several roles, while a multisignature or air-gapped design can separate them across devices and people.
Combining PSBTs merges compatible fields and signatures; it does not turn conflicting transactions into one valid transaction. Finalisation constructs the final scriptSig and witness for each input, and extraction produces the network transaction only after every required input is final.
Every signer verifies the full intent
A signer should verify all inputs, recipient outputs, change outputs, fee amount, fee rate and the policy it is expected to satisfy. A trusted display is important because the online coordinator may be compromised or may have misunderstood the payment.
A valid signature authorises the exact transaction digest covered by the signature. It does not certify that the recipient is genuine or that the fee is sensible. Human verification remains part of the security boundary.
Air gaps reduce connectivity, not the need for trust checks
An air-gapped signer can receive a PSBT through QR codes, removable media or another one-way workflow. Keeping the key system offline reduces remote attack surface, but the transfer channel can still carry malformed data, tracking metadata or an unintended transaction.
Use deterministic, documented transfer procedures; verify the payload on the signing device; and return only the signed PSBT. Test the entire recovery and signing route with regtest, Signet or a small amount before relying on it for significant funds.
Versions and script types require compatible fields
PSBT version 0 from BIP174 centres the workflow on one global unsigned transaction. BIP370 defines PSBT version 2, which represents transaction fields more flexibly and supports workflows where the transaction can be modified under explicit rules before signing.
Taproot inputs require additional key-path and script-path data defined by BIP371. Wallets and signers must agree on supported PSBT versions, script types and proprietary fields; unknown support should be tested rather than assumed.
Visual recap
A transaction without travelling keys
The PSBT moves through reviewed stages; private keys remain inside their signers.
Create proposal
Add UTXO and policy context
Verify on each signer
Collect signatures
Finalise inputs
Extract and broadcast
Key vocabulary
Terms worth knowing
- PSBT
- A keyed container that carries an unsigned transaction, signing context and partial signatures between workflow roles.
- Finalizer
- The role that constructs final scriptSig and witness data after required signatures and fields are present.
- Air gap
- An operational separation where the signing system has no direct network connection.
Worked example
A coordinator proposes an unexpected change output
Two offline signers receive a PSBT whose recipient is correct but whose change output does not match the wallet descriptor they expect.
- 1Reject rather than sign
- 2Verify all input UTXOs
- 3Compare the change script with the descriptor
- 4Rebuild the proposal on a trusted coordinator
- 5Repeat independent review on every signer
PSBT coordinates data; it does not make the coordinator trustworthy. Each signer remains responsible for the exact transaction it authorises.
Common misconceptions
What learners often get wrong
Misconception
An air-gapped signer can safely approve any imported PSBT.
More accurate
Imported data is untrusted and must be parsed, displayed and reviewed on the signing system.
Misconception
A partial signature reveals the signer's private key.
More accurate
Correct signature generation does not transmit the private key, though poor implementations or nonce failures can still create cryptographic risk.
Try it yourself
Write a three-signer PSBT ceremony checklist.
- Name each workflow role
- Define a trusted display requirement
- Verify inputs, recipient, change and fee
- Define PSBT transfer and comparison
- Test finalisation and recovery without real funds
Use fictional values and public information only. Never enter seed words, private keys or other wallet secrets into a learning exercise.
Key takeaways
- A PSBT carries transaction context and signatures, not private keys.
- Separate roles make multi-device and multisignature workflows auditable.
- Every signer must independently verify inputs, outputs, change, fees and policy.
- An air gap reduces remote connectivity but does not make imported data trustworthy.
- BIP370 and BIP371 extend PSBT workflows for version 2 and Taproot data.
Lesson recap
Check what you learned
Reveal each model answer, then honestly mark whether you understood it or need another review.
1 of 3
Recall
If an online coordinator creates a well-formed PSBT, may an offline signer safely approve it without reviewing the outputs?
References
