Paying 50 people with Litecoin: one transaction or 50?

We built and signed 164 candidate transactions with Litecoin Core 0.21.5.8 in an isolated regtest network. Every candidate passed that node’s standard mempool-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 SegWit (P2WPKH) 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 change output 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

For 50 recipients, the batch fee is 16,600 litoshis, 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 miner fee 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 fee rate, 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

A merchant receiving many small payments might need dozens of UTXOs 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 transaction ID 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.

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 address 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 wallet backup, invoice reference or withdrawal policy.

If a broadcast transaction is replaced, rebuilt or later affected by a reorganization, maintain the link between the business payment and the final on-chain output. Do not send a second batch simply because a block explorer 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

1. Approve the recipients and amounts. Verify destination changes through an authenticated channel and freeze the payout list before constructing the batch.
2. Inspect the available inputs. Estimate both the batch and separate-payment sizes using the same funding assumptions. Account for any preceding consolidation.
3. 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.
4. Broadcast once and save evidence. Record the final transaction ID, then map each payout to its actual output index.
5. Reconcile under the agreed confirmation 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 outpoints. 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, exchange withdrawal charges or GUI support.

Download and reproduce

Study ZIP · 12 scenario comparisons · CSV · All signed candidates · JSON · Reproduction script · Method and commands · SHA-256 checksums

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.