Our node first saw 68,640 sampled Litecoin transactions between 6 and 12 October 2026 UTC. At the frozen export on 13 October at 00:03:33 UTC, 64,087 records had a matched block inclusion. Their median observed wait was 135 seconds. That number leaves out 4,553 other outcomes. Those records are the reason this report includes a complete ledger before discussing speed.
The practical question is narrower than “How fast is Litecoin?”: what had this observer actually matched by one, five and ten minutes after first seeing each sampled transaction? We answer it using one fixed cohort, one recorded export time and the same sufficiently aged denominator at all three thresholds. The data and reproduction package are available below.
The seven days and the export are different clocks
Enrollment starts at 2026-10-06 00:00:00 UTC and ends just before 2026-10-13 00:00:00 UTC. Each transaction is assigned to the day this node first observed it, even if its inclusion was observed on a later day. The final archive was written three minutes and 33 seconds after enrollment closed. Its states describe that export time; they are not a reconstructed midnight state or a claim about today’s canonical chain.
We took transaction outcomes once, from the final archive’s retained cohort. We combined the seven daily poll files only for coverage. Adding the daily cohort files would count the same transactions repeatedly. This publication is a separate release from our earlier pilot report; that pilot and its original data remain unchanged.
What happened to all 68,640 records?
| Recorded outcome | Records | What the record establishes |
|---|---|---|
| Matched block inclusion | 64,087 | A qualified mempool observation was matched to a block observation. |
| Still pending | 7 | No inclusion had been matched; the wait remained open. |
| Left the mempool | 83 | Disappearance without matched inclusion. The cause is not established. |
| Collection-gap censored | 4,408 | Lost observation continuity prevents a comparable timing outcome. |
| Reorganization censored | 55 | The originally recorded confirming block was excluded by the observer’s canonical-membership check. |
| Awaiting membership recheck | 0 | No record had this state in the selected cohort at export. |
| Total | 68,640 | Every enrolled sampled record, including incomplete observations. |
The 55 reorganization-censored records reference one distinct original block hash. They are not evidence of 55 reorganizations, 55 attacks or 55 independent losses. We report the observer’s classification at export and preserve the original block fields so it can be inspected. We have not rerun a fresh canonical-chain audit for this article.
One, five and ten minutes: keep the denominator fixed
A record must have been first seen at least ten minutes before the export to enter this comparison. The inclusive cutoff is 2026-10-12 23:53:33 UTC: first_seen <= snapshot_at - 600. That leaves 68,605 records. We exclude the same 35 younger records at every threshold: 28 had already matched a block and seven were pending. Keeping the age rule independent of outcome avoids admitting only the quickest young confirmations.
“Matched by” includes a qualified observed duration equal to the threshold. “Matched later” requires an actual qualified later inclusion. “Unresolved” means this snapshot cannot assign either outcome. A disappeared or gap-censored record is never moved into “later” merely because a clock or a closure timestamp passed the deadline.
| Threshold | Matched by | Matched later | Unresolved | Denominator | Matched-by share |
|---|---|---|---|---|---|
| 1 minute | 14,252 | 49,807 | 4,546 | 68,605 | 20.77% |
| 5 minutes | 52,889 | 11,170 | 4,546 | 68,605 | 77.09% |
| 10 minutes | 62,450 | 1,609 | 4,546 | 68,605 | 91.03% |
At ten minutes, 62,450 records had qualified matched inclusions, 1,609 had qualified later inclusions, and 4,546 were unresolved: 4,408 gap-censored, 55 reorganization-censored and 83 disappeared. Thus 91.03% is a descriptive share of these aged sampled records with an observed match by this threshold. It is not a network-wide success probability or a prediction for a new payment.
Why 99.42% coverage does not mean 99.42% of outcomes are known
Across the scheduled 168 hours, the observer recorded 167 hours, two minutes and two seconds of covered intervals: 99.42%. Uncovered time totaled 57 minutes and 58 seconds. A covered interval requires consecutive valid polls no more than 30 seconds apart; restarts, synchronization, inconsistent reads and other gaps do not count as covered time.
Yet 4,408 of the 68,640 enrolled records, or 6.42%, were gap-censored. These percentages use different units. A brief gap can interrupt many transactions that were already being tracked. It also excludes entries present when a new baseline is established. Subtracting 99.42% from 100% cannot estimate the share of transactions whose timing is unusable.
This distinction matters when comparing services that publish a fast median without their collection ledger. High uptime can coexist with a material number of unresolved measurements. Our poll file includes baseline exclusions; those counts can repeat the same mempool entry at different baselines and are not an additional unique-transaction total.
Daily comparisons: what moved, and what did not
| Enrollment day | Enrolled | Matched | Gap censored | Reorg censored | Median, s | P90, s | Coverage |
|---|---|---|---|---|---|---|---|
| 2026-10-06 | 9,587 | 8,790 | 731 | 55 | 150 | 420 | 99.43% |
| 2026-10-07 | 9,770 | 9,214 | 544 | 0 | 135 | 360 | 99.39% |
| 2026-10-08 | 9,741 | 9,144 | 587 | 0 | 135 | 390 | 99.42% |
| 2026-10-09 | 10,348 | 9,897 | 443 | 0 | 150 | 436 | 99.61% |
| 2026-10-10 | 10,101 | 9,298 | 791 | 0 | 135 | 420 | 99.31% |
| 2026-10-11 | 9,547 | 8,896 | 636 | 0 | 150 | 376 | 99.38% |
| 2026-10-12 | 9,546 | 8,848 | 676 | 0 | 135 | 361 | 99.43% |
The week’s matched-only median was 135 seconds and its 90th percentile was 390 seconds. Daily medians varied from 135 to 150 seconds, and daily 90th percentiles from 360 to 436 seconds. The longest qualified matched wait was 1,306 seconds, or 21 minutes and 46 seconds. Those endpoints describe this sample; none is a maximum that a future payment must obey.
The 64,087 matched records reference 3,253 distinct confirming block hashes. Transactions in a block share an inclusion event, so treating all 64,087 waits as independent experiments would exaggerate the evidence. We do not attach a population confidence interval or infer a fee-versus-speed ranking: this dataset stores neither transaction fee rates nor virtual sizes.
Use the observations without turning them into an invoice rule
Suppose an invoice expires at 10:15:00 UTC. A sender reports broadcast at 10:14:40, while the receiver’s node first sees the payment at 10:15:08. That fictional example has two clocks before a confirmation is even discussed. The invoice-clock case I03 lets you replay it. Our measurement starts at the node’s first sighting; it cannot establish the sender’s broadcast time, payment-service credit time or the merchant’s acceptance decision.
For your own transfer, use the transaction checker to inspect the public transaction and recipient output, then check the receiving service’s actual terms. The updated confirmation page shows a threshold table for its newest verified completed-day archive. Its newer window and export time will naturally differ from this frozen report.
Reproduce the report
- Download the version 1 package and extract it.
- With Python 3.10 or later, run
python verify.py.txt. It checks the frozen file checksums, recalculates the report and compares the result withresults.json. No network access or additional packages are needed. - To print the calculations separately, run
python analyze.py.txt. Compare the full outcome ledger, threshold denominators and daily poll coverage before using individual timing figures.
Individual files: selected cohort CSV, seven-day poll CSV, computed results, boundaries and source archive hashes, analysis code, method and limitations, and SHA-256 checksums. The frozen archive index and seven original manifests are included. Each source ZIP remains linked by its immutable day-specific URL in the snapshot metadata.
Where this study stops
The collector polls one private, pruned, walletless Litecoin Core node at a nominal 15-second interval. Selection uses a fixed txid-prefix rule, roughly one in 16 eligible IDs. It only measures transactions exposed in the node’s public mempool and block lists; private MWEB transfers are not timed individually. A very fast transaction that reaches a block between polls may never enter the cohort, and entries already present at startup or after a gap are excluded from new timing measurements.
Both the start and end are polling observations, not precise broadcast and mining timestamps. Relay delays, the node’s policy and missed intervals influence the sample. The full published collection protocol explains the gap and reorganization rules. These data support an auditable description of one observer’s records. They do not establish irreversible finality, exchange crediting, attack probability or a universal Litecoin payment time.
