How to send an exact Litecoin amount or your whole wallet balance

You have 1 LTC and want to pay an invoice for exactly 0.4 LTC. A different day, you want to move the entire wallet balance. Those are different instructions. If you choose the wrong fee option, an invoice can be underpaid even though your wallet shows that you sent the amount you entered.

For an exact payment, keep the recipient amount fixed and pay the fee in addition. For a send-max payment, the recipient normally receives the available input value minus the fee. A “subtract fee” option can also reduce a smaller entered amount. Read the recipient amount in the final preview rather than relying on the amount you first typed.

We built 24 controlled Litecoin Core payment cases to measure the differences. Eighteen were fully signed and accepted by the isolated node's policy; six attempts to send the entire 1 LTC as an exact recipient amount failed. One selected send-max transaction was then mined and left its sending test wallet at zero. The worked figures below come from those transactions, not an approximate transaction-size formula.

This guide concerns ordinary transparent Litecoin. The inputs are native SegWit P2WPKH test outputs. It does not measure MWEB fees, exchange withdrawal pricing, mobile app interfaces or current mainnet fee requirements.

Decide which amount must stay fixed

Start with the purpose of the transfer. A merchant invoice usually specifies what the merchant must receive. Moving funds between your own wallets may instead specify how much of the old wallet you want to empty. A budget can specify the maximum total debit, including the fee.

The second row is what fee subtraction can do. It can be useful for a deliberate total budget, but it is a poor default for paying an exact invoice. A requested 0.4 LTC and a received 0.39999718 LTC are different amounts, even when the difference is small.

If you are paying an exchange deposit address, inspect its minimum creditable amount as well. The amount arriving after fees must meet the service's current terms. A valid on-chain receipt does not override a provider's deposit minimum.

Follow the measured 1 LTC example

We funded a fresh test wallet with one confirmed output worth exactly 1 LTC. We then used a declared rate of 2 litoshi per virtual byte. One litoshi is 0.00000001 LTC; the rate is an experimental setting, not a recommendation for today's network.

The first two signed transactions measured 141 vB; the one-output send-max transaction measured 110 vB. Its smaller measured fee follows from a smaller transaction in this setup. It does not establish that every application's max button always saves the same amount.

In the failed exact-1-LTC case, the wallet needed more than its 1 LTC input to preserve the recipient amount and pay a positive fee. It returned “Insufficient funds.” No transaction was broadcast and no network fee was charged. Merely preparing another preview does not repeatedly pay a fee.

Why a 1 LTC input does not mean a 1 LTC payment

An ordinary transparent transaction consumes each selected previous output in full. It creates a recipient output and, if needed, a new change output controlled by the sender. The network fee is the difference between total input value and total output value.

Exact payment in our test:
1.00000000 input
= 0.40000000 recipient
+ 0.59999718 change
+ 0.00000282 fee

Fee-subtracted payment:
1.00000000 input
= 0.39999718 recipient
+ 0.60000000 change
+ 0.00000282 fee

An explorer showing a 1 LTC input has not demonstrated that the recipient was paid 1 LTC. Neither has a wallet history row necessarily separated the recipient payment from change. Inspect the destination's actual output and keep the fee separate. Our transaction checker helps inspect public outputs; it cannot infer every output's owner.

Change is normally managed by the wallet. Do not replace its change address with an exchange deposit destination or a stranger's address because a tutorial mentions “custom change.” The UTXO and coin-control guide explains that structure in more detail.

The same 1 LTC balance produced different send-max amounts

We repeated the experiment with 1 LTC split over three outputs and ten outputs. Every candidate explicitly used all outputs in its group; automatic input selection did not decide how many to spend. The three-input group contained 0.33333333, 0.33333333 and 0.33333334 LTC. The ten-input group contained ten 0.1 LTC outputs.

At the same declared 2 litoshi/vB, the ten-input sweep paid 1,218 more litoshi than the one-input sweep. That is 0.00001218 LTC. The ten-input transaction's measured size was about 6.54 times the one-input size, despite both wallets starting with 1 LTC.

The important variable here is the transaction structure, not the fiat value of the wallet. Different script types, input counts, signatures and change outputs can change the final size. These measurements also explain why subtracting a remembered fee from a balance is less reliable than using an appropriate wallet preview.

This is not an instruction to consolidate coins before every transfer. Consolidation pays another fee now and can publicly link previously separate receipts. Our separate UTXO guide compares those tradeoffs. Use current fee information for context, then inspect the actual signed or final wallet quote.

“Send all” can mean all selected coins

A max button has to operate on a particular input budget. If coin control has selected only part of the wallet, the result can empty that selection rather than the whole wallet. Pending incoming receipts, immature rewards, intentionally locked outputs and watch-only value can also sit outside the eligible budget.

Our send-max cases emptied their explicitly selected 1 LTC groups. We broadcast and mined just one selected sweep: the one-input, 2-litoshi/vB candidate. Its recipient received 0.99999780 test LTC and the source wallet's confirmed balance became zero. The other 17 signed candidates were policy-tested without broadcasting; their expected accounting follows from their recorded inputs and outputs.

A zero balance after a sweep is a snapshot, not a promise that the old wallet can never receive money again. An earlier address controlled by that wallet can still receive later payments. Check saved withdrawal addresses and recurring payout destinations before retiring it. Our receiving-address experiment explains why generating new addresses does not disable old ones.

If “max” is much smaller than the visible balance, first inspect eligible inputs and signing access. The companion balance-but-cannot-send guide tests those exclusions. Increasing the fee cannot supply a missing private key or unlock a coin-selection restriction.

Keep exchange charges and market conversions separate

The measured numbers above apply to a self-custody transaction. An exchange may quote a fixed LTC withdrawal charge, enforce a minimum or combine multiple withdrawals into one transaction. Its interface can define an entered amount as a total debit or a net receipt. Check the actual labeled fields; do not assume its behavior matches Core's fee-subtraction option.

If an invoice is denominated in euros, there is another decision: which exchange rate and validity period establish the LTC amount due? A reference-price calculation is not necessarily the merchant's executable invoice quote. Recalculate only according to the agreed terms, rather than silently reducing the amount because the market price moved.

Use the complete purchase-cost comparison when the route includes buying and withdrawing. For an already issued Litecoin invoice, the payment request and reconciliation tools help keep requested amount, actual receipt and acceptance status distinct. Those tools calculate and inspect; they do not connect to your signing wallet.

Check precision, minimums and the full destination

Transparent LTC amounts in this experiment are integer litoshi: eight decimal places. A rounded fiat display can hide a shortfall. The fee-subtracted 0.4 LTC example was 282 litoshi below the request, even if both screens rounded to the same currency value.

Record the invoice amount in LTC and inspect the actual output with enough precision. Do not repeatedly resend a tiny difference without checking the recipient's rules: a service may reject deposits below its minimum, and a very small output can encounter dust-policy limits. Our controlled dust-policy guide shows why there is no universal threshold for every script and fee configuration.

A valid address checksum does not authenticate the recipient. Compare the full destination with a request obtained through a trusted channel. If you use a hardware signer, follow its documented display checks. A successful small test does not validate a substituted destination for the later larger payment.

A final preview checklist

1. Purpose: exact invoice amount, fixed total budget or transfer of all eligible coins?
2. Destination: correct asset, supported network and full address from a trusted request?
3. Recipient: what amount will the recipient actually receive after any fee subtraction?
4. Debit: what value leaves your control after accounting for change and the fee?
5. Selection: does max apply to the whole eligible wallet or only selected inputs?
6. Minimums: does the final receipt meet the destination's current minimum and invoice terms?
7. Authorization and outcome: does the final signer display match, and did the transaction actually broadcast?

Download the blank payment-preview checklist. Keep a record of the agreed recipient amount and the actual transaction ID. You do not need to disclose recovery material to check either.

If a recipient was underpaid, first agree how to settle the difference and retain both records. Do not assume a second transfer cancels or edits the first. The refund and underpayment guide covers that follow-up workflow.

Method, downloads and limits

The experiment used Core 0.21.5.8 on a fresh isolated regtest chain with no peers. It created three 1 LTC budgets with one, three and ten confirmed P2WPKH inputs. Each budget was tested at declared rates of 2 and 10 litoshi/vB, with four instructions: exact 1 LTC, exact 0.4 LTC, 0.4 LTC with fee subtraction and send max. That gives 3 × 2 × 4 = 24 construction cases.

The six exact-full-balance cases failed before broadcasting. Eighteen other candidates completed signing and passed that node's local mempool-policy check. One sweep was broadcast and mined on regtest. Across the shared wallet-state and payment experiments, 103 assertions passed.

The 24-case CSV provides amounts in integer litoshi. The results JSON also contains the signed transaction bytes and selected input values. The offline analysis redecodes all 18 signed transactions, verifies their recorded identifiers and recalculates virtual size and input-minus-output fees. It does not validate signatures, independently prove the inputs existed or measure propagation.

See the reproduction instructions, complete package and checksums. Source behavior was checked against the pinned Core wallet RPC implementation, including the different units of feeRate and fee_rate. Our script uses feeRate in LTC per 1,000 virtual bytes: 0.00002 corresponds to 2 litoshi/vB. Copying the value between differently named fields would change its meaning.

The exact measurements belong to these signed transactions. Another wallet, script type or signature can produce a different size. Regtest acceptance is not a mainnet confirmation guarantee. No actual purchase, service withdrawal, MWEB transfer or hardware/mobile interface was tested.

Released 3 October 2026, Europe/Warsaw; exact test time is recorded in UTC. Research, code and drafting used AI assistance. The original cover and SVG diagrams illustrate measured accounting, rather than pretending to be application screenshots. No independent external reviewer is claimed. Report an error through our corrections page.