You can put a future block height or time into a Litecoin transaction. That does not make it a standing order. It does not reserve the coins, tell a wallet to wake up, or promise that a miner will include the payment at the appointed moment.
We tested the difference in Litecoin Core 0.21.5.8. The surprising case was an ordinary coin with a signed, future-dated payment: a different transaction could still spend that coin immediately. The date restricted the first transaction, not every possible use of its input.
This is useful if you have seen a “scheduled” payment, want to leave instructions for someone else, or are trying to understand what a wallet's locktime field actually guarantees. The results below come from an isolated regtest network with test coins. They are not observations of mainnet settlement speed, a wallet compatibility survey or a production escrow design.
One coin, two different promises
A transaction names an existing output it wants to spend. For an ordinary key-controlled output, the holder of the signing key can usually construct more than one candidate spending transaction. A future nLockTime in one candidate does not modify the output already on the chain.
To restrict the output itself, its spending script must contain the intended condition. Our comparison uses OP_CHECKLOCKTIMEVERIFY, commonly shortened to CLTV. A spending transaction then has to satisfy that script as well as the transaction's finality rules. These are separate checks. The pinned Core finality implementation and script interpreter are the source references for that distinction.
| Arrangement | What the condition applies to | What it does not provide |
|---|---|---|
| Ordinary output; one future-dated transaction | That particular spending transaction, with locktime enabled by a non-final input sequence | A reservation preventing a different signed spend |
| An output whose required spending path contains CLTV | Any spend that must use that path | An automatic sender, fixed confirmation time or an expiry date |
| A reminder or a custodial recurring-payment service | Software or service behaviour under its own rules | Evidence that the output has an on-chain script restriction |
“Scheduled” is therefore an incomplete description. Ask whether you are looking at a saved instruction, a signed transaction, a service promise, or a condition committed into a funded output. A screenshot of a date field cannot answer that question.
The tests: what the node accepted and rejected
We used a fresh data directory, no peers, a loopback RPC endpoint and disposable wallets. Blocks were generated under our control. We saved decoded transaction fields, the chain boundary and testmempoolaccept responses before broadcasting selected cases. The frozen release contains 13 timelock cases. We generated 1,351 initial blocks and recorded CLTV and CSV activation before the tests; the mock time kept MWEB outside this study.
| Case | Recorded boundary | Observed result |
|---|---|---|
| Ordinary output: future locktime, enabled sequence | Tip 1,352; next block 1,353; locktime 1,355 | Admission: rejected. non-final. |
| Same ordinary input: every sequence is final | Tip 1,352; next block 1,353; locktime 1,355 | Admission: accepted. |
| Same ordinary input: alternative with locktime zero | Tip 1,352; next block 1,353; locktime 0 | Admission: accepted. |
| Ordinary candidate: next block equals locktime | Tip 1,354; next block 1,355; locktime 1,355 | Admission: rejected. non-final. Block-validation attempt: rejected. |
| Ordinary candidate: next block exceeds locktime | Tip 1,355; next block 1,356; locktime 1,355 | Admission: accepted. |
| After an alternative spend confirms | Tip 1,356; next block 1,357 | Old output spent; future candidate rejected with missing-inputs. |
| Separate ordinary coin: alternative confirms before future lock | Tip 1,357; next block 1,358; locktime 1,367 | Future candidate rejected; alternative accepted and confirmed in block 1,358. |
| Required CLTV path: try locktime zero | Tip 1,359; next block 1,360; required height 1,362 | Admission: rejected. CLTV requirement not satisfied. Block-validation attempt: rejected. |
| Required CLTV path: correct locktime, too early | Tip 1,359; next block 1,360; required height 1,362 | Admission: rejected. non-final. Block-validation attempt: rejected. |
| Required CLTV path: try a final sequence | Tip 1,362; next block 1,363; required height 1,362 | Admission: rejected. CLTV requirement not satisfied. Block-validation attempt: rejected. |
| Required CLTV path: correct signature and ripe boundary | Tip 1,362; next block 1,363; required height 1,362 | Admission: accepted. Block-validation attempt: accepted; transaction included at 1,363. |
| Time lock: mock clock ahead, chain median behind | Median 1,500,000,228; locktime 1,500,000,288 | Admission: rejected. non-final. |
| Time lock: chain median passes threshold | Median 1,500,003,888; locktime 1,500,000,288 | Admission: accepted. |
“Accepted” in this table means that our node's mempool admission check allowed the candidate in the recorded state. It is not a fee guarantee or evidence that every node would relay it. Cases with an explicit block-validation attempt are identified separately. Four rejected candidates also failed explicit generateblock validation attempts. The valid, key-signed CLTV spend was actually included in block 1,363. For a separate ordinary coin, an alternative spend confirmed at height 1,358, before its future candidate's locktime of 1,367.
The ordinary-output comparison is the important one: changing the future candidate's date does not alter the original coin. Its owner can sign a different spend. Conversely, deleting a script condition from a spending transaction does not delete a condition already committed into a funded output.
Why a locktime can be present but inactive
The finality check has a detail that a raw-transaction screenshot can easily miss. For ordinary base-chain transactions, when every input sequence is the final value 4294967295 (0xffffffff), a future nLockTime does not delay the transaction. Our all-final case tested that bypass directly.
That is not a shortcut around a required CLTV script. CLTV checks the spending input's sequence, too. A final sequence fails that script condition rather than silently disabling it. The two transactions may have the same visible future locktime and still have different restrictions because they spend outputs with different locking scripts. See BIP65's CLTV specification alongside the Litecoin implementation; the specification alone is not our test result.
Wallets also use sequence values for other purposes. Do not interpret every non-final sequence as a long delay. Absolute locktime, relative sequence locks and replacement policy are different mechanisms. Our experiment isolates absolute locktime and CLTV; it does not test every combination of those features.
The block-height boundary has an off-by-one
For an enabled, non-zero height locktime T with at least one non-final input, the comparison is strict: locktime must be less than the candidate block height. That makes T + 1 the first possible inclusion height, assuming its other conditions are satisfied.
This also explains a potentially confusing mempool result. At tip height T, a node considers a transaction for the next block, T + 1. It can admit the transaction at that tip even though a block at height T would not meet this finality condition. Our recorded boundary is locktime 1,355: rejected at tip 1,354, then eligible at tip 1,355.
A CLTV script requiring height T checks that the spending transaction's locktime is at least T, with a compatible height/time type. Setting it to exactly T then leaves the ordinary transaction finality rule to make T + 1 the earliest inclusion height. A later chosen locktime can delay it further.
The table and diagram describe the condition, not a timetable. A block height is not a calendar appointment. Blocks arrive irregularly, and crossing the boundary does not force inclusion.
A time lock does not follow your laptop clock
Values below 500000000 are interpreted as block heights; values at or above it are time-based locktimes. For the time-based finality check, the chain's median time past matters. It is derived from 11 block timestamps ending at the candidate block's parent, which is the current tip for mempool admission. The enabled locktime must be strictly below that median; equality is still too early. Your phone's clock is not this boundary.
The pinned Litecoin validation code supplies that boundary for admission, and BIP113 explains the median-time rule. We moved the mock node clock to 1,500,003,888, an hour beyond the chosen locktime 1,500,000,288. Admission still failed: the chain median was only 1,500,000,228. After six controlled blocks, the median became 1,500,003,888 and admission succeeded. These integers are artificial test timestamps, not a measurement of real calendar waiting time.
Even after the median-time boundary passes, someone must submit the transaction. Its inputs must still be unspent. Its fee and other properties must meet the relevant admission and block rules. A scheduled date cannot make an obsolete transaction valid again.
The related wallet-copy experiment checks another local change that leaves an existing output's signing authority intact: replacing the wallet file's password.
A not-before condition is not an expiry date
These locks set an earliest eligibility boundary. They do not say “pay between Monday and Friday, then cancel”. A previously signed ordinary transaction may remain usable later if its inputs are still available and the other checks pass. If the intended payment has become obsolete, keeping the file offline is not an on-chain cancellation.
Read our separate guide to cancelling a payment before and after broadcast before assuming that a future date gives you a refund window. A confirmed spend of the same input changes what is available; simply changing a label in a wallet does not.
Six questions before trusting a scheduled payment
- What is funded? Identify the actual output and its spending conditions. A saved draft is not a funded contract.
- Who can sign another transaction? For an ordinary output, a future candidate does not remove the original key holder's authority.
- Which boundary applies? Record height or median time past, the precise threshold, and the earliest eligible block rule.
- Who will broadcast it? Name the wallet, person or service that will remain available to send it.
- What can make it fail? Consider a spent input, changed fee conditions, unavailable signing material and a script or wallet incompatibility.
- What happens if plans change? Document the actual recovery or alternative spending path. Do not infer one from the word “scheduled”.
Use the blank scheduling worksheet to record those answers. Do not put a seed, password or private key in it. For a normal payment you intend to send later, a reminder plus a fresh review at sending time may fit the job better than a pre-signed transaction with stale inputs.
Reproduce the experiment
The method and scope, case table as CSV, recorded results and complete research package preserve what was tested. The script requires a disposable regtest instance; it must never be pointed at a wallet holding real funds. Each run creates new test wallets and transaction identifiers.
Our CLTV output used a real key-controlled P2SH script: a required height, CLTV, DROP, the public key and CHECKSIG. The mature spend carried a valid signature and passed the node's block validation. This minimal lab construction has no alternate recovery branch and is not a reviewed custody recipe. We did not test MWEB lock heights, production multisignature policies, exchange withdrawal scheduling, hardware-wallet support or real-world fee competition. Simulated blocks are deliberately produced quickly and provide no measurement of mainnet waiting time.
The hero image is an AI-generated editorial illustration, not a photograph of the test setup. Research, code and drafting were AI-assisted; the original diagrams use the saved experiment records. No independent external review is claimed. Report a reproducible discrepancy through our corrections page.
