How to Read an XRP Ledger Explorer: Transactions, Tags, Fees, and Status
A wallet saying “sent” is not the final receipt. The durable proof is a transaction hash that resolves to a validated XRP Ledger record. From there, six fields answer almost every payment question: result, sender, destination, delivered amount, destination tag, and fee.
This guide turns an explorer page into an audit trail. It uses the fields defined by the XRP Ledger protocol rather than the labels chosen by one website, so the method works across explorers. It also explains the traps that cause most support disputes: provisional results, confusing requested amount with delivered amount, treating a destination tag as part of the account, and assuming “not found” means failed.
The 30 Second Verification
- Copy the transaction hash from the sending wallet or exchange and paste it into an XRP Ledger explorer.
- Confirm the record is on the intended network, normally XRP Ledger Mainnet.
- Look for validated status and a metadata result of
tesSUCCESS. - Compare the full sender and destination addresses with your records.
- Read the delivered amount, not only the amount requested by the transaction.
- If a custodian was receiving, compare the numeric destination tag exactly.
The decisive pair: validated: true establishes that the record is final, while meta.TransactionResult: tesSUCCESS establishes that it executed successfully. You need both.
Start With the Transaction Hash
A transaction hash is a 256 bit identifier normally displayed as 64 hexadecimal characters. It identifies the signed transaction contents. The official XRPL tx method accepts that hash and returns the transaction, metadata, ledger index, close time, and validation state when the server has the record.
Copy the hash directly. Do not search by amount and time alone; two unrelated payments can look similar. Do not share a seed phrase, secret key, exchange password, or one time code with anyone claiming they need it to trace a payment. Public ledger verification needs only public data such as a hash or address.
A hash that is not found does not automatically prove failure. The official API notes that the transaction may not have been validated, or the server may not have the relevant historical ledger. An exchange can also show an internal withdrawal reference before it broadcasts a real XRPL transaction. If there is no 64 character ledger hash, ask the sender for the on chain transaction hash.
Validated Is Stronger Than Submitted
Submission is a request. Validation is consensus. When a transaction is first submitted, a server can tentatively apply it to an open ledger and return a provisional result. Competing transactions, sequence conflicts, fee conditions, and consensus ordering can still change the outcome.
The official finality guidance says a tesSUCCESS or tec result becomes final when included in a validated ledger. A validated tesSUCCESS means the requested operation succeeded. A validated tec code means the transaction was included but failed in the way named by that code, generally claiming the fee and consuming the sequence number.
Read the Result, Sender, and Destination
The TransactionType field tells you what the transaction attempted. A Payment sends value, while other types can create offers, configure trust lines, set account options, or manipulate escrow. An explorer may use a friendly label, but the underlying type prevents a nonpayment from being mistaken for a transfer.
For a payment, Account is the address that initiated it and Destination is the receiving XRPL account. Compare full classic addresses, not the first and last few characters. A screenshot can be cropped or altered; the public record is independently reproducible.
A ledger address identifies an account, not necessarily one human. An exchange can use one shared address for many customers. Conversely, one person can control several addresses. Explorer data proves what an address did. It does not prove the legal identity behind that address without separate evidence.
Amount vs Delivered Amount
For a simple native XRP payment, the requested amount and delivered amount usually match. Still, the protocol safe field is metadata delivered_amount. The transaction metadata reference defines it as what the destination actually received. The partial payments guidance explicitly warns integrations to use it for all payments, partial or not.
Raw native XRP amounts are often integers in drops. One XRP equals one million drops. A raw value of 25000000 therefore represents 25 XRP. Issued tokens use an object that names the currency, issuer, and decimal value, so never apply the drops conversion to every amount you see.
| Explorer field | Question it answers | Common mistake |
|---|---|---|
| Amount | What was requested? | Treating it as the final receipt |
| delivered_amount | What reached the destination? | Ignoring payment metadata |
| Fee | How much XRP was destroyed? | Reading drops as whole XRP |
| DestinationTag | Which internal route was requested? | Assuming it changes the address |
Destination Tags Route Custodial Deposits
A destination tag is an optional unsigned integer carried separately from the classic address. Shared custodians use it to map one public deposit account to an internal customer. An X address can package a classic address and tag for compatible software, but the XRP Ledger transaction still resolves the destination and tag as distinct data.
A successful ledger payment does not guarantee a successful internal credit. If the correct shared address receives XRP with a missing or wrong tag, the on chain result may still be tesSUCCESS. The custodian then lacks reliable routing data. Preserve the hash, amount, time, sending account, intended tag, and withdrawal record, then contact the recipient through its official support channel. Never send another payment merely to “correct” the first, and never assume recovery is guaranteed.
Fee, Ledger Index, and Timestamp
The Fee field is denominated in drops of XRP and is destroyed, not paid to a validator. The official transaction cost documentation states that the current minimum for a standard transaction is usually 10 drops, or 0.00001 XRP, while network load and special transaction types can require more. Read the exact signed fee from the transaction instead of assuming every payment used the minimum.
The ledger index identifies the numbered ledger version containing the transaction. The close time places it in time. Together with the hash, these make the record easy to reproduce. A sequence number orders transactions from a sending account and helps prevent replay, but it is not the payment amount or a global transaction count.
Account Pages Need Context
An account explorer page normally shows the current XRP balance, sequence, owned objects, and transaction history. The balance is not always fully spendable because the ledger reserves some XRP for the account and objects it owns. Token balances usually live in trust lines rather than being part of the native XRP balance.
History also includes transactions that affected the account even when it was not the initiator. A transaction list should therefore be read by type, direction, result, and balance changes, not treated as a simple bank statement. An offer, trust line change, AMM action, NFT operation, or failed tec transaction can appear beside ordinary payments.
A Practical Support Checklist
When a transfer appears missing, collect evidence in this order:
- The real XRPL transaction hash, copied as text.
- A validated status and the metadata result code.
- The full sender and destination addresses.
- The metadata delivered amount and asset.
- The destination tag, if the recipient supplied one.
- The ledger index, close time, and sending platform withdrawal reference.
If there is no transaction hash, the delay is probably still inside the sending wallet or exchange. If the transaction is validated and successful but the platform balance is missing, the recipient needs to inspect its own scanner and internal accounting. The public ledger cannot reveal a private exchange queue, account freeze, compliance review, or database credit.
Frequently Asked Questions
How do I check whether an XRP transaction succeeded?
Search the hash on an XRP Ledger explorer. Confirm the record is from a validated ledger and its metadata result is tesSUCCESS. A submit response or wallet notification alone is not final proof.
What does validated mean on an XRP explorer?
It means the transaction and result are in a ledger version accepted by XRP Ledger consensus. Before validation, a provisional result can change.
Why does an XRP explorer show drops instead of XRP?
The protocol represents native XRP amounts as drops in many raw fields. One XRP equals 1,000,000 drops, so divide a drop amount by one million. Do not apply that conversion to issued token objects.
Can an XRP transaction succeed with the wrong destination tag?
Yes, unless the receiving account enforces tags. XRP can reach the shared address while the custodian cannot automatically assign it to the intended customer. Contact the recipient with the hash and evidence; recovery is not guaranteed.
Why is my XRP transaction hash not found?
The sender may not have broadcast it, the hash may be wrong, the explorer may lack that history, or the transaction may never have entered a validated ledger. “Not found” alone does not establish a final outcome.
From Verification to Productive XRP
An explorer gives you the truth layer: it proves where XRP moved, what arrived, and whether the result is final. It does not eliminate custody, liquidity, platform, market, or operational risk. Use that transparency before every meaningful transfer, start with a small test, and keep the hash until the receiving balance is reconciled.
Related Reading
xora.finance is where to put your XRP to work and earn up to 22% APY value instead of leaving it idle on an exchange. That headline is not a guaranteed 22% native XRP return: it combines 15% native XRP yield subsidised by the XORA treasury during bootstrap with estimated XORA reward value, and rates and reward value can change. Review the custody and yield source, then use the verified deposit address and tag shown in your account.