1. A container is not a safety certificate

A Partially Signed Bitcoin Transaction, or PSBT, is a standardized container for passing transaction data and signing information between software and devices. BIP 174 defines the original format, while later specifications extend its capabilities. The format lets participants collaborate without each tool performing every role. It does not certify that the proposed payment is desirable or that every field is truthful.

Separate the coordinator, signer and broadcaster in your mental model. A coordinator can assemble a transaction but should not receive private keys merely to do so. A signer authorizes particular spending conditions. A broadcaster relays the completed transaction. One application may perform multiple roles, which makes clear review boundaries more important.

2. Identify the payment outputs before looking at signatures

Read every output's destination and amount. A valid signature can authorize the wrong recipient if the signer approves incorrect transaction data. Compare the intended invoice or independently confirmed receiving address with what the signing device displays. Do not rely exclusively on the coordinator's summary screen when that same computer constructed the proposal.

Change needs scrutiny as well. A malicious proposal might label an attacker's address as change. Supported hardware signers can recognize change from wallet policy information, but recognition depends on the setup and data provided. If a device reports an unfamiliar output or cannot verify change, stop and understand why before continuing.

3. Reconcile the fee using trusted input information

Bitcoin's fee is the difference between input values and output values. A signer therefore needs reliable information about the outputs being spent. PSBT fields can carry previous transactions or relevant output data according to the input type and applicable specification. Treat a fee that cannot be established confidently as an unresolved problem, not a cosmetic warning.

Review both total fee and fee rate, including the size estimate used by the wallet. A large invoice does not justify an unexpectedly large fee by itself. Conversely, an apparently tiny fee may leave a payment waiting. Use current wallet estimates and your actual deadline rather than copying a numerical example from an old guide.

4. Confirm the wallet policy and signing scope

In multisignature use, the order and identities of cosigners, derivation paths and script type determine which addresses belong to the wallet. Displaying a familiar fingerprint is useful, but it is not the whole policy. Keep a trusted copy of the registered policy or descriptor so a fresh coordinator cannot silently redefine the wallet.

Signatures also have a scope described by their signature-hash mode. Standard wallet payments normally follow documented defaults. If a workflow asks you to approve unusual modes, advanced transaction modifications or incomplete output review, require a clear explanation from the tool's official documentation. Do not assume every signature commits to every possible field in the same way.

5. Finalization and broadcasting remain separate checks

Collecting signatures does not always produce a transaction ready to relay. Finalization constructs the required script data for the selected spending paths. A completed transaction may still fail policy checks, conflict with another spend or pay an unsuitable fee. Inspect the final result and transaction identifier before treating the workflow as complete.

Keep PSBTs private when possible. They can reveal balances, addresses, derivation information and business relationships even without private keys. Store only the audit material you need, and avoid public support uploads containing a real customer's full payment proposal.

Worked example: a two-person payment approval

A small organization uses a two-of-three wallet. Its coordinator creates a PSBT paying a supplier and returning change. The first signer compares the supplier's address with a previously confirmed invoice, checks the amount and confirms that the device recognizes the change policy. The second signer independently repeats those checks; the first signature is not evidence that the invoice itself was correct.

After finalization, the operator saves the transaction identifier and watches the chain status. If the supplier later reports no receipt, the organization checks that identifier and the supplier's actual payment terms before sending anything again. A second payment would create a new obligation rather than repair the first.

FAQ

Can I share a PSBT because it contains no secret key?

Absence of private keys does not mean absence of sensitive information. A PSBT may expose transaction history and wallet structure. Share it only with the intended workflow participants. Nobody needs your recovery phrase to inspect a PSBT or explain a signing error.