What our node has observed about Litecoin confirmation times so far
A frozen 8,148-transaction sample from one Litecoin node: 17 hours 14 minutes of covered polling, matched-only waiting times, open outcomes and collection gaps. Download the raw data and reproduce every result.
Sources, review record & reproducibility
Downloadable data.
No separate dated review record is available for this article. The byline identifies its author or responsible editor; it does not imply independent verification.
See the article body for source links and any downloadable materials. Editorial method · Corrections · Report an issue
On this page
Our node’s first usable confirmation sample is shorter than the date range in its log. At 22:20 UTC on 1 October, the frozen export contained 8,148 selected transactions and 17 hours 14 minutes of covered polling. The five preceding UTC dates contained no eligible collection time: the node was synchronizing or the collector could not maintain continuity.
Among the 7,595 transactions for which the collector matched a first block inclusion, the median observed wait was 135 seconds and the 90th percentile was 390 seconds. Those are useful descriptions of this sample. They do not establish that 90% of all Litecoin payments confirm within six and a half minutes.
This report keeps the other 553 rows visible: 28 still waiting, 13 that left the node’s mempool without a matched block, and 512 whose observation ended at a collection gap. Download the frozen data and calculation code to check every number below.
What was frozen, and when
The cohort and polling log were exported in one read-only SQLite transaction. The numerical cutoff is the last recorded poll, eight seconds before the export timestamp. The data includes all retained rows in the preceding seven-day window, not seven days of successful observation.
| Field | Frozen value |
|---|---|
| Export timestamp | 2026-10-01 22:20:00 UTC |
| Last included poll | 2026-10-01 22:19:52 UTC |
| First eligible interval ended | 2026-10-01 04:58:21 UTC |
| First sampled transaction sighting | 2026-10-01 04:58:36 UTC |
| Covered polling time | 62,040 seconds / 17 h 14 min |
| Elapsed first-to-last eligible interval span | 62,506 seconds / 17 h 21 min 46 s |
| Sampled transactions | 8,148 |
| Matched confirming blocks | 334 |
| Node software | Litecoin Core 0.21.5.8, mainnet, pruned |
| Selection and nominal polling | 1 in 16 by transaction-ID prefix; 15 seconds |
The difference between the eligible span and covered time is 466 seconds. That describes gaps inside this short eligible period; it does not count the earlier synchronization period as useful coverage. A separate node-status read showed the node caught up and collecting. That diagnostic is in the metadata and is not used to calculate the outcome counts.
The coverage log matters more than its date range
| UTC date | Recorded polls | Covered time | Entries excluded at baseline resets |
|---|---|---|---|
| 2026-09-26 | 341 | 0 | 0 |
| 2026-09-27 | 5,632 | 0 | 0 |
| 2026-09-28 | 5,683 | 0 | 0 |
| 2026-09-29 | 5,604 | 0 | 0 |
| 2026-09-30 | 5,598 | 0 | 0 |
| 2026-10-01 | 5,353 | 17 h 14 min | 690 |
A scheduled poll is not automatically a usable interval. Initial synchronization, RPC timeouts and an unavailable node can produce log rows with zero covered seconds. After a reset, the collector treats the current mempool as a baseline and excludes its existing transactions, because their arrival times are unknown.
The 690 baseline exclusions on 1 October are exclusion events, not 690 unique failed transactions or 690 additional sampled rows. A transaction present at more than one reset can be counted more than once. The six calendar dates above therefore cannot be advertised as six days of measured confirmation performance.
All 8,148 rows: what each outcome means
| Recorded state | Rows | Interpretation at the cutoff |
|---|---|---|
| confirmed | 7,595 | A sampled entry was matched to a block during continuous observation. |
| censored_gap | 512 | Continuity was lost before a matched outcome; later confirmation is not inferred. |
| pending | 28 | Still open at the cutoff; not a failed payment. |
| left_mempool | 13 | No longer in this node’s mempool and no matched block; the reason is unknown. |
| recheck_required | 0 | No recorded confirmed block was awaiting its hash recheck at this cutoff. |
| censored_reorg | 0 | No retained row had this state; this is not evidence that no network reorganization occurred. |
“Left mempool” does not mean “cancelled”, “rejected by the network” or “lost funds”. This export cannot distinguish every eviction, replacement, missed block inclusion or later outcome. A payment disappearing from one mempool needs an individual transaction check, not a diagnosis based on the aggregate count.
Dividing 7,595 by 8,148 would produce a fraction of rows currently marked confirmed. It would not produce a network confirmation success rate. The youngest entries have had less time to reach an outcome; collection gaps end others early.
Observed waiting times, with the denominator attached
| Observed duration | Matched rows | Share of 7,595 matched rows |
|---|---|---|
| 0–60 seconds | 1,781 | 23.4% |
| 61–150 seconds | 2,556 | 33.7% |
| 151–300 seconds | 1,966 | 25.9% |
| 301–600 seconds | 1,146 | 15.1% |
| More than 600 seconds | 146 | 1.9% |
The matched-only median was 135 seconds; p90 was 390 seconds. 4,337 matched rows (57.1%) had an observed duration of at most 150 seconds. 7,449 (98.1%) were at or below 600 seconds. The largest matched duration was 1,035 seconds, or 17 minutes 15 seconds.
The computation subtracts the polling timestamp of first sighting from the polling timestamp of matched inclusion. Quantiles use linear interpolation at position (n − 1) × q in the sorted durations. No block-header timestamp is substituted for either endpoint.
These summaries exclude the pending, left-mempool and censored rows. That makes the numbers conditional on having a matched confirmation by the cutoff. Treating the absent durations as zero would be wrong; silently dropping their existence from the report would also be misleading.
The stopwatch starts at our node, not at your wallet
The collector does not see when a sender clicks Send, when a wallet finishes signing or when its first peer receives the transaction. It sees a transaction in this node’s mempool at a polling time. Network propagation before that sighting is outside the measurement.
Both endpoints are polled. With uninterrupted 15-second polls and ideal immediate RPC responses, endpoint rounding alone can change the recorded duration by roughly one polling interval in either direction. Real delays and variable intervals complicate that bound; our collector accepts intervals up to 30 seconds and explicitly breaks continuity beyond that. A 135-second result is not a stopwatch reading accurate to one second.
Transactions that arrive and confirm between two polls never enter this cohort. Entries already present at a baseline reset are excluded. The deterministic selection rule accepts transaction IDs whose first eight hexadecimal digits, interpreted as an integer, are divisible by 16. It is a reproducible subsample of observed new entries, not a random survey of every wallet or payment.
The measurement covers transparent transaction identifiers. It does not reconstruct private MWEB transfers, identify users, measure merchant sales, or time an exchange’s account-crediting process.
What this can help you do today
If your wallet says a payment is unconfirmed, a short wait can be consistent with ordinary block inclusion. This sample also contains matched waits above ten minutes. Neither observation tells you that a particular payment is healthy: check the transaction itself.
- Check the public transaction ID. If there is no visible transaction, investigate whether the wallet broadcast it and whether its source is current.
- Read the confirmation count and the recipient’s own acceptance policy. This report measures first inclusion, not the time to six confirmations or to an exchange credit.
- Check current fee information as a separate question. This dataset contains no fee-rate or virtual-size fields, so it cannot rank fee choices or establish that a higher fee caused a faster confirmation.
- For receiving payments, use the payment workflow and underpayment and refund guide. A timed-out invoice and a failed blockchain transaction are different events.
Do not turn the 390-second matched-only p90 into a fixed merchant timeout. It describes 334 confirming blocks in a short slice from one node. Transactions in the same block share an outcome, and missing intervals can be related to node load or network conditions. Thousands of rows are not thousands of independent experiments.
How to reproduce the numbers
Download the research package, unzip it, and run the supplied standard-library Python script. No wallet, node access, account or API key is needed to recalculate this frozen report.
python analyze.py.txt .The script checks the two input CSV hashes, unique transaction IDs, the selection rule, timestamps and covered-interval validity before calculating counts and timing summaries. Compare its output with results.json. Whitespace and JSON key order do not affect the numerical comparison.
- cohort.csv: all 8,148 selected entries, including open and censored outcomes.
- polls.csv: the 28,211 poll records used to calculate coverage.
- snapshot.json: cutoff, input hashes and separate node diagnostic.
- Calculation source and deployed cohort state machine.
- Method and reproduction instructions and package checksums.
The checksum files identify the downloadable bytes. They do not independently prove that this node observed every relevant transaction. Recomputing statistics from our export verifies the arithmetic, not the completeness of the original collection.
What the longer study still needs to establish
The archive metadata schedules the main study from 2 October 2026 at 00:00 UTC. This frozen pilot predates that start. It is neither the completed October report nor a replacement for the planned observation window.
A longer report needs coverage across UTC days, the full outcome ledger, honest accounting for restarts and gaps, and a defined follow-up period for entries enrolled near its end. A survival analysis could address some open waits, but its assumptions would need checking: censoring caused by operational problems may not be independent of transaction conditions.
For now we publish counts and conditional descriptive timings, without a population confidence interval, a confirmation guarantee or a fee-performance claim. The live observer continues to change. The files linked here will retain this cutoff; any correction requires a new version.
Sources, responsibility and citation
Produced by Litecoin.watch. Article editor: Jarosław Wasiński. Code and drafting were AI-assisted. The downloadable data supports checking the calculations; no external independent review is claimed. Author profile · Corrections policy.
Track Litecoin in real time
Rates for 30+ currencies. Check each tool for its latest source timestamp.
Open dashboard