Use an address generated by the intended receiver, on the intended Litecoin network, through a route both wallets support. A recognizable prefix is only the beginning of that check. It does not identify the owner, prove a deposit will be credited or establish what a later spend will cost.
Expanded review · 22 October 2026. Format descriptions use Litecoin Core 0.21.5.8. The examples reuse our 3 October controlled address-decoding study: 18 synthetic fixtures and 36 RPC observations, with disconnected mainnet-mode and regtest nodes. There was no transfer, synchronized-chain observation, service-credit test or MWEB wallet test.
Common mainnet formats
| Visible form | What it describes | Important qualification |
|---|---|---|
| L… | Base58Check P2PKH destination | Legacy transparent key-hash output |
| M… | Modern Litecoin Base58Check P2SH destination | Can wrap witness or other redeem scripts |
| 3… | Historical version-5 P2SH encoding | Overlaps Bitcoin's familiar form; chain remains a separate choice |
| ltc1q… | Witness version 0, Bech32 | Can encode a key-hash or script-hash program |
| ltc1p… | Witness version 1, Bech32m | Often associated with Taproot; require explicit wallet support |
| ltcmweb1… | MWEB receiving address | Requires an explicitly supported MWEB workflow |
The network parameters define Litecoin's version bytes and human-readable prefixes. The address encoder and decoder map them to destinations. Core accepts both historical and modern P2SH versions, while generating the modern form. This compatibility does not require every service to accept both.
“SegWit address” is not one unique family. P2SH may wrap a witness program; native witness addresses encode it directly. Likewise, the first witness-version character does not by itself establish the program's length, every spending rule or the sending wallet's capabilities. In particular, do not promise universal Taproot support from an ltc1p prefix.
Checksums, networks and ownership answer different questions
Base58Check and Bech32-family encodings contain error-detection checksums. A valid checksum can catch many transcription errors; it cannot tell whether an attacker supplied a different valid destination. The decoder must also accept the network, version, program length and checksum family.
BIP 173 defines the Bech32 family and case rules. BIP 350 specifies Bech32m for witness versions 1 and later; version 0 retains Bech32. For ordinary witness addresses, all-lowercase and all-uppercase representations can be valid, while mixed case is rejected. Base58 strings are case-sensitive and do not follow that conversion rule.
| Synthetic case | Mainnet-mode result | Meaning and limit |
|---|---|---|
| Modern M and historical 3, identical script-hash payload | Both valid; identical output scripts | Encoding compatibility, not ownership or cross-chain recovery |
| Ordinary ltc1q fixture | Valid | Syntax and destination accepted under these parameters |
| Different valid ltc1q payload | Also valid | A valid substituted destination still passes parsing |
| All-uppercase / mixed-case Bech32 fixture | Valid / invalid | Case rules are format-specific |
| One checksum-character typo | Invalid | The particular Base58 and Bech32 changes were detected |
| bc1, tltc1 or rltc1 fixture | Invalid | Wrong human-readable prefix for Litecoin mainnet |
| Complete litecoin: payment URI | Invalid as a bare address | A URI parser must extract and check its fields first |
The regtest node accepted the appropriate regtest forms instead. “Mainnet mode” here describes decoder parameters at height zero with no peers. It does not mean the fixtures were used on the live chain. Download the 36 recorded observations and method and limits; full fixture strings are explicitly labeled “do not send”. The study did not exercise witness-v1 or MWEB destinations.
A prefix is not a complete fee model
The destination determines the output script being created. Future fees also depend on the scripts of the inputs spent, input count, change, signatures and selected fee rate. Switching today's receiving format does not rewrite existing outputs: spending or moving them requires a new transaction.
A historical 3 and modern M encoding of the same script hash can create the same P2SH output. Renaming that encoding does not turn an arbitrary redeem script into native SegWit or reduce its spending data. The address also cannot reveal the entire redeem script hidden behind its hash.
Compare final wallet previews for equivalent payments rather than assigning one permanent fee to each prefix. For example, the same hypothetical 200 vB at 2 litoshi/vB costs 400 litoshis regardless of the amount sent. That illustration is not a measured P2SH, Taproot or MWEB size. The fee guide supplies actual archived signed-size cases and explains RPC units.
Compatibility is a two-sided question
Check four layers before paying: the chain selected by the sender, the destination's encoding, the sender's ability to construct that transaction, and the receiver's ability or willingness to recognize and spend the result. A custodian can impose narrower rules than the underlying protocol. A successful address-decoding check cannot substitute for its deposit instructions.
- Open a fresh receiving request in the intended wallet or provider account. Confirm the asset and actual network name.
- Read supported formats, minimum deposits and any route-specific restrictions. Resolve uncertainty with the receiver before sending.
- Paste or scan the complete request. Inspect any payment URI's destination and amount in the wallet's own preview.
- Authenticate the complete address through the intended channel, and review it on the signer's trusted display when available.
- If the receiver recommends a small trial, ensure it exceeds applicable minimums and verify actual credit before the remainder. A trial costs money and does not guarantee future compatibility.
Do not “repair” a rejected address by changing its visible prefix. That changes the encoded data without the required checksum and may misunderstand the destination. Historical P2SH re-encoding requires preserving the exact script hash and recomputing the checksum; use only a verified, explicitly supported workflow. An unknown web converter adds another place for address substitution.
MWEB changes visibility
An MWEB receiving address is not an ordinary transparent output with a cosmetic prefix. The MWEB design describes extension-block transactions and their confidentiality model. Wallet support and peg-in or peg-out handling matter to the route.
Confirm explicit MWEB support at both ends. A provider that accepts ordinary Litecoin mainnet deposits may still decline that workflow. Do not send to a generic deposit page on the assumption that every LTC route is interchangeable. Moving funds across visibility boundaries can reveal information at entry and exit; software, network metadata and a counterparty's records remain relevant. MWEB is not a promise of anonymity against every observer.
The address-decoding experiment above did not test MWEB transfer behavior. Use the MWEB learning path and a specific wallet's current documentation for that separate workflow.
Address hygiene matters across formats
Generate new receiving requests when your wallet supports them, keep useful private labels and verify the whole destination. An address copied from transaction history may belong to change, a previous counterparty or an attacker imitating familiar leading and trailing characters. A checksum does not authenticate your intended recipient.
Fresh addresses can reduce straightforward address reuse, but do not erase public links created when transparent inputs are later spent together. See the dusting and address-poisoning guide and the cold-storage recovery checks. Never disclose recovery words to an address checker; address validation does not require them.
What to do after a wrong-network transfer
Record the transaction ID, actual chain used, full destination, time and the receiver's deposit instructions. Establish whether anything was broadcast and confirmed. If it is still only a withdrawal request, the provider's cancellation process may matter more than blockchain tools.
After confirmation, the possible recovery depends on the actual output conditions, who controls the necessary keys or scripts, and the custodian's procedures. A visually similar address or shared script-hash version does not establish that a particular service can or will recover it. Sending more funds or importing a seed into a “recovery” website cannot reverse consensus history. Follow the wrong-network guide for evidence to collect and the boundaries of its controlled tests.
Use this guide
Download the address and route checklist. It separates checksum, network, wallet support, receiver policy and destination authentication. Use payment route information and the MWEB wallet filter to narrow your investigation, then check the chosen provider's current instructions. Neither directory is a guarantee for a specific deposit.
Frequently asked questions
Are all M addresses wrapped SegWit?
No. M identifies the modern Litecoin P2SH encoding. The underlying redeem script can represent different spending arrangements.
Can a 3 address be valid for Litecoin?
Yes. Core accepts the historical P2SH version. Its overlap with a familiar Bitcoin form makes the chain selection and receiver's instructions especially important.
Does a valid checksum prove I have the right recipient?
No. Another valid address can pass every syntax check. Authenticate the complete destination separately.
Is ltc1p universally supported?
No. It denotes witness version 1 with Bech32m encoding. Confirm the particular sender, receiver and spending workflow explicitly.
Does changing my receiving format move old coins?
No. Existing outputs retain their scripts. Moving their value requires spending them in a new transaction with its own fee and privacy consequences.
Can I send MWEB to every LTC exchange deposit?
No. Use an explicitly supported MWEB route. General Litecoin deposit support does not establish MWEB support.
