Why your Litecoin wallet shows a balance but cannot send

Your Litecoin wallet shows 1 LTC. You enter a small payment and it says “Insufficient funds,” asks you to unlock the wallet, or refuses to finish signing. Those messages describe different problems. Sending another deposit, increasing the fee or reinstalling the application can be the wrong response.

A displayed balance is an accounting view. A successful payment also needs eligible coins, sufficient signing authority and enough value for the recipient plus the fee. Start by finding which of those conditions is missing.

We reproduced the distinction in Litecoin Core 0.21.5.8. The same confirmed 1 LTC appeared in an ordinary wallet and in a watch-only wallet, but only the ordinary wallet could complete the signature. In another wallet, locking its single coin left the reported balance at 1 LTC while automatic payment construction failed. This guide uses those controlled results to build a practical diagnostic checklist.

Scope: ordinary transparent Litecoin in a self-custody wallet. An exchange account, wrapped LTC on another chain and MWEB balances have additional rules. Our experiment used an isolated regtest node, no network peers and no real money. It did not test a mobile application or a physical hardware wallet.

First establish where the balance is

Before changing anything, identify the application and the account or wallet currently open. A Litecoin exchange balance is a claim recorded by that service. Your self-custody wallet balance is its view of outputs associated with keys or scripts it knows. A block explorer's address balance is a third view: it does not establish that your current wallet can sign for that address.

If the LTC is on an exchange, adding a hardware wallet to your computer does not make the exchange's balance locally spendable. A withdrawal is a separate action. If you are in a restored wallet, compare a known receiving address and identify the intended account before concluding that an empty or unusable view means the coins disappeared. See our tested wallet-discovery guide for that separate problem.

Five different reasons for a balance that cannot fund a payment

The table below selects stages from our 11-state experiment. “Reported value” identifies the relevant balance category rather than adding every column into a fictional spendable total. Every 1 LTC receipt here is a synthetic test payment.

Download the 11-state balance CSV or the complete results JSON. These are wallet-state comparisons, not a survey of how frequently users encounter each problem.

A watch-only wallet can show the correct coins

A watch-only wallet contains enough public information to recognize certain destinations or scripts, but not necessarily the private signing material. That makes it useful for monitoring. It also makes its accurate balance a poor test of recovery success.

In our experiment we imported an ordinary wallet's address into a new wallet created with private keys disabled. After confirming a 1 LTC receipt, the original wallet reported 1 LTC in its mine.trusted category. The copied view reported 1 LTC in watchonly.trusted. The watch-only wallet's default getbalance also returned 1 LTC: Core includes watch-only value by default for a wallet whose private keys are disabled. Nevertheless, it could not produce a complete payment signature.

That is a useful recovery check: “the balance is right” and “the wallet can authorize a spend” are separate questions. An application paired with a hardware signer may deliberately keep keys elsewhere. In that case, check the documented device connection and signing procedure. Importing an address or an extended public key into another app does not turn that view into a signing wallet.

Identify the signer, backup type and, where relevant, wallet policy. Do not paste a seed, private key or wallet file into a support website to convert a watch-only balance into spendable coins. Our recovery evidence and checklist distinguish the materials that restore a view from those that restore signing access.

A coin-selection lock is different from an encrypted wallet lock

These two locks produced different failures in our test. A selection lock told the wallet not to choose its one confirmed output. The balance remained 1 LTC, but listunspent returned no available outputs and automatic funding failed. Unlocking that outpoint restored construction without any new deposit.

By contrast, encrypting a separate wallet left the confirmed output available for transaction construction. The wallet could fund the candidate, but signing failed until its local passphrase authorization was unlocked. After the documented local unlock, signing completed. We then relocked authorization.

Review why a coin was locked before unlocking it. You may have excluded an unsolicited receipt or kept funds from different activities separate. Do not bulk-unlock everything simply because a payment failed. Core's RPC selection locks are local wallet controls; their documented lifecycle is not a permanent blockchain restriction. Other applications can implement different persistence and interfaces.

A wallet password, a device PIN and an additional seed passphrase can have different roles. This experiment covers Core wallet-file encryption. It does not establish that changing one password restores a missing seed or that a hardware device uses Core's unlock procedure.

An incoming unconfirmed receipt may be visible but excluded

We sent 1 test LTC from a different wallet and deliberately did not mine a block immediately. Core reported the receipt in untrusted_pending. Its output appeared in an inclusive unspent listing with safe: false, while default payment funding returned “Insufficient funds.” After one local block confirmed the same receipt, the wallet reported 1 LTC trusted and funded the candidate.

This result is narrower than “you always need one confirmation to send Litecoin.” Wallets can treat their own unconfirmed change differently from an incoming payment created elsewhere. Coin selection, replacement conditions and application policy also matter. The demonstrated problem was an externally created, unconfirmed receipt in this Core configuration.

Check the receipt's transaction ID and status with the transaction checker. A pending payment is not a completed withdrawal merely because an exchange has reduced its account balance. A confirmed transaction is also not proof that a service has already credited its customer's account. If the public transaction itself is delayed, use the pending-payment diagnostic guide before attempting a second payment.

Do not disable safety checks as the first response. First establish whether the payment has actually confirmed and whether the sending and receiving services use the same network.

Mining rewards have a separate maturity rule

A coinbase transaction creates the block subsidy and collects the block's fees. Here “coinbase” is the transaction type, not the exchange of that name. An ordinary payment from a mining pool is not automatically a coinbase output just because mining was the source of the income.

Litecoin's pinned consensus source defines a 100-block coinbase maturity constant. In our wallet test, the isolated 50 LTC reward remained in the immature category at both one and 100 recorded confirmations. At 101 recorded confirmations, Core's wallet moved it to trusted value and could fund the candidate. Its wallet availability calculation uses the maturity constant plus one minus current depth. This is a precise report of Core wallet behavior, not a claim that every payment requires 101 confirmations.

We advanced a private chain with test-only block generation. The result is measured in chain depth, not elapsed minutes. Do not multiply a target block interval by a counter and treat the product as a guaranteed unlock time. A pool's own payout threshold, waiting period and withdrawal policy are additional service rules.

Check the amount and fee after checking the coins

Even a fully spendable 1 LTC balance cannot usually deliver exactly 1 LTC to someone else while also paying a positive network fee. An exact-amount transfer needs additional value for that fee. A send-max workflow instead reduces the recipient's amount to fit the available input budget.

In our companion experiment, six full-balance exact-amount constructions failed across three input counts and two declared fee rates. All six send-max alternatives constructed valid local candidates. That fixes a different problem from a missing key or a selection lock. The exact amount and send-max guide shows the receipt, change and fee for each approach.

Check total fee and fee rate separately. A wallet's transaction preview is the relevant place to confirm the actual recipient amount and debit. An exchange's fixed withdrawal charge is a service price; it need not equal the network fee on the resulting transaction.

A diagnostic order that avoids unnecessary changes

1. Identify the location. Record the application, wallet or account, asset and network. Is this self-custody, watch-only or a service balance?
2. Check the receipt. Find its transaction ID, confirmations and category. Separate pending and immature value from available coins.
3. Inspect selection. Does manual coin selection restrict the input budget? Are relevant outputs intentionally locked?
4. Identify signing access. Is the correct device connected? Is local authorization locked? Do you have signing material rather than only a public view?
5. Check fee coverage. Does the selected value cover the exact recipient amount plus the final fee? If using max, inspect the reduced recipient amount.
6. Check the final status. A constructed or signed candidate is not necessarily broadcast. Record the actual transaction ID after sending and verify its outcome.

If you use Core's console, the following are read-only inspection commands. Select the intended wallet first. Their output can contain addresses and transaction details; do not publish it casually.

getbalances
listunspent
listlockunspent
getwalletinfo

These commands do not unlock a wallet or spend money. A zero-length listunspent result alone does not prove a zero wallet balance: our selection-lock case is the counterexample. Inspect the balance categories and locks together.

Download a blank diagnostic record to keep the exact error, balance category and next check. It has no field for a seed, private key, wallet file or password. If you ask legitimate support for help, start with the application/version, public transaction status and exact non-secret error.

What we tested and how to reproduce it

The release contains 11 recorded wallet states and a shared payment-construction experiment. Across both parts, 103 executable assertions passed. All receipts and rewards are synthetic regtest coins. Wallet keys were generated temporarily and are not published. The source node used Core 0.21.5.8 with no peers; the script starts a new temporary directory rather than reusing a user's node.

The payment portion contains 18 fully signed candidates accepted by local regtest mempool policy, six rejected constructions and one selected send-max transaction actually mined. The offline analysis script independently decodes the exported signed transaction bytes to recalculate sizes, output totals and fees. That arithmetic check does not validate signatures or independently recreate wallet ownership.

Use the method and reproduction instructions, complete downloadable package and file checksums. Run experiments only with a verified Core binary. Random test keys mean addresses and transaction IDs differ on another run.

Source checks use the pinned wallet RPC implementation, wallet availability calculation and coinbase maturity constant. The source record preserves URLs and capture hashes.

Released 3 October 2026, Europe/Warsaw; the results file records the exact UTC test time. Research, code and drafting used AI assistance. The cover and figures are original explanatory diagrams, not wallet screenshots. No independent external review, mainnet transfer or hardware test is claimed. Send corrections through our corrections page.