How two wallet parsers handle Litecoin payment requests
Twenty identical requests reveal differences in repeated amounts, decimal precision and metadata at the parsing boundary of Electrum-LTC and Cake Wallet. Exact versions, code and results are published.
Dotted-underlined terms open a quick definition. Close it to keep reading.
A payment request can look correct as text and still be interpreted differently at the next step. To find out where those differences begin, we passed the same 20 inputs through code from Electrum-LTC 4.2.2.1 and Cake v6.4.5.
The most useful finding is about repeated amounts. For amount=1&amount=2, Electrum’s URI function returned a duplicate-key error. Cake’s request-parsing function, running with Dart 3.13.5, returned the amount string 2. That is a reason to remove ambiguity from a request before sharing it.
This is a test of source-isolated parsing functions. We did not run either complete wallet, scan with a phone camera, construct a payment, sign or broadcast. A function returning an invalid amount or does not establish that the complete application allows it. Its next screen can perform additional checks.
What we actually ran
The boundary of each test
Implementation
Executed code
Outside the experiment
Electrum-LTC 4.2.2.1
Unchanged upstream URI, Base58Check and SegWit validation function bodies, extracted through Python’s AST from the verified release archive
Full package startup, GUI, scanner, payment-request callback, signing and sending
Cake Wallet v6.4.5
Unchanged constructor and PaymentRequest.fromUri factory from commit 9fe23970c7a6e7f88e2bab88abe4e6346c732316, compiled and executed with Dart 3.13.5
Full app, fromString fallback, scanner, downstream send-screen amount/address checks, signing and sending
The Electrum archive was checked against ec5dbc72f7be1c3e490cae6281f9060ff36f4c27c0df783e0e6409e66c0f33d4. Cake’s source file and generated harness have separate hashes in the downloads. Its unrelated , ERC681 and Nano dependencies were replaced by guarded adapters. None of the corpus inputs entered those dependency branches; entering an unsupported branch would abort the experiment.
We used synthetic public address hashes with no known . They test encoding and checksum behavior, not . Never fund an address in the corpus. No real customer request or wallet secret was used. The exact text and returned fields are available in the case explorer.
Nine cases that change how you should prepare a request
Results at the parsing boundary; “returned” is not “payable”
Input
Electrum function
Cake function
Practical consequence
URI with no amount
No amount
No amount text
Ask the payer to enter and verify the agreed amount.
Nine decimals
12345678 litoshis
0.123456789
Request only amounts representable with eight decimals.
Negative amount
-100000000 litoshis
-1
A returned field does not establish a valid spend.
Duplicate amount
Error: Duplicate Key: 'amount'
2
Use one amount parameter; do not depend on precedence.
Unknown required field
Amount plus req-invoice retained
Amount returned; req-invoice not exposed
Do not depend on a required extension unless the actual wallet enforces it.
UTF-8 and encoded ampersand
Label: Café & invoice 17
No note from label
Check the destination through another trusted channel.
Address validation can happen after parsing; test the whole flow separately.
Wrong currency scheme
Error: Not a litecoin URI
0.125
A scheme returned as text is not currency validation.
Scientific notation
1 litoshis
1e-8
Use ordinary decimal LTC amounts for portable requests.
The full 20-case table also covers plain addresses, one- amounts, an empty amount, a decimal comma, optional metadata, an unescaped ampersand, uppercase scheme, native , an amount above supply and expiry fields. These are deliberately selected cases, not a random sample of real-world requests. We do not turn their counts into a wallet reliability score.
Repeated amount fields are an avoidable disagreement
The request litecoin:address?amount=1&amount=2 contains two instructions under one key. In this Electrum version, parsing the query detects the repeated key and raises an error. Cake’s factory reads Dart’s single-value Uri.queryParameters map; in the tested runtime it obtains the last amount value.
Neither behavior is an excuse to send an ambiguous invoice. Generate one amount field, decode the generated request and compare it with the invoice. If you receive a request with duplicates, ask for a corrected one rather than guessing which value the sender intended.
A readable QR symbol, a returned URI object and a valid payment are separate outcomes.
Precision can change before you see a send screen
With amount=0.123456789, Electrum returned 12345678 litoshis. Converting that integer back to LTC gives 0.12345678: the ninth decimal was truncated at this function boundary. Cake returned the original string 0.123456789. We did not test how its send screen rounds or rejects that string.
For an invoice, write an amount representable in eight decimal places. Avoid scientific notation, negative amounts and local decimal commas even when a parser happens to return them. Both tested functions returned a field for the negative-amount fixture; that observation is about parsing, not spend validation.
Required fields, labels and expiry need their own checks
Our unknown-required fixture added req-invoice=17. Electrum returned it in the parsed fields. Cake returned the address and amount without exposing that parameter in the request object. Neither result proves enforcement of a required extension by the complete application. A merchant should test the actual wallet flow before depending on an extension for acceptance.
An encoded label=Caf%C3%A9%20%26%20invoice%2017 became a readable label in Electrum. Cake’s tested factory uses message or tx_description for its note; the label fixture produced an empty note. A label can disappear without changing the destination, and a convincing label can accompany the wrong destination. Compare the full address through an authenticated channel.
The expiry fixture returned data at both boundaries. We did not establish whether either full application enforces its time and exp fields. Put quote expiry and late-payment policy in the invoice itself; do not assume an arbitrary URI field will enforce the commercial agreement.
A short preflight for merchants and payers
Use one destination and one ordinary decimal amount in LTC. Avoid duplicated keys and unnecessary extensions.
Decode the exact QR or URI you will share. Check every character of the destination and the eight-decimal amount against the invoice.
Test the actual wallet version and device your payer uses, with a safe controlled procedure. Record the decoded text, populated fields and validation result separately.
Before approving a real payment, read the destination and amount on the wallet’s trusted screen.
After broadcast, match the actual output and apply your agreed confirmation policy. A QR scan does not prove settlement.
Our local QR inspector flags duplicates and unsupported required fields rather than choosing a payment interpretation. The payment checklist connects that preflight with request creation, transaction inspection and reconciliation.
If your wallet behaves differently, record the exact version, operating system, URI text and stage where the difference occurs. Remove personal data and recovery secrets. A full-app observation can add evidence that this parser study does not provide. Submit a reproducible correction through our corrections page.
Measured 30 September 2026. AI-assisted research, code and drafting; scripted verification, no independent human reviewer claimed. No complete-wallet safety ranking is implied.
Litecoin (LTC)
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 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 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 A cryptographic hash function used twice in Bitcoin mining; Litecoin mining uses Scrypt but still uses SHA-256 elsewhere.
A cryptographic hash function producing a 256-bit digest. Bitcoin mining uses a double-SHA-256 construction; Litecoin proof of work uses Scrypt. Litecoin nevertheless uses SHA-256-based functions elsewhere, including transaction and block identification.
For example A Bitcoin mining device advertises SHA-256 hash power, while Litecoin mining hardware advertises Scrypt hash power.
Common mistake Assuming Litecoin does not use SHA-256 anywhere simply because its proof-of-work algorithm is Scrypt.
In brief A payment-channel network for transfers outside the blockchain, requiring Litecoin-compatible software, funds and routes.
A payment-channel network for off-chain transfers. Compatible Litecoin implementations exist, but wallet support, liquidity and routing are required. Bitcoin Lightning support alone does not imply Litecoin support.
For example A Litecoin payment-channel transfer needs compatible software and a usable route; an ordinary on-chain address is a different destination.
Common mistake Assuming a Bitcoin Lightning invoice can be paid with LTC because a wallet advertises Lightning support.
In brief Secret data a wallet uses to sign spending; one key may cover only part of a wallet and must never be shared.
Secret data used to authorize spending under the conditions attached to coins. In a simple single-key wallet, anyone with that key can spend the coins it controls. A wallet may manage many keys; never share them.
For example A wallet signs a spend using a private key; the recipient only needs your payment, not that secret key.
Common mistake Sharing a key with support or assuming one exported key necessarily backs up every address in a wallet.
Compare: Seed phrase vs private key
Seed Phrase
Recovery words used by many wallets to rebuild key material; the correct format, optional recovery passphrase and wallet settings still matter.
Private Key
A secret used to authorize spending under its key conditions; one exported private key is not necessarily a backup of every key a wallet uses.
One example A fictional simple HD wallet can derive several receiving keys from one recovery setup; exporting just one of those private keys does not preserve the others.
Remember: Identify the complete backup method for the original wallet, keep secret recovery material offline and never paste it into this website.
In brief Who controls spending access; with a custodial service, the provider controls the keys behind your account.
Who controls the signing material and the process for moving funds. With a custodial service, the provider controls the relevant keys and you use an account. Self-custody places key and backup responsibility with you; an account password is not a private key.
For example An exchange withdrawal moves funds from the provider's control to an address whose signing keys your own wallet controls.
Common mistake Assuming an exchange balance and a self-custody wallet offer the same control, recovery process or withdrawal availability.
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 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 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 Text, often encoded as a QR code, that requests a payment but does not send coins or prove the recipient's identity.
Structured request text, often inside a QR code, containing a destination and optional payment fields. Many Litecoin requests use the litecoin: scheme. Bitcoin's older BIP21 format provides background, but supported addresses, amounts and parameters depend on the actual Litecoin wallet.
For example The placeholder litecoin:ADDRESS?amount=0.1 requests 0.1 LTC; it does not send coins or prove that the named recipient controls the address.
Common mistake Assuming a QR code authenticates a merchant or that every wallet interprets optional fields and expiry information the same way.
Downloadable data or code · Source-function parser test.
Content review recorded: 2026-09-30. 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.
