XRPL Explorer Guide: How to Read Transaction Data

Most XRP holders never look at the blockchain itself—they trust exchanges, wallets, and third-party platforms to tell them what's happening with their assets. But here's the problem: without understanding how to read transaction data directly from the XRP Ledger, you're flying blind.

The XRPL Explorer isn't just a nice-to-have tool for developers—it's essential infrastructure for anyone who wants to verify transactions, troubleshoot failed payments, or understand what's actually happening with their XRP. And unlike Bitcoin or Ethereum, where transaction data can take 10-60 minutes to settle, XRPL transactions finalize in 3-5 seconds, meaning you need to know how to read this data quickly and accurately.

Understanding XRPL Transaction Anatomy

Every XRPL transaction—whether it's a simple XRP payment or a complex cross-currency exchange—contains roughly 15-25 standard fields that define what happens on the ledger. Unlike Ethereum's gas-based model or Bitcoin's UTXO system, XRPL uses an account-based ledger where every transaction explicitly states the sender, receiver, amount, and execution parameters in a structured JSON format.

The three most critical fields you'll encounter are Account (the sender), Destination (the receiver), and Amount (what's being transferred). But here's where it gets interesting—the Amount field behaves differently depending on whether you're sending XRP or an issued currency. For XRP, it's expressed in drops (1 XRP = 1,000,000 drops), while issued currencies use a combination of value, currency code, and issuer address. This distinction matters because it directly affects how you interpret transaction success or failure.

Transaction fees on XRPL are measured in drops and typically range from 10-20 drops (0.00001-0.00002 XRP) under normal conditions. However, during network stress—like the December 2017 period when XRPL processed 50,000+ transactions per ledger—fees can escalate based on the open ledger fee mechanism. The Fee field shows exactly what you paid, and comparing it against the network's median fee tells you whether your transaction was prioritized or delayed.

The Sequence number acts as a transaction counter for each account, starting at 1 and incrementing with every transaction. This isn't just bookkeeping—it's a critical security feature that prevents replay attacks and ensures transactions execute in order. If you see a sequence gap in an account's history, it means transactions were either unsuccessful or the account holder deliberately created that gap using the AccountSet transaction type.

Unlike some blockchains where transaction IDs can change due to malleability issues, XRPL hashes are immutable from the moment they're validated.

Every successful transaction generates a unique hash—a 64-character hexadecimal identifier like E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7. This hash serves as your permanent receipt and can be searched across any XRPL explorer to retrieve full transaction details. Unlike some blockchains where transaction IDs can change due to malleability issues, XRPL hashes are immutable from the moment they're validated.

How to Navigate Bithomp and XRPScan Explorers

Two explorers dominate XRPL transaction analysis: Bithomp (bithomp.com) and XRPScan (xrpscan.com). While both pull data from the same underlying ledger, they present information with different emphases—Bithomp excels at account-level analytics and historical tracking, while XRPScan offers superior real-time monitoring and network statistics.

Start by entering either an account address (rXXXXXXX format, 25-35 characters) or a transaction hash into the search bar. For addresses beginning with 'r', both explorers will display the account overview page showing current XRP balance, account reserve (10 XRP base + 2 XRP per object), transaction count, and recent activity. The account reserve is particularly important—it represents the minimum XRP balance that must remain locked in the account, and you'll see this reflected in the OwnerCount field multiplied by 2 XRP.

Transaction detail pages reveal the complete anatomy of any on-ledger action. Bithomp organizes this data into collapsible sections: Transaction Details, Affected Accounts, and Raw JSON. The Raw JSON view is where you'll find everything—every field, flag, and parameter exactly as it exists on the ledger. This is essential for debugging because consumer wallets and exchanges often hide or simplify complex fields like Paths, SendMax, or DeliverMin.

XRPScan's network statistics page provides real-time context that's missing from Bithomp. You'll see current ledger close time (typically 3-4 seconds), transaction throughput (averaging 1,500-3,000 transactions per ledger), and fee escalation data. During the 2021 NFT minting surge, XRPScan showed ledgers closing with 7,000+ transactions and median fees jumping to 50-100 drops—information that explained why some users experienced delays.

Both explorers support advanced search filters for transaction types, date ranges, and result codes. If you're investigating why an exchange deposit didn't credit, filter for Payment transactions to your deposit address within the last 24 hours, then check for DestinationTag matches. This targeted approach beats scrolling through hundreds of transactions manually, especially for high-volume accounts processing 500+ transactions daily.

The account "Trust Lines" tab—visible on both explorers—shows which issued currencies an account has explicitly enabled. Remember, XRPL requires opt-in for all non-XRP assets through TrustSet transactions. If someone claims they sent you USD-backed stablecoins but you see zero trust lines, the transaction either failed or they're mistaken—the ledger doesn't lie.

Reading Payment Transaction Fields

Payment transactions represent 60-70% of all XRPL activity, making them the most important transaction type to master. The basic structure includes Account, Destination, Amount, Fee, Sequence, and DestinationTag, but the devil lives in the details—especially when dealing with partial payments or cross-currency exchanges.

The Amount field uses different formats for XRP versus issued currencies. XRP amounts appear as strings of drops: "Amount": "25000000" represents 25 XRP (25 × 1,000,000 drops). Issued currencies use object notation: "Amount": {"value": "100", "currency": "USD", "issuer": "rN7n7otQDd6FczFgLdlqtyMVrn3HMxZxZZ"}. This three-part specification tells you exactly which asset from which issuer—critical for distinguishing between multiple USD issuers on XRPL.

Destination tags are 32-bit unsigned integers (0 to 4,294,967,295) that exchanges and hosted wallets use for internal routing. When you deposit XRP to Coinbase, Bitstamp, or Uphold, they provide a shared deposit address plus a unique destination tag. Missing this tag means your XRP reaches the exchange's master wallet but can't be credited to your account—requiring manual intervention and potentially 1-2 week delays. Always verify the DestinationTag field matches what the exchange provided, character for character.

The SendMax field appears in cross-currency payments and represents the maximum amount the sender is willing to give up to achieve the desired Amount delivery. If you see "SendMax": "110" with "Amount": "100", the sender allowed up to 10% slippage. The actual amount delivered appears in the transaction metadata under delivered_amount—and here's where partial payments become dangerous.

Partial payments carry the tfPartialPayment flag (hex value 0x00020000 or decimal 131072) in the Flags field. This flag allows transactions to succeed even when delivering less than the stated Amount. Imagine an explorer shows "Amount": "1000 USD" but the delivered_amount in metadata shows only "500 USD"—the transaction succeeded, but only half the expected value arrived. Exchanges have lost millions to partial payment exploits where attackers deposit small amounts while the Amount field claims large values.

Transaction metadata—found under meta or metaData in the raw JSON—contains the actual results of a transaction's execution. The TransactionResult field uses standardized codes: tesSUCCESS means full execution, while codes beginning with tec (like tecUNFUNDED_PAYMENT) indicate the transaction failed but still consumed the fee. The delivered_amount field in metadata always shows the truth for payments, regardless of what the Amount field claims.

Interpreting Transaction Results and Codes

XRPL uses a three-tier result code system that determines whether transactions succeed, fail with fee consumption, or fail without touching the ledger. Understanding these codes prevents misinterpretation—especially when troubleshooting why payments didn't arrive or offers didn't execute.

tesSUCCESS codes (those starting with tes) indicate complete success. The most common is tesSUCCESS, which means the transaction executed exactly as intended. For payments, this confirms the full Amount reached the Destination. For offers, it means the trade executed at the specified exchange rate. You'll see tesSUCCESS on roughly 85-90% of transactions under normal network conditions.

tec codes (Claimed Fee) represent transactions that technically succeeded in one sense—they made it into a validated ledger and consumed the transaction fee—but failed to achieve their intended purpose. tecUNFUNDED_PAYMENT appears when the sender lacks sufficient XRP or the specified currency to complete the payment. tecNO_DST_INSUF_XRP means the destination account doesn't exist and the payment amount was insufficient to create it (currently requires 10 XRP minimum). These failures still cost you the transaction fee, typically 10-12 drops.

The tecDST_TAG_NEEDED code catches many users by surprise. It appears when sending to an address that requires a destination tag (set via the asfRequireDest flag on AccountSet transactions) but none was provided. Major exchanges enable this flag to prevent tagless deposits—your XRP leaves your wallet, consumes the fee, but bounces back without reaching the intended destination.

tem, tef, and ter codes indicate transaction rejection before inclusion in a validated ledger—meaning no fee is charged. temBAD_FEE appears when the offered fee is too low relative to the open ledger fee. tefPAST_SEQ means you're trying to submit a transaction with a sequence number already used. terQUEUED tells you the transaction entered the queue system (used when the network is congested) but hasn't executed yet.

Result codes become especially important when investigating cross-currency payments through the decentralized exchange. If you see tecPATH_DRY, it means no liquidity path existed between the sending and receiving currencies at the time of execution. The Paths field in the original transaction shows the intended route through offers and liquidity pools—comparing this against the order book at that ledger index reveals whether liquidity evaporated between transaction submission and execution.

Transaction metadata includes AffectedNodes—a detailed log of every ledger entry modified by the transaction. This shows balance changes, trust line adjustments, offer creation or consumption, and reserve calculations. When debugging failed payments, scan AffectedNodes for ModifiedNode entries showing PreviousFields and FinalFields—these reveal exactly what changed (or didn't change) at the ledger level.

Advanced Fields: Memos, Paths, and Flags

Beyond basic payment fields, XRPL transactions support sophisticated features through memos, paths, and flags—capabilities that separate simple transfers from programmable value movement.

Memos allow arbitrary data attachment to any transaction via three optional subfields: MemoType, MemoData, and MemoFormat. All three must be hex-encoded, even if the underlying data is plain text. If you see "MemoData": "68747470733A2F2F6578616D706C652E636F6D2F696E766F696365", decode it from hex to reveal https://example.com/invoice. Memos are limited to 1KB per transaction but can encode invoice numbers, message content, or API callback URLs. They're particularly common in remittance flows where payment metadata matters for reconciliation.

Payment paths enable the XRPL's automatic cross-currency exchange functionality. The Paths field contains arrays of arrays—each inner array represents one possible route through the order book and liquidity pools. A path might show XRP → USD → EUR, automatically executing the necessary trades to deliver the desired currency. Path finding happens client-side before submission, meaning what you see in the explorer represents the path the sender's software calculated, not necessarily the optimal path available.

The SendMax and DeliverMin fields work together in cross-currency payments to define acceptable slippage bounds. SendMax caps the sender's loss, while DeliverMin (when present) ensures the receiver gets at least a minimum amount. If market conditions shift between submission and execution—say, a large offer consumes available liquidity—the transaction might fail with tecPATH_DRY rather than executing at an unfavorable rate.

Transaction flags modify behavior in powerful ways. The most important for payments are tfPartialPayment (allows underfunded deliveries), tfNoDirectRipple (requires currency exchange even when direct trust lines exist), and tfLimitQuality (prevents execution below a certain exchange rate quality). These flags appear as hex values in the Flags field—you'll need to decode them or check the explorer's parsed interpretation.

For offers (order book transactions), flags determine execution behavior. tfFillOrKill means "execute completely or cancel immediately"—no partial fills allowed. tfImmediateOrCancel allows partial execution but cancels any unfilled portion rather than leaving it on the order book. These flags let sophisticated traders control exactly how their orders interact with existing liquidity, which you can verify post-execution in the transaction metadata.

The SourceTag field mirrors DestinationTag but for the sending side. Some platforms use source tags for internal accounting—tracking which user or service initiated a transaction from a shared hot wallet. While less common than destination tags, they serve the same routing purpose and appear in identical format (32-bit unsigned integers).

Common Troubleshooting Scenarios

When transactions don't behave as expected, the XRPL explorer becomes your primary diagnostic tool. Here's how to investigate the most frequent issues.

Scenario 1: Exchange deposit not credited. Search for the transaction hash provided by your sending wallet. Verify three things: (1) TransactionResult shows tesSUCCESS, (2) Destination matches the exchange's deposit address exactly, and (3) DestinationTag matches the tag the exchange provided. If the destination tag is missing or incorrect, contact exchange support with the transaction hash—they can manually credit your account but typically take 1-2 weeks. If the transaction shows tecDST_TAG_NEEDED, your XRP bounced back to the sending address minus the fee.

Scenario 2: Payment shows success but wrong amount arrived. Check for tfPartialPayment flag in the Flags field. If present, compare the Amount field (claimed delivery) against delivered_amount in metadata (actual delivery). The difference represents either insufficient sender funds or path slippage in cross-currency payments. For pure XRP payments with partial payment flags, this usually indicates the sender's balance was insufficient to cover both the stated amount and the transaction fee.

Scenario 3: Transaction stuck or not appearing. First, verify the transaction hash is correct—mistyped characters produce "transaction not found" errors. Second, check if the transaction was submitted to the network at all by searching the sending account's recent history. If it appears with a ter code like terQUEUED, the network held it due to congestion—these usually process within 5-10 ledgers (20-40 seconds). If the transaction simply doesn't exist, the sending wallet may have failed to broadcast it, possibly due to connectivity issues or sequence number conflicts.

Scenario 4: Understanding fee consumption on failed transactions. Any transaction showing a tec result code consumed the fee despite failing. Locate the Fee field (typically 10-12 drops) and check the sending account's balance before and after using the AffectedNodes section. The fee reduces the sending account's XRP balance—it's not refundable. If you're seeing multiple failed transactions with mounting fee costs, pause and investigate the root cause (usually insufficient balance, wrong destination tag requirement, or bad trust line configuration) before resubmitting.

Scenario 5: Cross-currency payment executed at unexpected rate. Examine the Paths field to understand the intended route, then check the AffectedNodes section for ModifiedNode entries of type Offer. Each consumed offer shows PreviousFields and FinalFields—the difference reveals how much of each offer was used at what exchange rate. If the rate differs significantly from your expectations, compare the transaction timestamp against historical order book snapshots (available on XRPScan's DEX tab) to confirm market conditions at execution time.

Scenario 6: Account appears frozen or unable to send. Check the account's XRP balance against its reserve requirement. The explorer shows current balance and owner count—multiply owner count by 2 and add 10 for the base reserve. If available balance minus reserve is less than the transaction amount plus fee, the transaction will fail with tecUNFUNDED_PAYMENT. You'll need to either reduce the payment amount or remove trust lines (each trust line removal frees 2 XRP from reserve) to liberate locked funds.

The Bottom Line

Reading XRPL transaction data transforms you from passive recipient to informed participant—you're no longer dependent on third-party interpretations of what happened with your assets.