Finality of Results

The order in which transactions apply to the consensus ledger is not final until a ledger is closed and the exact transaction set is approved by the consensus process. A transaction that succeeded initially could still fail, and a transaction that failed initially could still succeed. Additionally, a transaction that was rejected by the consensus process in one round could achieve consensus in a later round.

A validated ledger can include successful transactions (tes result codes) as well as failed transactions (tec result codes). No transaction with any other result is included in a ledger.

For any other result code, it can be difficult to determine if the result is final. The following table summarizes when a transaction's outcome is final, based on the result code from submitting the transaction:

Error Code Finality
tesSUCCESS Final when included in a validated ledger
Any tec code Final when included in a validated ledger
Any tem code Final unless the protocol changes to make the transaction valid
tefPAST_SEQ Final when another transaction with the same sequence number is included in a validated ledger
tefMAX_LEDGER Final when a validated ledger has a sequence number higher than the transaction's LastLedgerSequence field, and no validated ledger includes the transaction

Any other transaction result is potentially not final. In that case, the transaction could still succeed or fail later, especially if conditions change such that the transaction is no longer prevented from applying. For example, trying to send a non-XRP currency to an account that does not exist yet would fail, but it could succeed if another transaction sends enough XRP to create the destination account. A server might even store a temporarily-failed, signed transaction and then successfully apply it later without asking first.