XRPL's 3,254-Transaction Ledger Shows Why Payment Capacity Needs More Than a Count

Direct answer: XRPL transaction inclusion is only the first capacity measure

XRP Ledger included 3,254 transactions in ledger 106,965,249 on September 13, but only 2,295 returned successful results. Our review of the validated record confirms the counts independently reported by CryptoSlate. For payment operators, the practical lesson is to measure completed work, fees and latency separately before translating a busy ledger into service capacity.

The event is material because it offers a real mainnet workload to examine, rather than a theoretical capacity claim. CryptoSlate revisited it on September 16 after earlier reporting described a record. This analysis uses the underlying transaction metadata to explain what an exchange, wallet or payment service could responsibly take from the observation. It does not certify an all-time maximum or convert the count into transactions per second.

Section sources[1][2][4][5]

The September 13 ledger separates recorded attempts from completed operations

Confirmed facts: the ledger records a close time of September 13 at 20:51:50 UTC. Ripple's two public JSON-RPC endpoints returned the same ledger hash and transaction metadata when checked for this article on September 16. XRPSCAN independently matched the header and 3,254 count. Sorting the expanded records by TransactionResult yields the results below, also reported by CryptoSlate.

The useful comparison is between inclusion and outcome. A validated ledger can preserve an unsuccessful operation as a final record. That does not mean validators failed to agree, that the network lost the instruction, or that the intended asset movement occurred. Treating every recorded transaction as a completed customer payment would combine operationally different events into one misleading total.

Analysis: an operator's capacity budget should name the work it promises to complete. A service that creates exchange offers needs a different acceptance measure from one sending direct XRP payments. Even successful protocol operations may serve different business purposes. The table is a description of this ledger, not a forecast of another application's success rate under load.

Section sources[2][3][4][10][12][14]

The one-drop pattern makes workload composition essential

The record contains 2,000 successful payments delivering one drop each, submitted by 20 accounts with 100 such payments per account. One drop is one-millionth of an XRP, so this particular group delivered 0.002 XRP in total. CryptoSlate corroborates those observations. The Crypto Basic's September 14 report attributes the throughput-testing interpretation to validator Vet.

Inference, not identification: the repeated arrangement is consistent with an automated test, but account-level repetition does not identify its operator or motivation. It also does not establish that every other transaction in the ledger was artificial. A more precise description is a concentrated group of tiny payments within a mixed transaction set. Calling the whole ledger synthetic goes beyond what those counts alone prove.

For a business evaluating XRPL, a useful next experiment would reproduce its actual instruction mix in a controlled environment. That means specifying the proportions of direct payments and more demanding exchange or cross-currency operations before declaring a target. Comparing two tests with different mixes risks attributing a workload difference to a network improvement. This is a proposed evaluation method, not a claim that such a comparative test has already been completed.

Section sources[2][4][5]

Unsuccessful exchange instructions require their own reconciliation

Among 458 OfferCreate transactions in the ledger, 440 returned non-success codes: 379 tecKILLED and 61 tecUNFUNDED_OFFER. These are included within the 959 unsuccessful results, not additional failures. The same breakdown appears in CryptoSlate's report. XRPL's code reference distinguishes an offer that cannot meet its execution conditions from an offer whose sender lacks the offered funds.

Those labels help operations teams ask the right questions. A conditional order can intentionally require an execution outcome that available liquidity does not support. Such a result is different from an unavailable network, and paying more in transaction fees does not automatically supply the missing funds or change the order's trading conditions. The observed totals do not establish a software defect, the submitters' motives, or how many independent trading decisions the instructions represent.

Analysis: reporting should separate protocol completion from the business objective. An exchange team could record whether an instruction reached a validated ledger, its final result, and the resulting order or balance changes. Those checks make a throughput report more useful to customers because they describe the service delivered. A large accepted set is encouraging evidence of processing, while successful commercial execution remains a separate question.

Section sources[2][4][10][12]

XRP fees measure submitted cost, not a universal capacity price

The Fee fields in this ledger sum to 111,136 drops, or 0.111136 XRP, matching CryptoSlate's independent tally. XRPL documentation explains that fees are destroyed rather than paid to validators, and included transactions with tec results still incur a charge. This fee total therefore covers the recorded workload, including unsuccessful operations; it is not the cost of 3,254 successful payments.

The network uses an adaptive open-ledger threshold. XRPL's transaction-cost documentation describes a soft transaction target and increasing admission cost once that target is reached. The transaction-queue documentation explains how eligible instructions can wait for a later ledger. The Crypto Basic independently reports the flexible target and the difference between simple and complex workloads.

Practical implication: a payment integration needs both a fee ceiling and a policy for waiting or escalating. A historical low aggregate cost cannot promise the fee available when a future customer submits. Equally, a higher signed fee should not be interpreted as a guarantee of a successful exchange or payment. Teams need to reconcile the final outcome before deciding whether an instruction needs correction, replacement or no further action.

Section sources[2][4][6][7][5][9]

Ledger timestamps do not establish a sustained speed guarantee

The header's close_time_resolution is 10 seconds. XRPL's close-time documentation explains that recorded close times are rounded and may be adjusted to remain later than a parent ledger's time. The implementation's consensus documentation also distinguishes initial close-time estimates from rounded times. Consequently, dividing one ledger's transaction count by a difference between header timestamps is not a reliable measurement of its actual processing duration.

Unresolved uncertainty: this record does not contain each customer's initial submission time, the time spent waiting before inclusion, or a sustained application benchmark. Those omissions matter to a merchant with a checkout deadline or a wallet handling an intermittent connection. A useful service test would measure the distribution of elapsed times from submission to verified result, including the slower cases, across many successive ledgers.

XRPL's reliable-submission guidance recommends tracking authoritative outcomes and bounding transaction validity with LastLedgerSequence. Analysis: the appropriate operational response is to retain an instruction's identity and reconcile it before creating a replacement. Otherwise a delayed confirmation can be mistaken for failure and lead to an unintended duplicate payment. A ledger capacity milestone is useful evidence, but it cannot substitute for that recovery discipline.

Section sources[2][3][8][13][9]

How readers can reproduce and use the evidence

Methodology: query the ledger method with ledger_index 106965249, transactions true and expand true. Check that validated is true, count the transactions, and group their metadata by TransactionResult. The cited Ripple endpoint requires a JSON-RPC POST request; the explorer and XRPSCAN header link provide browser-readable entry points. Preserve the ledger hash when comparing results so that every measurement refers to the same record.

For XRP holders, the observation confirms a substantial included workload and a measurable fee burn. It does not reveal net token purchases, prove a named institution used the network, or establish a price effect. For builders, it supplies a concrete example for designing reporting around success, waiting time and cost. The next useful milestone would pair another high-count observation with reproducible workload composition and end-to-end completion measurements.

Section sources[11][2][3][4][9]