How small can a Litecoin payment be? Dust limits tested in Core

A Litecoin payment can fail because one output is too small, even when the sender offers a generous transaction fee. In our test, a native SegWit output worth 2,939 litoshis was rejected as dust. Increasing it to 2,940 litoshis, with the same total fee, made the transaction acceptable to the local node.

We ran 21 candidate checks in Litecoin Core 0.21.5.8 on 27 September 2026. The experiment used a fresh, isolated regtest chain, synthetic coins and three common receiving script types. It also uncovered a documentation trap: comments in this release still quote dust examples based on a different default from the one Litecoin actually compiles.

The results help answer a practical question for small refunds, tips and test payments: is the amount too small for the output, or is the transaction fee too low? Those problems need different fixes. The data and reproduction script are public.

The three boundaries we measured

One litoshi is 0.00000001 LTC. That is the amount unit; it does not mean an ordinary transaction paying one litoshi to a receiving address will pass a node's relay policy. With the default dust setting, our three output types had these boundaries:

We also tested one litoshi above each boundary; all three candidates passed. These are deterministic boundary checks, not a statistical sample of Litecoin users. “Accepted” means that testmempoolaccept returned allowed: true for our local node. We did not broadcast the candidates or test their propagation across mainnet.

Why the familiar 546 and 294 figures are wrong here

The comments beside Core's dust calculation give examples of 546 and 294 smallest units at a rate of 3,000 per kilobyte. However, this Litecoin release's compiled default in policy.h sets DUST_RELAY_TX_FEE to 30,000. Reading only the example comments produces an answer ten times too low for the default we tested.

The calculation adds the serialized output size to a policy allowance for a future spending input, then applies that dust rate. For these scripts, the arithmetic is:

• P2PKH: (34 + 148) × 30,000 / 1,000 = 5,460 litoshis.
• P2SH-P2WPKH: (32 + 148) × 30,000 / 1,000 = 5,400 litoshis.
• P2WPKH: (31 + 67) × 30,000 / 1,000 = 2,940 litoshis.

The 148 and 67 are allowances used by this policy calculation, not promises about the exact size of a future signed input. The check rejects values strictly below its threshold; equality passes this particular check. Our boundary tests agreed with that arithmetic.

Nested SegWit deserves attention. Its receiving output is a P2SH script, so this dust calculation uses the non-witness branch for that outer script. It does not look inside the eventual redeem script and award the native P2WPKH boundary. Treating every SegWit address as having the same minimum would give the wrong result.

Paying ten times the fee did not fix dust

We kept each rejected output exactly one litoshi below its boundary, then increased the whole transaction fee from 10,000 to 100,000 litoshis. All three still failed with the same dust reason.

Those deliberately ample fees isolate the problem; they are not fee recommendations. Dust policy evaluates an individual output against a configured dust rate. It does not use the fee attached to the candidate transaction as a substitute for the output's value. To fix this failure, the sender has to change the small output or the payment construction, rather than simply bid more for the same transaction.

There can be more than one affected output. A recipient amount may be large enough while a tiny change output is not. Our UTXO and change guide explains why the amount sent, the change returned and the miner fee must be checked separately.

A node setting, not a universal minimum payment

For a second control, we restarted the isolated node with -dustrelayfee=0.00060000: 60,000 litoshis per kilobyte, twice the default. We repeated the minus-one, exact-boundary and plus-one tests. The measured boundaries doubled.

The startup option implementation exposes this setting. This is local transaction policy, not a consensus rule that every block must obey. Changing your own setting does not make peers adopt it. Our experiment did not try to get a dust output mined, and the override is not a recommendation for a public node.

Likewise, a wallet or exchange can impose its own minimum send, withdrawal or credited deposit. Passing Core's dust check does not override those rules. A merchant also needs an amount worth collecting and reconciling, not merely a technically admissible output.

What this changes for small payments and refunds

Consider a hypothetical 0.00004000 LTC payment: 4,000 litoshis. It is above our native P2WPKH boundary but below both other boundaries. Choosing a recipient-supported native SegWit address could therefore change the local policy outcome. It would not establish that the payment service credits such small deposits, or that the transfer is economical.

For a failed small payment, use this order:

1. Read the actual rejection. A dust error is different from an insufficient transaction fee or a service's withdrawal minimum. Raising fees is not a general repair.
2. Inspect every output. Check the recipient amount, script type and change. The transaction lab shows how inputs, outputs and fees fit together; it is not a promise that a payment provider will accept a particular amount.
3. Agree on a useful payment amount. For a refund below the applicable minimum, combine obligations or agree on another settlement method. Do not silently increase a refund, deduct an extra fee or change the destination.
4. Check the receiver's crediting rules. A transaction appearing on-chain and a custodial account being credited are different events. For invoices, see our refunds and underpayments guide.

An output at the boundary is not guaranteed to be worth spending later. Future transaction size, fee conditions and whether it can be combined with other inputs all matter. Our fee page addresses transaction costs; the dust thresholds above are not live fee estimates.

Finally, a dust-policy amount is not the same thing as a dusting attack. Unsolicited small transfers can be part of address tracking or poisoning attempts, even when they pass relay rules. The dusting and address poisoning guide covers that separate problem.

How to inspect and reproduce the evidence

Release 2026-09-27.1 records nine default-boundary candidates, three higher-fee controls and nine candidates under the doubled setting. Each spends the same mature test input and creates a target plus a large change output. The script signs the transaction, calls testmempoolaccept and confirms that the mempool remains empty.

One essential test condition: regtest normally permits nonstandard transactions. We explicitly started the node with -acceptnonstdtxn=0 to enforce the standardness checks. Omitting that flag would invalidate this comparison. Networking was disabled, and no existing wallet was opened.

Download the 21-row CSV, full JSON with signed transaction hex and RPC verdicts, or complete reproduction package. The README lists the exact version, binary hash, command and limitations; checksums cover the package contents. Fresh runs produce different keys and transaction IDs, but the tested amounts and decisions should match.

We tested transparent P2PKH, nested P2WPKH and native P2WPKH only. We did not test MWEB, P2WSH, wallet interfaces, mainnet propagation, mining or exchange minimums. Original observations and diagrams are CC BY 4.0; our script is MIT-licensed. Preparation used AI-assisted coding and drafting, actual executable runs and scripted checks. No independent human review is claimed. Reproducible corrections are welcome through our corrections process.