Sending Litecoin to the wrong network: address checks and recovery limits

You copy a deposit address, select a network and see a green “valid address” message. It is tempting to treat that as approval for the whole transfer. It is only one check. The address can pass while the recipient expects a different asset, a service does not support that route or nobody you intended to pay controls the destination.

A valid Litecoin address is a description the Litecoin software can turn into a destination. It is not proof of the recipient's identity, a promise of exchange credit or a command to send the coins onto another blockchain.

We generated 18 synthetic address and request fixtures and checked each with Litecoin Core 0.21.5.8 in two isolated modes. A historical P2SH address beginning with “3” passed the Litecoin mainnet-mode check. A modern “M” address encoding the same script hash also passed, and both produced the same output script. A Bitcoin “bc1” address did not pass. Those differences matter when someone says “a Bitcoin address will always be rejected” or “if the address passes, the network must be right.”

The tests did not send coins. Both nodes had zero peers, disabled wallets and chain height zero. This is an address-parser experiment, not a wrong-network recovery attempt or a survey of exchange deposit policies. All downloadable addresses are synthetic fixtures: never send money to them.

Separate the asset, network and destination

Before a transfer, write down three things: what asset leaves the source account, which network carries the transaction and what the recipient says it can receive. An LTC label alone is insufficient if a service also lists wrapped tokens or several deposit routes.

For a self-custody wallet, generate the receiving address in the intended wallet and network. For an exchange, open its current LTC deposit screen, read the network instructions and check any service notice, minimum and supported features. Do not substitute a BTC deposit screen because an old address looks familiar.

The sender's chain determines where an ordinary transparent transaction is published. If Litecoin software accepts a destination string, it constructs a Litecoin output; that string does not instruct Litecoin to deliver coins to the Bitcoin chain. A bridge or wrapped-token route is a separate system with its own controls and risks. Our bridge and wrapped-LTC guide covers that distinction.

What 36 Core checks actually returned

We submitted the same 18 fixtures to validateaddress on a disconnected Litecoin mainnet-mode node and on a fresh regtest node. The mainnet-mode node was deliberately not synchronized: this RPC checks address encoding without needing a transaction history. A positive result here says nothing about past payments or control of funds.

The complete 36-row CSV records both checks for every fixture. The JSON export retains the returned script and node-mode evidence. We did not test the corresponding Bitcoin node; the Bitcoin P2SH version-5 definition is separately documented in BIP13.

This matrix is for the listed transparent fixtures. It is not a complete compatibility list for every Litecoin script, witness version, MWEB destination or wallet product. A service can support fewer formats than Core accepts.

Why a “3” address is a particularly useful counterexample

A script-hash address encodes a hash associated with spending conditions. It does not contain the complete conditions or the signatures needed to satisfy them. Litecoin historically supported the same version-5 P2SH address encoding used by Bitcoin. The newer Litecoin version-50 encoding commonly starts with “M.”

In our fixture pair, the “3” and “M” strings looked different but Core returned exactly the same script bytes. For the declared synthetic payload H, the script was OP_HASH160 H OP_EQUAL. That is a narrow encoding equivalence, not proof that a particular recipient has the corresponding redeem script or signing keys.

If you submit a historical “3” destination to a Litecoin wallet that supports it, acceptance does not convert a Litecoin transfer into a Bitcoin transfer. It means the wallet recognized a script-hash destination on the Litecoin chain. A custodial Bitcoin deposit address may have no supported LTC crediting workflow, even if the provider controls related signing material.

Do not manually rewrite an exchange deposit address from “3” to “M” as a workaround. Encoding equivalence in our controlled pair does not authorize a route the service has not approved. Request current, explicit LTC deposit instructions from the provider.

A checksum does not authenticate the recipient

We altered one checksum character in a Base58Check fixture and one in a Bech32 fixture. Core rejected both. It also rejected a mixed-case Bech32 string. An all-uppercase version of the original Bech32 address passed and produced the same script as the lowercase version.

That behavior demonstrates useful error detection. It does not justify the claim that every wrong destination will fail. We generated a second, different Litecoin witness-v0 destination with its own correct checksum. It also passed, while its script differed from the first. A maliciously substituted address can be fully valid.

Compare the entire address with the current request obtained through a channel you trust. When using a hardware signer, follow the model's documented address and transaction-display checks. Our hardware-wallet threat checklist separates signing protection from fraudulent requests and stolen backups.

Do not treat a familiar first letter as a substitute for validation. Nor should you manually edit case or characters until a warning disappears. For a payment URI or QR code, inspect the request as a request: the bare validateaddress RPC rejected our litecoin:…?amount=1 fixture because a URI is not a bare address. A wallet may parse that URI first. The QR inspector and payment-request guide explain those layers.

A small test transfer helps with only part of the problem

A successful test to your own wallet can demonstrate that the chosen route delivered an output that the wallet discovered. A test credited by a service can check that service's current account workflow. Those are useful checks when a route is new, provided you also consider its minimum and charges.

A test below the service's minimum may confirm on-chain but remain uncredited. A small test cannot authenticate an investment scheme, prove a stranger will return funds or validate a later address changed by malware. Recheck the full destination and instructions before the larger transfer.

For exact deposits or invoices, remember that the received amount can differ from the amount entered when a fee is subtracted. Our exact amount and send-max experiment shows the accounting. Before treating an exchange withdrawal as complete, separate the source's account debit, public transaction status and receiving service's credit.

If a wrong transfer may already have happened

Stop before sending another payment. Preserve the source's withdrawal record, chosen asset/network, full destination, amount and transaction ID if one exists. A rejected preview is different from a broadcast transaction; a service withdrawal request can also be awaiting processing without a public transaction.

Use an explorer or our transaction checker appropriate to the actual sending chain. An explorer not finding a hash on one chain does not prove there was no transaction elsewhere. Check the source's stated network rather than trying unrelated explorers at random.

Contact a receiving service through its independently located official support route. Provide only the public transaction details and account information it legitimately requires through its authenticated process. Do not type a recovery phrase into an unsolicited “recovery” form or pay someone promising a guaranteed reversal.

Recovery depends on the actual destination, available signing material, script or contract rules, and service cooperation. Address validity alone cannot settle it. A confirmed ordinary Litecoin payment cannot simply be recalled because the destination was unintended; our cancellation experiment separates that from a local pending request.

A transfer record that catches the mismatch before signing

1. Record the source asset and network. Use the actual withdrawal or wallet screen, rather than a ticker copied from a price page.
2. Read the recipient's current supported route. Check the deposit screen, feature support, minimum and service status.
3. Compare the entire destination. Validate its format, then independently verify that it is the requested destination.
4. Inspect the final amount. Check net receipt, total fee and any exact invoice requirement.
5. Review the signer or final confirmation. A previously successful transfer does not authenticate a newly substituted address.
6. Retain the outcome. Record the transaction ID, confirmed output and service-credit result separately.

The blank route checklist is designed for local use. It has no field for a private key, seed or password. Treat address and transaction records as potentially revealing financial activity even though they are public on-chain.

Method and what our experiment did not prove

We built fixtures from deterministic synthetic 20-byte hash payloads using Base58Check and witness-v0 Bech32 encoding. We launched separate Core 0.21.5.8 processes in fresh temporary directories: one in mainnet mode, one in regtest mode. Both had networking disabled through their connection/listening settings, no peers, wallets disabled and height zero.

The 18 fixtures produced 36 validateaddress observations. Forty-six executable assertions checked modes, isolation, expected parser outcomes, equivalent historical/modern P2SH scripts, uppercase equivalence and two distinct valid destinations. The source definitions were checked against the pinned network parameters and destination decoder.

Download the collector code, method, complete package and checksums. An offline package check can verify encoding and recorded consistency; rerunning the Core experiment is necessary to obtain new Core parser observations.

We did not connect to the live chains, create wallets, possess signing keys for the fixtures, send funds, test MWEB or recover a mistaken deposit. No exchange or physical wallet was tested. The cover and SVG figures are original diagrams, not service screenshots. Research, code and drafting used AI assistance; no independent external reviewer is claimed. Released 3 October 2026. Corrections can be reported through our corrections page.