XRP Transaction Expiry: LastLedgerSequence and Safe Retry Math (2026)
TL;DR: XRP transaction expiry is an inclusive ledger deadline: LastLedgerSequence=1004 permits inclusion in ledger 1004, never 1005. A timeout or missing lookup does not prove failure; you need a validated result or complete history covering every possible inclusion ledger. Resubmitting the same signed transaction cannot pay twice, while creating another payment with a new account sequence can.
A wallet spinner answers a user interface question. It does not settle whether XRP moved. The useful question is whether the network has finalized the payment, ruled out every remaining opportunity to include it, or left your application without enough evidence. This guide turns that distinction into ledger counts and an original 250 XRP retry example. All ledger indexes, payment amounts, and coverage examples below are hypothetical, not observations of live XORA transfers.
What exactly expires?
LastLedgerSequence is a transaction field containing the largest permitted ledger index. It is neither a Unix timestamp nor the sender's account sequence. The common fields reference makes it optional, but supplying it bounds how far into future ledger history that signed instruction can remain eligible.
For example, a payment signed with deadline 1004 remains eligible for ledger 1004 while that ledger is being formed. It cannot enter 1005. Once 1004 is validated, its contents are fixed; the question becomes whether the payment appeared there or earlier. Expiry never undoes a successful payment already recorded before the deadline.
The official submission guide recommends that automated processes use the latest validated ledger index plus 4. That is a documented starting point, not a protocol mandate or a universal wallet default. Read the deadline actually embedded in the signed transaction.
The four ledger window shrinks while you sign
Let the initial validated index be V = 1000 and the fixed deadline be L = V + 4 = 1004. If d additional ledgers validate before the signed payment is submitted, the remaining future eligible indexes number max(0, 4 − d). This counts opportunities, not a promise that any particular one will accept the payment.
| Ledgers advanced | Now validated | Future eligible indexes | Count | Illustrative duration |
|---|---|---|---|---|
| 0 | 1000 | 1001 to 1004 | 4 | 12 to 20 seconds |
| 1 | 1001 | 1002 to 1004 | 3 | 9 to 15 seconds |
| 2 | 1002 | 1003 to 1004 | 2 | 6 to 10 seconds |
| 3 | 1003 | 1004 | 1 | 3 to 5 seconds |
| 4 | 1004 | None | 0 | 0 future intervals |
The duration column multiplies the remaining count by 3 and 5 seconds, using the cadence described in the XRPL overview. It is a simplified interval estimate, not an expiry timer, observed latency distribution, or upper bound. Your observation can arrive partway through a round; stalled consensus or delayed server data can extend waiting.
Two ledger advances consume 50% of this example's original window. A human taking time to approve a hardware wallet prompt may therefore encounter an expired instruction even when the network is healthy. Choose an appropriate window before signing and check the resulting transaction afterward; changing its deadline creates a newly signed transaction.
Separate an accepted request from a settled result
A submission response describes a provisional attempt. Even tesSUCCESS returned immediately is not enough. According to XRPL finality rules, success becomes final when the transaction is included in a validated ledger. A result with validated: true and successful transaction metadata is the evidence to retain.
There are three operational outcomes: validated success, final failure, and unresolved. Unresolved includes a payment still within its deadline and a payment whose deadline passed but whose history you cannot fully inspect. Keeping that third state prevents a disconnected application from treating uncertainty as permission to pay again.
The consensus structure documentation distinguishes candidate ledgers from the single validated history. A server can show a closed ledger that is not yet validated. Watching a ledger number rise on its own therefore does not establish the evidence needed to settle an invoice or reconcile a withdrawal.
Why 75% history coverage proves nothing about failure
Suppose your payment could only appear in 1001 through 1004. A server holding 1001, 1002, and 1004 has 3 of 4 relevant ledgers, or 75% coverage. A missing lookup still cannot exclude a successful payment in 1003. This percentage describes available records, not a 75% probability that the payment failed.
The tx method supports min_ledger and max_ledger. When a lookup returns txnNotFound, searched_all: true confirms that the server searched the whole requested interval; false means its records were incomplete. For this example, search 1001 through 1004 inclusive after those ledgers have validated.
The server_info reference exposes complete_ledgers, which can contain disconnected ranges. A large latest ledger index does not imply uninterrupted history. A gap outside your payment's possible interval is irrelevant; a gap inside it must be filled or checked using another trusted source.
Crucially, the interval must start from the original submission context, not the moment you restarted your application. Searching only 1004 would miss a payment settled in 1002. Even waiting until validated ledger 1005 cannot repair an incorrectly scoped history search.
One 250 XRP payment, three retries, or three payments?
Account sequence rules prevent an ordinary transaction from executing twice. Assume a direct 250 XRP payment uses sequence 50. Submitting the exact same signed bytes three times still represents one transaction with one hash and one sequence slot. Its maximum successful principal transfer is 250 XRP on that network.
Now suppose the application interprets each timeout as failure and creates fresh payments at sequences 50, 51, and 52. If all three satisfy their conditions and validate, principal transferred is 3 × 250 = 750 XRP. Against one intended 250 XRP payment, the extra amount is 750 − 250 = 500 XRP, or 200% of the intended amount. These are conditional exposure calculations, not observed loss rates.
Changing the fee or deadline while retaining sequence 50 produces a competing transaction, not identical resubmission. Only one transaction can consume that sequence, but the application must track which one won. Tickets have different sequencing mechanics; this worked example deliberately uses ordinary sequential payments.
The cancellation guide explains that a competing transaction can sometimes replace an unvalidated one. It cannot guarantee cancellation after distribution. A replacement is therefore a reconciliation decision, not a way to erase uncertainty by signing another instruction.
Fee math and a practical verification sequence
The transaction cost reference lists a standard minimum of 10 drops, equal to 0.00001 XRP, before load increases. If our three separate payments each used that fee, they would burn 30 drops rather than 10. The 20 drop difference is secondary to the 500 XRP duplicate principal exposure.
An instruction that expires without entering validated history consumes no fee. A validated tec result is different: the requested operation failed, but the fee and sequence were consumed. Diagnose the final outcome before choosing a new sequence or adjusting a fee.
- Save before submission. Retain the signed transaction, hash, sender, sequence, deadline, and original validated ledger reference. Associate them with one payment intent.
- Look up that hash. A validated success settles the payment. An unvalidated response remains provisional.
- Check both deadline and coverage. Without a result, establish complete relevant history through the final eligible ledger. Keep gaps unresolved.
- Reconcile before rebuilding. If the sender's validated sequence advanced unexpectedly, identify the transaction that consumed it. Retry only after accounting for the original intent.
This workflow follows the reliable submission procedure. Queue acceptance also depends on remaining room: the queue rules require an included deadline to be at least the current ledger index plus 2 for queue admission. A nearly expired transaction may miss that condition, so extending time without checking the original result is not a complete recovery strategy.
For XORA deposits, preserve the transaction reference and use the destination instructions shown in your account. A blockchain result and the receiving service's account credit are separate evidence. Review XORA custody and security before funding, and use the XRP yield guide to distinguish transfer mechanics from investment risk.
Frequently asked questions
Is LastLedgerSequence inclusive?
Yes. A transaction with LastLedgerSequence 1004 can be included in ledger 1004, but never ledger 1005. Ledger 1004 must be validated before its contents provide final evidence. An open ledger numbered 1004 has not yet settled the question.
Does txnNotFound mean my XRP payment failed?
No. The server may lack the ledger that contains the payment. Search the complete possible inclusion range through the deadline and check coverage. Missing history leaves the outcome unknown even after expiry.
Can I submit the same signed XRP transaction twice?
Yes. Sending the exact same signed transaction again on the same network does not create a second payment. Ordinary account sequence rules allow it to execute at most once. Creating another payment with a fresh sequence number is different.
Does an expired transaction burn its XRP fee?
A transaction that never enters a validated ledger burns no transaction fee. A transaction recorded with a tec result can fail its requested action while still charging its fee and consuming its sequence number. Check the validated result before retrying.
Can I cancel a payment by closing my wallet?
No. Closing a wallet does not remove a signed transaction already distributed to the network. A competing transaction using the same account sequence may replace it, but cancellation is not assured. A payment already validated cannot be reversed by changing its expiry.
Related reading
Sources checked
Primary documentation checked October 12, 2026. Calculations are original hypothetical illustrations of protocol rules. They are not live network statistics, service guarantees, or measured failure probabilities.
- XRPL transaction common fields
- XRPL reliable transaction submission
- XRPL consensus timing overview
- XRPL finality of results
- XRPL transaction lookup reference
- XRPL server history reference
- XRPL account sequence and ledger index
- XRPL cancellation and replacement rules
- XRPL transaction cost reference
- XRPL transaction queue rules
- XRPL consensus structure
- XORA yield source disclosure
Put your XRP to work with the risks understood
Put your XRP to work at xora.finance instead of leaving it idle on an exchange, with up to 22% APY value (15% native XRP yield, treasury-subsidised during a disclosed bootstrap, plus estimated XORA reward value). Returns are variable and never guaranteed. XORA is custodial; crypto prices, custody, a finite subsidy, and reward valuation create risk. XORA rewards are not currently tradable. Read the yield disclosure and model assumptions with the XRP yield calculator before allocating.