A Litecoin Core query returns null for an output you expected to find. That answer does not say, by itself, that the payment never existed or that someone stole the coins. It says that this node did not return that specific output as unspent in the view selected for the query.
The distinction can be useful when a wallet, an explorer and your own node appear to disagree. A confirmed output may still exist in the active-chain UTXO set while a locally observed, unconfirmed transaction spends it. In that situation, including the node's mempool changes the answer.
This guide explains the transparent gettxout RPC in Litecoin Core version 0.21.5.8. The examples are fictional and describe the source code's behavior under stated conditions; they are not results of a new node experiment. Private MWEB outputs, exchange account balances and other wallet implementations are outside this guide.
Start with an outpoint, not an address balance
An ordinary transparent transaction can create several outputs. Each output is identified by the transaction ID, or txid, and a zero-based output index, or vout. Together these form an outpoint. Output 0 and output 1 of the same transaction are different objects, even if both pay the same address.
gettxout asks about one such outpoint. It does not list the history of an address, search for all transactions belonging to a person, or identify the owner. The selected node needs the outpoint and a view of its active chain. With the mempool option enabled, it also considers that node's local unconfirmed transactions.
Imagine a fictional payment with a recipient output at index 0 and change at index 1. Checking index 1 when you meant to investigate the recipient checks a different output. If index 2 does not exist, a null result for that index does not describe either real output. Obtain the index from a reliable decoded transaction or the recipient's payment record; do not assume it is zero.
What the mempool switch changes
The third argument, include_mempool, defaults to true in the pinned Core version. With false, the RPC checks the active-chain UTXO view. With true, it uses a view combining the chain and local mempool and returns null if that mempool already contains a transaction spending the outpoint. The relevant code is in the RPC implementation and the mempool coin view.
The following table holds the node's state fixed for each hypothetical case, using ordinary spendable transparent outputs. “Object” means the RPC returns output details; “null” means no output object was returned. The columns are individual query settings, not two simultaneous measurements.
| Fictional state on this node | false: chain view | true: chain plus local mempool |
|---|---|---|
| Confirmed output is unspent in the active chain and no local mempool transaction spends it. | Object | Object |
| Confirmed output is unspent in the active chain, but a local mempool transaction spends it. | Object | Null |
| Output is created by a transaction in the local mempool and no local mempool transaction spends it. | Null | Object with zero confirmations |
| Output was spent in the active chain, or the outpoint is unknown to both views. | Null | Null |
The same pair of answers can have more than one explanation. In particular, null/null does not distinguish an already-spent output from a mistyped ID, the wrong index, the wrong network or a transaction not yet known to this node. A chain or mempool update between calls can produce a pair that does not describe either fixed-state row. Check the observation time and investigate the transaction rather than treating the table as a verdict.
The mempool belongs to the node answering the query. Another node may have a different set of unconfirmed transactions. A result with true cannot prove that every peer has seen the same spend, that a miner will include it, or that a payment is settled.
Three examples that can look like a contradiction
A confirmed receipt with a pending spend
A fictional receipt created an output of 0.75 LTC in an active-chain block. The recipient later broadcasts a transaction spending that exact outpoint. Before the spending transaction confirms, this node has accepted it into its mempool. The chain-only query can still return the 0.75 LTC output; the mempool-inclusive query returns null because the local mempool marks it as spent.
This is not a duplicate balance. The two settings answer different questions about the same outpoint. If the spending transaction confirms, the chain-only query will also stop returning that output. If the pending transaction leaves this node's mempool without confirming, the mempool-inclusive answer can change again. Its departure alone does not establish why it left, or what other nodes know.
A new, unconfirmed receipt
Suppose a second fictional transaction is in the node's mempool and creates an output of 0.20 LTC. No transaction in that same mempool spends the new output. The chain-only query cannot find it in the active-chain UTXO set, but the mempool-inclusive query can return its details with confirmations: 0. The confirmation count follows the code path for a mempool-created output; it is not a promise that the transaction will confirm.
A missing or spent output
A third fictional query returns null with both settings. The ID may be wrong, the selected output may never have existed, or a valid output may already have been spent in the active chain. The node may also be behind or on a different network from the record you intended to check. More evidence is needed to separate these possibilities. Never infer the identity of a spender from null alone.
Run read-only checks on your own node
First confirm the Litecoin Core version and the intended network. The commands below are examples for a configured local litecoin-cli. Replace TXID and VOUT with your own public transaction ID and the actual output index. Use a block hash only when you have a reason to examine that particular block.
litecoin-cli help gettxout
litecoin-cli getblockchaininfo
litecoin-cli getbestblockhash
litecoin-cli gettxout "TXID" VOUT false
litecoin-cli gettxout "TXID" VOUT true
litecoin-cli getbestblockhashThe commands read state; they do not create, sign or broadcast a payment. getblockchaininfo provides the node's chain and synchronization context. Compare the tip hashes before and after the two output queries. A changed tip means the chain view changed during the check; the same tip does not prove the mempool stayed unchanged. Record the time, node version, network, exact outpoint, chosen setting and each result. Mempool admission, removal or a reorganization can occur between separate RPC calls.
When an object is returned, bestblock identifies the chain tip used for that result, while value, scriptPubKey, confirmations and coinbase provide information about the output. A null result does not carry its own bestblock field, so keep the separate node observations with it. Do not publish wallet screenshots unnecessarily: addresses and transaction details can expose financial history even though they are not private keys.
Use the right evidence for the next question
| Question | Useful next evidence | Limit |
|---|---|---|
| Did I select the intended output? | Decode the transaction and compare its vout index, value and destination against the payment record. | An address shown in a transaction does not identify its controller. |
| Does this wallet know the transaction? | Check the selected wallet's transaction record and synchronization state. | A wallet record is scoped to that wallet and is not a complete network search. |
| Was a known spending transaction seen locally? | For its actual transaction ID, inspect the node's mempool entry and relevant transaction data. | One node's mempool does not represent every node or a miner's next block. |
| Was the receipt included in an active block? | Check its block reference and current active-chain status using a suitable node or documented explorer. | Block inclusion and an exchange's account credit are separate events. |
Core's gettransaction is a wallet RPC: it concerns transactions known to the selected wallet. The source for getrawtransaction describes a different lookup. Without a block hash, it can return a mempool transaction or use an enabled, ready transaction index for chain transactions. With a block hash, the specified block must be available and contain the transaction. A lookup error therefore needs its own interpretation; it does not automatically mean that a payment never happened.
Neither retrieval of the original transaction nor a returned UTXO proves that your wallet has the required signing material. Spendability also depends on the actual script, maturity, locks, wallet policy and available keys. For a mining reward, consult the separate coinbase maturity guide. For a wallet showing an unexpected balance, start with balance and signing checks.
When an exchange has not credited a deposit
A public output and a service's account ledger answer different questions. Compare the actual network, full destination, amount, transaction ID and reported confirmations with the exchange's current deposit instructions. A service can apply its own minimums, maintenance checks and crediting process. A public node cannot inspect those internal records.
Keep the transaction ID and the service's withdrawal or deposit reference, then contact the provider through its official support channel if needed. Do not send another payment solely because one lookup returned null. The transaction checker and payment retry guide explain how to preserve evidence before acting. No support agent needs your seed words, private key, wallet password or complete wallet backup to investigate a public transaction.
Frequently asked questions
Does null mean the Litecoin is gone?
No. It means this query did not return the specified outpoint as unspent in the selected local view. The output could be spent, absent from that view, or identified incorrectly. Establish the outpoint and chain context before drawing a conclusion.
Why does false return an output while true returns null?
One possible fixed-state explanation is a confirmed, chain-unspent output that a transaction in this node's mempool spends. Since separate calls can observe different states, compare timing and investigate the suspected spending transaction before concluding that is what happened.
Does a returned output prove that I can spend it?
No. It describes an output in the selected node view. Control of signing material, script conditions, maturity and wallet restrictions need separate checks. A zero-confirmation output also depends on an unconfirmed transaction.
Can this check reveal a private MWEB payment?
No. The examples query transparent transaction outpoints. They do not reconstruct a private MWEB receipt or prove which private recipient controls it.
Sources and scope
Reviewed against Litecoin Core v0.21.5.8 source on 27 October 2026. The examples are constructed explanations based on the code, not fresh runtime measurements. Node state, software versions and service policies can differ.
