A partially signed transaction file is a request to participate in a transaction. Before adding a Litecoin signature, establish what the file asks you to spend, where every output goes and how the proposed transaction relates to the payment you intended. Successful decoding is only the start.
This guide covers ordinary transparent PSBT version 0 using Litecoin Core 0.21.5.8 as a pinned implementation reference. It does not claim that every wallet, PSBT version, marketplace signing scheme or MWEB workflow behaves identically. The downloadable example is synthetic and has no spendable input or signatures.
What a PSBT contains
BIP 174 defines a key-value container with global, input and output maps. Its format allows different participants to create, update, combine, sign, finalise and extract transaction data. One file can be incomplete; another can contain enough signatures to produce a broadcastable transaction.
The pinned Litecoin PSBT definitions include previous-output information, partial signatures, script data and derivation metadata. A file can therefore reveal more than the intended payment amount. Treat its contents as potentially sensitive even if the file contains no private key.
PSBT is not a recovery phrase, a wallet backup or proof of a completed payment. Nor is a recognizable base64 prefix a guarantee of authenticity. A seller or coordinator can provide a perfectly readable file that proposes a transaction you should decline.
Establish the request independently
Start outside the file. Confirm the invoice or purchase through the expected channel: recipient, amount, asset, network and expiry. Decide the maximum fee and which wallet or policy may authorize the spend. If a coordinator changes the file, restart the comparison rather than trusting the previous approval.
A decoded output script must be interpreted on the intended network. A tutorial label such as “recipient” is not a property certified by the file. A change label supplied by another party is equally insufficient: your signer should recognize the change through its own trusted wallet information or policy.
Record a hash of the file you reviewed to distinguish revisions. That hash identifies the particular file, not the ultimate transaction's validity or a unique payment outcome. The separate txid and wtxid guide explains why identifiers and payment evidence require different checks.
Decode and inspect before any signing action
Check the installed version's help first. The pinned raw-transaction RPC source documents decodepsbt and analyzepsbt. These inspection calls are different from wallet signing, finalisation and broadcast. Use your local node and avoid pasting a real PSBT into an unknown online decoder.
litecoin-cli help decodepsbt
litecoin-cli help analyzepsbt
litecoin-cli decodepsbt "BASE64_PSBT"
litecoin-cli analyzepsbt "BASE64_PSBT"BASE64_PSBT is a placeholder for a locally reviewed file's data. The commands are shown for inspection; no signing or broadcast command is required for this exercise. Shell quoting and binary names can differ by installation. Keep real payment data out of shared terminal recordings and command-history exports.
Inspect every input's outpoint, previous-output amount and script, and every output's amount and spending destination. Reconcile previous-output data against a trustworthy source, rather than treating coordinator-supplied values as independently established. Check transaction version, locktime, input sequence and any script requirements that affect your intended spend.
| Check | Compare against | Stop condition |
|---|---|---|
| Recipient outputs | Authenticated request and exact amount | Unknown destination or changed amount |
| Change | Signer's trusted wallet policy | Ownership cannot be established |
| Inputs and fee | Trusted previous outputs and total outputs | Missing data or unexplained excess fee |
| Signature scope | Intended transaction commitments | Unexpected sighash or unsupported signing scheme |
Work through the synthetic fee example
Download the synthetic PSBT, offline calculation script and expected results. Save the script with a .py extension and run it with Python 3. It uses the standard library, creates its own fixture in memory and prints the results. It does not access a network or wallet, sign, broadcast or write files.
The fixture claims one input worth 100,000 litoshis, then creates outputs worth 90,000 and 5,000. Subtracting outputs from the claimed input gives a fee of 5,000 litoshis: 0.00100000 LTC in, 0.00095000 LTC out and 0.00005000 LTC difference. The second output is called possible change only for discussion; no wallet ownership is established.
The script parses this limited fixture and two constructed variants. Reducing the first output to 80,000 while leaving the second at 5,000 raises the apparent fee to 15,000. Changing only the input metadata to claim 200,000 produces an apparent fee of 105,000. The latter is not evidence of an actual input's value: the previous output is fictitious.
The exercise shows why checking arithmetic against untrusted metadata is incomplete. Its parser is intentionally limited to the demonstrated PSBT v0 structure. It is not a general PSBT validator, a signature checker or an approval tool. A matching exercise result proves only the stated parsing and arithmetic checks.
Signature commitments matter as much as displayed totals
Different signature-hash modes can commit to different parts of a transaction. A marketplace, multisignature coordinator or specialised protocol may request a mode that differs from the ordinary payment flow. Do not approve an unfamiliar mode merely because the current displayed amounts look correct. The signer must understand what could still change after its signature.
For normal wallet workflows, use compatible software that enforces the intended policy and gives a meaningful confirmation display. The pinned wallet RPC source distinguishes funded-PSBT creation from wallet processing, whose signing option can add signatures. An inspection step should not accidentally invoke a signing operation.
If you cannot establish the recipient, change, inputs or signature scope, retain the unsigned file and ask the coordinator to resolve the specific discrepancy. A successful parse is not a reason to lower your approval standard.
Handle the file and the result carefully
PSBT metadata may expose public keys, derivation information and transaction relationships. Share only what the workflow requires. Keep backup material separate; no legitimate PSBT inspection needs your recovery phrase. If a file already contains signatures, assume another holder may be able to combine or extract them under the relevant signing conditions.
After the intended signatures are collected, finalisation and extraction still do not establish live acceptance. A transaction can be rejected or conflict with another spend. Verify submission, current chain state and recipient credit using the transaction-state checklist. Avoid submitting a second payment just because the coordinator's interface stalled.
The review worksheet records the decision without requesting secrets. This guide's editorial checks covered versioned sources and the offline fixture. No Core RPC session, hardware signer or live payment was tested for this article. The exercise deliberately uses no real UTXO, so it must not be treated as a spend candidate.
Frequently asked questions
Does a PSBT contain private keys?
Its normal signing workflow does not require sharing private keys in the file. It can still contain sensitive metadata and signatures, so do not treat it as harmless public data.
Does successful decoding mean I should sign?
No. Decoding exposes structure; approval requires independent checks of intent, inputs, recipient, change, fee and signature commitments.
Does an output labelled change belong to me?
A label is insufficient. Your signer needs trusted wallet information or policy establishing that ownership.
Can a fully signed PSBT lead to a payment?
Yes. A holder may be able to extract and broadcast the completed transaction. Sharing signatures can therefore grant practical spending authority.
Can the synthetic file spend real LTC?
It contains a fictitious previous output and no signatures. It is an arithmetic and parsing exercise, not a valid payment candidate.
Does this guide cover every PSBT or MWEB workflow?
No. Its pinned scope is ordinary transparent PSBT v0. Check the exact wallet version and supported transaction type for other workflows.
