A Litecoin fee quote is useful only when you know what it measures. The transaction's network fee, an exchange withdrawal charge and the cost of converting money into LTC can be three different amounts. A small network fee does not establish that the complete payment route is the cheapest.
Expanded review · 22 October 2026. This guide covers ordinary transparent transactions. Signed-size observations below come from our archived Core 0.21.5.8 regtest study; other numbers are explicitly hypothetical. No new mainnet payments or live fee measurements were made for this update.
The basic units
One LTC equals 100,000,000 litoshis. A fee rate in litoshis per virtual byte, abbreviated litoshi/vB, describes a price for transaction size. A total fee in LTC describes what the whole transaction pays. Neither is a percentage of the amount sent.
Total fee in litoshis = virtual size × rate in litoshi/vB
Total fee in LTC = total litoshis ÷ 100,000,000For a hypothetical 200 vB transaction at 2 litoshi/vB, the fee is 400 litoshis, or 0.00000400 LTC. Sending a larger LTC amount need not increase the fee if the input and output structure stays the same. Selecting additional inputs can increase it even when the recipient receives less.
For conventional SegWit transactions, virtual size is the transaction's weight divided by four, rounded up. Raw serialized bytes and virtual bytes are different quantities. The BIP 141 size definitions explain the witness discount. Our simple multiplication examples use whole-number rates and sizes; actual wallets also apply integer rounding and their own construction rules.
Why two payments can cost different amounts
A wallet spends whole unspent outputs. Several small receipts may require several inputs, while one sufficiently large receipt may fund the same payment with one input. A change output returns the remainder to the sender. It contributes to size but is not a service charge. See the worked UTXO and coin-control guide for value conservation and privacy consequences.
| Construction | Recorded virtual size | Recorded total fee |
|---|---|---|
| 1 input, 1 recipient, 1 change | 141 vB | 1,410 litoshis / 0.00001410 LTC |
| 2 inputs, 1 recipient, 1 change | 208 vB | 2,080 litoshis / 0.00002080 LTC |
| 5 inputs, 5 recipients, 1 change | 536 vB | 5,360 litoshis / 0.00005360 LTC |
| 10 inputs, 5 recipients, 1 change | 874 vB | 8,740 litoshis / 0.00008740 LTC |
These are particular signed transactions, not permanent sizes for all wallets. Signatures and script types can change the result. The study checked candidates locally without broadcasting or mining them; its setup funding cost is excluded. The original JSON preserves signed hex, size and policy results. The batching study explains its 12 alternative comparisons and assumptions.
For five recipients with matched total input counts, the recorded batch used 536 vB instead of 705 vB for five separate one-input payments: 169 vB, about 23.97%, less. A pre-consolidated one-input batch used 265 vB, but that comparison excludes any earlier consolidation cost. Do not present the larger saving as available to every fragmented wallet.
Convert a Core estimate without changing its meaning
In Core 0.21.5.8, estimatesmartfee returns a rate in LTC per 1,000 virtual bytes. Check your own version's help before using any RPC field: similar names in other wallets can have different units. These commands inspect information; they do not send a payment:
litecoin-cli help estimatesmartfee
litecoin-cli estimatesmartfee 6 "CONSERVATIVE"
litecoin-cli getmempoolinfoSuppose an estimator returned {"feerate":0.00002000,"blocks":6}. This is a fabricated response for arithmetic, not a current quote. Convert it as follows:
0.00002000 LTC/kB × 100,000,000 ÷ 1,000 = 2 litoshi/vB
200 vB × 2 = 400 litoshis = 0.00000400 LTCMultiplying an LTC/kB value directly by a vbyte count overstates the fee by 1,000. Treating LTC/kB as LTC/vB is the same error. Conversely, dividing twice understates the intended rate. Keep the original unit alongside every copied number. The versioned RPC implementation defines the result and its insufficient-data response.
Estimation is not a confirmation guarantee
A target of six blocks expresses the estimator's objective, not a reservation in an upcoming block. Read the returned target and mode, and inspect any error. An insufficient-data response means that this node cannot supply that estimate; it does not mean a zero fee is appropriate.
Use the wallet's final preview for the transaction being authorized. An unsigned approximation can change after selection, change creation and signing. If an invoice requires exactly 1 LTC, verify whether the wallet adds the fee to your debit or subtracts it from the amount delivered. A hypothetical 1,410-litoshi fee means either a 1.00001410 LTC debit for a 1 LTC recipient payment, or a 0.99998590 LTC recipient payment if the total debit is fixed at 1 LTC.
Mempools and relay policy
Each node has a local mempool and policy settings. A transaction visible to one node is not proof of universal propagation or future inclusion. Inspect the fee tracker as dated context and the mempool guide for local minimums, rejection and observation limits.
Dust is a separate output-policy calculation. For ordinary P2PKH, P2SH and P2WPKH outputs, the pinned Core defaults yield thresholds of 5,460, 5,400 and 2,940 litoshis respectively. These follow the dust calculation and the 30,000-litoshi/kB value in policy constants. They are configurable policy values, not a network-wide minimum payment promise.
Increasing the transaction's total fee does not repair an output that remains below a node's dust threshold. The controlled boundary study separates that test from transaction fee rate. Also keep MWEB separate: Core's fee-rate implementation includes an MWEB weight component which the ordinary transparent formula here omits.
What to do about a delayed payment
| Observed state | Useful next check | What an extra fee cannot fix |
|---|---|---|
| Provider says pending, no transaction ID | Withdrawal queue and provider support | A transfer the provider has not broadcast |
| Unconfirmed transaction ID | Wallet status, inputs, rate and local acceptance | Automatic universal relay |
| Confirmed, service has not credited | Required confirmations, deposit route and service records | Internal account crediting |
| Wrong route or destination | Actual chain, output and receiver's recovery policy | Changing an already confirmed destination |
RBF requires a valid replacement and suitable wallet and node support. CPFP requires a spendable output and a child transaction whose package can satisfy relevant policy. Neither is a generic “speed up” button for every wallet. Follow the cancellation and replacement guide or the pending-payment diagnosis before trying another transfer. Sending a new independent payment can pay the recipient twice.
Reduce avoidable cost without hiding trade-offs
Batching shares overhead and change, but can associate recipients publicly and complicate accounting. Consolidation pays a fee now and combines receipt histories; compare the complete consolidation-plus-future-payment path with waiting. It may cost more if those inputs would otherwise be spent separately. An address-format change helps only through the scripts actually spent and created, with support at both ends.
A custodial withdrawal may be one output in a much larger batch. Its fixed withdrawal charge need not equal that transaction's network fee or a uniquely attributable share of it. Record the provider's quote and the wallet receipt separately. For frequent payouts, compare minimum withdrawals and future input count as well as the immediate fee.
Compare other payment routes honestly
Write down the complete route: acquisition, spread, transfer, recipient conversion and withdrawal. Use one currency and one observation time for comparisons. A route advertising no network charge can still include conversion costs; a small on-chain fee can be immaterial beside a large spread. Confirmation requirements and supported destinations also affect whether the route solves the payment.
Download the measured-size and hypothetical-rate cases and quote checklist. The CSV labels the original measured rows separately from conversions. It does not predict congestion or allocate an exchange's batch fee to individual customers.
Frequently asked questions
Does sending more LTC always cost more?
No. Input count, scripts, outputs and fee rate determine the ordinary transaction fee. The transferred value alone does not determine virtual size.
Is LTC/kB the same as litoshi/vB?
No. Multiply an LTC/kB rate by 100,000 to obtain litoshi/vB. For example, 0.00002000 LTC/kB equals 2 litoshi/vB.
Is the study's 10 litoshi/vB a recommendation?
No. It was a fixed experimental rate for signed candidates in isolated regtest. Check your wallet and current dated network context.
Does a missing estimate mean zero fee?
No. Core can return an insufficient-data error. That describes the estimator's evidence, not a free confirmation opportunity.
Can I fix a dust output by raising the fee?
Not if the output remains below the applicable dust threshold. Dust policy and total transaction fee are separate checks.
Is an exchange withdrawal fee paid entirely to miners?
Not necessarily. It is the provider's charge. Its network transaction can batch many withdrawals and pay a different total fee.
