To confirm an XRP Ledger transaction, look it up by its transaction hash and wait for the response to show validated: true. Then check meta.TransactionResult: only a validated tesSUCCESS confirms success. A wallet’s “pending” label, a timeout, or even an immediate tesSUCCESS from submission is not final proof.
What counts as a confirmed XRP Ledger transaction?
A transaction submission response is provisional: it reports a server’s initial handling of a candidate transaction, not its final outcome. The definitive result is recorded in a validated ledger. In the transaction lookup response, first check validated; interpret the result as final only when it is true. Then read meta.TransactionResult. A validated tesSUCCESS means the transaction succeeded. Other validated result codes indicate a final outcome that may include failure or a transaction cost, depending on the code.
XRPL documentation says many transactions reach a final outcome in about 4–7 seconds, often by entering the next ledger. That is typical timing, not a deadline: network connectivity and ledger conditions can lengthen the wait. New ledger versions usually arrive about every 3–5 seconds, which likewise does not guarantee that a particular transaction will be included in that interval. See the Send XRP tutorial and the ledger close-time documentation.
How to check a transaction by hash
- Find the transaction hash. Retrieve it from the wallet’s transaction details, signing output, or saved submission record. For an application, XRPL recommends saving the hash alongside the sender address and sequence number,
LastLedgerSequence, and latest validated ledger index at submission. - Query the transaction. Use the XRPL API’s
txmethod with the hash, or a client-library wrapper that returns the same transaction record. The tx method reference describes the response fields. - Check validation before interpreting the result. If
validatedisfalseor absent, the result is not yet final. If it istrue, readmeta.TransactionResultand note the ledger index. The response may also include the ledger close time.
Do not treat an immediate submit response as confirmation. XRPL’s Reliable Transaction Submission guidance explains that results remain provisional until the transaction is in a validated ledger.
#1 Best Overall
What to do if the transaction is still pending
Repeat the hash lookup after another validated ledger is available. A transaction commonly appears in the next ledger, but propagation problems or ledger conditions can delay it. The transaction’s LastLedgerSequence is the important boundary: it prevents inclusion in any ledger with a higher index.
- If the latest validated ledger is below
LastLedgerSequenceand the transaction is not found, the result is not conclusive. Continue checking. - If the transaction appears in a validated ledger at or below that limit, its outcome is final. Read its validated
meta.TransactionResult. - If the validated ledger has passed the limit and no result appears, check ledger-history completeness before concluding the transaction was not included.
XRPL recommends setting LastLedgerSequence for every transaction. Its reliable-submission documentation says automated processes commonly set it four ledgers above the last validated ledger index. This is guidance for applications, not a guarantee that a particular wallet uses that value or that confirmation will happen within four ledgers.
Rank #2
- Ideal for Gifting
- Ideal for a bookworm
- Compact for travelling
How to investigate a missing transaction after its ledger limit
A missing lookup is meaningful only if the server can search continuous ledger history covering the relevant period—from submission through the transaction’s LastLedgerSequence. A server with incomplete history may be unable to establish whether the transaction was included. Query a server with the needed history before treating non-appearance as evidence that it expired. If complete history confirms it was absent through the limit, it cannot later be included under that LastLedgerSequence.
Then check the sender account’s sequence. If it advanced, another transaction may have used that sequence; XRPL’s reliable-submission guidance recommends manual investigation in that situation. Saved submission details—the hash, sender, sequence, ledger limit, and latest validated ledger at submission—make this recovery easier after an application interruption.
Recommended Free Tools
How to interpret XRPL result codes
Result-code prefixes help explain a response, but an immediate engine_result is still provisional. For a final decision, use the validated transaction metadata. XRPL’s transaction results reference describes these categories:
tec: the intended transaction effect did not occur, but the transaction cost was destroyed. Treat this as final only when the result is in a validated ledger.tef: the transaction cannot be applied to the server’s current or a later ledger, though circumstances such as prior application or ledger conditions can matter.tel: a local server condition, such as high load, caused the error; another server or a later attempt may respond differently.tem: the transaction is malformed or cannot be applied by any server under current protocol rules.
Human-readable engine messages and numeric codes can change. Use the named result code and validated metadata rather than relying on a message alone.
Rank #4
Why a wallet and an explorer may show different statuses
Applications and servers may expose status information differently, so compare the underlying transaction facts rather than relying on a generic “pending” label. Check the validation state, final result in meta.TransactionResult, ledger index (and, if useful, close time), the transaction’s LastLedgerSequence against the latest validated ledger, and whether the server has continuous history for the relevant range. If the transaction is missing after its ledger limit, the sender’s sequence is another useful diagnostic.
When the delay may be outside the XRP Ledger
This lookup procedure establishes the ledger status of a transaction; it does not establish whether a wallet or hosted endpoint is operational or explain an exchange’s internal processing time. If a transaction has a validated result but a wallet, exchange, or other service still shows a different status, use the hash and validated ledger result when contacting that service. A ledger query cannot by itself diagnose its internal processing.
Quick Recap
Best Value
- It can be a gift option
- Comes with secure packaging
- Helpful in various ways
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
