Dotted-underlined terms open a quick definition. Close it to keep reading.
Our 50-recipient batch used 1,660 with one input, compared with 7,050 vbytes for 50 separate one-input payments: a 76.45% reduction. When the batch spent the same total 50 inputs as the separate payments, the saving fell to 29.38%. Both results matter; quoting only the larger percentage hides the role of the ’s inputs.
We built and signed 164 candidate transactions with Core 0.21.5.8 in an isolated regtest network. Every candidate passed that ’s standard -policy check. The measurements cover 1, 5, 20 and 50 recipients, with consolidated and fragmented inputs. No mainnet payment was made.
Study release 2026-09-30.1. Transparent native () only. The hero is an AI-generated conceptual illustration; charts below plot actual signed transaction measurements.
What a batch actually changes
A normal Litecoin payment can create several recipient outputs in one transaction. Batching shares the transaction’s overhead and normally creates one instead of repeating change in every payment. It does not merge the recipients’ balances into one output. Each recipient still receives a distinct output they can spend later.
In this study every recipient receives exactly 0.001 LTC. Each transaction also has one change output. Fifty separate payments therefore contain 100 outputs in total: 50 recipient outputs and 50 change outputs. A 50-recipient batch contains 51 outputs. That difference remains even if both approaches spend the same aggregate number of inputs.
Virtual size, measured in vbytes, reflects SegWit’s weighting of transaction data. Fees at a fixed rate are calculated from virtual size, not just the raw transaction byte count. The JSON records both size and weight; the tables use Core’s decoded vsize.
Measured size and fee for a consolidated wallet
One-input batch versus independent one-input payments; all outputs P2WPKH
Recipients
Batch vbytes
Separate total vbytes
Saving
Batch fee at 10 litoshi/vB
1
141
141
0.00%
1,410 litoshis
5
265
705
62.41%
2,650 litoshis
20
730
2,820
74.11%
7,300 litoshis
50
1,660
7,050
76.45%
16,600 litoshis
The batch spends one sufficiently large input; each separate payment spends its own input. All transactions include change. This comparison includes the benefit of spending fewer inputs.
For 50 recipients, the batch fee is 16,600 , or 0.00016600 LTC, at the experimental 10-litoshi/vbyte rate. Fifty separate payments cost 70,500 litoshis, or 0.00070500 LTC. The difference is 53,900 litoshis. Dividing the batch fee by 50 gives 332 litoshis per recipient as an accounting average; Litecoin does not charge or assign a separate to each output.
The 10-litoshi rate is an experimental setting used consistently across the study. It is not a quote for current mainnet inclusion. At another equal , the costs scale with size and the relative size saving remains the same. Use the fee estimator for a current planning exercise and read its source and freshness notes.
The fairer comparison keeps input count constant
Fifty recipients: alternative input arrangements measured in the same experiment
Scenario
Batch inputs
Batch vbytes
Matching separate baseline
Saving
One large input
1
1,660
50 × one input: 7,050 vB
76.45%
Same total input count
50
4,979
50 × one input: 7,050 vB
29.38%
Fragmented, same total inputs
100
8,367
50 × two inputs: 10,400 vB
19.55%
The 100-input batch must be compared with 50 two-input payments for an equal-input comparison. It is larger than 50 one-input payments. Funding history can matter more than the batch label.
A merchant receiving many small payments might need dozens of to fund a payout. Batching cannot make their signatures disappear. It still avoids repeated overhead and many separate change outputs, but the headline reduction is smaller. Our 100-input batch saves 19.55% against separate payments consuming those same 100 inputs.
Consolidating the wallet beforehand is another transaction with its own fee and privacy consequences. We did not charge an earlier consolidation transaction to the one-input scenario. Treating that input as already available is a stated condition, not evidence that a business can always obtain the 76.45% saving for free. The UTXO and coin-control guide explains how funding history shapes the available inputs.
One transaction ID is not one payment record
A batch has a single but several outputs. Reconciliation should retain the transaction ID, output index, destination and amount for each payout. Matching only the transaction ID can incorrectly mark every invoice in a batch as paid when one output was omitted or entered with the wrong amount.
Useful batch payout record — example field names, not real payment data
Field
Purpose
batch_id and payout_id
Connect the batch to each approved business payment.
destination and expected_ltc
Preserve the verified instruction before constructing the transaction.
txid and vout
Identify the specific recipient output after broadcast.
actual_output_ltc and status
Compare received value and record pending, confirmed or exception.
fee_ltc and allocation_rule
Keep the actual batch fee once; separately document any accounting allocation.
Output order can change during transaction construction. Do not assume the first line in a spreadsheet becomes output zero, or that the largest output is change. Decode the final signed transaction and map outputs to your approved destinations and amounts. If the same and amount appear more than once, keep output indexes and an explicit allocation rule so one output is not counted twice.
The payment tools help prepare and reconcile requests; the transaction checker can inspect a public transaction. The transaction lab explains inputs, recipient outputs and change. None of these tools should be treated as an authorization to send a payout.
When separate payments can be preferable
Batching publicly groups recipient outputs in the same transaction. An observer can see the addresses and amounts, although that alone does not prove the recipients’ identities or a particular business relationship. Combining inputs can also expose relationships between funds. A payroll, refund run or supplier payment list may have privacy requirements that outweigh a small fee reduction.
Waiting to fill a batch can delay a time-sensitive refund. A malformed output or construction error can require rebuilding the whole unsigned batch. Once a valid transaction is mined, its outputs confirm together; that does not mean every recipient has verified their own , invoice reference or withdrawal policy.
If a is replaced, rebuilt or later affected by a reorganization, maintain the link between the business payment and the final output. Do not send a second batch simply because a is slow. First establish whether the original transaction is unconfirmed, replaced, conflicted or confirmed. Our refund and underpayment guide covers the separate business decision about who should bear a fee.
A payout workflow you can actually audit
Approve the recipients and amounts. Verify destination changes through an authenticated channel and freeze the payout list before constructing the batch.
Inspect the available inputs. Estimate both the batch and separate-payment sizes using the same funding assumptions. Account for any preceding consolidation.
Review every output and the fee. Check the final recipient count, amount totals, change destination and fee rate before signing. Keep the recipient amount intact unless a different fee policy was agreed.
Broadcast once and save evidence. Record the final transaction ID, then map each payout to its actual output index.
Reconcile under the agreed policy. Separate amount mismatches from confirmation status and investigate exceptions before retrying.
A small trial run is useful for verifying a new payout process, but its fee and operating time belong in your own cost comparison. This experiment measures transaction construction, not the error rate of a payroll system or a wallet’s CSV import screen.
Exactly what we tested
The script launches its own temporary Core node with peer connections and discovery disabled and standardness explicitly enabled. It mines regtest funding, creates 100 native SegWit funding outputs and builds alternative candidates. Within each separate-payment set, every transaction spends disjoint input . Alternative scenarios reuse the laboratory pool; they are comparisons, not a claim that every scenario can be paid from the pool simultaneously.
For each candidate, the script signs the transaction, decodes the actual size, adjusts the fee to 10 litoshis per measured vbyte, signs again until that amount is consistent, and checks testmempoolaccept. Candidate transactions are not broadcast or mined. The mempool is checked to remain empty after the setup funding has confirmed.
There are 164 candidate checks, including repeated one-recipient controls, rather than 164 unique real-world payments. Random keys and ECDSA signature lengths can change individual vsize measurements slightly on a fresh run. The released JSON is the evidence for the exact table values. The setup funding transaction is excluded from payout fees, and the study does not measure MWEB, mainnet propagation, confirmation time, or GUI support.
The reproduction script needs Python 3 and the verified Litecoin Core 0.21.5.8 executables. It accepts paths to the binaries and an output file, never an existing wallet or data directory. It stops its own daemon on completion. The synthetic regtest data must never be treated as a real wallet backup or proof of mainnet settlement.
Virtual Byte (vB)
In brief A fee-sizing unit for ordinary transparent transactions, usually weight divided by four and rounded up.
A size unit used when quoting fees for ordinary transparent transactions. The usual calculation divides transaction weight by four and rounds up; node policy can also account for signature-operation cost. It can differ from the raw serialized byte count. Use the size unit expected by the quoted fee rate.
For example A transparent transaction with weight 565 has a virtual size of 142 vB, because the division rounds up.
Common mistake Multiplying a litoshi-per-vB rate by an unrelated raw-byte count or assuming the same formula covers every MWEB component.
In brief Software or a device for managing wallet keys and payments, though a watch-only setup cannot sign on its own.
Software or a device that manages keys and helps you receive and send Litecoin. Coins are recorded on the blockchain. A watch-only wallet can show addresses and transactions without holding the keys needed to spend.
For example One wallet can generate several receiving addresses and still show them as a single combined balance.
Common mistake Thinking coins live inside the app, or that seeing a balance proves that the wallet can sign a spend.
In brief A peer-to-peer cryptocurrency with its own Scrypt proof-of-work network and a maximum issuance of 84 million LTC.
A peer-to-peer cryptocurrency launched in 2011. Litecoin uses Scrypt proof of work, targets an average 2.5-minute block interval and has an issuance schedule capped at 84 million LTC. Individual block times and payment acceptance times vary.
For example Sending 0.1 LTC on Litecoin transfers a fraction of one coin; you do not need to buy a whole LTC first.
Common mistake Assuming a token with LTC in its name on another network is automatically native Litecoin.
In brief A participant running network software; a full node checks rules but need not keep all old block files.
A participant running network software. A full node independently validates rules; a pruned full node can discard older block files after validation. Not every node stores the complete historical blockchain.
For example A pruned full node checks the chain but later discards old block files to reduce disk use.
Common mistake Assuming every node is a miner, or that pruning means it skipped consensus validation.
In brief One node's local collection of accepted but unconfirmed transactions, which may differ from other nodes' collections.
A node's local collection of unconfirmed transactions it currently accepts. Nodes can see, retain or remove different transactions, so there is no single global waiting room. Appearing in a mempool is not confirmation or a guarantee of later inclusion.
For example One explorer may see your unconfirmed transaction while another node has not received it or has already removed it.
Common mistake Assuming that absence from one mempool proves the payment was never broadcast or that a seen transaction must confirm.
In brief A transaction format and validation change that separates witness data and changes how block capacity is counted.
Segregated Witness: a change to transaction serialization and validation that separates witness data, fixes certain transaction-malleability issues and changes capacity accounting. Litecoin activated it in May 2017.
For example An ltc1q receiving address uses a SegWit format; the sender still needs to check that its service accepts that address.
Common mistake Assuming every wallet supports every address format, or that SegWit guarantees a fixed confirmation time.
In brief A single-key SegWit output type; Litecoin's ltc1q prefix alone does not distinguish it from P2WSH.
A SegWit version-0 output type that commits to a public-key hash. Spending it places the signature and public key in witness data. Its native Litecoin mainnet address uses ltc1q, but that prefix also covers P2WSH, so the prefix alone is insufficient for a precise fee model.
For example The fee estimator's native SegWit input option models P2WPKH. Check the wallet's actual script type before selecting it.
Common mistake Assuming every ltc1q output is the single-key P2WPKH type or confusing its witness bytes with full-price base bytes.
In brief A wallet-controlled destination for leftover LTC after spending an input on a payment and its fee.
Spending a transparent transaction output uses its whole value. After paying the recipient and fee, a wallet can send the leftover LTC to an address it controls. That destination is a change address. Wallets usually choose it automatically.
For example A fictional 1 LTC input paying 0.3 LTC with a 0.00001 LTC fee can return 0.69999 LTC to a wallet-controlled change output.
Common mistake Assuming an unfamiliar second output is a second payment to the recipient; first check which outputs your wallet owns.
In brief An informal name for 0.00000001 LTC, the smallest Litecoin unit, with 100,000,000 in one LTC.
An informal name for the smallest Litecoin unit: 0.00000001 LTC. One LTC contains 100,000,000 litoshis. Some software uses the inherited label satoshi, so always check which coin and unit a screen means.
For example 10,000 litoshis equal 0.0001 LTC; 1 litoshi equals 0.00000001 LTC.
Common mistake Confusing a fee quoted per virtual byte with that many litoshis for the whole transaction.
In brief For ordinary transparent Litecoin transactions, the fee is total input value minus total output value, separate from a service withdrawal charge.
For an ordinary transparent Litecoin transaction, the network fee is the total input value minus all output values, including change. Wallets estimate it using transaction size and a fee rate, so sending more LTC does not automatically mean a higher fee. A service's withdrawal charge is a separate quote and may already cover network costs.
For example Fictional inputs total 1 LTC, while recipient and change outputs total 0.99999 LTC: the network fee is 0.00001 LTC.
Common mistake Confusing fee rate with total fee, leaving change out of output totals, or equating a service's withdrawal charge with the full network fee.
Compare: Network fee vs withdrawal fee
Transaction Fee
An ordinary transparent transaction's network fee is its total input value minus its total output value; transaction size and fee rate help determine the estimate.
Withdrawal Fee
A service sets its withdrawal charge under its own rules, and that charge can differ from the network fee on the transaction it broadcasts.
One example If a fictional service deducts a 0.001 LTC charge from a 1 LTC withdrawal, the recipient receives 0.999 LTC; these figures do not reveal the transaction's network fee.
Remember: Check the final account debit, recipient amount and minimum separately; add a network-fee estimate only if it is an additional charge, so the same cost is not counted twice.
In brief A fee per unit of transaction size, rather than the total charge, with MWEB using additional accounting.
A fee per unit of transaction size, rather than the total charge. For ordinary transparent Litecoin, wallets commonly quote litoshis per virtual byte. The estimated total depends on both that rate and the transaction's virtual size; MWEB adds different accounting.
For example An illustrative 200-vB transaction at 2 litoshis/vB costs 400 litoshis, while a 400-vB transaction at that rate costs 800.
Common mistake Reading 2 litoshis/vB as a 2-litoshi total, or assuming a recommended rate guarantees a confirmation time.
In brief An unspent output from an earlier transaction, used whole when selected for an ordinary transparent payment.
An unspent transaction output: a recorded amount from an earlier transaction that has not been spent. A transparent Litecoin wallet can select eligible UTXOs as inputs for a new payment. Each selected output is spent in full; value left after the payment and fee can return as change.
For example Fictional receipts of 0.4 LTC and 0.6 LTC can be two UTXOs even when a wallet shows a single 1 LTC balance.
Common mistake Assuming the displayed wallet balance is one indivisible account entry, or that spending an input sends all of it to the recipient.
In brief A transaction identifier for looking up outputs and confirmations, which alone does not prove that a payment arrived.
The identifier used to look up a transaction. For an ordinary transparent Litecoin transaction it is shown as a 64-character hexadecimal string. Use it to inspect the transaction's outputs and confirmations; the ID alone does not prove a payment is confirmed.
For example Copy the TXID from your wallet's payment details into a Litecoin explorer to check the recipient output and confirmation count.
Common mistake Sharing a seed phrase to trace a payment, or treating a screenshot or TXID alone as proof that the expected amount arrived.
In brief An encoded payment destination whose network, owner and wallet compatibility still need checking.
An encoded destination for a payment. Common transparent Litecoin addresses begin with L, M or ltc1; MWEB uses a different address format. An address is not a bank account or proof of identity. Check network and wallet compatibility before sending.
For example To receive LTC, copy a Litecoin receiving address from your wallet and check it against the address shown to the sender.
Common mistake A valid-looking address does not prove that it belongs to the intended person or uses the network the sender selected.
In brief Recovery material for a specific wallet and format, whose coverage depends on when and how the backup was made.
A recovery copy of the material needed for a particular wallet, such as its wallet file and required configuration. Coverage depends on the format and when it was made; later imported keys may require a fresh backup.
For example A Core wallet-file backup made before a separate key import can omit that imported key.
Common mistake Treating a receiving-address list as a spending backup, or assuming every wallet file can be restored by another application.
In brief Submitting a signed transaction to a node for checking and sharing, without proving it has been confirmed.
Submitting a signed transaction to a node for validation and possible relay to peers. A signed file and its identifiers can exist before submission. Acceptance by one node does not establish that all peers saw it, a miner included it or a service credited it.
For example An offline signer can prepare a payment that remains outside the mempool until the approved transaction is submitted online.
Common mistake Treating a TXID or signed file as proof of broadcast, or treating a local submission response as a confirmation.
In brief Recorded in accepted blockchain blocks, unlike account changes a service may make only in its own records.
Recorded in the blockchain's accepted blocks. For transparent Litecoin, many transaction details are publicly visible, but an exchange's internal account changes need not create an on-chain transaction. Blockchain records alone do not establish an owner's identity or why funds moved.
For example A confirmed ordinary LTC payment appears in Litecoin blocks; an exchange moving balances between its own customer accounts may not.
Common mistake Assuming every account activity creates a blockchain transaction or that every large transfer is a trade.
In brief A tool showing its indexed view of public blockchain data, which cannot reveal a service's internal account status.
A website or app that indexes blockchain data so you can inspect blocks, transactions and outputs. It reports its own data view. Looking up a public transaction needs no private key, and an explorer cannot see a service's internal account-crediting decisions.
For example Look up a transparent Litecoin TXID to check the destination output, amount and reported confirmations.
Common mistake Entering recovery words to track a public transaction, or treating one explorer's missing result as proof that no payment exists.
In brief A transaction gains confirmations as blocks build on its inclusion, but those confirmations can fall if chain history changes.
A transaction receives its first confirmation when included in a block in the accepted chain. Each block then built on top adds another. A chain reorganization can reduce or remove the count. The recipient decides how many confirmations it requires. Litecoin targets an average 2.5-minute block interval; individual blocks can arrive sooner or much later.
For example A transaction in the latest accepted block has one confirmation; the next block raises that count to two.
Common mistake Confusing a wallet's sent message, a TXID or mempool visibility with the first confirmation.
In brief A transaction ID plus an output number, identifying one specific output of a transparent transaction.
The pair that identifies one output of an ordinary transparent transaction: its TXID and zero-based output index, often called vout. One transaction can create several outputs, so a transaction ID alone does not identify which one you mean.
For example TXID plus vout 0 and the same TXID plus vout 1 identify different outputs, even if both use the same receiving address.
Common mistake Assuming the recipient is always output zero or treating an address balance as the state of one specific output.
In brief A service for trading currencies or assets, whose custodial account balance does not give you control of its private keys.
A platform or service for buying and selling cryptocurrencies against fiat currencies or other assets. Trading methods, custody, supported pairs and withdrawal rules vary by service. A balance on a custodial exchange is an account claim; it does not mean you control the wallet's private keys.
For example After buying LTC on a custodial exchange, you request a withdrawal if you want it sent to your own wallet.
Common mistake Assuming an account balance means you possess the private keys, or overlooking the selected withdrawal network.
In brief A service's charge for moving LTC out, which can differ from the network fee and reduce what the recipient receives.
A charge a service quotes for moving LTC out of your account. Its rules determine the fee, minimum and amount received. A service can batch several withdrawals into one transaction, so one customer's quoted charge need not match the transaction's network fee. Check the final account debit and recipient amount before confirming.
For example If a service deducts a hypothetical 0.001 LTC fee from a 1 LTC withdrawal, the recipient receives 0.999 LTC; other services may quote the debit differently.
Common mistake Assuming an exchange charge is the network's fixed fee, or confirming without checking the final recipient amount and minimum.
Compare: Network fee vs withdrawal fee
Transaction Fee
An ordinary transparent transaction's network fee is its total input value minus its total output value; transaction size and fee rate help determine the estimate.
Withdrawal Fee
A service sets its withdrawal charge under its own rules, and that charge can differ from the network fee on the transaction it broadcasts.
One example If a fictional service deducts a 0.001 LTC charge from a 1 LTC withdrawal, the recipient receives 0.999 LTC; these figures do not reveal the transaction's network fee.
Remember: Check the final account debit, recipient amount and minimum separately; add a network-fee estimate only if it is an additional charge, so the same cost is not counted twice.
Downloadable data or code · Controlled wallet / regtest.
Content review recorded: 2026-09-29. The review record does not identify a separate independent reviewer. An edited date above records an edit, not a new fact-check. AI-assisted editing or new artwork alone does not complete a source review.
Editor-in-chief of Litecoin.watch and founder of MyBank.pl. His published work covers foreign exchange, financial education and Litecoin. On Litecoin.watch, his remit includes editorial direction, source transparency and the practical guides and research published by the site.
