Submission starts the process
A signed transaction is submitted to an XRPL server. The server checks it against the current open ledger and can return a tentative engine result. That response describes the server's provisional evaluation, not an irreversible network outcome.
The candidate must propagate, survive consensus, and be applied in the agreed canonical order. A transaction that looks successful against one open-ledger state can produce a different result after other transactions are included or reordered.
Validated is the decisive status
A transaction with tesSUCCESS is final when it is included in a validated ledger. A transaction with a tec result is also final when included, but it failed while generally claiming its transaction cost. Other result classes have different finality conditions and may remain subject to change.
Applications should look for validated ledger evidence and inspect the final transaction metadata. A response without validated: true should not be treated as authoritative simply because an earlier submit call returned a favorable code.
Why LastLedgerSequence matters
LastLedgerSequence sets an upper ledger index after which the transaction cannot be included. Without an expiration boundary, a delayed transaction might remain eligible and execute later under changed conditions.
The reliable submission guidance recommends including this field and persisting the transaction hash, sender, sequence, expiration ledger, and related application data before submission. Those records let an application recover after an outage and determine what actually happened.
Open the related live demo or evidence lab →How long finality normally takes
XRPL documentation says new ledger versions usually close about every three to five seconds. That is a useful expectation, not a guarantee that every submitted transaction will be confirmed in the next ledger. Network load, propagation, fee levels, sequence conflicts, and other conditions can delay or prevent inclusion.
A production system should follow ledger validation rather than a stopwatch. The authoritative question is not whether several seconds elapsed; it is whether a validated ledger contains the transaction or whether its expiration and ledger history prove it can no longer be included.