XRP Ledger records 3,254 transactions in one ledger

The XRP Ledger has processed 3,254 transactions in one ledger, setting a reported single-ledger record on Sept. 14.

Validator operator Vet reported the figure after reviewing the ledger and said most entries were one-drop XRP payments. He described the activity as a possible throughput test, although the sender’s purpose has not been confirmed.

A drop is one-millionth of one XRP, making it the smallest unit recorded by the network. The high transaction count therefore represented many small transfers, not an unusually large amount of XRP moving between accounts.

The ledger index and initiating account were not identified in Vet’s public post. Without those details, the record claim relies on his analysis and cannot be compared through the post alone with every earlier ledger in XRPL history.

Tiny XRP payments dominated the record ledger

Most of the 3,254 transactions were simple payments carrying one drop of XRP, according to Vet. Simple native-asset transfers require less processing work than transactions involving decentralized exchange orders, NFTs or cross-currency payment paths.

“I don’t know why this person is doing these transactions, but it looks like throughput testing, probably,” Vet said. The description remains speculative because the account owner has not publicly explained the activity.

Transaction count does not show how much computational work a ledger required. A ledger containing thousands of direct XRP payments can place a different load on validators than one containing fewer trades, token operations or complex payment paths.

“Not all transactions are equal in load footprint,” Vet said. He estimated that 500 simple XRP payments could create less stress than 200 transactions that require extensive decentralized exchange processing.

Official XRPL documentation states that each validated ledger records the transactions applied to the preceding ledger state. The associated metadata provides the result and effects of each included transaction.

Transactions with a tesSUCCESS result completed their requested action. Entries carrying a tec result remain recorded and consume a fee, even when they fail to perform the requested operation. The reported total of 3,254 therefore describes included transactions, not necessarily 3,254 successful transfers.

XRP Ledger capacity uses an adaptive target

The XRP Ledger does not use one permanent transaction limit for every ledger. Its servers adjust operating conditions in response to transaction volume, network latency and consensus performance.

Vet said the network can raise its soft transaction target when a heavily loaded ledger closes within the expected period. When close times move beyond the preferred range, the network can reduce the target to help validators return to normal timing.

XRPL documentation says servers exchange proposals until trusted validators agree on a transaction set. Each server then calculates the new ledger state and distributes a signed validation containing the resulting ledger hash.

A supermajority of trusted validators must agree on the same hash before the ledger becomes validated. Once validated, its transactions and resulting state become final parts of XRPL’s ledger history.

The 3,254-transaction result consequently provides evidence that validators agreed on a ledger carrying that number of entries. It does not establish a new permanent throughput rate, because sustained capacity depends on transaction complexity, hardware, network conditions and consecutive ledger close times.

Throughput measured from one ledger differs from transactions per second over an extended period. A short burst can place many pending payments into a single ledger, while the following ledgers may return to normal activity.

No performance report from Ripple, the XRP Ledger Foundation or the network’s reference software maintainers had confirmed a permanent capacity change following the record. No service interruption or failed consensus round was reported in connection with the burst.

Recent activity has included heavier payments and trading

The record occurred after a period of increased XRPL payment and trading activity. In related coverage, XRP Ledger order-book volume rose 79% year over year during the second quarter of 2026, according to an Evernorth report.

Average daily order-book volume reached 3.57 million XRP during the quarter, while the number of daily traders fell from 1,864 to 1,111. Evernorth said average volume per trading account nearly tripled during the same comparison period.

Stablecoin transfers have created another source of network use. As crypto.news reported, RLUSD generated approximately $9 billion in first-half transfer volume on XRPL during 2026.

Such activity is separate from the one-drop transfers identified in the record ledger. No evidence cited by Vet connected the 3,254 transactions to RLUSD, institutional settlement, exchange trading or customer payments.

The sender could have been testing transaction submission, ledger packing or another technical process. The available account pattern does not confirm whether the activity came from a developer, institution, automated service or individual user.

BatchV1_1 moves through the amendment process

The record arrived while validators were considering protocol features introduced with version 3.3.0 of rippled, the network’s reference server software. The XRP Ledger Foundation released version 3.3.0 on Aug. 6.

Its proposed features include BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1 and Sponsor. Each feature follows the XRPL amendment process before it can become active across the main network.

BatchV1_1 would allow multiple transactions to be bundled and processed together. Official XRPL records say it replaces the earlier Batch amendment after developers found a critical bug in the original implementation.

The feature does not explain the 3,254-transaction ledger because BatchV1_1 had not completed mainnet activation when the activity occurred. Its presence in the server release means validators can review and vote on the amendment.

XRPL’s amendment rules require more than 80% support from trusted validators for two continuous weeks. If support falls to 80% or lower before the period ends, the countdown resets.

ConfidentialTransfer would introduce shielded balances and transfer amounts for Multi-Purpose Tokens while providing viewing mechanisms for authorized parties. DynamicMPT would permit issuers to change selected token settings unless they make those properties permanently immutable.

PermissionDelegationV1_1 replaces an earlier delegation feature that developers disabled after finding a critical bug. The updated amendment would let XRPL accounts assign limited permissions to other accounts after validator approval.

No activation date is guaranteed for amendments still under voting. Validator operators can change their votes, and the network checks amendment support around flag ledgers, which occur approximately every 15 minutes.