New Litecoin.watch tools for checking and reconciling payments
Follow transaction outputs, reconcile invoice CSVs and inspect our new confirmation observer. A worked example shows why a matching amount can still need attention.
Fictional payment records from the batch tool example. Amount matching and reported confirmations are separate checks.
On this page
Dotted-underlined terms open a quick definition. Close it to keep reading.
Litecoin.watch now has a transaction lab, a more detailed public transaction checker and a CSV tool for reconciling invoices. We have also launched a separate -time study backed by our own Core . Here is what each addition does, with a worked example you can try without connecting a .
Launch status: the payment tools and transaction lab are available now. At publication, the observer’s node was still synchronizing and had no eligible mainnet timing sample. Its live status page shows the current state; collection begins automatically after the readiness checks pass.
Choose the tool for the question you have
Four additions, with different sources and purposes
A sampled mainnet cohort, with collection status and incomplete outcomes.
A fully paid invoice can still need attention
Open batch reconciliation and select Try a fictional example. The invoice asks for 1.50000000 LTC and requires two confirmations. It expires at 12:00 UTC. The imported receipts contain a first payment, a top-up and an identical duplicate of the first payment.
Fictional receipts used by the built-in example; amounts in LTC
Receipt
Receiving output
Reported confirmations
Reported receipt time
Treatment
First payment
1.49000000
3
11:50 UTC
Counted once; meets the invoice’s confirmation requirement.
Top-up
0.01000000
0
12:05 UTC
Included in the recorded total; below the confirmation requirement and after expiry.
Duplicate first payment
1.49000000
3
11:50 UTC
Ignored and listed in the receipt issues report.
The recorded total is 1.50000000 LTC. The amount meeting the imported confirmation requirement is 1.49000000 LTC. The duplicate does not turn the received total into 2.99000000 LTC. The example flags the late receipt for review, while the confirmed-amount column exposes the outstanding confirmation requirement.
This distinction matters when closing an order. A top-up can resolve an amount shortfall without resolving confirmation status or an expired quote. The CSV tool keeps those facts visible; your agreed acceptance policy still determines what happens to the order. The refunds and underpayments guide covers the corresponding customer records and decisions.
Import your records without uploading them
Download the two templates on the payment page. The invoice file needs a unique invoice reference, a , the amount due and the required confirmation count. The receipt file identifies each receiving output by and its zero-based output index, vout, alongside the address, amount and reported confirmations.
Use the output paid to the invoice’s receiving address. A transaction’s combined output value can include the sender’s change and payments to other people. A fresh address for each invoice allows automatic matching. If you reuse an address across invoices, supply the correct invoice_id in the receipt records; the tool will not guess which order a payment settles.
Both files support up to 5,000 data rows and 2 MiB each. Use a decimal point and at most eight decimal places. The calculations use integer , avoiding floating-point rounding of LTC amounts. Address format and checksum checks run locally. Conflicting copies of the same output are excluded and flagged, rather than silently added together. Import one consistent receipt export; successive confirmation snapshots of one output are not separate payments.
After reconciling, download the invoice report and, where needed, the receipt issues report. Files are read in the current browser page, with no CSV upload or wallet connection. The batch feature does not save their contents in browser storage. Clear files and results removes the current selection and results; copies you downloaded remain on your device. See the privacy policy for the distinction between local inputs and ordinary page visits.
The result is an audit of the records you supplied. It does not independently check those receipts against the , discover missing payments or prove that a receiving address belongs to you. Private MWEB addresses and ambiguous legacy addresses beginning with 3 are outside this invoice tool’s scope.
Follow the outputs before interpreting the total
The expanded transaction checker draws public inputs and outputs and provides their individual rows. Before displaying an ordinary payment diagram, it checks that the received details are complete and arithmetically consistent: input value minus output value must equal the reported fee. Missing or inconsistent detail data does not become an invented total.
The checker still uses Blockchair for these on-demand lookups. Our new Core node powers the separate timing study. Neither source can identify the owner of an address merely from an output label. An apparent should not be treated as a verified refund destination.
For an example where we do know the roles of the outputs, open the transaction lab’s payment flow. Its recorded 0.02000000 LTC input funds a 0.01000000 LTC recipient output, 0.00999718 LTC of change and a 0.00000282 LTC fee. The fee is the difference between inputs and outputs, not an extra output.
The lab also compares 12 signed size measurements and replays a payment losing two confirmations during a deliberately created regtest reorganization. You can inspect the raw data and reproduction scripts in the experiment report. These controlled results explain transaction behavior; their clock intervals do not measure mainnet speed.
The new timing study keeps unfinished waits visible
The observer page will measure elapsed time between a transaction’s first eligible observation and its first matched inclusion. After synchronization, the collector polls our node every 15 seconds and applies a fixed rule selecting roughly one in sixteen newly observed transaction IDs. Existing mempool entries at startup or after a gap do not acquire a guessed starting time.
The rolling seven-day cohort keeps pending transactions, unmatched mempool departures, interrupted observations and changed confirming blocks visible alongside successful matches. A record that disappears from the mempool is not automatically called confirmed. An interruption does not restart the same retained record as a conveniently shorter wait.
The SVG distribution and any median or 90th percentile describe the currently confirmed subset only. Open and interrupted waits remain in the outcome table and CSV. The page withholds those two quantiles until it has at least 20 eligible confirmations; that threshold does not make a single node’s observations representative of every Litecoin payment.
At launch there is no timing chart to interpret because synchronization is still under way. Later visitors should check the live status, and measurement rules. First observation is not the moment a sender pressed “send,” and block inclusion is not the same event as an crediting an account.
Try one complete workflow
Start with the fictional example in batch reconciliation and compare the recorded and confirmed amounts.
Use the lab flow to see why an output, change and a transaction total are different numbers.
For your own public transaction, inspect its outputs and source time in the checker, then reconcile verified receipt records against your invoice.
If a result does not match your source records, keep the invoice reference and output index with your notes. Report the reproducible discrepancy through the corrections page; do not include wallet recovery material or customer details.
Confirmation
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 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 A participant running network software; a full node checks rules but need not keep all old block files.
A participant running network software. A full node independently validates rules; a pruned full node can discard older block files after validation. Not every node stores the complete historical blockchain.
For example A pruned full node checks the chain but later discards old block files to reduce disk use.
Common mistake Assuming every node is a miner, or that pruning means it skipped consensus validation.
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 transaction identifier for looking up outputs and confirmations, which alone does not prove that a payment arrived.
The identifier used to look up a transaction. For an ordinary transparent Litecoin transaction it is shown as a 64-character hexadecimal string. Use it to inspect the transaction's outputs and confirmations; the ID alone does not prove a payment is confirmed.
For example Copy the TXID from your wallet's payment details into a Litecoin explorer to check the recipient output and confirmation count.
Common mistake Sharing a seed phrase to trace a payment, or treating a screenshot or TXID alone as proof that the expected amount arrived.
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 linked record of transaction blocks that Litecoin nodes validate, choosing a valid chain by accumulated mining work.
A ledger of cryptographically linked blocks. Litecoin full nodes validate proposed blocks against consensus rules and select among valid chains by accumulated proof of work. Recent blocks can be reorganized, so confirmation depth matters.
For example A block explorer reads the chain so you can inspect where a transparent transaction was included.
Common mistake Assuming an explorer listing proves the sender's identity or that a recent block can never be replaced.
In brief A wallet-controlled destination for leftover LTC after spending an input on a payment and its fee.
Spending a transparent transaction output uses its whole value. After paying the recipient and fee, a wallet can send the leftover LTC to an address it controls. That destination is a change address. Wallets usually choose it automatically.
For example A fictional 1 LTC input paying 0.3 LTC with a 0.00001 LTC fee can return 0.69999 LTC to a wallet-controlled change output.
Common mistake Assuming an unfamiliar second output is a second payment to the recipient; first check which outputs your wallet owns.
In brief One node's local collection of accepted but unconfirmed transactions, which may differ from other nodes' collections.
A node's local collection of unconfirmed transactions it currently accepts. Nodes can see, retain or remove different transactions, so there is no single global waiting room. Appearing in a mempool is not confirmation or a guarantee of later inclusion.
For example One explorer may see your unconfirmed transaction while another node has not received it or has already removed it.
Common mistake Assuming that absence from one mempool proves the payment was never broadcast or that a seen transaction must confirm.
In brief A group of transactions linked to the previous block under the network's rules.
A batch of transactions accepted under the network rules and linked to the previous block. Litecoin targets one new block every 2.5 minutes on average; a particular block may arrive sooner or much later.
For example Your payment may wait unconfirmed and then receive its first confirmation when a miner includes it in an accepted block.
Common mistake Treating the 2.5-minute target as a countdown or a maximum wait for your payment.
In brief The share of a stated window or expected sample represented by usable records, which can still contain errors.
How much of a stated observation window or expected set is represented by usable records. The denominator may be scheduled polls, candle intervals or another declared sample. Coverage describes availability within that scope, not measurement accuracy or a complete view of the network.
For example If 90 of 96 expected price buckets are available, interval coverage is 93.75%; this says nothing about trades hidden inside those buckets.
Common mistake Reading missing observations as zero activity, or treating high coverage as proof that the sample is unbiased and error-free.
In brief A service for trading currencies or assets, whose custodial account balance does not give you control of its private keys.
A platform or service for buying and selling cryptocurrencies against fiat currencies or other assets. Trading methods, custody, supported pairs and withdrawal rules vary by service. A balance on a custodial exchange is an account claim; it does not mean you control the wallet's private keys.
For example After buying LTC on a custodial exchange, you request a withdrawal if you want it sent to your own wallet.
Common mistake Assuming an account balance means you possess the private keys, or overlooking the selected withdrawal network.
Content review recorded: 2026-09-26. 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.
