Using an air-gapped Bitcoin hardware wallet can feel reassuring: the signing device is offline, the private keys stay with it, and a file or QR code carries the request across. But the transaction still asks a consequential question: where should the bitcoin go? An air gap changes the transport. The owner still has to inspect the payment before approving it, as Coinkite’s signing guidance emphasizes.
Partially Signed Bitcoin Transactions, usually shortened to PSBTs, make that inspection possible across different wallet tools. The useful habit is to treat every incoming PSBT as a proposal requiring review, even when you created it yourself moments earlier.
What a PSBT actually carries
BIP 174 defines a format that packages transaction information and the supporting data a signer needs. That lets an offline device produce signatures without fetching the necessary details from the network. A coordinator wallet can prepare the transaction, a hardware device can sign it, and other software can complete the process.
The name does not mean every PSBT already contains a signature. The format serves several stages, including initial preparation and collecting signatures. In a multisignature arrangement, one device’s approval may leave additional signatures outstanding. Reading a filename such as “unsigned” or “signed” is therefore a poor substitute for checking what the wallet reports about the transaction itself.
Establish the recipient
Begin with the payment instruction: who are you paying, how much, and to which address? Obtain the destination from the intended recipient or the service’s genuine deposit page. Then compare the full destination shown on the signing device with that source.
This comparison has two parts. You need confidence that the address really belongs to the intended recipient, and confidence that it remained unchanged when the transaction was assembled. Trezor’s trusted-display explanation makes the distinction explicit: the device can show the transaction it is about to sign, but cannot determine whether somebody gave you the right address in the first place.
A match between two screens helps only when you understand what each screen is proving. If the original payment instruction was fraudulent, correctly signing that instruction still produces the wrong payment.
Account for the change and fee
Bitcoin payments consume previously received outputs, known as UTXOs. Each selected output is spent in full. Any value that is neither paid to a recipient nor returned as change becomes the transaction fee. Change is another transaction output, usually returning the remainder to your wallet. The Bitcoin developer guide explains this structure.
Consider an illustrative transaction spending 1,000,000 satoshis:
- Recipient: 250,000 satoshis
- Change returning to your wallet: 748,000 satoshis
- Network fee: 2,000 satoshis
The numbers reconcile to the input total. That arithmetic is necessary, but it cannot prove that the change destination belongs to you. A balanced transaction can still pay an unintended address.
A capable signer uses wallet information to verify change rather than trusting a label supplied by the computer. For example, COLDCARD’s transaction-review documentation describes showing destination amounts, fees, and change, plus rejecting a claimed change address that fails its wallet checks. Treat that as a product-specific safeguard. Check how your own device handles change, especially with a multisignature wallet or an unfamiliar setup.
Read the fee as an actual amount you are agreeing to spend. A device’s high-fee warning is a backstop; its absence does not establish that the fee is appropriate for your payment.
A deliberate offline signing sequence
-
Prepare the transaction in a compatible coordinator wallet. Inspect its inputs, recipient outputs, change, and total fee before exporting. Make the intended payment simple enough that you can explain every output.
-
Transfer the PSBT using a method both products support. In Sparrow’s documented SD-card workflow, the wallet saves a PSBT, the card moves to the hardware device, and the device displays the transaction for review. Exact menus depend on the products involved.
-
Review on the signing device before approving. Check every recipient and amount, the change treatment, and the fee. If something is unexplained or a warning appears, cancel and resolve it. Coinkite’s review instructions explicitly advise against signing an unrecognized transaction detail.
-
Return the signed result to the coordinator. Confirm whether the transaction has all required signatures. Bitcoin Core’s finalization documentation distinguishes an incomplete PSBT from a complete transaction that can be extracted for broadcast. Signing and broadcasting are separate stages, even when an application makes them feel continuous.
-
Broadcast through the intended wallet and check its reported status. Sparrow’s guide shows loading the signed PSBT before broadcasting. Do not mistake the signing confirmation for evidence that the network has received the payment.
The strongest routine is easy to repeat: know the intended payment, account for every output, understand the fee, and approve only after the hardware display agrees. The few moments spent reviewing are part of using the hardware wallet.